@antoneeo/kb-agentic-skill 1.25.0 → 1.26.1

package/CHANGELOG.md

@@ -2,6 +2,22 @@
 
 Every significant change to this skill is recorded here.
 
+## [1.26.1] - 2026-10-18
+
+### Fixed
+- F-072 (field run): the `SKILL.md` line that announces the docs site now reads `scripts/docs_site.py --root <project> --open` and says to use it to show the project state. Asked for the state, an agent had opened the site in its own client pane, where it renders blank, and improvised a local server; `--open` opens it in the user's browser, where it works offline.
+
+## [1.26.0] - 2026-10-18
+
+### Added
+- F-074: every Vision is born from an owner interview. Before any Vision text is written (project, feature, lens, and the devPNT M-VISION), the agent asks the owner six questions in order, re-asking an answer that has the wrong form: the problem as one concrete case, the benefit as a result for someone, the actors including who takes the initiative, a success signal with its starting value, the boundaries, and the known constraints with where each comes from. Then the owner approves a one- or two-sentence north star in their own words; without it no Vision is written, not even a draft. The blind check still tests that the rules hold; the approved north star shows they are the owner's. `vision.md` §The owner interview.
+
+### Changed
+- `elicitation.md`: the skip path never covers a Vision; the interview is a planned occasion like the round.
+- Bootstrap no longer writes a Vision reconstructed by the agent: the installer seeds `ai_docs/vision/project_vision.md` as a stub awaiting the interview (an existing file is never overwritten).
+- A Non-Goal now bounds scope. It rejects a proposal that pursues what it names; it is not a ban on behaviour that already exists and creates no obligation. A behaviour that must never happen is an Invariant or a constraint with its source.
+- Vision templates ask for the north star in the owner's words with its approval, the problem as a case, the actor with the initiative, signals with starting values, and the source of every rule.
+
 ## [1.25.0] - 2026-10-18
 
 ### Added

package/README.md

@@ -49,7 +49,7 @@ Deliberately absent: any per-node coverage or completion state. `gaps:` says wha
 - **Risk-proportional triage, measured in knowledge and never in files**: one claim row → propagating a fact already settled → a new knowledge unit (a source ingested, a node created or superseded, the hierarchy moved). Carrying one settled fact into eight documents is small; one claim that re-parents a node is not. On a live front, a new source or statement within an open unit's declared scope is an **ingestion step** of that unit — recorded on the ledger at once — while the rewrite of dependent documents, the registry and the full check run once, at a closure the practitioner calls. A **Write Triggers** table maps each knowledge event to exactly one destination.
 - **Portable knowledge**: `export` bundles a subgraph together with the bytes its claims cite — a closure, not a selection, because a claim whose source cannot be reopened is model knowledge arriving by another route. `import` merges it into another project **additively**: it never overwrites a node and never deletes, and claims already present are recognised by id rather than by comparing text, since the same artifact cited at the same span mints the same id in every project. Knowledge crosses the project boundary; **authority does not** — an imported ruling arrives as `prov: IMPORTED`, keeps its original `basis:`, and cannot settle a local disagreement until you re-ratify it.
 - **Several people, one project**: the workstream registry (`audit/handoff.md`) is **generated** from one file per open workstream, so two people opening or closing two workstreams on two branches edit two different files and their merge is clean. Row-per-workstream alone was not enough — a file-global `Date:` header defeats row-level ownership — so the header is derived from the sources and no writer touches it. The generated view can still conflict; that conflict is resolved by re-running `index`, never by hand, and `validate` refuses CLEAN until the file matches its sources. The append-only review log gets `merge=union` (a built-in driver, no per-clone configuration). It all works with no VCS at all: it is files and a generator.
-- **Vision-guided governance**: Standalone projects use `ai_docs/vision/`; Hybrid projects use devPNT `M-VISION` as the milestone north star. `DRAFT` informs, `APPROVED` binds, promotion is the user's alone.
+- **Vision-guided governance**: Standalone projects use `ai_docs/vision/`; Hybrid projects use devPNT `M-VISION` as the milestone north star. `DRAFT` informs, `APPROVED` binds, promotion is the user's alone. Every Vision, the M-VISION included, is written only after a six-question **owner interview** and your explicit approval of a one- or two-sentence north star in your own words — the agent never writes one alone.
 - **Independent review, twice**: the design before it is implemented, the result before it is declared done — fresh-context subagent > one-shot run > a declared self-pass, 3 rounds max, one log line each, and a PASS is invalid on "found nothing".
 - **Question discipline**: a real doubt is asked when it emerges, before its answer is written, with the pros and cons of each option; a choice whose pros clearly win is taken with the weighing written next to it. A question is legal only when the agent searched first, names the search with its result, and names the decision it unblocks.
 - **Verbatim request record**: every L3 starts `audit/requests/REQUEST_[topic].md` before the Vision Gate — the practitioner's own words and every later decision (answers, approvals, costs, rulings), append-only and redacted for secrets — so analyses cite what was asked instead of paraphrasing it, and reviews check owner statements against it.
