Yareta User & Operational Documentation
How people use, operate, support, and maintain the Yareta platform. This site covers the User & Operational Documentation category only.
Technical & architecture documentation (system architecture, API/DB docs, Mermaid architecture/ER/UML/data-flow diagrams, implementation notes, chat-sparkle-vision docs, known code-vs-doc gaps) lives in the sibling repo yareta-technical-documentation, not here.
It was generated from a source-code audit in August 2026 — every claim is grounded in the actual codebase, not generic boilerplate.
Documents
| Document | Covers |
|---|---|
| Quickstart | Sign up → add your first deal → see your first score, in six steps |
| User Guide | How end users use the application |
| Glossary | Every product term (DNA Score, Traffic Light, Competency DNA, and so on) in one place |
| Integrations Setup Guide | Connector-by-connector setup steps (Airtable, HubSpot, Fireflies, and the rest) |
| Admin Guide | Admin console functionality and configuration |
| Operations Runbook | What to do when something goes wrong |
| Deployment / Release Runbook | Step-by-step release and rollback process |
| Incident Response Guide | Handling production incidents |
| Troubleshooting Guide | Common issues and how to resolve them |
| Support / FAQ | Common user/support questions |
| Onboarding Guide | How a new developer/operator gets started |
| Maintenance Guide | Routine maintenance, upgrades, cleanup, rotations |
| Business Continuity Plan | How the business/service continues during major failures |
| Security & Privacy Overview | Customer-facing security/privacy draft — needs legal review before external use |
The Five Things Worth Knowing Before You Read Anything Else
- The GraphQL endpoint is
POST /api, not/api/graphql— a common mistake, including in this repo’s ownspectaql.yml. schema.graphqlis stale. Several live modules aren’t in the checked-in file. Regenerate viascripts/generate-schema.tsbefore trusting generated API docs.- Editing a prompt in code doesn’t change production behavior until it’s synced to the
system_promptsdatabase table. This has caused at least one real production incident. - Two deployable units, one shared database. The Next.js app (Cloudflare Pages) and the background job worker (a separate Cloudflare Worker) deploy independently but read/write the same D1 database per environment.
- Migration filenames collide. 24 numeric migration prefixes have more than one
.sqlfile on disk. Check the current highest number before generating a new migration, and never renumber the existing ones.
For the fuller, code-cited list of known drift and security-relevant gaps (including several not covered above — GraphQL auth surface, OTP bypass mechanism, Lovable scoring-constraint violations), see yareta-technical-documentation/technical-docs/KNOWN-GAPS.md in the sibling repo.
Known Documentation Gaps
Two things this audit identified but deliberately did not fabricate content for, rather than publishing something misleading:
- No changelog / release notes. There’s no version history or “what’s new” page for end users, and no changelog data in the codebase to source one from. If this is wanted, it needs a process going forward (e.g. a short entry per customer-visible release) rather than a backfilled one.
- The Security & Privacy Overview above is a first draft, not an approved policy — it’s flagged as such at the top of that document. It should not be sent to a customer or used in a security questionnaire until someone who owns that function has reviewed it.
Maintaining This Documentation
Treat staleness here as a demonstrated, recurring risk, not a hypothetical one. When you make an operationally significant change, update the relevant file in the same PR. See the Maintenance Guide’s documentation-currency section.