None.

actor

A person in the repository who designs a capability in passes while an agent edits the carriers.

problem

The Markdown Design Review offers no built-in Pack filters or navigation from arbitrary prose mentions to their entries, so a person iterating on a design still reads carrier files alongside it.

outcome

Generate an Obsidian vault from the one graph, in which a person reads, navigates and filters the corpus and follows each pass's edits, while the carriers stay the only place intent is written.

risks

• A notes app invites editing, and an edit to a generated note never reaches the carrier.

The world writes a probe corpus of one Pack and its member Specs, runs the vault command with the vault under the root's generated/ directory unless a point names another, and reads the vault from disk; a second run reads the same graph. The world leaves a stopped run's files by running the command with its first rename failing, which leaves the file list recording both contents and a whole temporary beside its target, and a failed run's files by running it while the member's carrier is one the extractor refuses, then repairing that carrier. A fresh vault is one the command writes into an empty directory from the same graph.

rule.ownProjection line 39 · specs/consumers/obsidian-vault.sdp.md:39

The vault is a projection of its own, written only through its synchronization, which sdp vault and the verb that writes every projection root run, and no part of the Studio's page set.

no example exercises it

rule.verb line 40 · specs/consumers/obsidian-vault.sdp.md:40

sdp vault [root | --root PATH] [--exclude PATH]... [--out DIR] [--watch] validates the graph as sdp validate does and then synchronizes the vault at DIR, by default generated/obsidian-vault/ under the root; the root is given as an argument or by --root, never both, and defaults to the working directory, each exclusion is a root-relative path prefix as for the publishers, and --out resolves against the working directory; a root given both ways, --root or --out given twice or without a value, and any other option refuse the run.

spec:consumers.obsidian-vault.fresh-vault · enabled

rule.outsideExtraction line 41 · specs/consumers/obsidian-vault.sdp.md:41

A vault directory inside the root must lie under a directory discovery skips or under an excluded prefix, so no file in the vault is ever read as a carrier or a source; any other vault directory inside the root refuses the run before the build, writing and removing nothing.

no example exercises it

rule.apartFromBuild line 42 · specs/consumers/obsidian-vault.sdp.md:42

A vault directory that is, lies inside or holds a path the shared build writes or removes, as spec:consumers.obsidian-vault#design.buildOwnedPaths lists, refuses the run before the build, writing and removing nothing, so no build ever removes a file in the vault.

spec:consumers.obsidian-vault.vault-in-build-path-refused · enabled

rule.ownedFolder line 43 · specs/consumers/obsidian-vault.sdp.md:43

The command writes only the generated folder sdp/ inside the vault; Obsidian's settings, a person's intent notes and every other file of the vault lie outside it and are never written, moved or removed.

spec:consumers.obsidian-vault.fresh-vault · enabled, spec:consumers.obsidian-vault.person-notes-survive · enabled, spec:consumers.obsidian-vault.vault-in-build-path-refused · enabled

rule.guard line 44 · specs/consumers/obsidian-vault.sdp.md:44

Before the build and before any cleanup, a run inspects sdp/ and every entry under it, names that begin with a dot included, and refuses when sdp/ or an entry under it is a symbolic link or neither a file nor a directory, when the file list is not well formed, when a file other than the file list, the command's own temporaries and a .DS_Store file is one the list does not name, or when a listed file other than a .base file has bytes matching no content the list records for it; a refused run writes nothing, removes nothing, names each such path and exits 1. A .DS_Store file under sdp/ is ignored. A listed .base file whose bytes a person changed is kept, even when it leaves the generated set; the run warns with its path and the words delete it to regenerate, keeps its recorded content in the list, and goes on. Without a file list, every file under sdp/ other than .DS_Store is one the list does not name.

spec:consumers.obsidian-vault.changed-note-refused · enabled, spec:consumers.obsidian-vault.failed-extraction-recovered · enabled, spec:consumers.obsidian-vault.hidden-file-refused · enabled, spec:consumers.obsidian-vault.unknown-note-refused · enabled

rule.synchronize line 45 · specs/consumers/obsidian-vault.sdp.md:45

A run that passes the guard first removes each file the list names that the new set no longer holds, except a changed .base file; then it writes each generated file whose bytes differ from the file on disk through a temporary sibling renamed into place, except a changed .base file, leaves every file whose bytes already match untouched, removes every directory under sdp/ left empty, and writes the file list last.

spec:consumers.obsidian-vault.interrupted-run-recovered · enabled, spec:consumers.obsidian-vault.person-notes-survive · enabled

rule.interruptedRun line 46 · specs/consumers/obsidian-vault.sdp.md:46

Before it changes any file, a run records in the file list both the content each path holds and the content it will hold, so a run stopped at any point leaves every generated file other than a kept, changed .base file matching the list, and the next run recognizes each, and each whole temporary, as its own and completes the synchronization; a temporary cut short while it was written matches no recorded content, so the guard refuses it as unknown and the person deletes it.

spec:consumers.obsidian-vault.interrupted-run-recovered · enabled

rule.standsApart line 47 · specs/consumers/obsidian-vault.sdp.md:47

The vault is not one of the five projection roots the shared build rewrites: the build's invalidation never removes it, and the repository's projection suite does not certify it. The verb that writes every projection root also synchronizes the vault, at the directory sdp vault would use for the same root unless that verb names another, through the same directory checks and guard, before it publishes any root; a refusal there leaves the vault untouched and fails that run. sdp vault enters the shared build, so it removes the five projection roots as sdp validate does.

no example exercises it

rule.deterministic line 48 · specs/consumers/obsidian-vault.sdp.md:48

Without kept, changed .base files, two runs over one graph write byte-identical files under sdp/, the file list included, and no file there holds a time, a commit, an absolute path or a host name.

spec:consumers.obsidian-vault.fresh-vault · enabled

rule.linksResolve line 49 · specs/consumers/obsidian-vault.sdp.md:49

Every wikilink, embed and block link a generated note writes resolves to a file the run wrote or kept and, with a block, to a block id that file carries; no note links outside the vault, a carrier or source file is named by its root-relative path in a code span, and text in a code span or a fenced block, where Obsidian reads no link, is no link.

spec:consumers.obsidian-vault.fresh-vault · enabled

rule.findingsShown line 50 · specs/consumers/obsidian-vault.sdp.md:50

Findings never withhold the vault: a run over a graph with validation findings still synchronizes and returns the validation exit code. A finding whose subject is a Spec or a Pack with a note shows on that note; every other finding shows on the index with its severity, its validator, its file and line when known and its message; and the index counts every finding by severity.

no example exercises it