@@ -89,7 +89,7 @@ Initialize a project:
 kb-agentic-init
 ```
 
-Run it inside a project to create `ai_docs/`, Vision documents, strategic docs, audit plan, and agent protocol files (`AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.cursorrules`).
+Run it inside a project to create `ai_docs/`, Vision stubs awaiting your interview, strategic docs, audit plan, and agent protocol files (`AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.cursorrules`).
 
 Installing or updating the npm package **wires the session-orientation hook
 machine-wide** (user-level `~/.claude/settings.json`, Claude Code with Python):

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "kb-agentic-skill",
-  "version": "1.25.0",
+  "version": "1.26.1",
   "description": "Knowledge-Base & Document-First protocol with risk triage, Vision governance, signal distillation and optional devPNT integration.",
   "author": "Antonio Pinto (https://github.com/Antoneeo)"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@antoneeo/kb-agentic-skill",
-  "version": "1.25.0",
+  "version": "1.26.1",
   "description": "Knowledge-Base & Document-First protocol for Claude Code, Gemini CLI, Google Antigravity and Codex with risk triage, Vision governance, signal distillation and optional devPNT integration.",
   "keywords": [
     "claude-code",

package/skills/kb-agentic-skill/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: kb-agentic
-version: 1.25.0
+version: 1.26.1
 description: Knowledge-Base & Document-First protocol with risk-proportional triage, Vision as a guide, Signal Distillation, a complete Standalone mode and optional symbiosis with devPNT. Use for user documentation, knowledge extraction, SOPs, research notes, decision logs, knowledge management — and for answering project questions from the claim ledger and topic graph.
 author: Antonio Pinto (https://github.com/Antoneeo)
 copyright: (c) 2026 Antonio Pinto
@@ -25,7 +25,7 @@ Support files in the skill directory:
 - `dispatch.md`: opt-in subagent execution of an approved plan, plus the family-wide delegation boundary (what may be delegated at all) — that part applies at any level.
 - `routing.md`: which lens owns this unit of work. Read ONLY when a sibling lens skill is installed alongside this one; a single-lens install never reads it.
 - `scripts/sdlc_check.py` + `scripts/sdlc_core.py`: the mechanical validator for the docs root (`check`, `validate`, `index`, `mark`, `benefit`, `gate`, `plan`, `orient`, `migrate`, and the knowledge overlay: `graph`, `corpus`, `claim-id`, `anchor`, `export`, `import`, `stale` (spine staleness plus `## claims` -- the time cycle's consolidated view), plus `remind` — the opt-in per-turn one-line reminder, ENFORCEMENT §4).  Keep the entry point, `scripts/sdlc_core.py` and `scripts/knowledge.py` together; the last supplies common memory and KB integrity.
-- `scripts/docs_site.py --root <project>`: writes an offline, read-only site of what the agent reads here, for the user to browse.
+- `scripts/docs_site.py --root <project> --open`: opens in the user's browser a read-only site of what the agent reads; use it to show the project state.
 - `ENFORCEMENT.md`: optional setup for CI and hooks.
 
 Read these files only when needed. `SKILL.md` is the operating contract; the support files are progressive resources.
@@ -97,7 +97,7 @@ Triage decides IF documentation is due; this table decides WHICH document each e
 | `audit/reviews/REVIEW_LOG.md` | Every completed review — recorded in log. | 3 / 5 |
 | ADR / Decision Log — `architecture/` or devPNT DB | A strategic decision was taken (pattern, policy, structural change): record before DONE. | 5 |
 | `strategic/architecture.md`, `strategic/existing_features.md` | Bootstrap; update at closure when the knowledge catalog actually changed. | 1 / 5 |
