​

AI-DLC artifacts

AI-DLC works because every meaningful step becomes an explicit artifact.

​

Artifact reference

​

How targeting works

AI-DLC separates planning scope from execution tracking.

​

Planning artifacts

Planning artifacts can use Fabriqa’s built-in targeting fields:

• target_scope
• target_workspace_project_ids

Workflow-authored schemas do not need to redefine those fields. Use them to say whether the plan applies to the whole workspace or to specific workspace projects. Typical pattern:

• intent may stay workspace-level when it spans several projects.
• unit, story, and especially bolt usually become project-targeted so Construction runs against an explicit build context.

Recommended semantics:

• target_scope: workspace
  • the artifact applies to the workspace as a whole
  • do not populate target_workspace_project_ids
• target_scope: workspace_project
  • the artifact applies to one or more workspace projects
  • populate target_workspace_project_ids

Use IDs as the canonical stored value. Project names should be resolved from workspace metadata instead of duplicated into artifact payloads. AI-DLC keeps workspace-wide targeting on purpose. Why:

• Inception can start from a cross-project objective before planning narrows into project-specific units, stories, and bolts.
• Some artifacts are genuinely workspace-wide, especially root intent, migration planning, and shared platform direction.

​

Execution artifacts

Execution artifacts can record:

• touched_workspace_project_ids

This is also a built-in Fabriqa field, so workflow-authored schemas do not need to redefine it. Typical pattern:

• bolt says where the work is intended to happen.
• walkthrough and test_report say what was actually touched.

​

Why this split matters

It gives you:

• honest execution reporting
• better multi-project visibility
• safer handoff to linked worktrees or project-specific execution sessions

​

What Construction creates while running a bolt

Construction is the execution agent for AI-DLC. Its prompt decides when these artifacts are needed, but the DSL makes the contracts explicit.

​

Design outputs

These are bolt-scoped artifacts that help Construction think and help you review:

• domain_design
• logical_design
• system_context
• implementation_plan

These should read like documents. Good examples:

• markdown summaries
• architectural rationale
• implementation strategy
• tradeoff notes

Bad examples:

• giant nested object arrays used as the main reading experience

​

Execution outputs

These are the primary execution-output artifacts for completed work:

• walkthrough
• test_report

These are the artifacts you should expect to read before you trust the result.

​

What to review before trusting Construction output

Before you approve a bolt outcome, read:

1. the bolt itself for scope and grouped stories
2. domain_design and logical_design if the bolt changed the model or architecture
3. walkthrough for the implementation narrative
4. test_report for verification results
5. deployment_unit if the bolt changed deployable behavior

​

Continue reading