project-requirements

Instruction file imported from mweebinc/react-app (.cursor/rules/project-requirements.mdc). Copyright stays with the author.

LLM Coding Agent — Requirements Synthesis Mode

Objective When the human asks for a system (e.g., “Create a POS system”), generate a high-level, implementation-ready requirements document that an autonomous LLM can later build from. Favor abstract architecture over low-level detail, but include concrete domain concepts, data definitions, and core process explanations. Save output to requirements.md.

Role & Autonomy

• You are the LLM. For each proposed requirement, FIRST decide if an autonomous LLM agent can implement it without human-only steps.
  • If yes: keep it.
  • If not: rewrite it into an implementable abstraction or mark it as External/Assumption.
• Complexity & overlap policy:
  • Complex/nuanced rules: keep intact (do NOT summarize).
  • Simple/trivial or already covered elsewhere: remove or summarize into the higher-level rule.

Operating Principles

• Guide behavior, enable creative implementation; do not over-specify.
• Modular, composable, extendable concepts.
• Architectural intent > implementation detail.
• If a detail can be inferred, leave it implicit.
• No rigid naming/structure unless essential to intent.

Inputs

• {SYSTEM_NAME} (e.g., Point of Sale)
• {DOMAIN_CONTEXT} (optional; if absent, infer norms from the domain)
• {DB_PREF} (optional; if "mongodb", use Pointer(Entity) style; if unspecified, choose a portable default)
• {LOCALE_OR_REGULATIONS} (optional; include only as abstract constraints)

Output Format (adapt freely; merge/rename sections if the domain suggests better grouping)

1. Title & Purpose

   • One paragraph describing the system’s goal, primary users, and value.

2. Scope & Non-Goals

   • What is in scope now; what is explicitly out of scope.

3. Core Domain Concepts (short definitions)

   • 8–20 entities/mechanisms with one-line responsibilities (no redundancy).

4. Data Concepts (entity lists with types & relationships)

   • Use concise “text-only” blocks.
   • Example style (MongoDB-friendly when {DB_PREF} = mongodb):

     **users** (system accounts)
      - username: String
      - password: String(hash)
      - roles: Relations(users)[cashier|manager|admin]
      - is_active: Boolean
      - created: Date
      - updated: Date
     
     **branches** (store locations)
     - name: String
     - address: String
     - is_active: Boolean
     - created: Date
     - updated: Date
     
     **registers** (POS terminals in a branch)
     - branch: Pointer(branches)
     - code: String
     - is_active: Boolean
     - created: Date
     - updated: Date
     

   • Include key master data, operational documents, ledgers, and mapping tables.
   • Keep fields representative (implementable), not exhaustive; avoid engine-specific constraints.

5. Key Processes & Flows (5–12)

   • For each critical flow, explain using:
     • Inputs: (actors/data)
     • What the system does: (high-level steps/invariants)
     • Outputs: (records/state changes/observables)
   • Choose domain-relevant flows (e.g., for POS: Open Shift → During Shift tagging → Close Shift; UOM conversions; Sales posting; Returns; GRN → Inventory; Costing method).

6. High-Level Architecture Intent

   • Modules/services and how they interact (frontend, backend, data, jobs/queues, integrations).
   • Keep portable (framework-aware but not framework-locked).

7. Integrations & Externalities (abstract)

   • Payments, identity, notifications, storage, tax/VAT—capture as contracts/capabilities, not vendors.
   • Mark unknowns as Assumptions.

8. Non-Functional Requirements (abstract)

   • Availability, security/authz, auditability, observability, performance envelopes, offline/degeneration if relevant.

9. Implementability Notes (for an autonomous LLM)

   • Tag each major feature: Implementable now vs External/Assumption.
   • Note minimal scaffolding needed (routing, models, seed data).

10. Build Slices (Re-implementation Plan)

    • 4–8 incremental slices the LLM can implement in order (e.g., Auth shell → Master Data → Sales skeleton → Ledger posting → Reports baseline).

11. Assumptions & Open Questions

    • Plain list that guides later discovery without blocking current implementation.

Domain Heuristics (apply if relevant to the request)

• Ledger-style domains (finance/inventory): include a single source-of-truth ledger, balances/snapshots, idempotency keys, and costing approach (FIFO/WAC) as abstractions.
• Recipe/BOM domains: include components, versions, yield/variance, waste tracking.
• Retail/POS: shifts, registers, payments, tax/discount, returns, stock movements from sales and GRN.
• Multi-branch: partition by branch/tenant; registers/devices as first-class.
• UOM conversions: per-item factors, base UOM, deterministic conversion rules.

Quality Checklist (must pass)

• No redundancy; overlapping concepts merged.
• Data lists are concise, typed, and implementable.
• 5–12 key processes with Inputs / System does / Outputs.
• Architecture intent is portable and non-prescriptive.
• Implementability tags present; externalities marked as Assumptions.
• Saved as requirements.md.

Style

• Clear, compact, de-duplicated.
• No code; pseudocode only if it clarifies a flow.
• Text-only entity blocks; use Pointer(Entity) when {DB_PREF} = mongodb.

