Develop SDLC in a self-hosting way wherever possible

State: open/published

Summary

• SDLC is built using SDLC: its planning artifacts describe its own work, its lifecycle drives that work, and its validators check what it produces.
• Self-hosting exposes friction in the model before any downstream consumer hits it.
• Applied pragmatically per P-0003-pragmatic-architecture: some bootstrap steps are not self-hosted yet.

Statement

SDLC is built using SDLC. Its planning artifacts (milestones, tasks, Decisions, Standards, Principles) describe the work to build itself, its task lifecycle drives that work, and its validators check the artifacts it produces. A step may skip self-hosting only when the SDLC mechanism it would use does not exist yet. Once that mechanism ships, the step is converted, and the conversion is tracked as a Task.

Why

A system that describes itself in its own terms is the toughest test of whether those terms are sufficient. Running SDLC on SDLC exposes a gap in the entity model at the moment it would also bite a consumer.

How it applies

• The planning artifacts of this project, under docs/planning/, use SDLC’s own entity schemas.
• A new entity type is exercised on SDLC’s own development before it is declared stable.
• Tooling that operates on entities is tracked as a Task or Capability like any other work.

Examples

• The planning effort itself: M-0000, M-0001-initial-entity-shape-and-roster, principles, standards, and capabilities were captured as SDLC entities (or proto-entities) before their schemas shipped.
• The Capability tree was authored ahead of its schema, then reshaped to C-0001 through C-0010 and schema-validated when the Capability type shipped.
• docs/planning/tasks/: SDLC’s own work tracked as Tasks with the same shape consumers use.

Implications

• A change to SDLC’s entity model is applied to docs/planning/ in the same change that ships it. An entity type that cannot describe this project’s own work is not ready to ship to consumers.

---

← Back to Principles