Vrida — Project Orientation

Vrida is a multi-tenant SaaS ERP/POS for US retail plant nurseries (vertical-neutral core), built by CodeCraft Solutions LLC. This file orients a session fast. For where docs live and current status, see DOCS_INDEX.md.

How this project works

• v2 is a fresh, AI-native redesign. The v1 docs (the 13 specs in docs/modules/, and prior schema docs) are SUPERSEDED reference/templates — proven patterns, not confirmed v2 design.
• Modules are built one at a time, end-to-end, through a fixed pipeline. A module is fully proven (designed, locked, built, tested, shipped) before the next begins.
• Inventory is module #1 — it is the process prototype; running it confirms the pipeline and the per-module doc templates.

The module pipeline (in docs/process/runbooks/)

Every module runs the same three runbooks:

• module-design.md — four parts, in order:
  • Part A — Features + gaps (what the module must do)
  • Part B — AI-plane application (which AI capabilities, authority, ON/OFF, state needed)
  • Part C — Schema design + audit (tables supporting A + B)
  • Part D — Lock gate → DESIGN-LOCK (verifies completeness, docs updated, seams hold, counts reconcile)
• smoke-test.md — E2E, AI-OFF acceptance, RLS cross-tenant leak; run repeatedly.
• ship.md — ship gate: UI live, smoke green, regression.

Two gates, one hard lock

• Parts A–C are committed-but-revisable checkpoints.
• Part D (DESIGN-LOCK) and Ship are the gates. Features, AI plane, and schema freeze together at Part D.

Core rules

• Single source of truth for counts/status: DOCS_INDEX.md. No other doc (including this one) restates counts.
• READMEs describe purpose/rules, never live contents/counts.
• AI is first-class and applied before schema (AI state drives table design).
• Every module must work fully with AI OFF (graceful degradation).
• Before implementing: give a concise overview and wait for go-ahead.
• CC tasks are given as explicit instructions.
• After ANY change to docs (.md files), rebuild the HTML viewer by running node tools/build-docs.js. The .md files are the source of truth; docs-html/ is the readable, navigable view derived from them. Folder descriptions and file counts must be DERIVED from the filesystem at build time, never hardcoded, so they never drift. This rebuild is part of completing any doc-writing task — not a separate step to remember.

Folder map

See DOCS_INDEX.md for the full file map. Top level: docs/ai, docs/architecture, docs/database, docs/modules, docs/decisions, docs/business-requirements, docs/process (+ runbooks).

Current focus

Building the process layer (docs/process). Folder skeleton complete. Next: requirements gathering (Part A input) and writing the Module Design Runbook content. No module designed yet.