@dzhechkov/p-replicator 1.10.4 → 1.13.1

package/templates/.claude/skills/cc-toolkit-generator-enhanced/references/templates/feature-lifecycle-ent.md

@@ -149,8 +149,8 @@ Use swarm of agents to validate:
 | validator-coherence | All docs cross-ref | PRD↔DDD↔ADR↔C4 consistency |
 
 **Iterative loop (max 3 iterations):**
-1. Run all validators in parallel (Task tool)
-2. Aggregate gaps and blocked items
+1. Run all validators in parallel (Task tool), under the positive file receipt contract below
+2. Aggregate gaps and blocked items — only from validators whose receipt is terminal-completed
 3. Fix gaps in documents
 4. Re-validate
 5. Repeat until: no BLOCKED items, average score ≥70
@@ -175,9 +175,24 @@ When documentation is ready for implementation:
 4. Generate tests from Gherkin .feature files
 5. Validate Fitness Functions during implementation
 6. Save frequent commits to GitHub
+7. Validate every trace before merge or integration
+
+#### Positive file receipt (required)
+
+Before dispatch, allocate one `RUN_ID` and, for every unit, a unique `WORK_UNIT_ID` plus an
+absolute `TRACE_PATH` unique to `(RUN_ID, WORK_UNIT_ID)`; record the launch instant and pass both
+fields to the worker. Each worker must write a substantive body ending in `Status: completed` or
+`Status: failed` to `TRACE_PATH` before it returns its one-line pointer. Before merge, verify every
+path is a regular non-symlink file, non-whitespace, post-launch, and terminal. Narrative output or
+silence is never a receipt. Name missing, stale, partial, unreadable, duplicate, failed, dead-PID,
+or probe-error units and refuse merge, aggregation, or completion until every required receipt is
+valid and completed. Run `node .claude/hooks/check-swarm-receipts.cjs <manifest>` — exit 0 all
+completed, exit 1 undelivered or failed, exit 2 the check did not run. See
+`.claude/rules/swarm-file-evidence.md` for mechanics and the bounded non-atomic-write exception.
 
 **Implementation rules:**
-- Each Bounded Context gets its own Task for parallel execution
+- Each Bounded Context gets its own Task for parallel execution, with its own `WORK_UNIT_ID` and
+  `TRACE_PATH`
 - Reference docs (pseudocode, DDD tactical, ADR), don't hallucinate code
 - Commit after each logical unit: `feat(<feature-name>): <what>`
 - Run tests from .feature files in parallel with implementation
@@ -207,8 +222,9 @@ Use swarm of agents for review:
 Process:
 1. Run brutal-honesty-review on implementation
 2. Verify ADR compliance — each decision reflected in code
-3. Verify Fitness Functions pass
-4. Fix identified issues (use Task tool for parallel fixes)
+3. Verify Fitness Functions pass — every review agent delivers under the same positive file
+   receipt contract as Phase 3; a reviewer that returned nothing did not review
+4. Fix identified issues (use Task tool for parallel fixes, same contract)
 5. Save frequent commits: `fix(<feature-name>): <what>`
 6. Benchmark performance after implementation
 7. Re-review critical findings until clean
@@ -302,6 +318,24 @@ Enterprise features with complex domains follow the 4-phase lifecycle:
 
 ### Implementation (Phase 3)
 - One parallel Task per Bounded Context
+
+#### Positive file receipt (required)
+
+Before dispatch, allocate one `RUN_ID` and, for every unit, a unique `WORK_UNIT_ID` plus an
+absolute `TRACE_PATH` unique to `(RUN_ID, WORK_UNIT_ID)`; record the launch instant and pass both
+fields to the worker. Each worker must write a substantive body ending in `Status: completed` or
+`Status: failed` to `TRACE_PATH` before it returns its one-line pointer. Before merge, verify every
+path is a regular non-symlink file, non-whitespace, post-launch, and terminal. Narrative output or
+silence is never a receipt. Name missing, stale, partial, unreadable, duplicate, failed, dead-PID,
+or probe-error units and refuse merge, aggregation, or completion until every required receipt is
+valid and completed. Run `node .claude/hooks/check-swarm-receipts.cjs <manifest>` — exit 0 all
+completed, exit 1 undelivered or failed, exit 2 the check did not run. See
+`.claude/rules/swarm-file-evidence.md` for mechanics and the bounded non-atomic-write exception.
+
+Why the file and not the reply: a worker that died looks exactly like a worker still running —
+both are silent — so a coordinator can report in good faith that a Bounded Context is under way
+when nothing is running. A named file turns that into a fact a machine can check.
+
 - Read pseudocode .pseudo files — don't hallucinate code
 - Enforce aggregate invariants from DDD tactical docs
 - Generate test stubs from Gherkin .feature files