rule.failedExtraction line 51 · specs/consumers/obsidian-vault.sdp.md:51

A run whose extraction fails keeps every generated file but the index and the file list: it rewrites the index to open with a warning naming the failure, through the steps spec:consumers.obsidian-vault#rule.interruptedRun and spec:consumers.obsidian-vault#rule.synchronize state, so the file list ends recording the warning index, and exits 1. The next run that succeeds finds the index matching the list and writes it whole again; with no earlier run, the failed run leaves only that index and the file list under sdp/.

spec:consumers.obsidian-vault.failed-extraction-keeps-notes · enabled, spec:consumers.obsidian-vault.failed-extraction-recovered · enabled

rule.plainNotes line 52 · specs/consumers/obsidian-vault.sdp.md:52

Notes are plain Markdown with YAML properties, wikilinks and block ids, which other notes tools read; only the .base files are Obsidian's own.

no example exercises it

rule.openAsVault line 53 · specs/consumers/obsidian-vault.sdp.md:53

A person opens the vault directory itself as an Obsidian vault, and every link and Base filter names its target by a path from that directory.

no example exercises it

0 unkeyed rules.

Verifying examples

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given a vault whose generated folder holds {generated: "the files an earlier run wrote"}
Given the vault holds {extra: "a generated note a person changed"}
Given the member {change: "stays in the corpus"}
When the vault command runs at that root
Then the run exits {exitCode: 1}
Then the run refuses the path {refusedPath: "sdp/specs/probe/spec.probe.member.md"} as {refusal: "changed"}
Then every file the person wrote is byte-identical: {personFilesKept: true}

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given a vault whose generated folder holds {generated: "the files an earlier run wrote"}
Given the vault holds {extra: "an intent note and Obsidian settings outside the generated folder"}
Given the member {change: "has a carrier the extractor refuses"}
When the vault command runs at that root
Then the run exits {exitCode: 1}
Then the member's note is present: {memberNote: true}
Then the index note warns that the last regeneration failed: {indexWarns: true}
Then every generated file matches a content the file list records for it: {listMatches: true}
Then every file the person wrote is byte-identical: {personFilesKept: true}

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given a vault whose generated folder holds {generated: "the files a run whose extraction failed left"}
Given the vault holds {extra: "an intent note and Obsidian settings outside the generated folder"}
Given the member {change: "stays in the corpus"}
When the vault command runs at that root
Then the run exits {exitCode: 0}
Then the index note warns that the last regeneration failed: {indexWarns: false}
Then the generated folder is byte-identical to a fresh vault's, the file list included: {matchesFresh: true}
Then every file the person wrote is byte-identical: {personFilesKept: true}

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given a vault whose generated folder holds {generated: "nothing"}
Given the vault holds {extra: "no other file"}
Given the member {change: "stays in the corpus"}
When the vault command runs at that root
Then the run exits {exitCode: 0}
Then a second run over the same graph leaves every generated file byte-identical: {byteIdentical: true}
Then the member's note is present: {memberNote: true}
Then every link a generated note writes resolves inside the vault: {linksResolve: true}

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given a vault whose generated folder holds {generated: "the files an earlier run wrote"}
Given the vault holds {extra: "a file a person wrote inside the generated folder under a temporary's name"}
Given the member {change: "stays in the corpus"}
When the vault command runs at that root
Then the run exits {exitCode: 1}
Then the run refuses the path {refusedPath: "sdp/specs/probe/.spec.probe.member.md.sdp-tmp"} as {refusal: "unknown"}
Then every file the person wrote is byte-identical: {personFilesKept: true}

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given a vault whose generated folder holds {generated: "the files a run stopped at its first rename left"}
Given the vault holds {extra: "an intent note and Obsidian settings outside the generated folder"}
Given the member {change: "changes its title"}
When the vault command runs at that root
Then the run exits {exitCode: 0}
Then the generated folder is byte-identical to a fresh vault's, the file list included: {matchesFresh: true}
Then every file the person wrote is byte-identical: {personFilesKept: true}

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given a vault whose generated folder holds {generated: "the files an earlier run wrote"}
Given the vault holds {extra: "an intent note and Obsidian settings outside the generated folder"}
Given the member {change: "leaves the corpus"}
When the vault command runs at that root
Then the run exits {exitCode: 0}
Then the member's note is present: {memberNote: false}
Then every file the person wrote is byte-identical: {personFilesKept: true}
Then every link a generated note writes resolves inside the vault: {linksResolve: true}

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given a vault whose generated folder holds {generated: "the files an earlier run wrote"}
Given the vault holds {extra: "a note a person wrote inside the generated folder"}
Given the member {change: "leaves the corpus"}
When the vault command runs at that root
Then the run exits {exitCode: 1}
Then the run refuses the path {refusedPath: "sdp/specs/probe/mine.md"} as {refusal: "unknown"}
Then the member's note is present: {memberNote: true}
Then every file the person wrote is byte-identical: {personFilesKept: true}

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given the vault command names the vault directory {out: "generated/design-review"}
Given a vault whose generated folder holds {generated: "nothing"}
Given the vault holds {extra: "an intent note and Obsidian settings outside the generated folder"}
When the vault command runs at that root
Then the run exits {exitCode: 1}
Then the run refuses the vault directory as {placement: "overlapping a path the build owns"}
Then every file the person wrote is byte-identical: {personFilesKept: true}

Example space

Given an extraction root holding a Pack and its member Specs, among them {member:string}
Given the vault command names the vault directory {out:string}
Given a vault whose generated folder holds {generated:"nothing"|"the files an earlier run wrote"|"the files a run stopped at its first rename left"|"the files a run whose extraction failed left"}
Given the vault holds {extra:"no other file"|"an intent note and Obsidian settings outside the generated folder"|"a note a person wrote inside the generated folder"|"a file a person wrote inside the generated folder under a temporary's name"|"a generated note a person changed"}
Given the member {change:"stays in the corpus"|"leaves the corpus"|"changes its title"|"has a carrier the extractor refuses"}
When the vault command runs at that root
Then the run exits {exitCode:number}
Then the run refuses the path {refusedPath:string} as {refusal:"unknown"|"changed"}
Then the run refuses the vault directory as {placement:"overlapping a path the build owns"|"inside the extraction"}
Then the index note warns that the last regeneration failed: {indexWarns:boolean}
Then every generated file matches a content the file list records for it: {listMatches:boolean}
Then the generated folder is byte-identical to a fresh vault's, the file list included: {matchesFresh:boolean}
Then a second run over the same graph leaves every generated file byte-identical: {byteIdentical:boolean}
Then the member's note is present: {memberNote:boolean}
Then every file the person wrote is byte-identical: {personFilesKept:boolean}
Then every link a generated note writes resolves inside the vault: {linksResolve:boolean}