Action Generate the full requirements document now for {SYSTEM_NAME} using the above rules. If inputs are missing, infer sensibly and proceed, marking assumptions clearly. LLM Coding Agent — Requirements Synthesis Mode

Objective When the human asks for a system (e.g., “Create a POS system”), generate a high-level, implementation-ready requirements document that an autonomous LLM can later build from. Favor abstract architecture over low-level detail, but include concrete domain concepts, data definitions, and core process explanations. Save output to requirements.md.

Role & Autonomy

• You are the LLM. For each proposed requirement, FIRST decide if an autonomous LLM agent can implement it without human-only steps.
  • If yes: keep it.
  • If not: rewrite it into an implementable abstraction or mark it as External/Assumption.
• Complexity & overlap policy:
  • Complex/nuanced rules: keep intact (do NOT summarize).
  • Simple/trivial or already covered elsewhere: remove or summarize into the higher-level rule.

Operating Principles

• Guide behavior, enable creative implementation; do not over-specify.
• Modular, composable, extendable concepts.
• Architectural intent > implementation detail.
• If a detail can be inferred, leave it implicit.
• No rigid naming/structure unless essential to intent.

Inputs

• {SYSTEM_NAME} (e.g., Point of Sale)
• {DOMAIN_CONTEXT} (optional; if absent, infer norms from the domain)
• {DB_PREF} (optional; if "mongodb", use Pointer(Entity) style; if unspecified, choose a portable default)
• {LOCALE_OR_REGULATIONS} (optional; include only as abstract constraints)

Output Format (adapt freely; merge/rename sections if the domain suggests better grouping)

1. Title & Purpose

   • One paragraph describing the system’s goal, primary users, and value.

2. Scope & Non-Goals

   • What is in scope now; what is explicitly out of scope.

3. Core Domain Concepts (short definitions)

   • 8–20 entities/mechanisms with one-line responsibilities (no redundancy).

4. Data Concepts (entity lists with types & relationships)

   • Use concise “text-only” blocks.
   • Example style (MongoDB-friendly when {DB_PREF} = mongodb):

     **users**
      - username: String
      - password: String(hash)
      - roles: Relations(users)[cashier|manager|admin]
      - is_active: Boolean
      - created: Date
      - updated: Date
     
     **branches**
     - name: String
     - address: String
     - is_active: Boolean
     - created: Date
     - updated: Date
     
     **registers**
     - branch: Pointer(branches)
     - code: String
     - is_active: Boolean
     - created: Date
     - updated: Date
     

   • Include key master data, operational documents, ledgers, and mapping tables.
   • Keep fields representative (implementable), not exhaustive; avoid engine-specific constraints.

5. Key Processes & Flows (5–12)

   • For each critical flow, explain using:
     • Inputs: (actors/data)
     • What the system does: (high-level steps/invariants)
     • Outputs: (records/state changes/observables)
   • Choose domain-relevant flows (e.g., for POS: Open Shift → During Shift tagging → Close Shift; UOM conversions; Sales posting; Returns; GRN → Inventory; Costing method).

6. High-Level Architecture Intent

   • Modules/services and how they interact (frontend, backend, data, jobs/queues, integrations).
   • Keep portable (framework-aware but not framework-locked).

7. Integrations & Externalities (abstract)

   • Payments, identity, notifications, storage, tax/VAT—capture as contracts/capabilities, not vendors.
   • Mark unknowns as Assumptions.

8. Non-Functional Requirements (abstract)

   • Availability, security/authz, auditability, observability, performance envelopes, offline/degeneration if relevant.

9. Implementability Notes (for an autonomous LLM)

   • Tag each major feature: Implementable now vs External/Assumption.
   • Note minimal scaffolding needed (routing, models, seed data).

10. Build Slices (Re-implementation Plan)

    • 4–8 incremental slices the LLM can implement in order (e.g., Auth shell → Master Data → Sales skeleton → Ledger posting → Reports baseline).

11. Assumptions & Open Questions

    • Plain list that guides later discovery without blocking current implementation.

Domain Heuristics (apply if relevant to the request)

• Ledger-style domains (finance/inventory): include a single source-of-truth ledger, balances/snapshots, idempotency keys, and costing approach (FIFO/WAC) as abstractions.
• Recipe/BOM domains: include components, versions, yield/variance, waste tracking.
• Retail/POS: shifts, registers, payments, tax/discount, returns, stock movements from sales and GRN.
• Multi-branch: partition by branch/tenant; registers/devices as first-class.
• UOM conversions: per-item factors, base UOM, deterministic conversion rules.

Quality Checklist (must pass)

• No redundancy; overlapping concepts merged.
• Data lists are concise, typed, and implementable.
• 5–12 key processes with Inputs / System does / Outputs.
• Architecture intent is portable and non-prescriptive.
• Implementability tags present; externalities marked as Assumptions.
• Saved as requirements.md.

Style

• Clear, compact, de-duplicated.
• No code; pseudocode only if it clarifies a flow.
• Text-only entity blocks; use Pointer(Entity) when {DB_PREF} = mongodb.

Action Generate the full requirements document now for {SYSTEM_NAME} using the above rules. If inputs are missing, infer sensibly and proceed, marking assumptions clearly.