@@ -388,6 +422,10 @@ Complex domain features use the enterprise lifecycle: `/feature-ent [name]`
 3. **IMPLEMENT** — parallel agents per Bounded Context from validated docs
 4. **REVIEW** — brutal-honesty-review swarm (6 agents) → ADR + fitness verified
 
+Every swarm phase delivers under `.claude/rules/swarm-file-evidence.md`: each parallel unit writes
+a file at a named `TRACE_PATH`, and an agent's reply is a pointer, never the result. Verify with
+`node .claude/hooks/check-swarm-receipts.cjs <manifest>` before merging anything.
+
 Use `/feature` for simple features, `/feature-ent` for complex domain features.
 
 Available enterprise lifecycle skills in `.claude/skills/`:

package/templates/.claude/skills/cc-toolkit-generator-enhanced/references/templates/feature-lifecycle.md

@@ -133,8 +133,8 @@ Use swarm of agents to validate:
 | validator-coherence | All SPARC files | Cross-reference consistency |
 
 **Iterative loop (max 3 iterations):**
-1. Run all validators in parallel (Task tool)
-2. Aggregate gaps and blocked items
+1. Run all validators in parallel (Task tool), under the positive file receipt contract below
+2. Aggregate gaps and blocked items — only from validators whose receipt is terminal-completed
 3. Fix gaps in SPARC documents
 4. Re-validate
 5. Repeat until: no BLOCKED items, average score ≥70
@@ -156,10 +156,24 @@ When SPARC plan is ready for implementation:
    - Implementation agents — parallel Task tool for independent modules
 3. **Make implementation modular** for reuse in other cases and applications
 4. Save frequent commits to GitHub
-5. Spawn concurrent tasks to speed up development
+5. Spawn concurrent tasks to speed up development, under the contract below
+6. Validate every trace before merge or integration
+
+#### Positive file receipt (required)
+
+Before dispatch, allocate one `RUN_ID` and, for every unit, a unique `WORK_UNIT_ID` plus an
+absolute `TRACE_PATH` unique to `(RUN_ID, WORK_UNIT_ID)`; record the launch instant and pass both
+fields to the worker. Each worker must write a substantive body ending in `Status: completed` or
+`Status: failed` to `TRACE_PATH` before it returns its one-line pointer. Before merge, verify every
+path is a regular non-symlink file, non-whitespace, post-launch, and terminal. Narrative output or
+silence is never a receipt. Name missing, stale, partial, unreadable, duplicate, failed, dead-PID,
+or probe-error units and refuse merge, aggregation, or completion until every required receipt is
+valid and completed. Run `node .claude/hooks/check-swarm-receipts.cjs <manifest>` — exit 0 all
+completed, exit 1 undelivered or failed, exit 2 the check did not run. See
+`.claude/rules/swarm-file-evidence.md` for mechanics and the bounded non-atomic-write exception.
 
 **Implementation rules:**
-- Each module gets its own Task for parallel execution
+- Each module gets its own Task for parallel execution, with its own `WORK_UNIT_ID` and `TRACE_PATH`
 - Reference SPARC docs, don't hallucinate code
 - Commit after each logical unit: `feat(<feature-name>): <what>`
 - Run tests in parallel with implementation
@@ -185,8 +199,9 @@ Use swarm of agents for review:
 | testing | Test coverage | Edge cases, missing tests |
 
 Process:
-1. Run brutal-honesty-review on implementation
-2. Fix identified issues (use Task tool for parallel fixes)
+1. Run brutal-honesty-review on implementation — every review agent delivers under the same
+   positive file receipt contract as Phase 3; a reviewer that returned nothing did not review
+2. Fix identified issues (use Task tool for parallel fixes, same contract)
 3. Save frequent commits: `fix(<feature-name>): <what>`
 4. Benchmark after implementation
 5. Re-review critical findings until clean
@@ -265,8 +280,25 @@ Every new feature MUST follow the 4-phase lifecycle:
 - Run tests in parallel with development
 - Format: `feat(<feature-name>): <description>`
 
