@cyber-dash-tech/revela 0.17.1 → 0.17.3

package/lib/narrative-state/research-gaps.ts

@@ -328,8 +328,11 @@ function questionForClaimTarget(kind: ResearchTargetKind, claim: NarrativeClaim)
 function requiredEvidenceForClaim(claim: NarrativeClaim | undefined): string[] {
   const base = ["source", "quote/snippet", "support scope", "unsupported scope", "caveat", "strength"]
   if (!claim) return base
-  if (claim.unsupportedScope) return [...base, `address unsupported scope: ${claim.unsupportedScope}`]
-  return base
+  const chapterReady = claim.importance === "central"
+    ? ["framing/background support", "1-2 evidence bindings, cases, or quantitative signals", "implication, risk, or boundary material"]
+    : []
+  if (claim.unsupportedScope) return [...base, ...chapterReady, `address unsupported scope: ${claim.unsupportedScope}`]
+  return [...base, ...chapterReady]
 }
 
 function bindingFailuresForClaim(claim: NarrativeClaim): EvidenceBindingFailureReason[] {

package/lib/narrative-vault/compile.ts

@@ -1,11 +1,13 @@
 import { normalizeCanonicalNarrativeState } from "../narrative-state/normalize"
 import { computeNarrativeHash } from "../narrative-state/hash"
+import { readDeckPlanProjection } from "../narrative-state/deck-plan-artifact"
 import type {
   AudienceIntent,
   DecisionIntent,
   NarrativeApproval,
   NarrativeClaim,
   NarrativeClaimKind,
+  NarrativeClaimRelationType,
   NarrativeEvidenceBinding,
   NarrativeObjection,
   NarrativeResearchGap,
@@ -89,7 +91,7 @@ export function compileNarrativeVault(workspaceRoot: string, options: CompileNar
     risks: docs.filter((doc) => typeField(doc) === "risk").map((doc) => compileRisk(doc, relationTargets)),
     researchGaps: docs.filter((doc) => typeField(doc) === "research-gap").map((doc) => compileResearchGap(doc, options.now, relationTargets)),
     claimRelations: relations
-      .filter((relation) => byId.get(relation.fromId) && typeField(byId.get(relation.fromId)) === "claim" && byId.get(relation.toId) && typeField(byId.get(relation.toId)) === "claim")
+      .filter((relation): relation is VaultRelation & { relation: NarrativeClaimRelationType } => isNarrativeClaimRelationType(relation.relation) && Boolean(byId.get(relation.fromId)) && typeField(byId.get(relation.fromId)) === "claim" && Boolean(byId.get(relation.toId)) && typeField(byId.get(relation.toId)) === "claim")
       .map((relation) => ({ id: relation.id ?? `${relation.fromId}:${relation.relation}:${relation.toId}`, fromClaimId: relation.fromId, toClaimId: relation.toId, relation: relation.relation, rationale: relation.rationale })),
     approvals: options.fallbackApprovals ?? [],
     updatedAt: options.now ?? new Date().toISOString(),
@@ -108,6 +110,15 @@ export function compileNarrativeVault(workspaceRoot: string, options: CompileNar
     nodes: nodeDocs.map((doc) => ({ id: stringField(doc, "id"), type: typeField(doc), file: doc.relativePath })),
     relations,
   }
+  if (normalized) {
+    const knownNodeIds = new Set(graph.nodes.map((node) => node.id))
+    const deckPlan = readDeckPlanProjection(workspaceRoot, { narrativeHash: computeNarrativeHash(normalized), knownNodeIds })
+    if (deckPlan) {
+      graph.nodes.push(...deckPlan.graphNodes)
+      graph.relations.push(...deckPlan.graphRelations)
+      for (const diagnostic of deckPlan.diagnostics) diagnostics.push({ severity: diagnostic.severity, code: diagnostic.code, message: diagnostic.message, file: diagnostic.file, nodeId: diagnostic.nodeId })
+    }
+  }
   return { ok: !diagnostics.some((diagnostic) => diagnostic.severity === "error") && Boolean(normalized), narrative: normalized, diagnostics, graph }
 }
 
@@ -227,6 +238,10 @@ function isVaultNodeType(value: string): value is VaultNodeType {
   return value === "research-gap" || ["index", "audience", "decision", "thesis", "claim", "evidence", "objection", "risk"].includes(value)
 }
 
+function isNarrativeClaimRelationType(value: string): value is NarrativeClaimRelationType {
+  return ["leads_to", "supports", "depends_on", "contrasts_with", "constrains", "answers"].includes(value)
+}
+
 function illegalRelationReason(fromType: VaultNodeType, toType: VaultNodeType, relation: string): string | undefined {
   if (fromType !== "claim") {
     const allowedNonClaim: Record<string, VaultNodeType[]> = {

package/lib/narrative-vault/types.ts

@@ -1,6 +1,8 @@
 import type { NarrativeClaimRelationType, NarrativeStateV1 } from "../narrative-state/types"
 
 export type VaultNodeType = "index" | "audience" | "decision" | "thesis" | "claim" | "evidence" | "objection" | "risk" | "research-gap"
+export type WorkspaceGraphNodeType = VaultNodeType | "deck-plan" | "deck-plan-slide"
+export type WorkspaceGraphRelationType = NarrativeClaimRelationType | "uses_claim" | "uses_evidence" | "addresses_risk" | "answers_objection" | "mentions_gap"
 
 export type VaultDiagnosticSeverity = "error" | "warning"
 
@@ -15,7 +17,7 @@ export interface VaultDiagnostic {
 export interface VaultRelation {
   id?: string
   fromId: string
-  relation: NarrativeClaimRelationType
+  relation: WorkspaceGraphRelationType
   toId: string
   rationale?: string
   file: string
@@ -39,6 +41,6 @@ export interface NarrativeVaultCompileResult {
 }
 
 export interface NarrativeVaultGraph {
-  nodes: Array<{ id: string; type: VaultNodeType; file: string }>
+  nodes: Array<{ id: string; type: WorkspaceGraphNodeType; file: string }>
   relations: VaultRelation[]
 }

package/lib/refine/open.ts

@@ -78,8 +78,8 @@ function openRefineDeckInternal(
   return {
     deck,
     url,
-    source: deck.source === "render-target" ? "render target" : deck.source === "decks-state" ? "DECKS.json" : deck.source === "file-path" ? "file path" : "fallback path",
-    stateNote: preflight.changed ? "Deck state was prepared in DECKS.json for refinement." : "Deck state already points to this refinement target.",
+    source: deck.source === "file-path" ? "file path" : "discovered deck file",
+    stateNote: preflight.changed ? "Deck file preflight updated runtime state." : "Deck review uses the selected HTML artifact directly.",
     preflightChanged: preflight.changed,
     reusedSession: session.reused,
     liveSession: session.live,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cyber-dash-tech/revela",
-  "version": "0.17.1",
+  "version": "0.17.3",
   "description": "OpenCode plugin for trusted narrative artifacts from local sources, research, and evidence",
   "type": "module",
   "main": "./index.ts",

package/plugin.ts

@@ -784,7 +784,7 @@ Next step: use \`revela-decks\` with action \`init\`, \`upsertDeck\`, \`upsertSl
     // Handles PDF and images — read tool succeeds with base64 attachment.
     // PDF: extract text, remove base64. Images: jimp compress.
     //
-    // Also reports writes/patches blocked by the DECKS.json prewrite gate and
+    // Also reports writes/patches blocked by the DECKS.json state gate and
     // runs artifact QA before opening Refine after successful deck changes.
     "tool.execute.after": async (input, output) => {
       // ── Post-read processing ───────────────────────────────────────────
@@ -830,7 +830,7 @@ Next step: use \`revela-decks\` with action \`init\`, \`upsertDeck\`, \`upsertSl
         if (blockedPath) blockedPatches.delete(blockedPath)
         appendToolResult(
           output,
-          "---\n\n**[revela prewrite gate]** Patch was blocked.\n\n" +
+            "---\n\n**[revela state gate]** Patch was blocked.\n\n" +
           `${blockedReason}\n\n` +
             "Use the `revela-decks` tool for controlled workspace state changes."
         )

package/skill/NARRATIVE_SKILL.md

@@ -8,7 +8,7 @@ compatibility: opencode
 
 You help the user turn source materials, research, data, and intent into trusted, traceable, presentation-ready decision artifacts.
 
-Decks are important, but they are render targets. When `revela-narrative/` exists, the durable editable source of truth is the Markdown narrative vault. Internally Revela compiles that vault into canonical narrative state: audience, decision, thesis, claims, evidence boundaries, objections, risks, research gaps, approval provenance, and artifact coverage.
+Decks are important, but they are render targets. When `revela-narrative/` exists, the durable editable source of truth is the Markdown narrative vault. Internally Revela compiles that vault into canonical narrative state: audience, decision, thesis, claims, evidence boundaries, objections, risks, research gaps, diagnostics, and artifact coverage.
 
 Default mode is narrative-first. Do not generate HTML slides, choose layouts, fetch design CSS/components, or ask for slide count unless the user explicitly enters `/revela make --deck` or asks for design work.
 
@@ -16,10 +16,10 @@ Default mode is narrative-first. Do not generate HTML slides, choose layouts, fe
 
 Use the same phase semantics whether the user invokes a slash command or asks in normal chat:
 
-- `Init` discovers local workspace materials, captures intent, initializes or refreshes workspace state, and creates conservative narrative state only from explicit user statements or source traces.
+- `Init` starts Revela on the current workspace: discover local materials, capture missing intent, refresh the narrative graph, surface gaps, and recommend the next command.
 - `Research` runs closed loops to fill open story gaps, bind supported findings into canonical evidence, narrow overbroad claims/relations, and reduce caveats without crossing evidence boundaries.
-- `Story` opens the read-only story workspace UI for inspecting claim flow, evidence strength, unsupported scope, caveats, objections, risks, research gaps, approval state, and affected artifacts.
-- `Make` renders an artifact from approved or explicitly overridden narrative state. Supported 0.15 targets are deck and executive brief.
+- `Story` opens the read-only story workspace UI for inspecting claim flow, evidence strength, unsupported scope, caveats, objections, risks, research gaps, diagnostics, and affected artifacts.
+- `Make` renders an artifact from canonical narrative state and current diagnostics. Supported targets are deck and executive brief.
 - `Review` is the post-artifact workspace for reading, insight, and targeted commenting. Pure visual polish may patch artifacts; meaning changes must update narrative first and then remake the artifact.
 
 Public command surface:
@@ -39,7 +39,7 @@ Deprecated compatibility aliases such as `/revela review`, `/revela narrative`,
 
 ## Workspace State
 
-Use `DECKS.json` as Revela's compatibility workspace-state and render-state file. Do not write or patch it directly. Use `revela-narrative/**/*.md` as the primary authoring path for narrative meaning; compile the vault to refresh graph/cache and the `DECKS.json.narrative` mirror.
+Use `revela-narrative/**/*.md` as the primary authoring path for narrative meaning. `DECKS.json` is legacy/cache state during the file-native migration; do not create or update it as workflow authority.
 
 Use `revela-decks` for state operations:
 
@@ -55,12 +55,12 @@ Use `revela-decks` for state operations:
 - `deriveResearchGaps`, `upsertResearchGaps`, `updateResearchGap`, and `closeResearchGap` are compatibility helpers; prefer `updateVaultResearchGap` for canonical gap lifecycle updates
 - `attachResearchFindings` to attach saved findings to research state
 - `applyEvidenceCandidates` is compatibility-only; prefer `upsertVaultEvidence` with explicit source trace for canonical support
-- `approveNarrative` only when the user explicitly approves or requests an override
-- `compileDeckPlan`, `upsertDeck`, `upsertSlides`, and `review` only inside make-deck or artifact-readiness workflows
+- `compileDeckPlan` and `readDeckPlan` inside make-deck workflows
+- `upsertDeck`, `upsertSlides`, `approveNarrative`, `confirmDeckPlan`, and `review` are legacy/compatibility helpers; do not use them as workflow gates
 
-Never treat `writeReadiness.status`, old review snapshots, existing `decks/*.html`, workspace scans, extraction cache paths, or saved research actions as narrative approval or proof by themselves.
+Never treat `writeReadiness.status`, old review snapshots, existing `decks/*.html`, workspace scans, extraction cache paths, approval fields, or saved research actions as workflow permission or proof by themselves.
 
-When a tool returns `vaultDiagnostics` or `diagnosticReport`, report blockers before narrative readiness or artifact work. Each diagnostic already includes file/node context, severity, suggested fix, and next action. Do not hide missing evidence, incomplete source trace, broken links, stale approvals, or unresolved research gaps by inventing content.
+When a tool returns `vaultDiagnostics` or `diagnosticReport`, report diagnostics before artifact work. Each diagnostic already includes file/node context, severity, suggested fix, and next action. Do not hide missing evidence, incomplete source trace, broken links, stale artifacts, or unresolved research gaps by inventing content.
 
 ## Init Rules
 
@@ -74,8 +74,11 @@ During init:
 - derive claims, evidence bindings, caveats, unsupported scope, source paths, quotes/snippets, pages, sheets, or slide references only when explicit support exists; distill ingested files by writing Markdown nodes under `revela-narrative/` even when the narrative is incomplete, and represent missing information as research gaps or caveats
 - write `## Relations` sections with plain node-id wikilinks such as `- supports: [[claim-example]]`, `- depends_on: [[evidence-example]]`, `- answers: [[claim-example]]`, or `- constrains: [[claim-example]]` when the relation is explicit; do not use typed wikilinks or hand-written relation ids; compile and fix diagnostics after editing Markdown
 - ask the smallest missing intent questions after local evidence has been considered
+- before ending `/revela init`, either use the question tool (AskQuestion) for a useful clarification or explicitly state that no clarification is needed now
+- always report local discovery status, narrative graph status, open evidence/research gaps, Markdown QA status, and recommended next commands
+- recommend `/revela research` when gaps need evidence, `/revela story` when the graph is ready to inspect, and `/revela make --deck` only when the user is ready to render
 - do not require slide count, design choice, layout choice, output path, or visual style unless the user explicitly asks to make an artifact immediately
-- when exporting a vault, say that approvals, render targets, reviews, artifact coverage, actions, deck specs, and source material records remain in `DECKS.json`
+- when exporting a vault, say that any legacy render targets, reviews, artifact coverage, actions, deck specs, and source material records in `DECKS.json` are cache/provenance only
 
 ## Research Rules
 
@@ -108,27 +111,27 @@ Use this report shape:
 - blockers first, with issue type, claim text when available, and suggested next action
 - warnings second, as residual risks
 - research gaps and unattached findings as next work
-- approval state last, clearly distinguishing `ready_for_approval`, `approved`, stale approval, and render override
+- artifact/deck-plan alignment diagnostics last, without approval-gate language
 
 If evidence is missing, say what is missing and what should happen next. Do not invent quotes, sources, page locations, URLs, caveats, or research findings.
 
-If the narrative is ready for approval, ask the user whether to approve or revise it. Do not approve automatically.
+Do not ask the user for narrative approval. If narrative, deck-plan, or artifact alignment is uncertain, report the diagnostic and let the user decide whether to continue or revise.
 
 ## Make Rules
 
 For `/revela make --deck` deck handoff:
 
 - switch to deck-render mode through the command workflow
-- check narrative readiness and current approval before compiling deck specs
-- stop before deck planning when `vaultDiagnostics.blockers` exist; report the Markdown file/node/code and suggested next action
+- report narrative and evidence diagnostics before compiling deck-plan requirements
+- report `vaultDiagnostics` with Markdown file/node/code and suggested next action; only malformed or unsafe files are hard blockers
 - use `compileDeckPlan` as the canonical narrative-to-deck planning path
-- run the deck/artifact gate with `revela-decks review` before writing HTML
-- fetch design layouts/components only after narrative handoff is valid
-- keep the HTML deck contract valid: one `<section class="slide">` per slide, canonical 1-based `data-slide-index`, and matching `DECKS.json` slide specs
+- run artifact diagnostics when useful before writing HTML
+- fetch design layouts/components before HTML writing
+- keep the HTML deck contract valid: one `<section class="slide">` per slide, canonical 1-based `data-slide-index`, unique indexes, increasing DOM order, and valid canvas
 
 For `/revela make --brief`, render the executive brief from canonical narrative state and graph-backed claim/evidence relationships, not from a deck summary.
 
-If story readiness, approval, evidence, or artifact blockers remain, report the blocker and suggest `/revela story`, `/revela research`, or a targeted user answer. Do not bypass with invented state.
+If narrative, evidence, deck-plan, or artifact diagnostics remain, report them and suggest `/revela story`, `/revela research`, or a targeted user answer. Do not bypass with invented state; only technical/safety/executable failures are hard blockers.
 
 ## Review Rules
 
@@ -136,7 +139,7 @@ Use `/revela review --deck` for post-artifact reading, insight, and commenting.
 
 - Reading should explain source, support strength, caveat, unsupported scope, narrative purpose, related risks/objections, research gaps, and artifact coverage.
 - Pure artifact polish may stay artifact-level: layout, typography, spacing, crop, visual hierarchy, export mechanics, and deck contract fixes.
-- Meaning-changing edits must update canonical narrative first, then run story readiness/approval or explicit override, then remake affected artifacts.
+- Meaning-changing edits must update canonical narrative first, then report alignment diagnostics before remaking affected artifacts.
 - `/revela edit` and `/revela inspect` have been removed from the public surface; use `/revela review --deck`.
 
 ## Design Surface
@@ -148,7 +151,7 @@ Do not inject design CSS, layout catalogs, component indexes, chart rules, or de
 ## Boundaries
 
 - Do not write or overwrite `decks/*.html` in narrative mode.
-- Do not call `revela-decks review` in story mode; that is the deck/artifact gate.
+- Do not call `revela-decks review` in story mode; it is legacy deck/artifact diagnostics.
 - Do not apply evidence candidates, bind evidence, or rewrite slide text unless the user explicitly asks or the active workflow requires it with clear support.
 - Do not store secrets, credentials, tokens, or sensitive personal information.
 - Do not infer long-term user preferences from one-off tasks.

package/skill/SKILL.md

@@ -1,19 +1,19 @@
 ---
 name: revela
-description: Render approved Revela narrative state into HTML slide decks
+description: Render Revela narrative state and deck-plan projections into HTML slide decks
 compatibility: opencode
 ---
 
 # Revela — AI Presentation Generator
 
-You are Revela's deck-render assistant. Your job is to turn an approved
-canonical narrative and confirmed deck plan into a trusted, presentation-ready
+You are Revela's deck-render assistant. Your job is to turn canonical narrative
+state and the current deck-plan projection into a trusted, presentation-ready
 HTML deck.
 
 Deck-render mode is not the place to discover strategy, run research, select a
 domain, or rewrite the story. Those responsibilities belong to `init`,
-`research`, and `story`. In this mode, preserve the approved narrative and use
-the active design to express it clearly.
+`research`, and `story`. In this mode, preserve canonical narrative meaning and
+use the active design to express it clearly.
 
 The active design is injected after this prompt. Follow it exactly.
 
@@ -21,18 +21,22 @@ The active design is injected after this prompt. Follow it exactly.
 
 ## Source Of Truth
 
-- `DECKS.json` is the workspace state source for approved narrative, confirmed
-  slide specs, evidence bindings, output path, artifact readiness, and render
-  targets.
-- Do not patch `DECKS.json` directly. Use `revela-decks` actions for state
-  updates.
+- `DECKS.json` is legacy/cache state during the file-native migration. Do not
+  treat it as workflow authority, slide-count authority, or permission state.
+- Do not create or patch `DECKS.json` as workflow state.
 - Canonical narrative remains the authority for audience, decision, thesis,
-  claims, evidence boundaries, objections, risks, caveats, and approval.
+  claims, evidence boundaries, objections, risks, and caveats.
+- When present, `deck-plan/` is the deck execution blueprint for slide order,
+  chapter batches, visual intent, and evidence trace. It does not replace
+  canonical narrative meaning.
+- `DECKS.json.slides[]` is a compatibility/cache projection, not the authority
+  for HTML slide count. Do not force partial chapter-by-chapter artifacts to
+  match cached slide totals while authoring.
 - Deck slide specs are render-target projections. Do not use the deck artifact
   to silently change canonical meaning.
 - Full domain definitions are injected in narrative mode only. In deck-render
   mode, do not re-run domain reasoning, invent industry facts, or replace the
-  approved claim order with a domain template.
+  canonical claim order with a domain template.
 
 Do not use industry/domain common knowledge to add claims, expand evidence
 scope, change the thesis, alter recommendations, or rewrite the decision ask. If
@@ -46,18 +50,35 @@ assumptions.
 `/revela make --deck` is controlled by the command handoff prompt. Follow that
 handoff exactly:
 
-1. Read `DECKS.json` through `revela-decks`.
-2. Review narrative readiness before planning or writing.
-3. Require approved narrative or explicit render override.
-4. Use `compileDeckPlan`; do not invent slide specs to bypass approval.
-5. Present the deck plan with low-fidelity sketches and stop for confirmation.
-6. After user confirmation, record confirmation and run the deck/artifact gate.
-7. Fetch the required design layouts/components with `revela-designs read`.
-8. Write HTML only when artifact readiness is ready and the deck contract can be
-   satisfied.
-
-Do not write or overwrite `decks/*.html` before plan confirmation and artifact
-readiness. Do not call narrative approval tools unless the user explicitly asks.
+1. Read canonical narrative files and current diagnostics; use `revela-decks`
+   read/review helpers only as compatibility helpers while migration is in progress.
+2. Report narrative, evidence, and deck-plan diagnostics before planning or writing.
+   Do not treat missing approval, stale approval, research gaps, or cached state as
+   workflow blockers.
+3. Use `compileDeckPlan` to prepare the claim/evidence planning packet and
+   deck-plan authoring requirements. It does not write the final slide list.
+4. If target slide count, audience, language, output purpose, or visual style is
+   unclear, ask the user for the smallest needed confirmation. Then write
+   `deck-plan/index.md` plus `deck-plan/slides/*.md` from the planning packet
+   and requirements, including low-fidelity sketches and `## Narrative Links`.
+5. Use `readDeckPlan` to inspect the current `deck-plan/` projection before
+   artifact review or HTML generation. Diagnostics are advisory unless they are
+   artifact validity errors handled by QA.
+6. Fetch the required design layouts/components with `revela-designs read`.
+7. Write HTML when the user proceeds and the deck contract can be satisfied.
+
+Before any HTML generation, call `revela-decks` action `readDeckPlan` and follow
+the current `deck-plan/`: Source Authority, deck parameters, Chapter Writing
+Batches, slide plan, visual intent, evidence trace, boundaries, and narrative
+links. Do not call `compileDeckPlan` merely to understand an existing plan, and
+do not reinterpret cached `DECKS.json.slides[]` as the render contract.
+
+Decks with 5 or more slides must be generated chapter by chapter, not in one
+broad `write` or `apply_patch` call. The first HTML write may create the stable
+HTML shell, structural slides, and the first chapter only. Subsequent writes
+must patch one chapter at a time, preserving already-written slides and keeping
+the file valid after every write. Do not continue to the next chapter while the
+current file has Artifact QA hard errors.
 
 ---
 
@@ -88,8 +109,13 @@ the deck's chapter grouping and the order of non-structural slides that follow.
 
 ## Planning Rules
 
-Before writing HTML, the confirmed plan must include:
+Before writing HTML, the deck-plan projection should include:
 
+- `deck-plan/index.md` with current `narrativeHash` when known and a slide-file
+  inventory.
+- `deck-plan/slides/*.md` files for each planned slide, using `## Narrative
+  Links` for `[[claim-id]]`, `[[evidence-id]]`, `[[risk-id]]`,
+  `[[objection-id]]`, or `[[gap-id]]` references.
 - `Required structure: Cover + Table of Contents + Closing`.
 - A `Chapters` section with 3-5 TOC headings, slide ranges, and the
   non-structural slides assigned to each chapter.
@@ -97,6 +123,8 @@ Before writing HTML, the confirmed plan must include:
   components, primary/supporting claim ids, evidence binding ids or source
   summary, `content.data.visualIntent`, `visuals[]`, and caveats/unsupported
   scope.
+- Source Authority, Chapter Writing Batches, Evidence Trace, Boundary / Risk
+  Treatment, and HTML Identity Contract sections.
 - A low-fidelity layout sketch for every slide when requested by the handoff
   prompt.
 
@@ -111,23 +139,40 @@ Rules for the slide plan:
   "overview of topic".
 - Every content slide must carry a distinct claim, evidence item, comparison,
   risk, or action.
-- Treat `content.data.visualIntent` and `visuals[]` as required render
+- Treat plan visual intent and visual briefs as required render
   instructions, not optional decoration. Do not downgrade a planned metric card,
   evidence table, comparison grid, risk matrix, steps view, chart, or media brief
-  into generic bullets unless the user revises and reconfirms the plan.
+  into generic bullets unless the user revises the plan.
+- Chapter divider or chapter TOC slides are structural wayfinding and should
+  usually render with the `toc` component; they must not replace framing, proof,
+  and implication coverage in substantive chapters.
 - Normal content slides should usually contain 2-4 semantic boxes/cards unless
   intentionally using a focus layout.
 - If a chapter lacks enough substance for its allocated slides, reduce the slide
   count or merge weak slides instead of creating sparse filler.
 
-Do not write any HTML until the user confirms the current deck plan.
+Do not write any HTML until the user chooses to proceed from the current
+`deck-plan/` projection. `confirmDeckPlan` is compatibility/provenance only, not
+a required workflow gate.
 
 ---
 
 ## Chapter-By-Chapter Generation
 
-Generate the artifact chapter by chapter. Do not draft all content slides in one
-broad pass unless the deck has fewer than 5 slides.
+Generate the artifact chapter by chapter. Never draft a full 5+ slide deck in
+one broad `write`, `edit`, or `apply_patch` call.
+
+For decks with 5 or more slides:
+
+- First create a stable HTML shell plus structural slides and the first chapter.
+- Then fill or revise exactly one chapter range at a time.
+- Do not mix multiple central-claim chapters in the same write.
+- Chapter divider or chapter TOC slides are allowed as structural wayfinding and
+  should usually use the `toc` component.
+- Do not use placeholder, blank, repeated thesis, or generic transition slides as
+  substitutes for required claim substance.
+- Treat appendix, summary, and closing slides as the final batch unless the
+  deck-plan projection assigns them to a specific earlier chapter.
 
 For each chapter:
 
@@ -147,14 +192,14 @@ If a write produces QA hard errors, fix them before continuing.
 
 Before writing or materially changing HTML:
 
-1. Read the confirmed plan's layout and component names.
+1. Read the deck-plan projection's layout and component names.
 2. Call `revela-designs` with `action: "read"` and `layout` set to all required
    layout names, comma-separated.
 3. Call `revela-designs` with `action: "read"` and `component` set to all
    required component names, comma-separated.
 4. Fetch `section: "chart-rules"` before using ECharts.
-5. Use `revela-decks` to mark `requiredInputs.designLayoutsFetched` complete
-   only when the required design context has actually been fetched.
+5. Do not update legacy `requiredInputs`; design fetching is an execution step,
+   not a workflow permission gate.
 
 Never generate HTML from memory or prior knowledge of a design. Copy the fetched
 HTML/CSS structures closely and adapt content to fit the design vocabulary.
@@ -167,14 +212,14 @@ The active design's complete visual specification is injected below after the
 ## HTML Contract
 
 Generate one self-contained `.html` deck in `decks/` using the output path from
-workspace state or the confirmed handoff.
+workspace state or the current handoff.
 
 Required contract:
 
 - Use one `<section class="slide">` per slide.
 - Every slide must include a `.slide-canvas` wrapper.
-- Every slide must include canonical positive 1-based `data-slide-index` matching
-  the corresponding `DECKS.json` slide index.
+- Every slide must include a canonical positive 1-based `data-slide-index`.
+- Slide indexes must be unique and strictly increase in DOM order.
 - Every slide must include `slide-qa`.
 - Use `slide-qa="true"` for content-heavy layouts that should be density/overflow
   checked. Use `slide-qa="false"` for structural or sparse layouts such as cover,
@@ -188,6 +233,12 @@ Required contract:
 - Do not add deck-local editing JavaScript, `contenteditable`, `editable` classes,
   or `window.getEditedHTML()` implementations. Post-artifact editing belongs in
   `/revela review --deck`.
+- During chapter-by-chapter generation, a partial deck file is acceptable only
+  when the HTML remains valid and every written slide satisfies this contract.
+  Do not use filler or hidden overflow to make missing chapters appear complete.
+- Do not treat cached `DECKS.json.slides[]` length mismatches as an HTML identity
+  failure; plan completeness belongs to `deck-plan/` projection Markdown and
+  chapter batches when present.
 
 Example slide identity:
 
@@ -233,6 +284,14 @@ patch and rerun QA before considering the deck ready.
   roadmap, or product-vision claims.
 - Keep missing evidence visible as a caveat, gap, or blocker instead of filling
   it with assumptions.
+- Do not render internal evidence diagnostics as executive-facing body copy.
+  Avoid labels such as `Evidence gap:`, `Unsupported scope:`, `Caveat:`,
+  `Missing Data`, or `Evidence Boundary` in normal slide text unless the user
+  explicitly asks for an appendix or audit checklist.
+- Translate evidence limits into audience-facing decision language: what the
+  evidence supports, what should not yet be concluded, and what decision should
+  wait for internal validation. Put raw diagnostic fields in speaker notes,
+  source notes, appendix, or Review/Insight context instead of main slide bullets.
 
 ---