UNPKG

paqad-ai

Version:

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

github.com/Eliyce/paqad-ai

Eliyce/paqad-ai

33 lines (24 loc) • 1.55 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
# Readiness criteria verified: 2026-11-02 The readiness verdict decides whether the map is worth building yet. It is graded from what the engine can detect, never from optimism about what the code "probably" contains. ## The three verdicts - **ready**: the app kind is detected and a dedicated extractor covers its shape (for example a Node CLI with a discoverable command program, or a service with a route convention the extractor recognises). The run proceeds with normal confidence. - **partial**: the app kind is detected but only the generic convention fallback applies. The run proceeds in exploratory mode; every surface it produces is tagged `confidence: low` so a reader knows the map is a first pass, not a proof. - **blocked**: no extractor covers the app shape. The engine records a `blocked_checks` entry with the reason. The run stops here; a map built by guessing surfaces is worse than no map. ## What counts as "detectable" - The app kind (`web | api | cli | mobile | desktop | service | llm-workflows`) resolves from the manifests, not from a guess. - At least one framework signal is present, or the generic route/command convention matches real files. ## Anti-false-positive discipline - A `blocked` verdict is honest, not a failure to try harder. Do not invent an app kind to force a `ready` verdict. - Do not treat an empty extraction as `ready` clean. An extractor that found nothing on a non-trivial app is evidence of a coverage gap, which is a `partial` or `blocked` signal, not a clean map.