[OTHER] Iteratively define and build the Workforce concept

[Joncallim]

ADR

0002-capability-routing.md

Goal

Introduce capability classification into Architect plans without implementing the full Workforce system.

Scope

• Add capability classification field to plan output
• Support primary capability
• Support optional secondary capabilities
• Preserve backwards compatibility with existing plans

Example:

capability:
  primary: backend
  secondary:
    - documentation

Out of Scope

• Workforce scheduler
• Automatic worker assignment
• Capability execution engine
• Multi-agent routing

Acceptance Criteria

• Architect emits capability metadata
• Existing plans remain valid
• Capability field is optional
• Metadata is available for future routing work

Notes

The objective is classification, not orchestration.

[Joncallim]

Clearly written, but this proposes a fundamental shift in Forge's orchestration model (capability → workforce → work-order hierarchy, a new verification layer, MCP tool surface). That's squarely a "run Architect first" change per this repo's workflow rules — it needs a design doc/ADR and almost certainly a phased rollout plan before any code lands, not a single implementation pass.

Not implementing this now. If you want to move on it, the next concrete step would be an Architect-agent design pass scoped to just the Capability Routing layer (the smallest viable slice: capability taxonomy + Architect classifying a task into required/optional/excluded capabilities), rather than building the full hierarchy at once.

[Joncallim]

Architect design pass done: docs/adr/0002-capability-routing.md in PR #36. Proposes the smallest viable first slice — the Architect's existing plan output gains a required/optional/excluded capability classification field, read-only for now, with the full Workforce/Work-Order/Worker-runtime stack explicitly deferred pending that proving useful.

[Joncallim]

Partial progress landed on main in commit bac5ddb (Add architect capability classification metadata).

Implemented in this slice:

• Architect prompt now requests a machine-readable capability_classification_json block using the fixed 22-capability taxonomy from the prior ADR design pass.
• Worker parses, normalizes, validates, strips, and persists the classification under artifacts.metadata.capabilityClassification.
• Validation is warnings-only: missing/malformed JSON, unknown capabilities, and invalid excluded entries do not block artifact persistence or task progression.
• Task detail renders a read-only "Capability Classification" panel near Planned Agents and MCP Access Plan.
• Existing agent breakdown / [Role]-based routing remains authoritative; this does not implement Workforce routing, Work Orders, runtime assignment, or execution behavior changes.

Evidence:

• Architect agent approved this as the smallest safe [OTHER] Iteratively define and build the Workforce concept #30 slice and recommended keeping it separate from MCP execution design.
• QA agent was satisfied for merge; only non-blocking future coverage gaps were noted for deeper worker integration/component render tests.
• Reviewer agent approved with no findings and confirmed no DB schema/routing/execution drift.
• cd web && npm test: 19 files / 156 tests passed.
• cd web && npm run lint: passed.
• cd web && npm run build: passed, with the existing non-fatal Turbopack NFT warning around next.config.ts / lib/workspace.ts.
• git diff --check: passed before commit.

I am not recommending closure of #30 yet. This completes the inert capability metadata slice, but the broader Workforce concept still needs follow-up work for Workforce grouping, Work Orders, runtime routing, and verification before the umbrella issue should close.