78 lines
3.4 KiB
Markdown
78 lines
3.4 KiB
Markdown
# Gatekeeper
|
|
|
|
A **plan self-containedness gate**. Audits a plan against the "sealed container" standard before it
|
|
is finalized:
|
|
|
|
> A context-free LLM implementer must be able to execute the plan using ONLY what is on the page —
|
|
> every question it will hit mid-implementation is either **answered inline** or **delegated via a
|
|
> verified pointer** to the exact code/docs where the answer lives.
|
|
|
|
Where [`plan-review`](../../skills/plan-review/SKILL.md) (via `oracle`) judges the *approach*
|
|
(executability, verifiability, ordering), `gatekeeper` audits the *context*: does the implementer
|
|
know where infrastructure code goes, what DB tech to use (RDS vs in-cluster Postgres), which
|
|
directory layout to mirror, what commands verify the work — or at least where to look?
|
|
|
|
## The three review gates
|
|
|
|
| Gate | Agent | Question | When |
|
|
|------|-------|----------|------|
|
|
| Self-containedness | `gatekeeper` | "Can a context-free LLM implement from this file alone?" | Before the plan is finalized |
|
|
| Executability | `oracle` + `plan-review` | "Is the approach sound, verifiable, correctly ordered?" | Before the plan is promoted |
|
|
| Conformance | [`adversary`](../adversary/README.md) | "Is the built code what the plan asked for?" | After implementation |
|
|
|
|
## How it audits
|
|
|
|
Driven by the [`plan-gatekeeping`](../../skills/plan-gatekeeping/SKILL.md) skill:
|
|
|
|
1. Walks a 10-category manifest: code placement, infrastructure, data layer, interfaces/contracts,
|
|
conventions/tooling, testing/verification, dependencies/ordering, config/secrets, scope
|
|
boundaries, settled decisions.
|
|
2. For each category: answered inline, delegated via pointer, or **missing**.
|
|
3. **Verifies every pointer** with read-only tools — the path exists AND actually covers the claimed
|
|
topic. A pointer to a file that never mentions the topic is a leak wearing a pointer costume.
|
|
4. Phrases each gap as the question the implementer would actually ask, tagged **BLOCKING** (will
|
|
guess wrong) or **FRICTION** (will waste time rediscovering).
|
|
|
|
## Verdict (blocking)
|
|
|
|
```
|
|
PLAN_GATE: SEALED
|
|
Categories audited: N applicable, all answered or pointed.
|
|
```
|
|
|
|
```
|
|
PLAN_GATE: LEAKY
|
|
Missing questions (N):
|
|
1. [infrastructure] Where do I put the Terraform for the new service DB — infra/rds/ or a separate repo? — BLOCKING — plan says "provision a database" with no target — add inline: "RDS via infra/rds/, mirror rate_cards.tf"
|
|
Broken pointers (if any):
|
|
- "see docs/db.md for conventions" — path missing
|
|
```
|
|
|
|
`LEAKY` blocks finalization. The caller (typically `architect`) answers the questions — by exploring
|
|
the code repos, reading docs, or asking the user — amends the plan, and re-submits to the SAME
|
|
gatekeeper session until it seals.
|
|
|
|
## Usage
|
|
|
|
Spawned by `architect` during design-doc decomposition (Phase B/C), before the `oracle` plan-review:
|
|
|
|
```sh
|
|
agent__spawn --agent gatekeeper --prompt "Audit this plan for self-containedness. Return SEALED/LEAKY.
|
|
|
|
Plan: <plans_dir>/PLAN-<slug>.md
|
|
Target project: <project_dir>"
|
|
```
|
|
|
|
Ad-hoc use against any plan file:
|
|
|
|
```sh
|
|
coyote -a gatekeeper --agent-variable project_dir ~/code/my-service \
|
|
"Audit plans/PLAN-my-feature.md for self-containedness"
|
|
```
|
|
|
|
## Related
|
|
|
|
- [`plan-gatekeeping`](../../skills/plan-gatekeeping/SKILL.md) — the manifest + methodology it runs on.
|
|
- [`architect`](../architect/README.md) — the orchestrator that gates plans through it.
|
|
- [`adversary`](../adversary/README.md) — the post-implementation conformance counterpart.
|