+#### Positive file receipt (required)
+
+Before dispatch, allocate one `RUN_ID` and, for every unit, a unique `WORK_UNIT_ID` plus an
+absolute `TRACE_PATH` unique to `(RUN_ID, WORK_UNIT_ID)`; record the launch instant and pass both
+fields to the worker. Each worker must write a substantive body ending in `Status: completed` or
+`Status: failed` to `TRACE_PATH` before it returns its one-line pointer. Before merge, verify every
+path is a regular non-symlink file, non-whitespace, post-launch, and terminal. Narrative output or
+silence is never a receipt. Name missing, stale, partial, unreadable, duplicate, failed, dead-PID,
+or probe-error units and refuse merge, aggregation, or completion until every required receipt is
+valid and completed. Run `node .claude/hooks/check-swarm-receipts.cjs <manifest>` — exit 0 all
+completed, exit 1 undelivered or failed, exit 2 the check did not run. See
+`.claude/rules/swarm-file-evidence.md` for mechanics and the bounded non-atomic-write exception.
+
+Why the file and not the reply: a worker that died looks exactly like a worker still running —
+both are silent — so a coordinator can report in good faith that work is under way when none is.
+A named file turns that into a fact a machine can check.
+
 ### Review (Phase 4)
-- Use brutal-honesty-review with swarm of agents
+- Use brutal-honesty-review with swarm of agents, under the same positive file receipt contract
 - No sugar-coating — find real problems
 - Fix all critical and major issues before marking complete
 - Benchmark performance after implementation
@@ -323,6 +355,10 @@ New features use the 4-phase lifecycle: `/feature [name]`
 3. **IMPLEMENT** — parallel agents from validated docs
 4. **REVIEW** — brutal-honesty-review swarm → fix all criticals
 
+Every swarm phase delivers under `.claude/rules/swarm-file-evidence.md`: each parallel unit writes
+a file at a named `TRACE_PATH`, and an agent's reply is a pointer, never the result. Verify with
+`node .claude/hooks/check-swarm-receipts.cjs <manifest>` before merging anything.
+
 Available lifecycle skills in `.claude/skills/`:
 - `sparc-prd-mini` (orchestrator, delegates to explore, goap-research, problem-solver-enhanced)
 - `explore` (Socratic questioning → Product Brief)

package/templates/.claude/skills/cc-toolkit-generator-enhanced/references/templates/start-command.md

@@ -54,8 +54,25 @@ Generate:
 {{PACKAGE_FILE_LIST}}
 
 **Commits:** {{PACKAGE_COMMITS}}
+**Receipt:** write the substantive summary to `TRACE_PATH`, terminal line last, then reply one line.
 {{/FOR_EACH_PACKAGE}}
 
+#### Positive file receipt (required)
+
+Before dispatch, allocate one `RUN_ID` and, for every unit, a unique `WORK_UNIT_ID` plus an
+absolute `TRACE_PATH` unique to `(RUN_ID, WORK_UNIT_ID)`; record the launch instant and pass both
+fields to the worker. Each worker must write a substantive body ending in `Status: completed` or
+`Status: failed` to `TRACE_PATH` before it returns its one-line pointer. Before merge, verify every
+path is a regular non-symlink file, non-whitespace, post-launch, and terminal. Narrative output or
+silence is never a receipt. Name missing, stale, partial, unreadable, duplicate, failed, dead-PID,
+or probe-error units and refuse merge, aggregation, or completion until every required receipt is
+valid and completed. Run `node .claude/hooks/check-swarm-receipts.cjs <manifest>` — exit 0 all
+completed, exit 1 undelivered or failed, exit 2 the check did not run. See
+`.claude/rules/swarm-file-evidence.md` for mechanics and the bounded non-atomic-write exception.
+
+Phase 3 may not begin until that check exits 0. A package Task that produced no trace produced no
+package, however confidently it reported.
+
 ### Phase 3: Integration (sequential)
 
 1. **Verify cross-package imports** (shared modules used correctly)
@@ -177,7 +194,8 @@ Check Architecture.md for database presence:
 ### Key Principles
 
 1. **Docs as source of truth** — every Task must reference specific docs, never generate from memory
-2. **Maximize parallelism** — independent packages run as parallel Tasks
+2. **Maximize parallelism** — independent packages run as parallel Tasks, each delivering its own
+   file receipt; a Task's reply is a pointer, never the result
 3. **Atomic commits** — one commit per logical change, not one giant commit
 4. **Full integration** — Phase 3 MUST include Docker build + start + health check (+ DB if applicable)
 5. **Error recovery** — git commits after each phase ensure progress is saved

