Skip to content
CAT Mascot CAT Documentation

Construction Phase

The Construction phase is where code gets written. Unlike traditional development, construction in the DLC is governed by the ARC and organized into discrete bolts — each with explicit scope, constraint mappings, and acceptance criteria.

Purpose

Section titled “Purpose”

The Construction phase ensures that:

  • Code is built in manageable, reviewable increments (bolts)
  • Every piece of code traces to specific ARC constraints
  • AI-generated code receives the same review rigor as human code
  • Testing is driven by constraints, not afterthought

Key Artifacts

Section titled “Key Artifacts”

Bolt Specs

Section titled “Bolt Specs”

Atomic units of work decomposed from Features. Each bolt spec defines:

  • Scope — exactly what this bolt builds
  • ARC constraint mapping — which constraints apply
  • Acceptance criteria — specific, testable “done” conditions
  • Testing requirements — what tests must pass
  • Dependencies — what must exist first

Created by: cat-bolt-writer with Julian

Bolt Execution Reports

Section titled “Bolt Execution Reports”

Documentation of each bolt’s implementation, including constraint compliance status.

Created by: cat-bolt-execution with Marcus

Code Review Reports

Section titled “Code Review Reports”

Joint review by Marcus and Vera covering ARC compliance, AI governance, and testing coverage.

Created by: cat-code-review with Marcus and Vera

Test Plan

Section titled “Test Plan”

Risk-prioritized test strategy derived from ARC testing requirements with full traceability.

Created by: cat-test-plan with Vera

Datadog Dashboard Plans

Section titled “Datadog Dashboard Plans”

For services requiring monitoring, Argus creates dashboard configurations with monitors and SLOs.

Created by: cat-datadog-dashboard with Argus

Mid-Construction Changes

Section titled “Mid-Construction Changes”

When scope or constraints need to change during construction:

cat-change-proposal

Clara and Julian produce a formal Change Proposal with impact analysis across all affected artifacts. See Handle Scope Changes.

Construction Best Practices

Section titled “Construction Best Practices”
  1. Execute bolts in dependency order. Bolt 1.1 before 1.2 if 1.2 depends on 1.1.
  2. Code review each bolt before starting the next. Don’t accumulate unreviewable code.
  3. Reference the ARC during execution. Marcus does this automatically, but if you’re coding manually, keep the ARC open.
  4. Don’t bypass constraints. If a constraint can’t be met, use cat-change-proposal to formally change it.

See Also: Write Bolt Specs · Execute Bolts · What Are Bolts?