layout line 56 · specs/consumers/obsidian-vault.sdp.md:56

the generated folder sdp/ holds index.md, specs.base, specs/<family>/<note>.md, packs/<note>.md beside packs/<note>.base, code/<namespace>/<note>.md, terms/<note>.md and the file list .sdp-vault.json; <family> is the first segment of a Spec's path, <namespace> a code unit's or anchor's namespace, and <note> the note name spec:consumers.obsidian-vault.notes#design.noteName states.

fileList line 57 · specs/consumers/obsidian-vault.sdp.md:57

{ "schema": "sdp-vault/1", "files": { "<path under sdp/>": ["<sha256 hex of the file's bytes>"] } } in sdp/.sdp-vault.json, paths sorted in code-unit order, JSON with two-space indentation and a closing newline; a path lists one content after a completed run and at most two while a run is under way, the content it held first.

no citation recorded

wellFormedList line 58 · specs/consumers/obsidian-vault.sdp.md:58

a file list is well formed when it parses to the fileList shape, every path is relative to sdp/, /-separated, with no empty, . or .. segment, and names neither the file list nor a temporary, every content is 64 lowercase hex digits, every path lists one or two contents, and the file's bytes equal the serialization spec:consumers.obsidian-vault#design.fileList states of what it parses to, so a repeated or reordered path is not well formed.

temporaryName line 59 · specs/consumers/obsidian-vault.sdp.md:59

a file is written as .<name>.sdp-tmp in its own directory and renamed over <name>; a temporary a run finds is the command's own only when its bytes match a content the file list records for <name>, and the run removes it after the guard passes; the file list's own temporary is the command's own only when it is itself a well-formed file list; any other file of a temporary's name is one the list does not name.

buildOwnedPaths line 60 · specs/consumers/obsidian-vault.sdp.md:60

under the root, generated/graph.json, generated/contracts/, generated/registrars.json, generated/imports.json, generated/design-review/, generated/census/, generated/mermaid/, generated/gherkin/ and generated/spec-studio/, each with its .tmp sibling, and every path the shared build comes to write or remove.

Cited at

• test/skills.test.ts:2037

guardMessage line 61 · specs/consumers/obsidian-vault.sdp.md:61

one stderr line per refused path, with <path> relative to the vault: sdp vault: <path> is not a file this command wrote (unknown), sdp vault: <path> has changed since this command wrote it (changed), sdp vault: <path> is a link or a special file, which this command never writes (not a file) or sdp vault: sdp/.sdp-vault.json is not a file list this command wrote (malformed); then sdp vault: nothing was written or removed; keep what you wrote outside sdp/, then delete each refused path, or delete sdp/ whole.

outsideExtractionMessage line 62 · specs/consumers/obsidian-vault.sdp.md:62

sdp vault: the vault <out> lies inside the root and would be read as source; choose a directory under generated/, under an excluded prefix, or outside the root.

no citation recorded

buildOwnedMessage line 63 · specs/consumers/obsidian-vault.sdp.md:63

sdp vault: the vault <out> overlaps <path>, which every build rewrites or removes; choose another directory, such as generated/obsidian-vault/, with <path> the first overlapping path in the order spec:consumers.obsidian-vault#design.buildOwnedPaths lists them.

no citation recorded

summaryLine line 64 · specs/consumers/obsidian-vault.sdp.md:64

on stdout after a synchronization, Wrote <out>/sdp (<n> files: <w> written, <u> unchanged, <r> removed).

exitCodes line 65 · specs/consumers/obsidian-vault.sdp.md:65

0 when the vault is synchronized over a graph with no validation error; the validation exit code when it is synchronized over one with errors; 1 on a refused option, a refused vault directory, a guard refusal, a case collision, a failed extraction or a write that fails.

indexNote line 66 · specs/consumers/obsidian-vault.sdp.md:66

sdp/index.md opens with > [!info] Generated by `sdp vault` from the graph. Every file under `sdp/` is regenerated, except a `.base` file you changed: write your own notes outside it, and intent notes in `intent/`. , then # Spec graph, the finding counts by severity, ## Findings without a note with one line per finding whose subject has no Spec or Pack note, in report order, the corpus Base embedded, and a link to each Pack note in id order.

no citation recorded

findingLine line 67 · specs/consumers/obsidian-vault.sdp.md:67

- <severity> · <validator id> · <file>:<line> · <message>, leaving out the file and line when the finding names none and the line when it names only a file, with the message escaped as spec:consumers.obsidian-vault.notes#rule.textEscaped states.

no citation recorded

failedIndex line 68 · specs/consumers/obsidian-vault.sdp.md:68

after a failed extraction, sdp/index.md opens with > [!warning] The last regeneration failed, and the notes show the graph of the last one that succeeded. followed by one line per extraction error, its root-relative file and its message.

Verifier bindings

• spec:consumers.obsidian-vault.changed-note-refused · A generated note a person changed refuses the regeneration and keeps the edit · declared · example enabled · specs/consumers/obsidian-vault.changed-note-refused.sdp.md
• spec:consumers.obsidian-vault.failed-extraction-keeps-notes · A failed extraction keeps the notes and says so on the index · declared · example enabled · specs/consumers/obsidian-vault.failed-extraction-keeps-notes.sdp.md
• spec:consumers.obsidian-vault.failed-extraction-recovered · The run after a failed extraction passes the guard and restores the index · declared · example enabled · specs/consumers/obsidian-vault.failed-extraction-recovered.sdp.md
• spec:consumers.obsidian-vault.fresh-vault · A fresh vault is written the same way twice and every link resolves · declared · example enabled · specs/consumers/obsidian-vault.fresh-vault.sdp.md
• spec:consumers.obsidian-vault.hidden-file-refused · A person's file under a temporary's name refuses the regeneration · declared · example enabled · specs/consumers/obsidian-vault.hidden-file-refused.sdp.md
• spec:consumers.obsidian-vault.interrupted-run-recovered · A run after a stopped synchronization finishes it · declared · example enabled · specs/consumers/obsidian-vault.interrupted-run-recovered.sdp.md
• spec:consumers.obsidian-vault.person-notes-survive · A regeneration removes a note that left the graph and keeps a person's notes · declared · example enabled · specs/consumers/obsidian-vault.person-notes-survive.sdp.md
• spec:consumers.obsidian-vault.unknown-note-refused · A note a person wrote inside the generated folder refuses the regeneration · declared · example enabled · specs/consumers/obsidian-vault.unknown-note-refused.sdp.md
• spec:consumers.obsidian-vault.vault-in-build-path-refused · A vault directory the build removes refuses the run and keeps a person's notes · declared · example enabled · specs/consumers/obsidian-vault.vault-in-build-path-refused.sdp.md