package/templates/.claude/skills/cc-toolkit-generator-enhanced/references/templates/swarm-file-evidence.md

@@ -0,0 +1,151 @@
+# Swarm File Evidence Templates
+
+> The swarm contract, in the form the GENERATOR emits it. Everything below is written INTO the
+> target project — it is not guidance for this skill.
+>
+> WHY THIS FILE EXISTS. A worker that died looks exactly like a worker that is still running: both
+> are silent. Silence therefore reads as `in progress`, and a coordinator reports in good faith
+> that the review is running when no review exists. The absence of a receipt is indistinguishable
+> from unfinished work, and so it reads as progress. The cure is to declare the RESULT of every
+> parallel unit to be a FILE at a named path: no file, no work — and that is a fact a machine can
+> establish, not a feeling a reader has to trust.
+>
+> MEASURED 2026-09-01 (the defect this closes): the generated feature lifecycle told the toolkit to
+> launch parallel agents 22 times and required a file result zero times, while the package that
+> emits it had already carried the cure in nine of its own files. The generator reproduced in every
+> consumer project a defect its author had already fixed at home.
+
+---
+
+## 1. Rule Template: `swarm-file-evidence.md`
+
+**Output path:** `.claude/rules/swarm-file-evidence.md`
+
+**Do NOT overwrite** an existing file at that path — `npx @dzhechkov/p-replicator init` pre-ships
+this rule, and a project initialised that way already has it. Generate it only when the path is
+absent, which is the case for every toolkit produced into a project this package never initialised.
+
+Emit the body below VERBATIM. It is byte-identical to the pre-shipped rule, and
+`tests/unit/generator-swarm-contract.test.js` asserts that identity, so the two cannot drift.
+
+```markdown
+# Swarm File Evidence
+
+## Rule
+
+Every parallel work unit has a named file result. A narrative reply is only a pointer; silence is
+neither progress nor completion. The coordinator may aggregate only positive, attributable terminal
+receipts from the assigned files.
+
+## Mechanics
+
+1. Before dispatch, allocate a run-unique `RUN_ID` and a unique `WORK_UNIT_ID`. Resolve one absolute
+   `TRACE_PATH` per `(RUN_ID, WORK_UNIT_ID)`, record its pre-launch state, and pass both fields to the
+   worker. Two workers never share a path.
+2. The worker writes a substantive Markdown body to a temporary regular file in the same directory,
+   appends exactly `Status: completed` or `Status: failed` as the final line, renames it to
+   `TRACE_PATH`, then returns a one-line pointer. The terminal marker is written last.
+3. Before merge, synthesis, or completion, the coordinator checks each assigned path: absolute and
+   unique; regular and non-symlink; readable and non-whitespace; absent before launch or observably
+   changed after launch; final line terminal. It reads the file as the payload and reports
+   `valid receipts / required receipts` with every failed `WORK_UNIT_ID` and path.
+4. `Status: completed` permits consumption. `Status: failed` is a delivered failure and blocks a
+   successful aggregate. Missing, empty, stale, partial, unreadable, duplicate, or probe-error
+   evidence is undelivered or inconclusive. A dead PID stops waiting as failure; a live PID may only
+   extend waiting. Neither PID state proves delivery.
+
+## Bounded exception
+
+If atomic rename is unavailable, write directly to `TRACE_PATH` and append the terminal marker last;
+until that line exists the file is partial. Host-authoritative liveness may extend a deadline, but it
+cannot replace the file result or turn missing evidence into success.
+
+## Observable violation → replacement
+
+| Observable violation | Required replacement |
+|---|---|
+| Task report exists but `TRACE_PATH` does not | Name the unit/path, mark undelivered, and refuse aggregation. |
+| File is empty, stale, symlinked, unreadable, or non-terminal | Keep the evidence out of the aggregate and rerun or diagnose that unit. |
+| Status says `running` but its recorded PID is dead | Close the unit as failed; do not report continued work from silence. |
+| Fewer than all required receipts are terminal-completed | Report the partial ratio and refuse completion. |
+
+## Self-check
+
+For every parallel unit, point to its assignment containing `WORK_UNIT_ID` and absolute `TRACE_PATH`,
+then point to the coordinator check performed before aggregation. Exercise missing, empty, stale,
+partial, failed, dead-PID, and probe-error traces; only a fresh substantive file ending in
+`Status: completed` may satisfy delivery.
+```
+
+---
+
+## 2. Seam Template: the positive file receipt
+
+**Paste this block VERBATIM into every generated instruction that dispatches parallel agents** —
+the `/feature` and `/feature-ent` commands, the `feature-lifecycle` rules, `/start` Phase 2, the
+autonomous `/run` and `/go` loops, and any pipeline a project builds with `pipeline-forge`.
+It is short on purpose: a contract nobody can afford to repeat is a contract that gets dropped.
+
+```markdown
+#### Positive file receipt (required)
+
+Before dispatch, allocate one `RUN_ID` and, for every unit, a unique `WORK_UNIT_ID` plus an
+absolute `TRACE_PATH` unique to `(RUN_ID, WORK_UNIT_ID)`; record the launch instant and pass both
+fields to the worker. Each worker must write a substantive body ending in `Status: completed` or
+`Status: failed` to `TRACE_PATH` before it returns its one-line pointer. Before merge, verify every
+path is a regular non-symlink file, non-whitespace, post-launch, and terminal. Narrative output or
+silence is never a receipt. Name missing, stale, partial, unreadable, duplicate, failed, dead-PID,
+or probe-error units and refuse merge, aggregation, or completion until every required receipt is
+valid and completed. See `.claude/rules/swarm-file-evidence.md` for mechanics and the bounded
+non-atomic-write exception.
+```
+
+## 3. The deterministic half: `check-swarm-receipts.cjs`
+
+Section 2 is layer-2 text — it is read every run and violated in silence. The layer-1 half is a
+utility that answers the same question without a model in the loop:
+
+```bash
+node .claude/hooks/check-swarm-receipts.cjs .claude/traces/<RUN_ID>/receipts.json
+```
+
+Three exit codes, and the third is the point:
+
+| Exit | Meaning | Coordinator's obligation |
+|------|---------|--------------------------|
+| `0` | every receipt is fresh, substantive and `Status: completed` | may aggregate |
+| `1` | at least one unit is undelivered or delivered `Status: failed` | refuse merge; name the units |
+| `2` | THE CHECK DID NOT RUN — no manifest, malformed assignment, unreadable trace, or a still-live worker | refuse merge; this is an unknown, never a pass |
+
+The coordinator writes the manifest BEFORE dispatch, which is what makes freshness checkable at all
+— `launchMs` cannot be recovered afterwards:
+
+```json
+{
+  "runId": "feature-auth-2026-09-01T12-00-00Z",
+  "launchMs": 1756728000000,
+  "units": [
+    { "workUnitId": "api",  "tracePath": "/abs/project/.claude/traces/<RUN_ID>/api.md",  "pid": 12345 },
+    { "workUnitId": "docs", "tracePath": "/abs/project/.claude/traces/<RUN_ID>/docs.md" }
+  ]
+}
+```
+
+`pid` is optional and can only move an ABSENT trace between "undelivered" and "still waiting". A
+live worker may extend waiting; liveness has never been delivery.
+
+## 4. Where the generator must place all of this
+
+| Generated artifact | What must appear |
+|---|---|
+| `.claude/rules/swarm-file-evidence.md` | Section 1 verbatim, unless the path already exists |
+| `.claude/commands/feature.md` — Phase 3 | Section 2 block |
+| `.claude/rules/feature-lifecycle.md` — Implementation | Section 2 block |
+| `.claude/commands/feature-ent.md` + `feature-lifecycle-ent.md` | Section 2 block |
+| `.claude/commands/start.md` — Phase 2 | Section 2 block |
+| Autonomous loop commands (`/run`, `/go`) | Section 2 block |
+| Any `pipeline-forge` pipeline with a swarm stage | Section 2 block |
+| `CLAUDE.md` lifecycle section | one line naming the rule, so the contract is discoverable |
+
+A generated toolkit that dispatches parallel agents anywhere and carries none of this is INCOMPLETE
+— `06-package-deliver.md` fails delivery on it.

