Wire the CellixJS mixed capability profile, document the workflow, and dogfood it

[nnoce14]

Summary

Adopt the orchestration system in the CellixJS repo, document how it works, and validate it on representative tasks.

Why

The workflow needs proof that it is useful and not just elaborate process design.

This task should also prove that the design is modular enough to support the current mixed CellixJS repo while remaining cleanly extensible to future framework-only and application-only repos.

Scope

CellixJS capability-profile adoption

Wire the current CellixJS repo to use the mixed capability profile, including:

• correct package/path class mapping for reusable framework code
• correct package/path class mapping for application/reference-app code
• activation of reusable framework behavior where relevant
• activation of application-delivery behavior where relevant
• activation of cellix-tdd only for framework-oriented task routing

Documentation

Document:

• orchestration spec
• repo capability profiles
• task lanes
• workflow states and transitions
• package/path classes
• responsibilities of instructions vs skills vs agents vs hooks
• artifact depth policy
• relationship to PR Add new agent skill cellix-tdd #186 / cellix-tdd
• how future framework-only Cellix repos should simplify adoption
• how future application-only consumer repos should adopt the workflow with minimal config

Dogfooding

Validate the workflow on:

• one fixture task in a test or sandbox area to avoid circularity
• one representative framework task in CellixJS
• one representative application/reference-app task in CellixJS
• one documented application-only example or simulated run using the application-only profile
• one documented framework-only example showing how the future split would simplify the repo profile

Capture:

• where lane selection worked or failed
• where workflow state transitions worked or failed
• whether artifact depth felt appropriate
• whether validator and hooks caught real issues
• whether the workflow is too heavy anywhere
• whether the design remains clean when projected into framework-only and application-only futures

Failure-path validation

At least one dogfood run must intentionally exercise an invalid transition or disallowed agent/phase combination and confirm that:

• the workflow blocks it correctly
• the denial/guidance is useful
• the orchestrator can recover cleanly

Acceptance criteria

• CellixJS wired to the mixed capability profile
• cellix-tdd integrated only for framework-oriented routing
• contributor docs added
• at least three representative runs completed inside the current mixed repo shape
• at least one invalid-transition or disallowed-agent scenario demonstrated and handled correctly
• application-only posture demonstrated and documented
• framework-only future posture demonstrated and documented
• follow-up simplifications/tightening identified from evidence