FDE engagement documents¶
Scaffold a forward-deployed engineering engagement as a local charter and seven gated stage pages, and check its stage exits.
ai-dlc fde scaffold implements the local portion of issue #50. Confluence
conversion, publication, synchronization and remote hierarchy registration
remain unavailable; destination hints do not create or bind remote pages.
Create an engagement¶
Run from the repository root (or supply --root PATH):
ai-dlc fde scaffold customer_delivery --title "Customer delivery" --dry-run
ai-dlc fde scaffold customer_delivery --title "Customer delivery"
ai-dlc fde check customer_delivery
Dry run returns exact prospective paths and content without writing anything. The normal command writes the engagement and returns its paths and contents. Existing destinations refuse even in dry run: rerunning cannot overwrite authored work. If a filesystem error interrupts creation, inspect the partial engagement; the command retains it for recovery and does not overwrite it on retry.
The default directory is docs/fde_engagements. Configure a dedicated repository
docs subdirectory in ai-dlc.toml:
[project.fde]
docs_dir = "docs/company/engagements"
Both commands accept --docs-dir docs/company/engagements as a per-call override.
The directory must be below docs/; traversal, absolute paths and symlinks are
refused. Local vault paths and machine-specific account choices do not belong in
this setting. The command creates files locally; it does not stage a Git commit.
Optional --space TEAM --parent 123 values preserve a chosen Confluence space
and engagement-parent ID as charter frontmatter. Supply both or neither. The
values are non-secret hints supplied explicitly by the caller, not verified
access or publication receipts. Stage pages intentionally have no invented
remote page IDs or parent IDs. Company-specific taxonomy belongs in the actual
project's reviewed documents, not ai-dlc's portable defaults.
Work through the stages¶
Each engagement contains _index.md, AGENTS.md, CLAUDE.md and seven folders:
| Folder | Initial status | Focus |
|---|---|---|
01_discover |
ACTIVE | Customer context, stakeholders, workflows and constraints |
02_frame |
GATED | Problem, success measures and scope |
03_design |
GATED | Architecture, interfaces, experience and risks |
04_build |
PLANNED | Implementation and verification |
05_deploy |
PLANNED | Deployment, monitoring and recovery |
06_enable |
PLANNED | User adoption and operator guidance |
07_expand |
PLANNED | Outcomes and further opportunities |
Every stage's _index.md is the local landing page and intended future parent
for that stage's child deliverables. Store deliverables beside that page. The
charter has sponsor and business-goal sections and a dashboard linking current
stage records. Stage frontmatter owns current state; the dashboard does not
maintain a second status copy.
After reviewing a stage's exit criteria, edit its frontmatter in Git:
status: "ACTIVE"
exit_criteria_met: true
exit_evidence: "Review PR 12: approved discovery findings and stakeholder map"
Then change the next stage's status to ACTIVE and run ai-dlc fde check SLUG.
All earlier stages must have exit_criteria_met: true and nonempty review
evidence before a downstream stage becomes ACTIVE or records completed exits.
There is no separate DONE status: exit completion and lifecycle status describe
different facts.
Check prints current stages and evidence, reports all available findings and exits nonzero on invalid structure or gates. It reads only the eight known landing pages, each at most 256000 bytes, and does not traverse deliverable links. Invalid YAML (including duplicate fields), missing pages and symlinks refuse validation.
A review-evidence string records the team's assertion; ai-dlc does not prove that a linked approval occurred or that prose exit criteria were satisfied. To make this check a project gate, add the actual engagement command to that project's required checks. It does not become a work-finish gate automatically. When new evidence invalidates an earlier stage, reopen that exit and gate downstream stages again before proceeding.
Agent guidance and publication boundary¶
The engagement's AGENTS.md explains stage ownership, validation, supplied target
hints and private/shared boundaries. CLAUDE.md references it. Explicitly load the
same rule through another harness's supported project guidance mechanism; creating
files alone does not establish native harness behavior or qualification.
Only explicitly selected, reviewed team documents may be published through a separately reviewed existing connection. Never scan or mirror private Obsidian vaults, infer publication from tags, or follow private source links into outgoing payloads. A requested local summary records the source URL, available version and retrieval date; explicit refresh preserves personal annotations and reports inaccessible or stale sources honestly.
This scaffold has no XHTML dry-run, lint-conversion or sync command; fde check
checks local structure and metadata only. The cancelled
publication proposal
retains the converter fidelity, preview/apply, conflict refusal and live
qualification requirements for any future port.