Requirement drawing

Decisions

• spec:decisions.shipped-projections-frozen

  Re-specifying the shipped Design Review, census, Mermaid, or Gherkin projection is refused. These four projections are the ruled read surfaces over the one graph. A later decision Spec that supersedes this one replaces the ruling whole; a decision Spec that refines this one narrows it for one projection or one rendering and leaves the rest frozen. Either passes the ADR three-part test.

• The vault's generator owns one folder and synchronizes it

  The vault's generator owns one folder of the vault, sdp/, and keeps there a file list naming every file it wrote with a hash of its content. A .DS_Store file under sdp/ is ignored. A listed .base file a person changed is kept, even when it leaves the generated set, with its recorded content unchanged in the list; the run warns with its path and the words delete it to regenerate and goes on. For every other file, a run refuses, writing and removing nothing, while that folder holds a file the list does not name or one whose content the list does not record. Otherwise it synchronizes the folder: it writes the files whose content changed, leaves the others untouched, and removes the files it wrote that the graph no longer holds. The vault is not one of the projection roots the shared build rewrites: no build removes it, a vault directory where the build writes or removes is refused, and only the vault's synchronization writes it, whether sdp vault or the verb that writes every projection root runs it.

• component:protocol.cli · entry points, shared build and publication · src/cli/build-command.ts:32 · layer edge · context protocol

  Uses

  • component:protocol.adapters · external runtime and source adapters · src/adapters/vitest.ts:23 · layer adapter · context protocol
  • component:protocol.codegen · contracts and registrar output · src/codegen/contracts.ts:633 · layer application · context protocol
  • component:protocol.extract · the carrier and source pipeline · src/extract/index.ts:192 · layer application · context protocol
  • component:protocol.graph · the one graph and its semantic decisions · src/graph/schema.ts:34 · layer domain · context protocol
  • component:protocol.import · canonical conversion with a fidelity boundary · src/import/import.ts:45 · layer application · context protocol
  • component:protocol.model · the authored contracts and stable ids · src/model/anchors.ts:100 · layer domain · context protocol
  • component:protocol.projections · read-only output, layout and owned publication · src/projections/design-review.ts:29 · layer edge · context protocol
  • component:protocol.reader · the typed graph contract and body evaluator · src/reader/reader.ts:671 · layer application · context protocol
  • component:protocol.validate · one finding currency and ordered checks · src/validate/validators.ts:72 · layer domain · context protocol
• component:protocol.projections · read-only output, layout and owned publication · src/projections/design-review.ts:29 · layer edge · context protocol

  Uses

  • component:protocol.extract · the carrier and source pipeline · src/extract/index.ts:192 · layer application · context protocol
  • component:protocol.graph · the one graph and its semantic decisions · src/graph/schema.ts:34 · layer domain · context protocol
  • component:protocol.model · the authored contracts and stable ids · src/model/anchors.ts:100 · layer domain · context protocol
  • component:protocol.notation · the leaf step codec · src/notation/slots.ts:261 · layer domain · context protocol
  • component:protocol.reader · the typed graph contract and body evaluator · src/reader/reader.ts:671 · layer application · context protocol
  • component:protocol.validate · one finding currency and ordered checks · src/validate/validators.ts:72 · layer domain · context protocol
• impl:protocol.vault-command · validates after vault preflight and retains prior notes behind a failed-extraction index · src/cli/vault-command.ts:191

  Component: component:protocol.cli · entry points, shared build and publication · src/cli/build-command.ts:32 · layer edge · context protocol

  Uses

  • component:protocol.projections · read-only output, layout and owned publication · src/projections/design-review.ts:29 · layer edge · context protocol
• impl:protocol.vault-notes · renders reader contexts, declared relations and keyed terms as linked notes · src/projections/vault/notes.ts:45

  Component: component:protocol.projections · read-only output, layout and owned publication · src/projections/design-review.ts:29 · layer edge · context protocol

  Uses

  • impl:protocol.reader · typed graph queries, entry adapters and context joins · src/reader/reader.ts:687
• impl:protocol.vault-sync · guards every owned entry and records transitional hashes before atomic file replacement · src/projections/vault/sync.ts:98

  Component: component:protocol.projections · read-only output, layout and owned publication · src/projections/design-review.ts:29 · layer edge · context protocol

  Uses

  None.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Regenerate the vault from the one graph as often as a design pass needs without ever removing or rewriting a note a person wrote in it.

context

Every projection root is rewritten wholesale, and every command that enters the shared build removes all of them first, because an absent view is honest and a stale one is not. A vault is different: a person keeps it open in Obsidian, keeps Obsidian's settings in it, and writes intent notes beside the generated ones.

decision

The vault's generator owns one folder of the vault, sdp/, and keeps there a file list naming every file it wrote with a hash of its content. A .DS_Store file under sdp/ is ignored. A listed .base file a person changed is kept, even when it leaves the generated set, with its recorded content unchanged in the list; the run warns with its path and the words delete it to regenerate and goes on. For every other file, a run refuses, writing and removing nothing, while that folder holds a file the list does not name or one whose content the list does not record. Otherwise it synchronizes the folder: it writes the files whose content changed, leaves the others untouched, and removes the files it wrote that the graph no longer holds. The vault is not one of the projection roots the shared build rewrites: no build removes it, a vault directory where the build writes or removes is refused, and only the vault's synchronization writes it, whether sdp vault or the verb that writes every projection root runs it.

rationale

• A wholesale rewrite removes whatever a person put in the root, and a regeneration that removes or rewrites a note a person wrote is refused.
• Writing only the files that changed keeps every other note's bytes and modification time, so Obsidian keeps a person's place while a pass runs; a wholesale rename shows Obsidian every note removed and created again.
• A list of written contents tells the generator's files from a person's without marking any note, and it is a function of the graph like the notes it lists, so the vault keeps its determinism.

alternatives

• Rewrite the folder wholesale through a temporary sibling, as the five roots are rewritten; refused, because it moves a reader off their place and removes any note a person left in the folder.
• Overwrite a generated note a person changed and report it afterwards; refused, because the overwrite loses what the person wrote.
• Mark each generated note with a hash in its own properties; refused, because a person's copy of a generated note carries a valid mark and would be removed as stale, and the mark shows on every note.
• Make the vault a sixth projection root; refused, because the shared build's invalidation would remove a person's intent notes with it.

