Spec Studio

Packs

Specs grouped by the Packs that hold them, from the reader.

  • 456 Specs and 9 Packs in this corpus.
  • 5 Specs stated idea.
  • 4 Specs stated scoped.
  • No Specs stated defined.
  • 447 Specs stated ready.
  • No Specs stated above their floor.
  • 16 open questions and 10 blocking questions.
  • 166 Specs with an implementation binding and 397 Specs with a verifier binding.
  • No errors and 3 warnings.

Start here

Packs

An adopter at full speed · pack:adopter-speed-v1 · 59 members

Read the Pack page

  1. The evaluation sink runs one body and prints its return · ready · floor ready
  2. A script holding a graph runs a shipped recipe through the exported evaluator · ready · floor ready
  3. A body calls a shipped recipe and returns its answer unchanged · ready · floor ready
  4. A call to a recipe the catalog does not hold fails the body · ready · floor ready
  5. Corpus-authored rules run on the one validation path · ready · floor ready
  6. Editing a parameter file starts a cycle that reads the new parameters · ready · floor ready
  7. Rewriting a rules file under node_modules starts a cycle that runs the new body · ready · floor ready
  8. A parameter file that stops being JSON fails only its own rules file, and the watcher runs on · ready · floor ready
  9. Validation re-runs while an author edits carriers · ready · floor ready
  10. Address resolution and dependency cycles stay executable graph recipes · ready · floor ready
  11. A dependency chain with no cycle yields no finding · ready · floor ready
  12. The shipped dependency-cycles file fails a rules run on a cycle · ready · floor ready
  13. The shipped address-resolution file fails a rules run on an address that names no entry · ready · floor ready
  14. A corpus checks the register tokens its prose cites · ready · floor ready
  15. A held token no Spec cites fails a rules run only when the caller asks · ready · floor ready
  16. A cited token the register lacks or retires fails a rules run · ready · floor ready
  17. Every verb answers --help, and one verb writes every projection root · ready · floor ready
  18. A root that fails its check is removed while sdp generate writes the others · ready · floor ready
  19. One run of sdp generate leaves all five roots current · ready · floor ready
  20. A publisher's --help prints its help and touches no root · ready · floor ready
  21. An example step may carry a key that survives rewording · ready · floor ready
  22. An example marker that disagrees with its vocabulary withholds the contract · ready · floor ready
  23. A keyed Gherkin step keeps its binding across a rewording · ready · floor ready
  24. A step key equal to another step's skeleton withholds the contract · ready · floor ready
  25. A step marker whose key is off the grammar refuses the carrier · ready · floor ready
  26. Renaming a step key breaks the binding · ready · floor ready
  27. One key on two vocabulary steps refuses the carrier · ready · floor ready
  28. A keyed step reworded in its vocabulary and its example keeps its binding · ready · floor ready
  29. The same rewording without a key breaks the binding · ready · floor ready
  30. Two keys on one step refuse the carrier · ready · floor ready
  31. A keyed TypeScript step keeps its key through import to Markdown · ready · floor ready
  32. The build derives step and space contracts from graph examples · ready · floor ready
  33. Derived runnable modules freeze the registrar interface · ready · floor ready
  34. A Model term may carry a key that addresses it · ready · floor ready
  35. A keyed term is reified and its address resolves · ready · floor ready
  36. A term marker whose key is off the grammar refuses its carrier · ready · floor ready
  37. A term key repeated in one Spec refuses its carrier · ready · floor ready
  38. A keyed TypeScript term keeps its address through import to Markdown · ready · floor ready
  39. An address that names a term key no term carries is an error · ready · floor ready
  40. A Spec id written in prose is a checked mention · ready · floor ready
  41. The graph records where anchored source cites an entry address · ready · floor ready
  42. A code file's comment cites a declaration without reading as a test line · ready · floor ready
  43. A test title in an anchored file cites a pinned declaration · ready · floor ready
  44. A file that carries no anchor is not read for citations · ready · floor ready
  45. A citation of an entry its Spec lacks reports through the recipe, never as a Protocol finding · ready · floor ready
  46. A context bundle is composed per invocation within a stated budget · ready · floor ready
  47. A member larger than the budget is named, and no part is returned · ready · floor ready
  48. A Pack too large for one bundle reads whole in parts · ready · floor ready
  49. The readiness planner orders the statements a person can make · ready · floor ready
  50. Waiting Specs that rest on each other share a round and report a cycle · ready · floor ready
  51. A waiting decision comes before the Spec it shapes · ready · floor ready
  52. The Spec another rests on comes first in the queue · ready · floor ready
  53. An owner's blocking question lists the Specs it holds · ready · floor ready
  54. The upgrade kit shows a corpus what it could adopt · ready · floor ready
  55. Capability adoption counts where each capability is used and where it could apply · ready · floor ready
  56. Capability adoption counts keyed rules and reasoned relations · ready · floor ready
  57. The rule-key proposal keys every unkeyed rule as a change proposal · ready · floor ready
  58. Two rules that coin one key stay apart, and a rule with no ASCII word stays unkeyed · ready · floor ready
  59. A rule-key proposal passes the proposal check and validates once applied · ready · floor ready
Corpus checks · pack:corpus-checks-v1 · 16 members

Read the Pack page

  1. Corpus-authored rules run on the one validation path · ready · floor ready
  2. An error from a corpus rule fails validation and leaves the Protocol's line alone · ready · floor ready
  3. A warning from a corpus rule informs and passes · ready · floor ready
  4. A finding with no subject fails its rules file · ready · floor ready
  5. A rules file that empties its graph leaves the next file's graph whole · ready · floor ready
  6. Rewriting a rules file under node_modules starts a cycle that runs the new body · ready · floor ready
  7. Editing a parameter file starts a cycle that reads the new parameters · ready · floor ready
  8. A parameter file that stops being JSON fails only its own rules file, and the watcher runs on · ready · floor ready
  9. Declared architecture rules are checked against anchored structure · ready · floor ready
  10. A domain member that uses an infrastructure member breaks a forbidden pair · ready · floor ready
  11. The walk named as a rules file fails validation on an isolation breach · ready · floor ready
  12. A component with no layer leaves its edge unclassified · ready · floor ready
  13. Components are designed ahead of their code · ready · floor ready
  14. A component design no anchor satisfies is listed as unrealized · ready · floor ready
  15. A realized component that differs from its design gives one row per field · ready · floor ready
  16. A realized component that matches its design gives no row · ready · floor ready
Design iteration · pack:design-iteration-v1 · 11 members

