UNPKG

paqad-ai

Version:

Spec-driven development framework — AI agents that think before they type

github.com/Eliyce/paqad-ai

Eliyce/paqad-ai

34 lines (24 loc) • 1.56 kB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# Guard evidence verified: 2026-11-02 A guard is a claim that access to a surface or transition is controlled. Recording a guard the code does not actually enforce is worse than recording none: it puts a lock on the map where the door is open. So a guard exists only where the enforcement is proven. ## What proves a guard - A middleware, decorator, route-metadata check, or policy that runs before the surface and can deny access. - A feature-flag read that gates whether the surface or variant renders at all. - An auth-state or data-state check the code performs, not one a comment merely promises. Each guard records its `kind` (`permission | role | feature-flag | auth-state | data-state | capability | environment`), what it `requires`, a `satisfy_via` (how it is met), and a resolving `file:line`. ## satisfy_via - `satisfy_via` names how a caller satisfies the guard: an actor that holds a permission, a role, a flag variant, an environment. A guard with no way to satisfy it is a dead end to flag, not a guard to leave dangling. ## Anti-false-positive discipline - Do not infer a guard from naming or convention alone. If the enforcement is not in the code, the honest output is a `SM-GUARDLESS`-style finding about missing protection, not a guard entry. - A backstage surface with no evidenced guard is a coverage gap to surface, not a place to assume an inherited guard. - Never place a secret, token, or credential value in guard evidence. Cite the `file:line` and the enforcement; the bytes of the secret never enter the map.