consequences

• While a run is under way the folder may hold notes of two generations, each note whole, and the file list lets the next run recognize what an interrupted run left.
• A run whose extraction fails keeps the last notes and says so on the index note, so a broken carrier never empties the vault a person is reading.
• The vault's determinism is checked by tests, since the repository's projection suite certifies the five projection roots only.

Verifier bindings

No verifier binding recorded.

Requirement drawing

• Declared verifying examples: no declared verifying example.
• Test or oracle bindings: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Execute the verb, the generated folder, determinism and link resolution on a vault the command writes for the first time.

Examples

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given a vault whose generated folder holds {generated: "nothing"}
Given the vault holds {extra: "no other file"}
Given the member {change: "stays in the corpus"}
When the vault command runs at that root
Then the run exits {exitCode: 0}
Then a second run over the same graph leaves every generated file byte-identical: {byteIdentical: true}
Then the member's note is present: {memberNote: true}
Then every link a generated note writes resolves inside the vault: {linksResolve: true}

Verifier bindings

• test:protocol.consumers.obsidian-vault.fresh-vault · anchored · test anchor binding present · test/vault-examples.test.ts:653

Requirement drawing

• Satisfying or referencing units: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Execute synchronization on a vault holding a person's intent note and Obsidian's settings while a Spec leaves the corpus.

Examples

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given a vault whose generated folder holds {generated: "the files an earlier run wrote"}
Given the vault holds {extra: "an intent note and Obsidian settings outside the generated folder"}
Given the member {change: "leaves the corpus"}
When the vault command runs at that root
Then the run exits {exitCode: 0}
Then the member's note is present: {memberNote: false}
Then every file the person wrote is byte-identical: {personFilesKept: true}
Then every link a generated note writes resolves inside the vault: {linksResolve: true}

Verifier bindings

• test:protocol.consumers.obsidian-vault.person-notes-survive · anchored · test anchor binding present · test/vault-examples.test.ts:660

Requirement drawing

• Satisfying or referencing units: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Execute the guard on a file the command never wrote, left inside its generated folder.

Examples

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given a vault whose generated folder holds {generated: "the files an earlier run wrote"}
Given the vault holds {extra: "a note a person wrote inside the generated folder"}
Given the member {change: "leaves the corpus"}
When the vault command runs at that root
Then the run exits {exitCode: 1}
Then the run refuses the path {refusedPath: "sdp/specs/probe/mine.md"} as {refusal: "unknown"}
Then the member's note is present: {memberNote: true}
Then every file the person wrote is byte-identical: {personFilesKept: true}

Verifier bindings

• test:protocol.consumers.obsidian-vault.unknown-note-refused · anchored · test anchor binding present · test/vault-examples.test.ts:667

Requirement drawing

• Satisfying or referencing units: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Execute the guard on a generated note whose bytes a person changed after the command wrote it.

Examples

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given a vault whose generated folder holds {generated: "the files an earlier run wrote"}
Given the vault holds {extra: "a generated note a person changed"}
Given the member {change: "stays in the corpus"}
When the vault command runs at that root
Then the run exits {exitCode: 1}
Then the run refuses the path {refusedPath: "sdp/specs/probe/spec.probe.member.md"} as {refusal: "changed"}
Then every file the person wrote is byte-identical: {personFilesKept: true}

Verifier bindings

• test:protocol.consumers.obsidian-vault.changed-note-refused · anchored · test anchor binding present · test/vault-examples.test.ts:674

Requirement drawing

• Satisfying or referencing units: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Execute the guard on a file whose name begins with a dot and reads as a temporary of a generated note, but whose bytes the file list does not record.

Examples

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given a vault whose generated folder holds {generated: "the files an earlier run wrote"}
Given the vault holds {extra: "a file a person wrote inside the generated folder under a temporary's name"}
Given the member {change: "stays in the corpus"}
When the vault command runs at that root
Then the run exits {exitCode: 1}
Then the run refuses the path {refusedPath: "sdp/specs/probe/.spec.probe.member.md.sdp-tmp"} as {refusal: "unknown"}
Then every file the person wrote is byte-identical: {personFilesKept: true}

Verifier bindings

• test:protocol.consumers.obsidian-vault.hidden-file-refused · anchored · test anchor binding present · test/vault-examples.test.ts:681

Requirement drawing

• Satisfying or referencing units: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Execute the refusal of a vault directory inside a projection root the shared build removes, and show that a person's notes there survive.

Examples

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given the vault command names the vault directory {out: "generated/design-review"}
Given a vault whose generated folder holds {generated: "nothing"}
Given the vault holds {extra: "an intent note and Obsidian settings outside the generated folder"}
When the vault command runs at that root
Then the run exits {exitCode: 1}
Then the run refuses the vault directory as {placement: "overlapping a path the build owns"}
Then every file the person wrote is byte-identical: {personFilesKept: true}

Verifier bindings

• test:protocol.consumers.obsidian-vault.vault-in-build-path-refused · anchored · test anchor binding present · test/vault-examples.test.ts:688

Requirement drawing

• Satisfying or referencing units: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Execute the recovery from a run stopped at its first rename, which left the file list recording both contents and a whole temporary beside its target.

Examples

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given a vault whose generated folder holds {generated: "the files a run stopped at its first rename left"}
Given the vault holds {extra: "an intent note and Obsidian settings outside the generated folder"}
Given the member {change: "changes its title"}
When the vault command runs at that root
Then the run exits {exitCode: 0}
Then the generated folder is byte-identical to a fresh vault's, the file list included: {matchesFresh: true}
Then every file the person wrote is byte-identical: {personFilesKept: true}

Verifier bindings

• test:protocol.consumers.obsidian-vault.interrupted-run-recovered · anchored · test anchor binding present · test/vault-examples.test.ts:695

Requirement drawing

• Satisfying or referencing units: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Execute a run whose extraction fails over a vault an earlier run wrote, which keeps every note, rewrites the index with a warning and records it in the file list.

Examples

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given a vault whose generated folder holds {generated: "the files an earlier run wrote"}
Given the vault holds {extra: "an intent note and Obsidian settings outside the generated folder"}
Given the member {change: "has a carrier the extractor refuses"}
When the vault command runs at that root
Then the run exits {exitCode: 1}
Then the member's note is present: {memberNote: true}
Then the index note warns that the last regeneration failed: {indexWarns: true}
Then every generated file matches a content the file list records for it: {listMatches: true}
Then every file the person wrote is byte-identical: {personFilesKept: true}

Verifier bindings