Read the Pack page

  1. Recipe answers fit an agent's context and explain their misses · ready · floor ready
  2. A rule or flow entry may carry a key that addresses it · ready · floor ready
  3. An open question may name who decides it, its links, a provisional reading and a re-entry trigger · ready · floor ready
  4. An authored relation may carry its reason · ready · floor ready
  5. Designs are compared between a base commit and the working tree at entry grain · ready · floor ready
  6. A context bundle is composed per invocation within a stated budget · ready · floor ready
  7. A Pack is read from a named perspective · ready · floor ready
  8. A change proposal is addressed, based and checked before it lands · ready · floor ready
  9. Enrichment keeps one Spec while its detail changes · ready · floor ready
  10. File-level imports show where curation is missing · ready · floor ready
  11. Mechanical code structure stays inferred and apart from curated intent · ready · floor ready
Design management · pack:design-management-v1 · 24 members

Read the Pack page

  1. The Design Review's Pack page presents the Pack's design · ready · floor ready
  2. The Pack context carries the Pack's design · ready · floor ready
  3. A Pack page shows where the Pack's design stands · ready · floor ready
  4. The graph records where each addressable entry is written · ready · floor ready
  5. Recipes take parameters as data and ship as runnable files · ready · floor ready
  6. Design work reads its answers from catalog recipes · ready · floor ready
  7. Example spaces report which values their examples cover · ready · floor ready
  8. The CLI names the engine that produced a result · ready · floor ready
  9. Validation re-runs while an author edits carriers · ready · floor ready
  10. What a Spec's design carries is derived, beside its readiness · ready · floor ready
  11. Components are designed ahead of their code · ready · floor ready
  12. An open question may name who decides it, its links, a provisional reading and a re-entry trigger · ready · floor ready
  13. A rule or flow entry may carry a key that addresses it · ready · floor ready
  14. An authored relation may carry its reason · ready · floor ready
  15. A Pack is read from a named perspective · ready · floor ready
  16. A context bundle is composed per invocation within a stated budget · ready · floor ready
  17. Designs are compared between a base commit and the working tree at entry grain · ready · floor ready
  18. A change proposal is addressed, based and checked before it lands · ready · floor ready
  19. A reference projection serves a reader outside the repository · idea · floor idea
  20. Mermaid diagrams can be rooted at code units · scoped · floor scoped
  21. A Spec shaped by a superseded decision warns · ready · floor ready
  22. Declared architecture rules are checked against anchored structure · ready · floor ready
  23. Corpus-authored rules run on the one validation path · ready · floor ready
  24. CI run records are joined to verifiers in a view · ready · floor ready
Obsidian vault · pack:obsidian-vault-v1 · 23 members

Read the Pack page

  1. An Obsidian vault lets a person iterate on designs from the one graph · ready · floor ready
  2. The vault's generator owns one folder and synchronizes it · ready · floor ready
  3. A fresh vault is written the same way twice and every link resolves · ready · floor ready
  4. A regeneration removes a note that left the graph and keeps a person's notes · ready · floor ready
  5. A note a person wrote inside the generated folder refuses the regeneration · ready · floor ready
  6. A generated note a person changed refuses the regeneration and keeps the edit · ready · floor ready
  7. A person's file under a temporary's name refuses the regeneration · ready · floor ready
  8. A vault directory the build removes refuses the run and keeps a person's notes · ready · floor ready
  9. A run after a stopped synchronization finishes it · ready · floor ready
  10. A failed extraction keeps the notes and says so on the index · ready · floor ready
  11. The run after a failed extraction passes the guard and restores the index · ready · floor ready
  12. Every Spec, Pack, code unit and keyed term is a note, and every relation is a link · ready · floor ready
  13. An entry address in prose opens the entry's block in its Spec's note · ready · floor ready
  14. A mention of an entry that does not exist stays as written · ready · floor ready
  15. A keyed Model term gets a note, and its address in prose opens the term's block · ready · floor ready
  16. Two Specs whose notes differ only in case refuse the run · ready · floor ready
  17. A Pack's members and the standing queries are tables over the reader's values · ready · floor ready
  18. Each standing view selects what its source selects · ready · floor ready
  19. A design pass is followed and answered from the vault · ready · floor ready
  20. A carrier edit under watch rewrites only the notes it changes · ready · floor ready
  21. An anchor added in a source file under watch rewrites the Spec's note · ready · floor ready
  22. The vault skill teaches agents to keep an Obsidian vault of the graph · ready · floor ready
  23. A Model term may carry a key that addresses it · ready · floor ready
The Protocol's roadmap · pack:roadmap · 4 members

Read the Pack page

  1. The Protocol removes its frozen plans, review reports and superseded concept material · idea · floor idea
  2. A pinned declaration shows the words of each test line that cites it · scoped · floor scoped
  3. An outside register is a named Studio input, so a cited token links to its entry · scoped · floor scoped
  4. Views compose scoped intent instead of patching canonical source · ready · floor ready
Roadmaps, capability maps and design slices · pack:roadmaps-and-slices-v1 · 49 members

Read the Pack page

  1. The engine's accepted set covers its significant abstractions and only those · ready · floor ready
  2. The engine's architectural roles each name one pattern · ready · floor ready
  3. The architecture page lists each component's significant units by role · ready · floor ready
  4. The capability map reads every epic and its refinement descendants · ready · floor ready
  5. Capability epics keep kind independent of altitude · ready · floor ready
  6. The Protocol organizes its own features in capability epics · ready · floor ready
  7. Bound examples execute their authored steps · ready · floor ready
  8. The capability map page makes refinement readable by epic · ready · floor ready
  9. The Studio chooses diagram kinds from graph values · ready · floor ready
  10. A diagram preserves readable labels before zoom · ready · floor ready
  11. Edges route around boxes with deterministic orthogonal paths · ready · floor ready
  12. A diagram offers Mermaid source as copyable text · ready · floor ready
  13. A dependency drawing shows the declared footing of a Spec set · ready · floor ready
  14. A refinement drawing follows the capability map · ready · floor ready
  15. A Spec set draws the architecture it touches · ready · floor ready
  16. The maturity map is drawn as a grid of counts · ready · floor ready
  17. A requirement drawing separates intent from realization and verification · ready · floor ready
  18. A slice reads a Pack as one design, with the architecture it touches and what each member needs next · ready · floor ready
  19. Outside components stop at the touched components' neighbors · ready · floor ready
  20. Members rest on a chain · ready · floor ready
  21. A shaping decision comes before its member · ready · floor ready
  22. A cycle shares a depth · ready · floor ready
  23. An example folds without lending its readiness · ready · floor ready
  24. An example with its own dependency stays unfolded · ready · floor ready
  25. An unanchored component design stays visible · ready · floor ready
  26. An anchor alone does not realize a component design · ready · floor ready
  27. A realized component matches its declared values · ready · floor ready
  28. A realized component keeps its differing layer and uses apart · ready · floor ready
  29. An unreadable declared layer stays visible · ready · floor ready
  30. A prerequisite reaches its satisfying component · ready · floor ready
  31. An unbound prerequisite invents no component · ready · floor ready
  32. An outside prerequisite names the member it holds · ready · floor ready
  33. A slice page shows a Pack's design as one whole · ready · floor ready
  34. A roadmap states advisory priority in the graph · ready · floor ready
  35. A roadmap orders the next bodies of work, and the graph says what each still needs · ready · floor ready
  36. Built work stays on the roadmap · ready · floor ready
  37. A ready unbound part needs building · ready · floor ready
  38. A complete part waits for a statement · ready · floor ready
  39. An unfinished part needs design · ready · floor ready
  40. A binding below ready remains drift · ready · floor ready
  41. A descendant without evidence names its holding clause · ready · floor ready
  42. A descendant question holds the entry for design · ready · floor ready
  43. A descendant names its outside parent · ready · floor ready
  44. Waiting statements keep dependency order against roadmap places · ready · floor ready
  45. The roadmap page shows the upcoming work in priority order, split by what it needs · ready · floor ready
  46. A roadmap renders as the forward section of a pull request description · ready · floor ready
  47. Plan and review files stop carrying the delivery record once the roadmap and the pull request do · ready · floor ready
  48. The Protocol reads its next work from its roadmap and keeps its delivery record in git and its pull requests · ready · floor ready
  49. Roadmap views read releases, baselines and phases from git and the graph · scoped · floor scoped