package/templates/.claude/skills/goap-research-ed25519/SKILL.md

@@ -42,6 +42,17 @@ record of something recited from memory. That combination is legal, expressible,
 | `ASSERTED` | Stated from model memory, source never opened | Nothing about the source | `0.0` |
 | *(absent)* | Fact predates this axis | Evidence is **unknown** — neither asserted nor verified | no ceiling of its own |
 
+For quoted text, the acquisition method is a separate closed vocabulary. The author-facing names
+map exactly to the stored values; only the verifier can emit the verdict after comparing captured bytes.
+
+| Stored method | Author-facing name | Verbatim ceiling |
+|---|---|---|
+| `raw-fetch` | `сырая-загрузка` | eligible only after a matching captured excerpt |
+| `tool-summary` | `пересказ-инструментом` | never verbatim, even when the words happen to match |
+| `search-listing` | `из-поисковой-выдачи` | eligible only after reconciliation against a captured excerpt |
+| `manual` | `вручную` | eligible only after reconciliation against a captured excerpt |
+| *(absent/other)* | `method-unknown` | never verbatim |
+
 **`FETCH_VERIFIED` cannot be self-declared.** It is minted only by `create_fetched_fact()`, which
 requires a `FetchRecord` — the byte hash, HTTP status and date of a request that actually happened.
 The manual constructors (`create_listing_fact`, `create_asserted_fact`) have no way to produce it.