• test:protocol.consumers.obsidian-vault.failed-extraction-keeps-notes · anchored · test anchor binding present · test/vault-examples.test.ts:702

Requirement drawing

• Satisfying or referencing units: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Execute the run that follows a failed extraction once the carrier is repaired: the guard accepts the warning index the failed run recorded, and the vault ends as a fresh one would.

Examples

Given an extraction root holding a Pack and its member Specs, among them {member: "spec:probe.member"}
Given a vault whose generated folder holds {generated: "the files a run whose extraction failed left"}
Given the vault holds {extra: "an intent note and Obsidian settings outside the generated folder"}
Given the member {change: "stays in the corpus"}
When the vault command runs at that root
Then the run exits {exitCode: 0}
Then the index note warns that the last regeneration failed: {indexWarns: false}
Then the generated folder is byte-identical to a fresh vault's, the file list included: {matchesFresh: true}
Then every file the person wrote is byte-identical: {personFilesKept: true}

Verifier bindings

• test:protocol.consumers.obsidian-vault.failed-extraction-recovered · anchored · test anchor binding present · test/vault-examples.test.ts:712

Requirement drawing

• Satisfying or referencing units: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Write one note per Spec, Pack, code unit, test anchor, oracle anchor and keyed Model term, with graph and reader values as properties and every declared relation and checked mention as a wikilink, so a person follows the graph in both directions.

The world writes a probe corpus whose Specs mention each other, runs the vault command, and reads the mentioning Spec's note from disk. A keyed Model term is written as spec:model.term-addresses states.

rule.oneNotePer line 26 · specs/consumers/obsidian-vault.notes.sdp.md:26

The vault holds one note per Spec, Pack, code unit, test anchor and oracle anchor, and one per Model term that carries a key, which spec:model.term-addresses gives an address; a term without a key appears only in its Spec's note, since no address can name it, and a ratified glossary term gains a note only where a Spec's Model section defines it with a key.

spec:consumers.obsidian-vault.notes.term-address-link · enabled

rule.termNoteGrain line 27 · specs/consumers/obsidian-vault.notes.sdp.md:27

A term defined in several Specs gets one note per defining Spec and term, so each definition keeps its authored owner; the term's aliases bring the notes together when a person types it.

no example exercises it

rule.noteNames line 28 · specs/consumers/obsidian-vault.notes.sdp.md:28

A note is named by its id with the colon after the namespace replaced by a dot, and a term note by term., its Spec's path, a dot and its key; one vault holds the notes of one corpus.

spec:consumers.obsidian-vault.notes.entry-address-link · enabled

rule.caseCollision line 29 · specs/consumers/obsidian-vault.notes.sdp.md:29

Two notes whose paths differ only in case refuse the run before it writes, naming both ids, so no two names collide on a file system that ignores case; the run writes and removes nothing and exits 1.

spec:consumers.obsidian-vault.notes.case-collision-refused · enabled

rule.idInAliases line 30 · specs/consumers/obsidian-vault.notes.sdp.md:30

A note's id, colon included, is written as plain text only in its aliases property and in the code span of its head line, since Obsidian shows an alias as plain text; a property that names another node holds a link to its note, and no other property value the generator composes is an id or an entry address. Authored text in a property, such as a title or a label, is written as authored, and the generator never treats one that looks like an address as an address.

spec:consumers.obsidian-vault.notes.entry-address-link · enabled

rule.readerProperties line 31 · specs/consumers/obsidian-vault.notes.sdp.md:31

A Spec note's properties are the reader's values for that Spec, listed under spec:consumers.obsidian-vault.notes#design.specProperties; every join, delivery fact, floor and rung among them is one the reader computed, and the generator computes none.

no example exercises it

rule.bindingProperties line 32 · specs/consumers/obsidian-vault.notes.sdp.md:32

A Spec's bindings are two booleans, implementationBinding true where the reader's delivery facts hold implemented and verifierBinding true where they hold has-verifier, and the note's body renders the four binding lines spec:consumers.binding-language-views states, so no rendered label is a delivery-fact name.

no example exercises it

rule.relationsBothWays line 33 · specs/consumers/obsidian-vault.notes.sdp.md:33

Each declared relation whose two ends have notes is a link on the notes at both ends, with its type, its reason, and for an example's verifies a link to the block of each rule it exercises in the verified Spec's note; an end with no note, such as a target that does not resolve, and an exercised key the verified Spec does not carry, appear on the source note as their id or key in a code span, with no link.

no example exercises it

rule.blockIds line 34 · specs/consumers/obsidian-vault.notes.sdp.md:34

Each keyed Design and UI entry, keyed open question, keyed rule or flow, and keyed Model term ends its line in its Spec's note with the block id ^<section>-<key>, with section design, ui, question, rule or term.

spec:consumers.obsidian-vault.notes.entry-address-link · enabled, spec:consumers.obsidian-vault.notes.term-address-link · enabled

rule.mentionLinks line 35 · specs/consumers/obsidian-vault.notes.sdp.md:35

A mention in any text the vault renders from the graph, found by the scanner the prose-mention validator uses, becomes a link when its Spec resolves and, for an entry address, its entry does; a mention that does not resolve stays as written. A code span holding exactly one mention becomes that link, and any other code span stays code.

spec:consumers.obsidian-vault.notes.entry-address-link · enabled, spec:consumers.obsidian-vault.notes.term-address-link · enabled, spec:consumers.obsidian-vault.notes.unresolved-mention-stays · enabled

rule.textEscaped line 36 · specs/consumers/obsidian-vault.notes.sdp.md:36

Text from the graph renders as written, except that the generator escapes what Obsidian would read as a link, an embed, a tag, a block id, a comment, a highlight or math, so no note holds a link, tag or block id the graph does not.

no example exercises it

rule.addressRoundTrip line 37 · specs/consumers/obsidian-vault.notes.sdp.md:37

Every note name and block id converts back to what it names: a note name to its id by restoring the colon after the namespace, a term note's name to its term address, and a block id in a Spec's note to its entry address, so an agent reading a link a person wrote names the entry it cites.

no example exercises it

Cited at

• test/skills.test.ts:2143

0 unkeyed rules.

Verifying examples

Given a corpus holding the Specs {first: "spec:probe.Member"} and {second: "spec:probe.member"}
When the vault command runs over that corpus
Then the run exits {exitCode: 1}
Then the refusal names {named: "spec:probe.Member and spec:probe.member"}
Then nothing under the generated folder was written: {nothingWritten: true}