Self-hosting · pack:self-hosting-v1 · 456 members

Read the Pack page

  1. Markdown authoring enters the one graph · ready · floor ready
  2. The Markdown envelope is explicit and bounded · ready · floor ready
  3. The Markdown parser reifies the ruled subset · ready · floor ready
  4. One finding class is shared while the carriers' outcomes stay their own · ready · floor ready
  5. A TypeScript-carried Spec can be converted to Markdown · ready · floor ready
  6. A TypeScript carrier survives import as an equal Markdown graph · ready · floor ready
  7. A bare .feature corpus can be imported · idea · floor idea
  8. Every prose value has one typed owner · ready · floor ready
  9. A Pack has a Markdown manifest carrier · ready · floor ready
  10. A Markdown Pack twin matches its TypeScript manifest · ready · floor ready
  11. A Spec key on a Pack envelope is refused · ready · floor ready
  12. The Markdown body accepts one closed form per section · ready · floor ready
  13. A table under a section is refused · ready · floor ready
  14. A bullet wrapped onto a second line is refused · ready · floor ready
  15. An ordered list is refused · ready · floor ready
  16. A fence other than gwt or gwt-vocabulary is refused · ready · floor ready
  17. An H3 under Design is refused · ready · floor ready
  18. A plain bullet under an open section is refused · ready · floor ready
  19. A keyed bullet under a plain-bullet owner is refused · ready · floor ready
  20. Prose after structured content is refused · ready · floor ready
  21. A repeated single-valued field is refused · ready · floor ready
  22. An unrecognized heading is refused with a suggestion · ready · floor ready
  23. A second primary owner is refused · ready · floor ready
  24. Raw HTML outside a code span is refused · ready · floor ready
  25. A second description across Behavior and Example space is refused · ready · floor ready
  26. An integer-like Model term is refused · ready · floor ready
  27. Inline code is content, never markup · ready · floor ready
  28. Code spans in a Spec narrative are literal · ready · floor ready
  29. Code spans in section descriptions are literal · ready · floor ready
  30. Code spans in list entries are literal · ready · floor ready
  31. Code spans in Pack framing are literal · ready · floor ready
  32. Gherkin authoring enters the one graph · ready · floor ready
  33. A Feature and Scenario enter the graph as parent and child · ready · floor ready
  34. The pseudo-scenario supplies example space without a node · ready · floor ready
  35. Markdown and Gherkin twins derive equal graphs and contracts · ready · floor ready
  36. A Feature without identity is refused · ready · floor ready
  37. A Scenario Outline is refused · ready · floor ready
  38. A graph-aware tag near miss is refused · ready · floor ready
  39. An authored delivery fact lookalike is refused · ready · floor ready
  40. A malformed relation target is refused · ready · floor ready
  41. A Gherkin example with an unbound used slot fails its stated readiness floor · ready · floor ready
  42. Duplicate Markdown and Gherkin surfaces are both excluded · ready · floor ready
  43. A bad description key reports its physical source line · ready · floor ready
  44. A step-less Scenario is refused at its Scenario line · ready · floor ready
  45. Multiple findings exclude one carrier and keep a healthy sibling · ready · floor ready
  46. Slot notation declares, binds, and refuses to guess · ready · floor ready
  47. A typed declaration normalizes to the skeleton its binding shares · ready · floor ready
  48. A stray brace stays prose while an unusable group stays a named slot · ready · floor ready
  49. A one-literal group in a vocabulary is a binding that declares nothing · ready · floor ready
  50. An example step may carry a key that survives rewording · ready · floor ready
  51. A keyed step reworded in its vocabulary and its example keeps its binding · ready · floor ready
  52. The same rewording without a key breaks the binding · ready · floor ready
  53. A keyed Gherkin step keeps its binding across a rewording · ready · floor ready
  54. Renaming a step key breaks the binding · ready · floor ready
  55. One key on two vocabulary steps refuses the carrier · ready · floor ready
  56. Two keys on one step refuse the carrier · ready · floor ready
  57. A step marker whose key is off the grammar refuses the carrier · ready · floor ready
  58. An example marker that disagrees with its vocabulary withholds the contract · ready · floor ready
  59. A step key equal to another step's skeleton withholds the contract · ready · floor ready
  60. A keyed TypeScript step keeps its key through import to Markdown · ready · floor ready
  61. The Protocol models delivery with one enrichable Spec · ready · floor ready
  62. Enrichment keeps one Spec while its detail changes · ready · floor ready
  63. Spec sections carry typed detail and direct verifier semantics · ready · floor ready
  64. Specs declare typed directed relations · ready · floor ready
  65. Stable IDs are the Protocol's durable join key · ready · floor ready
  66. A namespaced dotted path with a sub-part survives parsing unchanged · ready · floor ready
  67. An uppercase namespace is refused with its reason named · ready · floor ready
  68. A # sub-part without its section is refused with its reason named · ready · floor ready
  69. A Pack is a truth-free review aggregate · ready · floor ready
  70. Source anchors bind code without carrying intent · ready · floor ready
  71. A consumer-local lookalike builder mints no anchor and no finding · ready · floor ready
  72. A deep relative import that resolves to the Protocol builders is trusted · ready · floor ready
  73. Architecturally significant units are annotated where they are realized · ready · floor ready
  74. An open question may carry a key that addresses it · ready · floor ready
  75. A keyed question is reified and its address resolves · ready · floor ready
  76. A renamed question key fails the mention that addresses it · ready · floor ready
  77. A repeated question key refuses its carrier · ready · floor ready
  78. What a Spec's design carries is derived, beside its readiness · ready · floor ready
  79. Components are designed ahead of their code · ready · floor ready
  80. A component design no anchor satisfies is listed as unrealized · ready · floor ready
  81. A realized component that differs from its design gives one row per field · ready · floor ready
  82. A realized component that matches its design gives no row · ready · floor ready
  83. An open question may name who decides it, its links, a provisional reading and a re-entry trigger · ready · floor ready
  84. A TypeScript question list that cannot be read drops whole with a warning · ready · floor ready
  85. A rule or flow entry may carry a key that addresses it · ready · floor ready
  86. An authored relation may carry its reason · ready · floor ready
  87. A Model term may carry a key that addresses it · ready · floor ready
  88. A keyed term is reified and its address resolves · ready · floor ready
  89. An address that names a term key no term carries is an error · ready · floor ready
  90. A term key repeated in one Spec refuses its carrier · ready · floor ready
  91. A term marker whose key is off the grammar refuses its carrier · ready · floor ready
  92. A keyed TypeScript term keeps its address through import to Markdown · ready · floor ready
  93. Carrier reification derives the one graph · ready · floor ready
  94. Resolving bindings confer direct delivery facts · ready · floor ready
  95. Committed source derives byte-identical output · ready · floor ready
  96. The build pipeline has one ordered flow · ready · floor ready
  97. One query invocation shares its extracted graph and validation result · ready · floor ready
  98. Extraction exclusions are strict consumer input · ready · floor ready
  99. A prefix excludes its own tree and leaves a similar sibling standing · ready · floor ready
  100. A Windows-drive absolute path is refused rather than normalized · ready · floor ready
  101. Graph claims retain their epistemic source · ready · floor ready
  102. Generated artifacts are disposable projections · ready · floor ready
  103. The graph declares its schema version · ready · floor ready
  104. A derived payload carries a schema version its consumer can read · ready · floor ready
  105. Bound examples execute their authored steps · ready · floor ready
  106. The build derives step and space contracts from graph examples · ready · floor ready
  107. An unbound slot in a used step earns no step contract · ready · floor ready
  108. A second structured entry is named, never left silently inert · ready · floor ready
  109. A case-only path collision withholds the whole contracts tree · ready · floor ready
  110. Pinned declarations give an adopter a derived module to typecheck · ready · floor ready
  111. Serialization preserves authored entry order · ready · floor ready
  112. Derived runnable modules freeze the registrar interface · ready · floor ready
  113. A bound example runs its contract steps against a fresh world · ready · floor ready
  114. A repeated step runs its one handler at each occurrence, in contract order · ready · floor ready
  115. A red step names itself before the assertion detail · ready · floor ready
  116. A Pack node keeps its members in authored order · ready · floor ready
  117. A manifest's member order survives into the graph and the reader · ready · floor ready
  118. The graph records where each addressable entry is written · ready · floor ready
  119. The graph records where anchored source cites an entry address · ready · floor ready
  120. A code file's comment cites a declaration without reading as a test line · ready · floor ready
  121. A test title in an anchored file cites a pinned declaration · ready · floor ready
  122. A file that carries no anchor is not read for citations · ready · floor ready
  123. A citation of an entry its Spec lacks reports through the recipe, never as a Protocol finding · ready · floor ready
  124. Stated readiness must clear its floor · ready · floor ready
  125. A scoped Spec with no relation names the relation clause · ready · floor ready
  126. A blocking open question holds a Spec below defined · ready · floor ready
  127. A ready Spec rests only on settled dependencies · ready · floor ready
  128. Every relation reads the four stated target rungs · ready · floor ready
  129. Missing targets fail relation resolution once · ready · floor ready
  130. An unsettled constraint bounds ready but permits defined · ready · floor ready
  131. Target floor failures do not propagate across dependencies · ready · floor ready
  132. Duplicate carrier IDs are excluded loudly · ready · floor ready
  133. TypeScript and Markdown duplicates are both refused · ready · floor ready
  134. Validation separates well-formedness from non-pretending · ready · floor ready
  135. One report carries both families and claims neither as its own · ready · floor ready
  136. Every graph reference resolves · ready · floor ready
  137. An unrelated missing target is a bare conformance error · ready · floor ready
  138. A unique near miss earns a did-you-mean suggestion · ready · floor ready
  139. Every Spec id written in prose resolves · ready · floor ready
  140. Graph claims and contracts stay distinct · ready · floor ready
  141. A binding edge cannot borrow the declared claim · ready · floor ready
  142. An unratified kind fails closed instead of reaching the floor · ready · floor ready
  143. Example verification and oracle bindings resolve honestly · ready · floor ready
  144. A declared verifier no test binds confers nothing · ready · floor ready
  145. An oracle targeting a Spec with no example space is refused · ready · floor ready
  146. An unbound example below ready is data, not a warning · ready · floor ready
  147. Below-ready examples keep declared verifier data · ready · floor ready
  148. Ready examples and non-example verifiers keep warnings · ready · floor ready
  149. Parent gaps follow enabled bindings and preserve the decision exemption · ready · floor ready
  150. Oracle eligibility follows example-space ownership · ready · floor ready
  151. A rule owning an example space accepts an oracle · ready · floor ready
  152. A target without an example space refuses an oracle · ready · floor ready
  153. Packs are coherent aggregates · ready · floor ready
  154. A repeated member and a non-model modelRef are both named · ready · floor ready
  155. Machine truth is never authored · ready · floor ready
  156. A delivery fact smuggled into a section is refused · ready · floor ready
  157. A stated delivery fact no binding earns is refused · ready · floor ready
  158. Missing connective evidence warns without failing · ready · floor ready
  159. A disconnected Spec warns and fails nothing · ready · floor ready
  160. A ready Spec without a verifier warns and fails nothing · ready · floor ready
  161. Each kind carries its own evidence · ready · floor ready
  162. Constraints alone stop short of complete behavior evidence · ready · floor ready
  163. A constraint without a machine-readable target is not complete · ready · floor ready
  164. An empty promoted child confers no evidence · ready · floor ready
  165. A constraint whose second entry has no target is not complete · ready · floor ready
  166. One diagnostic currency, its location composed from structured fields · ready · floor ready
  167. One finding, three location shapes, one composition rule · ready · floor ready
  168. The same three location shapes, rendered as table cells · ready · floor ready
  169. Every validator ships evidence in both directions · ready · floor ready
  170. Every shipped check reports its refusing probe and leaves its near miss alone · ready · floor ready
  171. A check that stops reporting is named silent · ready · floor ready
  172. A check that reports its near miss is named overeager · ready · floor ready
  173. A registered check without a probe pair is named unpaired · ready · floor ready
  174. A check paired twice is named · ready · floor ready
  175. A finding id the source writes outside every registry is named · ready · floor ready
  176. The floor names what blocks the floor's next rung · ready · floor ready
  177. A defined Spec resting on a scoped dependency is told which one · ready · floor ready
  178. A scoped Spec held by a blocking question is told the clause · ready · floor ready
  179. A Spec shaped by a superseded decision warns · ready · floor ready
  180. A Spec shaped by a replaced decision warns once and fails nothing · ready · floor ready
  181. The warning names the decision at the end of a chain of replacements · ready · floor ready
  182. A replacement chain that branches names every end · ready · floor ready
  183. A chain of replacements that closes on itself is named and fails nothing · ready · floor ready
  184. A dependency on a replaced decision raises no warning · ready · floor ready
  185. A superseded decision is not warned for the decision it names · ready · floor ready
  186. A replacement still below ready is named as it stands · ready · floor ready
  187. A decision still decided by the record it replaces warns · ready · floor ready
  188. A chain of replacements that reaches an end and a loop names both · ready · floor ready
  189. Declared architecture rules are checked against anchored structure · ready · floor ready
  190. A domain member that uses an infrastructure member breaks a forbidden pair · ready · floor ready
  191. The walk named as a rules file fails validation on an isolation breach · ready · floor ready
  192. A component with no layer leaves its edge unclassified · ready · floor ready
  193. Corpus-authored rules run on the one validation path · ready · floor ready
  194. A rules file that empties its graph leaves the next file's graph whole · ready · floor ready
  195. An error from a corpus rule fails validation and leaves the Protocol's line alone · ready · floor ready
  196. A finding with no subject fails its rules file · ready · floor ready
  197. Editing a parameter file starts a cycle that reads the new parameters · ready · floor ready
  198. Rewriting a rules file under node_modules starts a cycle that runs the new body · ready · floor ready
  199. A parameter file that stops being JSON fails only its own rules file, and the watcher runs on · ready · floor ready
  200. A warning from a corpus rule informs and passes · ready · floor ready
  201. A corpus checks the register tokens its prose cites · ready · floor ready
  202. A cited token the register lacks or retires fails a rules run · ready · floor ready
  203. A held token no Spec cites fails a rules run only when the caller asks · ready · floor ready
  204. Projections fan out from one graph without becoming truth stores · ready · floor ready
  205. Roadmap views read releases, baselines and phases from git and the graph · scoped · floor scoped
  206. Mechanical code structure stays inferred and apart from curated intent · ready · floor ready
  207. File-level imports show where curation is missing · ready · floor ready
  208. Exhaustive symbol reach waits for a language-neutral identity · idea · floor scoped
  209. Agents script a visible typed graph · ready · floor ready
  210. A scripted body returns claim-decoded context, pre-shaped by the body · ready · floor ready
  211. One body reaches every entry point the demand map names, and no symbol entry · ready · floor ready
  212. Recipe answers fit an agent's context and explain their misses · ready · floor ready
  213. The evaluation sink runs one body and prints its return · ready · floor ready
  214. A body calls a shipped recipe and returns its answer unchanged · ready · floor ready
  215. A call to a recipe the catalog does not hold fails the body · ready · floor ready
  216. A script holding a graph runs a shipped recipe through the exported evaluator · ready · floor ready
  217. Design Review renders graph context without becoming a gate · ready · floor ready
  218. The view is the graph read twice, and the corpus is untouched by reading it · ready · floor ready
  219. Census renders the runtime taxonomy without becoming a registry · ready · floor ready
  220. Mermaid renders bounded one-hop and Pack diagrams without becoming a graph browser · ready · floor ready
  221. Gherkin view renders any Spec as a disposable read shape · ready · floor ready
  222. The reader bridges agent entry points to composable graph context · ready · floor ready
  223. A concept recorded only inside a Spec's sections is still reached, and the field is named · ready · floor ready
  224. A source file reaches the Spec its binding names, and a carrier reaches its own Spec · ready · floor ready
  225. A changeset names what it reaches, why, and what it cannot see · ready · floor ready
  226. Views compose scoped intent instead of patching canonical source · ready · floor ready
  227. Authors move one Spec from intent to reviewed evidence · ready · floor ready
  228. The reading skill teaches agents to query the graph · ready · floor ready
  229. Delivery sessions route work from current graph state · ready · floor ready
  230. Authoring questions stay executable graph recipes · ready · floor ready
  231. Register questions stay executable graph recipes · ready · floor ready
  232. Composed intent hands off on one proposal shape · ready · floor ready
  233. The next body of work is planned from the graph, not from a prose index · ready · floor ready
  234. An adopter learns graph homes, carrier grammar and shipped paths from the on-ramps · ready · floor ready
  235. The package ships the Specs and on-ramps its skills cite · ready · floor ready
  236. Derived readiness renders beside the stated rung and warns in one direction · ready · floor ready
  237. An overstated rung raises the banner and names the clause that refused · ready · floor ready
  238. A rung the structure overshoots renders as information, not as a banner · ready · floor ready
  239. Views speak binding language, never the internal fact name · ready · floor ready
  240. A fully bound Spec renders binding language on the page and in the index · ready · floor ready
  241. The Pack member table speaks the page's binding language, not a shorthand · ready · floor ready
  242. Every view run rewrites the view wholesale · ready · floor ready
  243. A page from an earlier run does not survive the next one · ready · floor ready
  244. A page the build's invalidation never saw still does not survive the swap · ready · floor ready
  245. A run that cannot produce a current view leaves no view at all · ready · floor ready
  246. A build that never renders still takes the old view down · ready · floor ready
  247. Address resolution and dependency cycles stay executable graph recipes · ready · floor ready
  248. The shipped dependency-cycles file fails a rules run on a cycle · ready · floor ready
  249. The shipped address-resolution file fails a rules run on an address that names no entry · ready · floor ready
  250. A dependency chain with no cycle yields no finding · ready · floor ready
  251. The Spec Studio is a static HTML workbench over the one graph · ready · floor ready
  252. The index says where the corpus stands and narrows every Spec · ready · floor ready
  253. A Pack page shows the Pack's design as one card per member · ready · floor ready
  254. sdp studio publishes the Studio as one page set · ready · floor ready
  255. Search finds a Spec, a Pack, an entry or a bound file by a word · ready · floor ready
  256. A few custom elements filter, search, open and copy on a rendered page · ready · floor ready
  257. The Studio renders from the reader's values and embeds only what its script reads · ready · floor ready
  258. The Studio's shell frames every page with navigation, a rail and a canvas · ready · floor ready
  259. Five lenses read the graph as Packs, capabilities, architecture, tests and evidence · ready · floor ready
  260. A Spec page shows one Spec in collapsible panels, in a fixed order · ready · floor ready
  261. A Spec page's core shows the whole Spec, with an anchor for every entry · ready · floor ready
  262. The panels for examples, targets, verifiers and evidence · ready · floor ready
  263. A composing panel on every page gathers scoped intent for an agent · ready · floor ready
  264. The Studio's custom elements each hold one view the build renders · ready · floor ready
  265. The Studio reads on a phone as on a desktop · ready · floor ready
  266. A Studio build is stamped and shared from a static host · ready · floor ready
  267. The stamp is written beside the page set, and a later build removes it · ready · floor ready
  268. A page takes each recipe answer from the recipe's shipped body · ready · floor ready
  269. The Studio reads two named inputs beside the graph, a base graph and run records · ready · floor ready
  270. Without inputs the page set is the graph's alone · ready · floor ready
  271. Both inputs add their pages, named, and the same inputs write the same bytes · ready · floor ready
  272. sdp studio --watch rebuilds the page set on each carrier change · ready · floor ready
  273. Each watch cycle writes the page set a plain run writes · ready · floor ready
  274. Every page of the page set is reached from the top navigation and the index · ready · floor ready
  275. The Packs lens groups every Spec by the Packs that hold it · ready · floor ready
  276. The architecture lens draws components by context and layer, the planned beside the built · ready · floor ready
  277. The architecture page lists each component's significant units by role · ready · floor ready
  278. A component design no anchor realizes draws planned beside the built one · ready · floor ready
  279. The tests lens shows how far each Spec's verification reaches · ready · floor ready
  280. A Spec's row on the tests lens counts its exercised keyed rules · ready · floor ready
  281. The evidence lens names each source of runtime evidence and reads it as not tracked · ready · floor ready
  282. A Pack page's maturity map places every member by its stated rung and its floor · ready · floor ready
  283. A pinned declaration shows the test line that cites it · ready · floor ready
  284. Each keyed rule shows the examples that exercise it, or that none does · ready · floor ready
  285. The corpus's registers are pages a reviewer opens from a link · ready · floor ready
  286. The questions page lists the Specs with a blocking question first · ready · floor ready
  287. The owner queue page orders the statements and questions only a person can settle · ready · floor ready
  288. The owner queue lists a waiting statement after the one it rests on · ready · floor ready
  289. The diff page shows what changed in the design since a base graph · ready · floor ready
  290. The diff page shows a changed entry's base and built values · ready · floor ready
  291. The runs page shows the run records the build was given, joined to test files · ready · floor ready
  292. The runs page shows a run as external evidence from a test file · ready · floor ready
  293. The glossary page lists every term the corpus's Specs define · ready · floor ready
  294. A word two Specs define appears once per Spec on the glossary page · ready · floor ready
  295. Refreshing a tab keeps every gathered intent · ready · floor ready
  296. A diagram is laid out from graph values into SVG with a text equivalent · ready · floor ready
  297. An architecture within the bound draws in one diagram, the same bytes twice · ready · floor ready
  298. An architecture over the bound folds by context · ready · floor ready
  299. One context over the bound folds by layer · ready · floor ready
  300. A Pack exports as one file, and every page prints as a document · ready · floor ready
  301. A Pack's export opens alone and keeps its links inside it · ready · floor ready
  302. The Studio skill teaches agents to publish, share and read the Spec Studio · ready · floor ready
  303. The Pack context carries the Pack's design · ready · floor ready
  304. A Pack page shows where the Pack's design stands · ready · floor ready
  305. Recipes take parameters as data and ship as runnable files · ready · floor ready
  306. Design work reads its answers from catalog recipes · ready · floor ready
  307. The CLI names the engine that produced a result · ready · floor ready
  308. Validation re-runs while an author edits carriers · ready · floor ready
  309. Example spaces report which values their examples cover · ready · floor ready
  310. A literal no example binds is reported uncovered, and an unbound child is named · ready · floor ready
  311. A number slot is not enumerable and reports no uncovered value · ready · floor ready
  312. A Pack is read from a named perspective · ready · floor ready
  313. A context bundle is composed per invocation within a stated budget · ready · floor ready
  314. A Pack too large for one bundle reads whole in parts · ready · floor ready
  315. A member larger than the budget is named, and no part is returned · ready · floor ready
  316. Designs are compared between a base commit and the working tree at entry grain · ready · floor ready
  317. A change proposal is addressed, based and checked before it lands · ready · floor ready
  318. Recipe 49 renders a change proposal as the Markdown memo a person reviews · ready · floor ready
  319. Recipe 49 and the composing panel write one memo for one proposal · ready · floor ready
  320. A reference projection serves a reader outside the repository · idea · floor idea
  321. Mermaid diagrams can be rooted at code units · scoped · floor scoped
  322. An Obsidian vault lets a person iterate on designs from the one graph · ready · floor ready
  323. A fresh vault is written the same way twice and every link resolves · ready · floor ready
  324. A regeneration removes a note that left the graph and keeps a person's notes · ready · floor ready
  325. A note a person wrote inside the generated folder refuses the regeneration · ready · floor ready
  326. A generated note a person changed refuses the regeneration and keeps the edit · ready · floor ready
  327. A person's file under a temporary's name refuses the regeneration · ready · floor ready
  328. A vault directory the build removes refuses the run and keeps a person's notes · ready · floor ready
  329. A run after a stopped synchronization finishes it · ready · floor ready
  330. A failed extraction keeps the notes and says so on the index · ready · floor ready
  331. The run after a failed extraction passes the guard and restores the index · ready · floor ready
  332. Every Spec, Pack, code unit and keyed term is a note, and every relation is a link · ready · floor ready
  333. An entry address in prose opens the entry's block in its Spec's note · ready · floor ready
  334. A mention of an entry that does not exist stays as written · ready · floor ready
  335. A keyed Model term gets a note, and its address in prose opens the term's block · ready · floor ready
  336. Two Specs whose notes differ only in case refuse the run · ready · floor ready
  337. A Pack's members and the standing queries are tables over the reader's values · ready · floor ready
  338. Each standing view selects what its source selects · ready · floor ready
  339. A design pass is followed and answered from the vault · ready · floor ready
  340. A carrier edit under watch rewrites only the notes it changes · ready · floor ready
  341. An anchor added in a source file under watch rewrites the Spec's note · ready · floor ready
  342. The vault skill teaches agents to keep an Obsidian vault of the graph · ready · floor ready
  343. The readiness planner orders the statements a person can make · ready · floor ready
  344. The Spec another rests on comes first in the queue · ready · floor ready
  345. A waiting decision comes before the Spec it shapes · ready · floor ready
  346. Waiting Specs that rest on each other share a round and report a cycle · ready · floor ready
  347. An owner's blocking question lists the Specs it holds · ready · floor ready
  348. The upgrade kit shows a corpus what it could adopt · ready · floor ready
  349. Capability adoption counts where each capability is used and where it could apply · ready · floor ready
  350. Capability adoption counts keyed rules and reasoned relations · ready · floor ready
  351. The rule-key proposal keys every unkeyed rule as a change proposal · ready · floor ready
  352. A rule-key proposal passes the proposal check and validates once applied · ready · floor ready
  353. Two rules that coin one key stay apart, and a rule with no ASCII word stays unkeyed · ready · floor ready
  354. Every verb answers --help, and one verb writes every projection root · ready · floor ready
  355. A root that fails its check is removed while sdp generate writes the others · ready · floor ready
  356. One run of sdp generate leaves all five roots current · ready · floor ready
  357. A publisher's --help prints its help and touches no root · ready · floor ready
  358. The capability map reads every epic and its refinement descendants · ready · floor ready
  359. The capability map page makes refinement readable by epic · ready · floor ready
  360. The Studio chooses diagram kinds from graph values · ready · floor ready
  361. A diagram preserves readable labels before zoom · ready · floor ready
  362. Edges route around boxes with deterministic orthogonal paths · ready · floor ready
  363. A diagram offers Mermaid source as copyable text · ready · floor ready
  364. A dependency drawing shows the declared footing of a Spec set · ready · floor ready
  365. A refinement drawing follows the capability map · ready · floor ready
  366. A Spec set draws the architecture it touches · ready · floor ready
  367. The maturity map is drawn as a grid of counts · ready · floor ready
  368. A requirement drawing separates intent from realization and verification · ready · floor ready
  369. A slice reads a Pack as one design, with the architecture it touches and what each member needs next · ready · floor ready
  370. Outside components stop at the touched components' neighbors · ready · floor ready
  371. Members rest on a chain · ready · floor ready
  372. A shaping decision comes before its member · ready · floor ready
  373. A cycle shares a depth · ready · floor ready
  374. An example folds without lending its readiness · ready · floor ready
  375. An example with its own dependency stays unfolded · ready · floor ready
  376. An unanchored component design stays visible · ready · floor ready
  377. An anchor alone does not realize a component design · ready · floor ready
  378. A realized component matches its declared values · ready · floor ready
  379. A realized component keeps its differing layer and uses apart · ready · floor ready
  380. An unreadable declared layer stays visible · ready · floor ready
  381. A prerequisite reaches its satisfying component · ready · floor ready
  382. An unbound prerequisite invents no component · ready · floor ready
  383. An outside prerequisite names the member it holds · ready · floor ready
  384. A slice page shows a Pack's design as one whole · ready · floor ready
  385. A roadmap orders the next bodies of work, and the graph says what each still needs · ready · floor ready
  386. Built work stays on the roadmap · ready · floor ready
  387. A ready unbound part needs building · ready · floor ready
  388. A complete part waits for a statement · ready · floor ready
  389. An unfinished part needs design · ready · floor ready
  390. A binding below ready remains drift · ready · floor ready
  391. A descendant without evidence names its holding clause · ready · floor ready
  392. A descendant question holds the entry for design · ready · floor ready
  393. A descendant names its outside parent · ready · floor ready
  394. Waiting statements keep dependency order against roadmap places · ready · floor ready
  395. The roadmap page shows the upcoming work in priority order, split by what it needs · ready · floor ready
  396. A roadmap renders as the forward section of a pull request description · ready · floor ready
  397. A pinned declaration shows the words of each test line that cites it · scoped · floor scoped
  398. An outside register is a named Studio input, so a cited token links to its entry · scoped · floor scoped
  399. Runtime observations can close the liveness loop · idea · floor idea
  400. CI run records are joined to verifiers in a view · ready · floor ready
  401. A test whose reporter wrote an absolute path joins its anchored file · ready · floor ready
  402. A test in a file with no test anchor is reported as unjoined · ready · floor ready
  403. The Protocol authors and validates itself · ready · floor ready
  404. The engine's structural self-binding covers its architecturally significant units · ready · floor ready
  405. The engine's accepted set covers its significant abstractions and only those · ready · floor ready
  406. The engine's architectural roles each name one pattern · ready · floor ready
  407. The Protocol organizes its own features in capability epics · ready · floor ready
  408. The Protocol reads its next work from its roadmap and keeps its delivery record in git and its pull requests · ready · floor ready
  409. The Protocol removes its frozen plans, review reports and superseded concept material · idea · floor idea
  410. Durable references lead with meaning · ready · floor ready
  411. Concept documents may dissolve after executable truth lands · ready · floor ready
  412. Validation follows one graph · ready · floor ready
  413. Spec extensions identify the carrier without colliding with tests · ready · floor ready
  414. Each example binds one point · ready · floor ready
  415. Markdown is the default Spec carrier · ready · floor ready
  416. Prose belongs to typed graph owners · ready · floor ready
  417. The Protocol owns the envelope grammar · ready · floor ready
  418. Consumer exclusions stay exact · ready · floor ready
  419. The Protocol is an executable meta-model · ready · floor ready
  420. Delivery nouns remain familiar without workflow gates · ready · floor ready
  421. One Spec carries named delivery coordinates · ready · floor ready
  422. The meta-model is a software delivery protocol · ready · floor ready
  423. Bindings state existence, not liveness · ready · floor ready
  424. Sections carry content while relations carry links · ready · floor ready
  425. Floor-read sections are closed typed shapes · ready · floor ready
  426. Readiness evidence follows the Spec kind · ready · floor ready
  427. Promoted evidence must carry its own evidence · ready · floor ready
  428. Packs group review context without becoming truth · ready · floor ready
  429. Agents script the visible graph · ready · floor ready
  430. MCP integration remains deferred · ready · floor ready
  431. The agent front door is one evaluation sink over the exported reader · ready · floor ready
  432. Verification mode states posture, not realization · ready · floor ready
  433. Example realization stays evidence, not backlog work · ready · floor ready
  434. Packs have a Markdown manifest carrier · ready · floor ready
  435. Decision records state readiness from ratification evidence · ready · floor ready
  436. Behavior and example Specs may use Gherkin canonically · ready · floor ready
  437. Canonical Gherkin carriers use .sdp.gherkin · ready · floor ready
  438. Carrier universality is bounded by honest kind structure · ready · floor ready
  439. Adopted runnable registrars are committed · ready · floor ready
  440. The shipped projections stay frozen · ready · floor ready
  441. Planning truths live in ruled graph homes · ready · floor ready
  442. A Spec id written in prose is a checked mention · ready · floor ready
  443. The Design Review renders open-section entries as a list · ready · floor ready
  444. The Design Review shows an open question's key · ready · floor ready
  445. The Studio renders HTML, and the HTML stays derived · ready · floor ready
  446. The Studio is built from custom elements, not a framework · ready · floor ready
  447. The build renders every Studio view, and an element only enhances it · ready · floor ready
  448. The engine lays out every Studio diagram as static SVG when the page set is built · ready · floor ready
  449. The comment form is a second anchor representation · ready · floor ready
  450. Bindings are optional, plural, and may reference a design · ready · floor ready
  451. Architectural significance is annotated where it is realized · ready · floor ready
  452. The Design Review's Pack page presents the Pack's design · ready · floor ready
  453. The vault's generator owns one folder and synchronizes it · ready · floor ready
  454. A roadmap states advisory priority in the graph · ready · floor ready
  455. Plan and review files stop carrying the delivery record once the roadmap and the pull request do · ready · floor ready
  456. Capability epics keep kind independent of altitude · ready · floor ready