@@ -54,7 +65,7 @@ Provenance, not truth.
 ### The report gate
 
 ```bash
-python3 scripts/check_report_evidence.py --report report.md --facts facts.json [--profile patient.json]
+python3 scripts/check_report_evidence.py --report report.md --facts facts.json [--profile patient.json] [--excerpts evidence_excerpts]
 ```
 
 `ASSERTED` claims must not appear in a report at all. `LISTING_ONLY` claims may appear only with a
@@ -197,12 +208,10 @@ mkdir ~/health-research && cd ~/health-research     # medical work lives here
 Do not run medical investigations inside a shared code repository. If you already have,
 the prompt log is `.dz/recall-usage.jsonl` and the lessons are in `.health-brain/`.
 
-Choosing the shared store anyway is not blocked — it is ADVISED against. `dz teach
---domain health-research` into a shared store prints what follows from the choice and
-the command that does it the other way; `dz recall --all --json --include-domain
-health-research` hands the data over and says how much of it is medical. Both end with
-"Nothing was blocked — this is your call." The data is yours; our job is that the choice
-is knowing rather than accidental.
+Choosing the shared store anyway is ADVISED against, never blocked: both `dz teach --domain
+health-research` and `dz recall --all --json --include-domain health-research` print what follows
+from the choice and end with "Nothing was blocked — this is your call" — the choice must be
+knowing, not accidental.
 Step 1 is what makes a lesson safe to keep: a rule about a method has nowhere to put a
 person. But note what that is and is not — it is a discipline, performed by you and
 asserted with `--confirm-method`, which nothing verifies. The property that holds
@@ -501,38 +510,44 @@ Invalid signatures are rejected with confidence `0.0`; they are never a recovera
 4. Extract claims and source URLs.
 5. **Fetch each source through the tool, not by hand:**
    ```python
-   from evidence_fetch import fetch_source, FetchRecord
-   record = fetch_source(url)                      # real HTTP, stdlib only
+   from evidence_fetch import fetch_source_returning_body, FetchRecord
+   from quote_provenance import QuoteRecord, capture_excerpt, write_excerpt
+   record, body = fetch_source_returning_body(url) # real HTTP, captured bytes
    if isinstance(record, FetchRecord):
-       fact = verifier.create_fetched_fact(claim, record, issuer, source_date="2024-03-01")
+       captured = capture_excerpt(body, quoted_text, record)
+       write_excerpt("evidence_excerpts", captured)
+       quoted = QuoteRecord(quoted_text, "raw-fetch", record.final_url,
+                            record.sha256_body, locator, captured["excerpt_id"])
+       fact = verifier.create_fetched_fact(claim, record, issuer, quote=quoted)
    else:                                            # offline, 404, oversize, refused scheme…
        fact = verifier.create_listing_fact(claim, url, reason=record.reason)
    ```
    A claim you never opened a source for is `verifier.create_asserted_fact(claim)` — record it
    honestly and let the gate refuse it. Never hand-label a class you did not earn.
+5a. **When quoting verbatim, capture at fetch time as shown above.** No captured source bytes means
+   no verbatim verdict; `tool-summary` can never earn one even when its words happen to match.
 6. Add facts to the research ledger; issuer-signed facts only when a pinned issuer key actually
    signed the message.
 7. Verify facts and citation chains.
 8. Cross-check claims through ordinary source evaluation.
 9. **Run the report gate before delivering:**
    `python3 scripts/check_report_evidence.py --report <report.md> --facts <facts.json>` — exit 0 required.