-| `vision/project_vision.md`, `roadmap.md`, `principles.md` | Bootstrap as `Status: DRAFT`; promoted to APPROVED only by explicit user confirmation. | 1 / 2 |
+| `vision/project_vision.md`, `roadmap.md`, `principles.md` | Bootstrap writes each as a **stub** awaiting the owner interview (`Status: DRAFT`) — never a Vision reconstructed by the agent. The Vision is written only after the owner interview and its approved north star (`vision.md` §The owner interview); promoted to APPROVED only by explicit user confirmation. | 1 / 2 |
 | `topics/<slug>.md` | A placement verdict creates it (MISSING/INADEQUATE-child, `taxonomy.md`); reconciliation updates its claim rows. One node per topic — a similar-but-distinct concept is a sibling with `related:` + a written distinction, never a merge and never a duplicate. Merged/renamed nodes become tombstones (`status: SUPERSEDED` + `redirect_to:`), never deleted. | 4 |
 | a KB bundle (`export`) | Knowledge must leave this project. Export is L1 — it writes nothing into the corpus. **Importing one is L3**: a source enters the corpus and nodes are created, and a bundle is external input, so never L1 whatever its size (`portability.md`). | — |
 | `corpus/given/*` + sidecar | A source arrives: it becomes a content-addressed artifact with a sidecar carrying digest/date/`supersedes:`. A text source is copied verbatim. A non-text source yields its stored canonical extraction — copied **beside** the original when that is small enough to keep, or **instead of it** on a large binary corpus, where the original stays where it lives and is recorded as `original_path:`/`original_sha256:` (`distillation.md` §1, which owns this rule). Never edited after ingest — the digest check on whatever `given/` holds is what enforces it. | 4 |
@@ -125,12 +125,13 @@ Use this mode when `devpnt_*` tools are available and point at the current proje
 ### 1. Audit and Alignment
 - Read `ai_docs/audit/handoff.md` (workstream registry) to see active topics.
 - Read `ai_docs/README.md`, `ai_docs/INDEX.md` and `ai_docs/reference/INDEX.md` (the guide router) before exploring notes. The router is a mandatory read, not an optional one: it is the only orientation step that tells you a guide already governs the work you are about to do.
-- If `ai_docs/` is missing, create the bootstrap set: `README.md`, `vision/` docs, `strategic/` docs, and `audit/audit_plan.md`, then run `sdlc_check.py index`.
+- If `ai_docs/` is missing, create the bootstrap set: `README.md`, `vision/` stubs awaiting the owner interview, `strategic/` docs, and `audit/audit_plan.md`, then run `sdlc_check.py index`.
 
 ### 2. Vision Gate
 - Read `project_vision.md`, `roadmap.md`, `principles.md` (or devPNT `M-VISION`).
 - Compare them with the request as recorded in `audit/requests/REQUEST_[topic].md`, not with a paraphrase of it.
 - Verify request aligns with expected benefits, user goals, and success signals.
+- Writing or amending a Vision starts with the owner interview (`vision.md` §The owner interview): the north star is approved in the owner's words before any Vision text exists; there is no skip path.
 
 ### 3. Request Analysis & Taxonomy Pass
 

package/skills/kb-agentic-skill/elicitation.md

@@ -10,10 +10,20 @@ Skip path: if the spec is already complete — an approved Vision or explicit
 user requirements already answer goal, scope, and constraints — skip the
 round and add a one-line note in the analysis stating why it was skipped.
 Do not run the round as a formality when the answers are already on record.