Spec Studio · pack:spec-studio-v1 · 64 members

Read the Pack page

  1. The Spec Studio is a static HTML workbench over the one graph · ready · floor ready
  2. The Studio renders HTML, and the HTML stays derived · ready · floor ready
  3. The Studio renders from the reader's values and embeds only what its script reads · ready · floor ready
  4. A page takes each recipe answer from the recipe's shipped body · ready · floor ready
  5. The Studio reads two named inputs beside the graph, a base graph and run records · ready · floor ready
  6. Without inputs the page set is the graph's alone · ready · floor ready
  7. Both inputs add their pages, named, and the same inputs write the same bytes · ready · floor ready
  8. sdp studio publishes the Studio as one page set · ready · floor ready
  9. sdp studio --watch rebuilds the page set on each carrier change · ready · floor ready
  10. Each watch cycle writes the page set a plain run writes · ready · floor ready
  11. The Studio's shell frames every page with navigation, a rail and a canvas · ready · floor ready
  12. Search finds a Spec, a Pack, an entry or a bound file by a word · ready · floor ready
  13. Every page of the page set is reached from the top navigation and the index · ready · floor ready
  14. Five lenses read the graph as Packs, capabilities, architecture, tests and evidence · ready · floor ready
  15. The Packs lens groups every Spec by the Packs that hold it · ready · floor ready
  16. The index says where the corpus stands and narrows every Spec · ready · floor ready
  17. The architecture lens draws components by context and layer, the planned beside the built · ready · floor ready
  18. The architecture page lists each component's significant units by role · ready · floor ready
  19. A component design no anchor realizes draws planned beside the built one · ready · floor ready
  20. The tests lens shows how far each Spec's verification reaches · ready · floor ready
  21. A Spec's row on the tests lens counts its exercised keyed rules · ready · floor ready
  22. Example spaces report which values their examples cover · ready · floor ready
  23. A literal no example binds is reported uncovered, and an unbound child is named · ready · floor ready
  24. A number slot is not enumerable and reports no uncovered value · ready · floor ready
  25. The evidence lens names each source of runtime evidence and reads it as not tracked · ready · floor ready
  26. A Pack page shows the Pack's design as one card per member · ready · floor ready
  27. A Pack page's maturity map places every member by its stated rung and its floor · ready · floor ready
  28. A Spec page shows one Spec in collapsible panels, in a fixed order · ready · floor ready
  29. A pinned declaration shows the test line that cites it · ready · floor ready
  30. A Spec page's core shows the whole Spec, with an anchor for every entry · ready · floor ready
  31. The panels for examples, targets, verifiers and evidence · ready · floor ready
  32. Each keyed rule shows the examples that exercise it, or that none does · ready · floor ready
  33. The corpus's registers are pages a reviewer opens from a link · ready · floor ready
  34. The questions page lists the Specs with a blocking question first · ready · floor ready
  35. The owner queue page orders the statements and questions only a person can settle · ready · floor ready
  36. The owner queue lists a waiting statement after the one it rests on · ready · floor ready
  37. The diff page shows what changed in the design since a base graph · ready · floor ready
  38. The diff page shows a changed entry's base and built values · ready · floor ready
  39. The runs page shows the run records the build was given, joined to test files · ready · floor ready
  40. The runs page shows a run as external evidence from a test file · ready · floor ready
  41. CI run records are joined to verifiers in a view · ready · floor ready
  42. A test whose reporter wrote an absolute path joins its anchored file · ready · floor ready
  43. A test in a file with no test anchor is reported as unjoined · ready · floor ready
  44. The glossary page lists every term the corpus's Specs define · ready · floor ready
  45. A word two Specs define appears once per Spec on the glossary page · ready · floor ready
  46. A composing panel on every page gathers scoped intent for an agent · ready · floor ready
  47. Refreshing a tab keeps every gathered intent · ready · floor ready
  48. Recipe 49 renders a change proposal as the Markdown memo a person reviews · ready · floor ready
  49. Recipe 49 and the composing panel write one memo for one proposal · ready · floor ready
  50. The Studio's custom elements each hold one view the build renders · ready · floor ready
  51. The Studio is built from custom elements, not a framework · ready · floor ready
  52. The build renders every Studio view, and an element only enhances it · ready · floor ready
  53. The engine lays out every Studio diagram as static SVG when the page set is built · ready · floor ready
  54. A diagram is laid out from graph values into SVG with a text equivalent · ready · floor ready
  55. An architecture within the bound draws in one diagram, the same bytes twice · ready · floor ready
  56. An architecture over the bound folds by context · ready · floor ready
  57. One context over the bound folds by layer · ready · floor ready
  58. A few custom elements filter, search, open and copy on a rendered page · ready · floor ready
  59. The Studio reads on a phone as on a desktop · ready · floor ready
  60. A Pack exports as one file, and every page prints as a document · ready · floor ready
  61. A Pack's export opens alone and keeps its links inside it · ready · floor ready
  62. A Studio build is stamped and shared from a static host · ready · floor ready
  63. The stamp is written beside the page set, and a later build removes it · ready · floor ready
  64. The Studio skill teaches agents to publish, share and read the Spec Studio · ready · floor ready

Specs

Filtering needs script. All Specs are shown.

456 of 456 shown

Findings

  • warning · honesty/gaps · spec:extraction.executable-examples · Spec "spec:extraction.executable-examples" states readiness "ready" with no resolving verifier — a gap, informative only (ready never requires delivery facts). · specs/extraction/executable-examples.sdp.md
  • warning · honesty/gaps · spec:model.spec-sections · Spec "spec:model.spec-sections" states readiness "ready" with no resolving verifier — a gap, informative only (ready never requires delivery facts). · specs/model/spec-sections.sdp.md
  • warning · honesty/gaps · spec:protocol.role-vocabulary · Spec "spec:protocol.role-vocabulary" states readiness "ready" with no resolving verifier — a gap, informative only (ready never requires delivery facts). · specs/protocol/role-vocabulary.sdp.md
Composing (0)

Composing needs the script.