Spec — Car Fleet¶
The spec is where you define the feature before any code is written. Time spent here is time saved in every step that follows.
Set up the branch¶
Create your feature branch by simply asking the agent:
Run the spec prompt¶
Read AGENTS.md, specs/tech-design.md, and specs/roadmap.md.
We are starting Feature 1 — Fleet register (roadmap row 1).
Create a feature spec in specs/YYYY-MM-DD-fleet-register/ (use today's date):
- requirements.md — what this feature must do; what it explicitly does NOT include
- plan.md — the AL objects, field names, and pages; no new tables, no new documents
- acceptance.md — testable scenarios that define done
Follow specs/tech-design.md §1.3 exactly.
Do not write any AL code yet.
Review the spec¶
Read all three files before moving on.
requirements.md — are all vehicle fields from the brief covered? Is the scope clearly bounded — no bookings, no pricing, no wizards in this spec?
plan.md — does the plan match tech-design.md §1.3? Check:
- Type = Non-Inventory on Item
- Base Unit of Measure = DAY
- tableextension on Item (not a new table)
- pageextension on Item Card with a Vehicle group
- Standard Document Attachments FactBox — no custom attachment logic
acceptance.md — can every scenario be run against the live app? Vague scenarios like "fields look correct" are not testable. Push back on anything you can't verify by clicking through BC.
If anything is off, ask the agent to fix it now — before any code exists.
Don't oversteer
Give the agent the constraints from tech-design.md, but let it decide field names, captions, and layout order. Those are low-stakes. Save your interventions for structural issues.