Given a corpus holding the Spec {source: "spec:probe.source"} whose narrative mentions {mention: "spec:probe.target#design.limit"}
Given the Spec {target: "spec:probe.target"} keys the Design entry {key: "limit"}
When the vault command runs over that corpus
Then the mentioning Spec's note is {notePath: "sdp/specs/probe/spec.probe.source.md"}
Then the mention renders as {rendered: "[[sdp/specs/probe/spec.probe.target.md#^design-limit|spec:probe.target#design.limit]]"}
Then the note's aliases open with {alias: "spec:probe.source"}
Then no property but aliases holds an id or an entry address as plain text: {plainProperties: true}

Given a corpus holding the Spec {source: "spec:probe.source"} whose narrative mentions {mention: "spec:probe.target#term.limit"}
Given the Spec {termSpec: "spec:probe.target"} defines a Model term with the key {termKey: "limit"}
When the vault command runs over that corpus
Then the term's note is {termNotePath: "sdp/terms/term.probe.target.limit.md"}
Then the defining Spec's note carries the block id {blockId: "term-limit"}
Then the mention renders as {rendered: "[[sdp/specs/probe/spec.probe.target.md#^term-limit|spec:probe.target#term.limit]]"}

Given a corpus holding the Spec {source: "spec:probe.source"} whose narrative mentions {mention: "spec:probe.target#design.missing"}
Given the Spec {target: "spec:probe.target"} keys the Design entry {key: "limit"}
When the vault command runs over that corpus
Then the mention renders as {rendered: "spec:probe.target#design.missing"}

Example space

Given a corpus holding the Spec {source:string} whose narrative mentions {mention:string}
Given a corpus holding the Specs {first:string} and {second:string}
Given the Spec {target:string} keys the Design entry {key:string}
Given the Spec {termSpec:string} defines a Model term with the key {termKey:string}
When the vault command runs over that corpus
Then the run exits {exitCode:number}
Then the refusal names {named:string}
Then nothing under the generated folder was written: {nothingWritten:boolean}
Then the mentioning Spec's note is {notePath:string}
Then the mention renders as {rendered:string}
Then the term's note is {termNotePath:string}
Then the defining Spec's note carries the block id {blockId:string}
Then the note's aliases open with {alias:string}
Then no property but aliases holds an id or an entry address as plain text: {plainProperties:boolean}

noteName line 40 · specs/consumers/obsidian-vault.notes.sdp.md:40

<namespace>.<path> for an id <namespace>:<path>, as spec.model.rule-keys, pack.design-iteration-v1 and impl.protocol.reader; term.<path>.<key> for the term address spec:<path>#term.<key>.

no citation recorded

linkForm line 41 · specs/consumers/obsidian-vault.notes.sdp.md:41

[[<path from the vault>.md|<id or address>]], with #^<block id> after .md for an entry; every link names the file's extension, and an embedded Base is ![[sdp/packs/<note>.base]] or ![[sdp/specs.base]].

no citation recorded

blockId line 42 · specs/consumers/obsidian-vault.notes.sdp.md:42

<section>-<key>, written as ^<section>-<key> at the end of the entry's line, so spec:<id>#design.limit opens as [[sdp/specs/<family>/<note>.md#^design-limit|spec:<id>#design.limit]].

no citation recorded

propertyEncoding line 43 · specs/consumers/obsidian-vault.notes.sdp.md:43

the properties sit between two --- lines at the top of the note, one per line as <key>: <JSON value>, in the order listed below; a property the graph does not hold is left out.

specProperties line 44 · specs/consumers/obsidian-vault.notes.sdp.md:44

aliases (the id, then the title), title, specKind, altitude, statedReadiness, derivedReadiness (none when no rung derives), statedNextRung (left out when the Spec states ready), statedNextRungFailures (the failing clause ids), implementationBinding, verifierBinding, designEntries, declarations, openQuestions (a count), blockingQuestions, decisions (links to the notes of the resolving decisions the design columns name), packs (links to the Pack notes), carrier (the root-relative carrier path).

no citation recorded

packProperties line 45 · specs/consumers/obsidian-vault.notes.sdp.md:45

aliases (the id, then the title), title, manifest (the root-relative manifest path), and optional order, present as "priority" only when the Pack states it.

no citation recorded

codeProperties line 46 · specs/consumers/obsidian-vault.notes.sdp.md:46