+The skip path never covers a Vision (next paragraph).
+
+Vision path: when the unit writes or amends a Vision — any kind, the M-VISION
+included — the owner interview in `vision.md` §The owner interview runs instead
+of this round for the Vision's own content, and it has **no skip path**: one
+sentence from the user plus a spike never makes a Vision's spec complete. The
+round then covers only what the interview did not (the unit's own scope and
+acceptance), deriving from the interview's answers. The interview is a planned
+occasion like the round (§Ask before the write): its questions go in one numbered
+set, and only an answer in the wrong form is asked again.
 
 Unattended path: when the user is not reachable (a scheduled or autonomous run,
-and a bootstrap Vision is `DRAFT` by mandate, so the skip path above cannot
-apply on a project's first L3) and a real doubt remains, do not stall and do not
+and a bootstrap Vision is a stub awaiting the owner interview, so the skip
+path above cannot apply on a project's first L3) and a real doubt remains, do not stall and do not
 invent consensus. Write it as a **declared assumption** (§Ask before the write)
 in the artifact it touches. At L3, mark the ANALYSIS `BLOCKED on the user` and
 stop before implementation; below L3, proceed and list the assumption in the
@@ -24,9 +34,10 @@ design is not.
 
 A doubt kept silent is decided by the agent alone and reaches the documents
 looking settled; a useless question wastes the practitioner's attention. This
-section rules on both. The process *plans* questions in two places — the round
-below, and the Capture Moment sweep at a user-signed closing (`SKILL.md`) — each
-a planned occasion that keeps its own form.
+section rules on both. The process *plans* questions in three places — the round
+below, the owner interview for a Vision (`vision.md` §The owner interview), and the
+Capture Moment sweep at a user-signed closing (`SKILL.md`) — each a planned
+occasion that keeps its own form.
 
 ### When a doubt emerges
 

package/skills/kb-agentic-skill/templates.md

@@ -103,18 +103,30 @@ the first draft — the properties that make a rule survive a motivated reader a
 cheap to apply while writing and expensive to retrofit. `vision.md` §6 is the
 blind check that gates promotion to APPROVED.
 
+**No section below is written before the owner interview** (`vision.md` §The owner
+interview) and its approved north star. Until then — at bootstrap, or for an owner
+not yet reached — the file is this stub, and nothing traces to it:
+
+```markdown
+# Project Vision
+Status: DRAFT
+<!-- STUB: awaiting the owner interview (vision.md §The owner interview). Not a
+     Vision: no artifact traces to it. What the agent observed is in strategic/. -->
+```
+
 Sections below marked **[gate]** are load-bearing for that ruling; the others are
 orientation for humans. Keep the human ones — just know which is which.
 
 ```markdown
 # Project Vision
 Status: DRAFT
-<!-- Status: DRAFT (reconstructed by the agent, NOT a gating authority)
+<!-- Status: DRAFT (written from the owner interview, NOT yet a gating authority)
      or APPROVED (by <who>, <date>) — only after the user's explicit confirmation
      AND the blind check in vision.md §6. -->
 
 ## North Star
-<!-- [gate, partly] The BENEFIT to be obtained — what the actor gets, never the
+<!-- [gate, partly] One or two sentences IN THE OWNER'S WORDS, approved before any
+     other section (Gate 1): (approved: REQUEST_[topic].md#R<n>). The BENEFIT to be obtained — what the actor gets, never the
      mechanism, and never by comparison to another product (a comparative
      definition rots silently when the comparison target moves). Concrete enough
      that an obstacle to it is recognizable: that is what makes every Non-Goal
@@ -123,11 +135,15 @@ Status: DRAFT
      scale levels. Routing the reader to another file breaks the cold-read
      premise. -->
 ## Core Problem
-<!-- Human orientation: what goes wrong without this product. Carries no gate
-     weight unless the admission test names it. -->
+<!-- Interview question 1: ONE concrete case that today does not get the expected
+     result, with its example — never a missing feature. Cite the answer
+     (REQUEST_[topic].md#R<n>). Human orientation: carries no gate weight unless
+     the admission test names it. -->
 ## Actors
 <!-- [gate] the cast this product serves. One light line per actor:
      **Role** — primary goal; good UX = what a good experience means to them.
+     Interview question 3: who receives the benefit, who acts, and who has the
+     INITIATIVE — an actor that acts unprompted is named here, or it goes missing.
      The "good UX =" clauses are admissible work, not decoration — say so in the
      admission test. Define each actor ONCE here; use-cases (Standalone) / D-UC
      (Hybrid) reference them by role and never re-describe them (anti-DRY).
@@ -144,7 +160,14 @@ Status: DRAFT
      with BOTH branches answered, plus an anti-laundering clause naming the
      re-descriptions you expect. Omit the section if the product has none. -->
 ## Non-Goals
-<!-- [gate — the REJECT side; this is your ENTIRE rejection surface]
+<!-- [gate — the REJECT side, with the Invariants]
+     A Non-Goal bounds SCOPE: it rejects a proposal that pursues what it names; it
+     never bans a behaviour the product already has and never creates an
+     obligation (obligations come from the North Star and the Success Signals). A
+     behaviour that must never happen is an Invariant, with its provenance.
+     PROVENANCE on every rule, at the end of its bullet: (source: owner
+     REQUEST_[topic].md#R<n> | higher Vision: "quoted line" | inference confirmed
+     REQUEST_[topic].md#R<n>). An unconfirmed author inference is not a rule.
      Derive every rule by the deletion test: remove it — if the benefit is still
      reachable, the rule does not belong (it spends a degree of freedom on
      nothing); if not, keep it and name the obstacle it removes. Constraints
@@ -164,7 +187,7 @@ Status: DRAFT
      clause. State the default for anything unreached, per path. -->
 ## Success Signals
 <!-- [gate] Each checkable against a NAMED artifact or command by someone who was
-     not here. Not "we are the best" — a file, a command, a battery, and what the
+     not here, with its STARTING VALUE (interview question 4). Not "we are the best" — a file, a command, a battery, and what the
      result must be. -->
 ## Where the rest lives
 <!-- Pointers, so an absence reads as intentional rather than as a gap. Competitive
@@ -197,16 +220,32 @@ Only for features spanning multiple ANALYSIS documents or multiple milestones: o
 ```markdown
 # Feature Vision: [Name]
 
+<!-- Written only after the owner interview (vision.md §The owner interview). Each
+     section cites the answer it comes from: REQUEST_[topic].md#R<n>. -->
+## North Star
+<!-- One or two sentences in the owner's words, explicitly approved before any
+     other section (Gate 1): (approved: REQUEST_[topic].md#R<n>). -->
 ## Problem
+<!-- One concrete case that today does not get the expected result, with its
+     example — not a missing feature. -->
 ## Expected Benefit
+<!-- What who obtains once solved: a result, not a function. -->
 ## Actors
 <!-- the cast this feature serves — usually a subset/refinement of the project
      Actors, or a distinct feature-local cast for internal-tooling work. One light
      line each: **Role** — primary goal; good UX = what good feels like.
+     Name who receives the benefit, who acts, and who has the initiative.
      Referenced by the use-cases, not re-described in them. -->
 ## Success Signals
+<!-- Observable, each with its starting value. -->
 ## Non-Goals / Out of Scope
+<!-- Scope this feature does not pursue. Not a ban on existing behaviour, and no
+     obligation: those come from the Benefit and the Signals. -->
 ## Related Constraints and Principles
+<!-- Each with its provenance: (source: owner REQUEST_[topic].md#R<n> | higher
+     Vision: "quoted line" | inference confirmed REQUEST_[topic].md#R<n>). A
+     constraint imported from a higher Vision is asked about, never assumed to
+     apply here. -->
 ```
 
 ## ai_docs/audit/requests/REQUEST_[topic].md

package/skills/kb-agentic-skill/vision.md

@@ -47,14 +47,67 @@ Four consequences, each operational:
 
 Extracting the benefit from a discussion is real work: a discourse arrives with
 solutions, preferences and constraints tangled together, and the Vision is the
-distilled benefit only. The elicitation round (`elicitation.md`) asks for it first
-— and a mechanism ("a dashboard") is not an acceptable answer to a benefit
-question ("never lose the thread"); ask again until the answer names what the
-actor obtains.
+distilled benefit only. The owner interview below asks for it — and a mechanism
+("a dashboard") is not an acceptable answer to a benefit question ("never lose
+the thread"); ask again until the answer names what the actor obtains.
 
 The deletion test decides **which** rules exist. Everything below decides **how**
 to write a rule so it holds once you know it must exist.
 
+## The owner interview (before any Vision text)
+
+A Vision is the **owner's** statement of what is to be obtained. Nothing in this
+file after this section can detect a Vision the author wrote alone: the blind
+check (§6) tests whether the rules survive a hostile reader, never whether they
+are the owner's. So every Vision is born from an interview of the owner, and its
+north star is approved **before** a line of it is drafted.
+
+**Scope — every Vision, in every mode:** `project_vision.md`, a feature
+`VISION_*.md`, a lens Vision (course, marketing), and the devPNT M-VISION in
+Hybrid; also an ANALYSIS `## Feature Vision` that states a benefit no existing
+Vision names (one that cites an approved Vision's benefit is alignment, not a
+Vision). An amendment re-runs the questions whose answers it changes, and Gate 1
+again when the north star changes. **There is no skip path**: one sentence from
+the user plus a spike is not a complete spec — that exact shortcut produced a
+Vision with an imported prohibition, no north star and a missing actor, and four
+downstream artifacts built on it (field case, 2026-10). A reply already on record
+in the owner's words is read back for confirmation, never re-asked as an open
+question; an answer the author derived (from a spike, the code, another Vision)
+is never an answer — it is a proposal the owner confirms or rejects.
+
+**The questions, in this order.** Each is repeated until its answer has the form
+stated; the wrong form is named so it can be recognized and asked again.
+
+| # | Question | Right form | Wrong form — ask again |
+|---|---|---|---|
+| 1 | **Problem** — which concrete case today does not get the expected result? | one real case, with an example | a missing feature ("there is no drawing tool") |
+| 2 | **Benefit** — once solved, who obtains what? | a result for a named actor | a function or mechanism ("a renderer") |
+| 3 | **Actors** — who receives the benefit, who acts, who has the initiative? | all three named, initiative included | only the one who asks — the actor who acts unprompted goes missing |
+| 4 | **Success** — what observable signal shows the benefit arrived? | a signal with its starting value | a feeling, or a signal with no baseline |
+| 5 | **Boundaries** — what does this NOT pursue? | scope excluded from this work | a ban on behaviour ("X must never happen") — that is a constraint (6) or an obligation (2, 4) |
+| 6 | **Known constraints** — each with its provenance: owner, a quoted line of a higher Vision, or author inference | every constraint sourced; every inference asked here | a constraint written in silently, or imported from a higher Vision without asking whether it applies here |
+
+A **Non-Goal bounds scope**: it rejects a proposal that pursues what it names; it
+is not a ban on behaviour that already exists, and it creates no obligation.
+Obligations come from the Benefit and the Success Signals.
+
+**Gate 1 — north star.** One or two sentences, in the owner's words, explicitly
+approved by the owner. The author may compose a wording from the answers; the
+approval is of that exact text, recorded verbatim in the request record
+(`audit/requests/REQUEST_[unit].md`; a Vision written outside any unit, such as
+the project Vision after bootstrap, records its interview in
+`audit/requests/REQUEST_project_vision.md`). **Without it no Vision text is written** —
+not a DRAFT, not a reconstruction: bootstrap writes a stub awaiting the
+interview, and what the agent observed goes to `strategic/`.
+Unattended, the unit is `BLOCKED on the user` (`elicitation.md` Unattended path).
+
+**Gate 2 — the full Vision**, written from the answers. Every section traces to
+an answer or a stated provenance (`REQUEST_[unit].md#R<n>`); every rule carries
+its provenance; an author inference the owner did not confirm is not in it. The
+blind check (§6) verifies that it holds; the approved north star verifies that it
+is the owner's. Promotion to APPROVED still needs the owner's explicit
+confirmation — Gate 2 is that confirmation, given on the written text.
+
 ## 0. The one-line test
 
 > Could a reader who has never seen this project rule ACCEPT or REJECT on a
@@ -138,7 +191,14 @@ rule that survived and the same rule leaking.
 This is the most common structural failure and it is invisible from the inside.
 
 - **A Goal cannot reject anything.** If the admission test says "advances a Goal
-  and violates no Non-Goal", then rejection power lives *only* in the Non-Goals.
+  and violates no Non-Goal", then rejection power lives *only* in the Non-Goals
+  (and the Invariants, where the Vision has them).
+- **A Non-Goal rejects scope, not behaviour.** It turns away a proposal that
+  pursues what it names; it never forbids a behaviour the product already has, and
+  it never creates an obligation — obligations come from the Benefit and the
+  Success Signals. A behaviour the product must never have is an Invariant, or a
+  constraint with its provenance (§The owner interview, question 6). Written as a
+  Non-Goal, it reads as a ban the owner never stated.
   A Goal that says "scale cost to risk in both directions" cannot stop cost
   inflation — you need a prohibition for that.
 - **A prohibition scoped to one rung of your own scale protects only that rung.**
@@ -204,7 +264,10 @@ it.
 ## 6. The blind check (procedure)
 
 Run this **before promoting any Vision to APPROVED, and before any amendment of an
-approved one**. Not for DRAFT edits — promotion is when authority is granted, and
+approved one**. It runs on a Vision that already passed Gate 1 (§The owner
+interview): it tests whether the rules hold against a hostile reader, and it
+cannot see whether they are the owner's — a Vision the author wrote alone passes
+it cleanly. Not for DRAFT edits — promotion is when authority is granted, and
 it is rare, so the cost lands where it buys most.
 
 1. **Give the reviewer the document text and nothing else.** Not a path — the