Delivery model
How autograph organizes work: filesystem-based tracking, reactive environments, and specialization-driven ticket design.
The filesystem is the tracker
In autograph, the status of any unit of work (epic or ticket) is determined by where the file lives in the directory tree. There is no database, no external tool, no metadata field to keep in sync. Moving a ticket from 0_todo/ to 1_in_progress/ changes its status.
This approach survives across agent sessions (no conversational context needed), is human-readable (browse the directory), and is Git-friendly (status changes are visible in diffs).
delivery/
├── DELIVERY_CONTEXT.md # Project-specific conventions
├── 01_draft/ # Ideas, not yet actionable
│ └── Exx-some-idea/
├── 02_todo/ # Ready to start, tickets written
│ └── E05-some-feature/
│ ├── EPIC.md
│ ├── 0_todo/
│ │ ├── T01-behavior.md
│ │ └── T02-architecture.md
│ └── refs/
├── 03_in_progress/ # Currently being worked
│ └── E04-active-epic/
│ ├── EPIC.md
│ ├── 0_todo/
│ ├── 1_in_progress/
│ │ └── T03-quality.md
│ └── 2_done/
│ ├── T01-behavior.md
│ └── T02-architecture.md
└── 04_done/ # Completed and validated
└── E01-foundation/Two levels of tracking
Epics
A phase, a feature, a spike. Its status is expressed by which top-level directory it lives in (01_draft/, 02_todo/, etc.). Contains an EPIC.md with objectives, completion criteria, and a decisions/deviations log.
Tickets
An individual deliverable within an epic. Its status is expressed by which subdirectory it lives in (0_todo/, 1_in_progress/, 2_done/). Written before execution and never modified after the fact. Deviations go in EPIC.md.
Reactive environment delivery
The core principle: every specialist must be able to validate their work in a context where the system responds to their changes. No one works blind. At each step, the specialist guarantees the integration of their work with everyone else's.
Before starting any ticket: "Who validates this work, and what system do they interact with to validate it?" If no one can validate until the next ticket is also done, the decomposition is wrong.
Delivery strategy
The core principle is borrowed from lean and agile: deliver value where it can be measured first, then iterate toward quality.
Get to a testable state as fast as possible. The system responds to changes, feedback is immediate. This is the inception: break down the work so that the most valuable part is demonstrable first, even if rough.
Then iterate on all three axes, in parallel or not, until the expected quality level is reached:
Specialization profiles
Each ticket is associated with a specialization that determines who validates it and what the validation environment looks like.
Behavior
Make the feature work visibly in the real application. Inline, with mock data if needed.
Validates via: Browser, real product
Architecture
Extract, restructure, define interfaces from working code. System still works AND code is cleaner.
Validates via: Code review, running system
Quality
Add tests, fix edge cases, harden. Coverage, performance benchmarks.
Validates via: Test suite
Security
Audit and harden working code. Threat models, AuthN/AuthZ rules, GDPR.
Validates via: Security review, test suite
UX / UI
Design or redesign in the real product context. May completely reinvent a page.
Validates via: Browser, accessibility check
Infrastructure
Docker, Compose, Taskfile, CI/CD. Deploy topology, scaling, observability.
Validates via: Container orchestration, monitoring
Backend
Server-side implementation, API design, data persistence, business logic.
Validates via: API tests, integration tests
Prompt engineering
LLM prompt design, eval baselines, quality metrics. Never optimize blind.
Validates via: Eval suite, measured improvement
This list is not exhaustive. Each project can define its own specialization profiles based on its needs.
Anti-patterns
A specialist produces artifacts that no one can validate until another specialist completes their part. Example: backend built before frontend exists, so no one can see the feature.
Extracting components, writing abstractions, or optimizing code that has no visible effect in the product yet.
Designing interfaces and abstractions before the behavior is validated. Architecture should emerge from working code.
Improving performance or prompt quality before having a measurable baseline.
Ticket anatomy
Each ticket follows a standard structure. Validation criteria use Gherkin scenarios for unambiguous, testable acceptance.
# T03 - Attachment upload
## Objective
Allow architects to upload PDF attachments to demands.
## Specialization
Behavior
## Context
The demand detail page exists (T01, T02). Attachments are a
frequently requested feature from the architecture team.
## Deliverables
- Upload zone component (drag-and-drop + click)
- File type validation (PDF, DOCX, images)
- Attachment list with name, size, type badge
## Validation
```gherkin
Scenario: Architect uploads a PDF attachment
Given I am on the demand detail page for demand "D001"
When I drop a PDF file onto the upload zone
Then the file appears in the attachment list
And the file shows its name, size, and "PDF" type badge
Scenario: Upload is rejected for unsupported format
Given I am on the demand detail page
When I attempt to upload a file with extension ".exe"
Then an error message indicates the format is not supported
```Commit convention
Commits tied to delivery work use the ticket identifier as scope, linking git history directly to the delivery structure.
[Exx.Tyy] <type>: <message>[E02.T05] feat: add getting-started and architecture pages
[E01.T03] fix: correct volume mount path in agent compose
docs: update glossary with metalab terminology