aliases (the id), label, role, layer, context, component (a link to the component's note), sourceFile (root-relative), sourceLine.

no citation recorded

termProperties line 47 · specs/consumers/obsidian-vault.notes.sdp.md:47

aliases (the term, then its address), definedIn (a link to the defining Spec's note).

no citation recorded

banner line 48 · specs/consumers/obsidian-vault.notes.sdp.md:48

the first line after the properties, > [!info] Generated by `sdp vault` from the graph. Edit the <carrier|Pack manifest|source file> `<root-relative path>`, never this note: a regeneration refuses while a note it wrote has changed. , naming the Spec's carrier, the Pack's manifest or the unit's source file.

headLine line 49 · specs/consumers/obsidian-vault.notes.sdp.md:49

under a Spec note's title, `<id>` · <kind display label> · <altitude> · stated <rung> · floor <rung or none> , then · <stated next rung>: <failing clause ids, or nothing blocks> when the Spec states less than ready.

specNoteBody line 50 · specs/consumers/obsidian-vault.notes.sdp.md:50

the banner, # <title>, the head line, the narrative's paragraphs, each section under ## <Section> in the graph's order with Intent's open questions under ### Open questions and an example's steps or an example space's vocabulary in a fenced gherkin block, then ## Relations with ### From this Spec and ### Toward this Spec, ## Bindings, ## Packs and ## Findings, each heading left out when it has nothing under it.

bindingLines line 51 · specs/consumers/obsidian-vault.notes.sdp.md:51

under ## Bindings, - Implementation binding: present or none with each realizing unit, the units that reference the Spec, - Verifier binding: present or none with each verifier, - Expected-outcome oracle: present or none, and - Runtime observation: not tracked.

packNoteBody line 52 · specs/consumers/obsidian-vault.notes.sdp.md:52

the banner, # <title>, the framing, ## Members, filterable with the Pack's Base embedded, ## Members, in advisory priority order when order is "priority", otherwise ## Members, in reading order, as a numbered list in manifest order, each a link with its stated rung, floor and stated next rung or nothing blocks, then ## Boundary with the reader's four boundary lists and ## Findings. A roadmap states Priority confers no permission or sequencing requirement. before its ordered list heading.

codeNoteBody line 53 · specs/consumers/obsidian-vault.notes.sdp.md:53

the banner, # <id>, the label, `<file>:<line>` , then link lists under ## Member of, ## Members, ## Uses, ## Used by, ## Satisfies, ## References, ## Verifies and ## Models, each left out when empty.

termNoteBody line 54 · specs/consumers/obsidian-vault.notes.sdp.md:54

the banner, # <term>, the definition, and Defined in [[<Spec note>.md#^term-<key>|<term address>]].

caseCollisionMessage line 55 · specs/consumers/obsidian-vault.notes.sdp.md:55

sdp vault: <first id> and <second id> name notes whose paths differ only in case; nothing was written, one line per colliding pair, the ids in code-unit order.

no citation recorded

escapes line 56 · specs/consumers/obsidian-vault.notes.sdp.md:56

a backslash before [[, %%, ==, $, a # that opens a tag after a space or at a line's start, and a ^ that would end a line as a block id; text inside a code span is left as written.

Verifier bindings

• spec:consumers.obsidian-vault.notes.case-collision-refused · Two Specs whose notes differ only in case refuse the run · declared · example enabled · specs/consumers/obsidian-vault.notes.case-collision-refused.sdp.md
• spec:consumers.obsidian-vault.notes.entry-address-link · An entry address in prose opens the entry's block in its Spec's note · declared · example enabled · specs/consumers/obsidian-vault.notes.entry-address-link.sdp.md
• spec:consumers.obsidian-vault.notes.term-address-link · A keyed Model term gets a note, and its address in prose opens the term's block · declared · example enabled · specs/consumers/obsidian-vault.notes.term-address-link.sdp.md
• spec:consumers.obsidian-vault.notes.unresolved-mention-stays · A mention of an entry that does not exist stays as written · declared · example enabled · specs/consumers/obsidian-vault.notes.unresolved-mention-stays.sdp.md
• test:protocol.vault-priority · anchored · test anchor binding present · test/vault.test.ts:53

Requirement drawing

Decisions

No decision record named.

• component:protocol.projections · read-only output, layout and owned publication · src/projections/design-review.ts:29 · layer edge · context protocol

  Uses

  • component:protocol.extract · the carrier and source pipeline · src/extract/index.ts:192 · layer application · context protocol
  • component:protocol.graph · the one graph and its semantic decisions · src/graph/schema.ts:34 · layer domain · context protocol
  • component:protocol.model · the authored contracts and stable ids · src/model/anchors.ts:100 · layer domain · context protocol
  • component:protocol.notation · the leaf step codec · src/notation/slots.ts:261 · layer domain · context protocol
  • component:protocol.reader · the typed graph contract and body evaluator · src/reader/reader.ts:671 · layer application · context protocol
  • component:protocol.validate · one finding currency and ordered checks · src/validate/validators.ts:72 · layer domain · context protocol
• impl:protocol.vault-notes · renders reader contexts, declared relations and keyed terms as linked notes · src/projections/vault/notes.ts:45

  Component: component:protocol.projections · read-only output, layout and owned publication · src/projections/design-review.ts:29 · layer edge · context protocol

  Uses

  • impl:protocol.reader · typed graph queries, entry adapters and context joins · src/reader/reader.ts:687
• impl:protocol.vault-sections · renders sections in graph order with keyed entry block ids · src/projections/vault/sections.ts:10

  Component: component:protocol.projections · read-only output, layout and owned publication · src/projections/design-review.ts:29 · layer edge · context protocol

  Uses

  None.

• impl:protocol.vault-text · renders checked mentions and escapes Obsidian syntax outside code spans · src/projections/vault/text.ts:30

  Component: component:protocol.projections · read-only output, layout and owned publication · src/projections/design-review.ts:29 · layer edge · context protocol

  Uses

  None.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Execute note naming, the id alias and a mention of an entry address rendered as a block link.

Examples

Given a corpus holding the Spec {source: "spec:probe.source"} whose narrative mentions {mention: "spec:probe.target#design.limit"}
Given the Spec {target: "spec:probe.target"} keys the Design entry {key: "limit"}
When the vault command runs over that corpus
Then the mentioning Spec's note is {notePath: "sdp/specs/probe/spec.probe.source.md"}
Then the mention renders as {rendered: "[[sdp/specs/probe/spec.probe.target.md#^design-limit|spec:probe.target#design.limit]]"}
Then the note's aliases open with {alias: "spec:probe.source"}
Then no property but aliases holds an id or an entry address as plain text: {plainProperties: true}

Verifier bindings

• test:protocol.consumers.obsidian-vault.notes.entry-address-link · anchored · test anchor binding present · test/vault-examples.test.ts:719

Requirement drawing

• Satisfying or referencing units: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Execute the mention rule on an entry address whose key its Spec does not carry, which validation reports and the vault leaves unlinked.

Examples

Given a corpus holding the Spec {source: "spec:probe.source"} whose narrative mentions {mention: "spec:probe.target#design.missing"}
Given the Spec {target: "spec:probe.target"} keys the Design entry {key: "limit"}
When the vault command runs over that corpus
Then the mention renders as {rendered: "spec:probe.target#design.missing"}

Verifier bindings

• test:protocol.consumers.obsidian-vault.notes.unresolved-mention-stays · anchored · test anchor binding present · test/vault-examples.test.ts:726

Requirement drawing

• Satisfying or referencing units: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Execute the term note, the term's block id and a mention of a term address rendered as a block link.

Examples

Given a corpus holding the Spec {source: "spec:probe.source"} whose narrative mentions {mention: "spec:probe.target#term.limit"}
Given the Spec {termSpec: "spec:probe.target"} defines a Model term with the key {termKey: "limit"}
When the vault command runs over that corpus
Then the term's note is {termNotePath: "sdp/terms/term.probe.target.limit.md"}
Then the defining Spec's note carries the block id {blockId: "term-limit"}
Then the mention renders as {rendered: "[[sdp/specs/probe/spec.probe.target.md#^term-limit|spec:probe.target#term.limit]]"}

Verifier bindings

• test:protocol.consumers.obsidian-vault.notes.term-address-link · anchored · test anchor binding present · test/vault-examples.test.ts:733

Requirement drawing

• Satisfying or referencing units: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Execute the case-collision refusal on two Spec ids that differ only in the case of one letter.

Examples

Given a corpus holding the Specs {first: "spec:probe.Member"} and {second: "spec:probe.member"}
When the vault command runs over that corpus
Then the run exits {exitCode: 1}
Then the refusal names {named: "spec:probe.Member and spec:probe.member"}
Then nothing under the generated folder was written: {nothingWritten: true}

Verifier bindings

• test:protocol.consumers.obsidian-vault.notes.case-collision-refused · anchored · test anchor binding present · test/vault-examples.test.ts:740

Requirement drawing

• Satisfying or referencing units: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.