Gate: plan-seeds-valid
The plan only seeds specs in a layer that has specs.
| Property | Value |
|---|---|
| Checker | plan-seeds-valid |
| Confronts | plan |
| Blocking by default — new project | yes |
| Blocking by default — existing project | no — informs |
How it measures
Section titled “How it measures”Confronts artifact paths seeded by an implementation plan against the project Structure: every specification path that a plan promises to create must belong to a valid governed layer.
An implementation plan seeds new artifacts to be born during execution. When a plan declares which specifications will be created, developers and automated agents rely on those paths to execute their tasks. If a plan seeds specifications in layers where specifications are prohibited or undefined, that structural contradiction is only discovered downstream during execution.
Observed across three consecutive rounds in project history: an implementation plan repeatedly seeded
packages/backend/models/metadata.spec.md — **nasce**, even though models/ was a recognized declarative layer
(regime: declarativo) which does not accept specifications by architectural definition. Each time, a full
execution round was spent rediscovering the contradiction, because downstream defenses (such as creation tools
and gate runners) only act at execution time. The root cause of the defect was the plan itself. Because the plan
is a declared layer in the repository, its structural promises can and must be verified before execution starts.
This gate confronts two structural defects in plan seeds:
- Seeding in a declarative layer: Seeding a specification in a layer declared as
regime: declarativo(which by definition does not carry specifications). - Seeding in an undeclared layer: Seeding a specification in a concrete repository directory that does not match any declared layer in the project Structure (indicating a path typo or an undeclared layer).
What separates this gate from neighbouring gates:
- It deliberately does NOT verify whether the seeded specification already exists on disk (seeds are intended to be created during execution).
- It does NOT check whether plan progress is synchronized or complete (which belongs to plan progress gates).
- It does NOT inspect the content or implementation steps of the plan items.
- It restricts evaluation strictly to the structural validity of the specification paths the plan promises to create.
Finally, casual mentions of template specifications (_TEMPLATE_*.spec.md), bare file names in prose, and
informal path fragments that do not correspond to top-level repository directories are recognized as narrative
references rather than actionable seeds.
Declaring it
Section titled “Declaring it”gates: - name: plan-seeds-valid on: [plan] check: plan-seeds-valid