+9a. **A NEGATIVE conclusion ("no competitor has this") MUST carry its own basis:** КОРПУС · ПОЛНОТА ·
+   СПОСОБ ПОИСКА · ГРАНИЦА КОРПУСА · СЛЕДСТВИЕ. "We did not find it" is a property of the SEARCH;
+   "it is not there" is a property of the WORLD, and only an exhaustive corpus licenses the second.
+   Form, closed values and the measured reason: `references/negative-results.md`.
 10. Report confidence, evidence-class mix, unsigned claims, rejected signatures, and limitations
     explicitly.
 
 ## Output Expectations
 
-Reports should include:
-
-- Research objective and GOAP plan executed.
-- Findings with source URLs.
-- Verification status per claim on BOTH axes: trust (`ISSUER_SIGNED` / `SELF_ATTESTED` /
-  `UNVERIFIED`) and evidence (`FETCH_VERIFIED` / `LISTING_ONLY` / `ASSERTED` / unknown-legacy).
-- The evidence-class mix as a count — the share of `ASSERTED` should be zero.
-- A visible marker next to every `LISTING_ONLY` claim ("source not opened directly — verify").
-- Chain integrity result when citation chains are used.
-- Unsigned and rejected claims.
-- Explicit caveat that cryptographic provenance is not truth verification, and that
-  `FETCH_VERIFIED` means the bytes arrived — not that the source is right.
+Reports include: the objective + executed GOAP plan; findings with source URLs; per-claim status on
+BOTH axes — trust (`ISSUER_SIGNED`/`SELF_ATTESTED`/`UNVERIFIED`) and evidence
+(`FETCH_VERIFIED`/`LISTING_ONLY`/`ASSERTED`/unknown-legacy); the evidence-class mix as a count
+(the `ASSERTED` share should be zero); a visible marker on every `LISTING_ONLY` claim ("source not
+opened directly — verify"); chain integrity when chains are used; unsigned and rejected claims; the
+explicit caveat that cryptographic provenance is not truth verification — `FETCH_VERIFIED` means
+the bytes arrived, not that the source is right.
 
 ## Implementation
 

package/templates/.claude/skills/goap-research-ed25519/references/negative-results.md

@@ -0,0 +1,94 @@
+# Отрицательный вывод: «не нашли» и «доказали, что нет» — разные утверждения
+
+Читается по требованию. В `SKILL.md` из этого файла живёт одна строка-указатель; всё остальное здесь,
+потому что всегда-загружаемый корпус пакета исчерпан, а объём этой темы в него не помещается.
+
+## Отказ, ради которого это написано
+
+Отчёт исследования умеет делать очень сильное утверждение: **«такой функции нет ни у одного из
+конкурентов; ниша свободна»**. На нём основывают продукт. И ровно оно было НЕВИДИМО для аппарата
+доверия.
+
+**ИЗМЕРЕНО 2026-09-01, ТВИН-ТЕСТОМ, а не грепом** (грепу здесь верить нельзя: он находит словарь, а
+не слепоту). `scripts/check_report_evidence.py` шёл ОТ ЛЕДЖЕРА К ОТЧЁТУ — для каждого записанного
+факта искал его употребление в тексте. Два прогона на ОДНОМ леджере, отчёты различаются РОВНО одной
+строкой отрицательного вывода:
+
+```bash
+python3 check_report_evidence.py --report a.md --facts f.json --json > oa.json
+python3 check_report_evidence.py --report b.md --facts f.json --json > ob.json   # b.md = a.md + одна строка
+diff oa.json ob.json      # ДО починки: пусто, оба exit 0
+```
+
+Вывод гейта был БАЙТ В БАЙТ одинаков. То есть ничем не подкреплённое отрицание не могло ни
+увеличить, ни уменьшить число находок: оно было вне области зрения ПО ПОСТРОЕНИЮ, а не по недосмотру.
+Причина простая и структурная: аппарат оценивал только утверждения, у которых ЕСТЬ источник, а у
+отрицания источника нет — в этом и состоит отрицание.
+
+**МЕХАНИЗМ:** «не встретилось» и «доказано, что нет» приходят в отчёте В ОДИНАКОВОЙ ФОРМЕ, и решения
+по ним принимают одинаково. Первое — свойство ПОИСКА. Второе — свойство МИРА. Только второе
+оправдывает продукт, построенный на пустой нише.
+
+## Форма, которую отрицательный вывод обязан нести
+
+Пять полей рядом с утверждением (в пределах 900 знаков — блок, а не приложение):
+
+| Поле | Что отвечает | Закрытые значения |
+|---|---|---|
+| `КОРПУС` | что именно прочитано, ПЕРЕЧНЕМ | свободный текст, но перечислимый |
+| `ПОЛНОТА` | чем является этот перечень | `перечислимо и объявлено исчерпывающим` · `выборка` · `неизвестна` |
+| `СПОСОБ ПОИСКА` | как искали и какими запросами | свободный текст |
+| `ГРАНИЦА КОРПУСА` | по состоянию на когда | свободный текст |
+| `СЛЕДСТВИЕ` | что из этого следует | `не встретилось` · `намеренно отсутствует` |
+
+**Потолок, и он несущий.** `СЛЕДСТВИЕ: намеренно отсутствует` допустимо ТОЛЬКО при
+`ПОЛНОТА: перечислимо и объявлено исчерпывающим`. Выборка и неизвестная полнота поддерживают
+«не встретилось» и ничего сильнее: отсутствие в ЧАСТИ корпуса — отсутствие в ПОИСКЕ, а не в мире.
+
+**Почему пяти полей, а не двух.** Первая редакция требовала только `КОРПУС` и `ПОЛНОТА`. Проверяющая
+модель назвала это самым слабым местом заявки и была ПРАВА: **исчерпывающий ПЕРЕЧЕНЬ не доказывает
+исчерпывающего ПОИСКА**. Двенадцать страниц, прочитанных от корки до корки, всё равно пропустят
+функцию, если это были не те двенадцать — или если в запросе ни разу не прозвучало слово, которым
+её называет сам поставщик. Поэтому в потолок входят также способ поиска, покрытие запросов, отказы
+выборки и временная граница корпуса. Без них сильное «нет» выписывает себе разрешение само.
+
+## Пример
+
+```markdown
+Вывод: массового экспорта нет ни у одного из трёх конкурентов.
+
+КОРПУС: справочные центры A (14 стр.), B (9 стр.), C (11 стр.) — перечень в приложении A
+ПОЛНОТА: выборка — 34 из ~120 страниц; отказ выборки: раздел для партнёров под входом
+СПОСОБ ПОИСКА: полнотекстовый поиск по 6 запросам: «bulk export», «экспорт», «CSV», «API export», «выгрузка», «download all»
+ГРАНИЦА КОРПУСА: по состоянию на 2026-08-30
+СЛЕДСТВИЕ: не встретилось
+```
+
+`СЛЕДСТВИЕ: намеренно отсутствует` в этом примере было бы отвергнуто гейтом: полнота — выборка.
+
+## Чего проверка НЕ решает, и это граница, а не недоделка
+
+**Подходит ли названный корпус ВОПРОСУ.** Второй случай из полевого каталога ровно об этом: вопрос
+«есть ли у продукта X функция Y», функция описана ТОЛЬКО в справочном центре, а корпусом взята карта
+сайта. Карта сайта — идеально перечислимый, идеально исчерпывающий и НЕ ТОТ корпус. Проверка
+заставляет корпус НАЗВАТЬ, чтобы человек мог судить о его пригодности; судить — не её работа, и
+делать вид, что её, значило бы то самое ложное закрытие класса, которое весь гейт и отвергает.
+
+## Ворота
+
+Отдельного вызова не нужно: проверка живёт внутри уже существующего гейта и ходит во ВТОРУЮ сторону —
+от отрицательных выводов отчёта к их обоснованию.
+
+```bash
+python3 .claude/skills/goap-research-ed25519/scripts/check_report_evidence.py \
+  --report report.md --facts facts.json --json
+```
+
+Виды находок: `NEGATIVE_CONCLUSION_WITHOUT_BASIS` (нет одного из пяти полей — перечисляются, каких) ·
+`NEGATIVE_COMPLETENESS_UNRECOGNISED` · `NEGATIVE_IMPLICATION_UNRECOGNISED` ·
+`NEGATIVE_CLAIM_EXCEEDS_ITS_CEILING` (сильное следствие на выборке).
+
+**Область срабатывания сужена намеренно.** Ловятся УНИВЕРСАЛЬНЫЕ отрицания («ни у одного», «none of
+the», «ниша свободна»), а не любое «нет» в тексте: жадный сторож — не более строгий сторож, а
+сторож, который удалят. Новая формулировка отрицания будет пропущена, и здесь это сказано вслух,
+ровно как соседний пояс по относительному риску говорит о себе то же самое.