wtf-p 0.7.2 → 0.7.4

package/vendors/copilot/project/.github/prompts/wtfp-review-section.prompt.md

@@ -5,8 +5,6 @@ agent: agent
 tools: []
 ---
 
-<!-- Generated by WTF-P adapter compiler v5 from protocol/actions/review-section; do not edit. -->
-
 WTFP_ACTION_UNAVAILABLE
 
 Action: `review-section`
@@ -16,3 +14,5 @@ Unavailable effects: `user.gate`
 
 No workflow, tool, network request, package operation, external issue, VCS operation, or other effect ran.
 Safe alternative: preserve project state and return a manual, non-executed handoff for the requested operation.
+
+<!-- Generated by WTF-P adapter compiler v5 from protocol/actions/review-section; do not edit. -->

package/vendors/copilot/project/.github/prompts/wtfp-settings.prompt.md

@@ -5,8 +5,6 @@ agent: agent
 tools: []
 ---
 
-<!-- Generated by WTF-P adapter compiler v5 from protocol/actions/settings; do not edit. -->
-
 WTFP_ACTION_UNAVAILABLE
 
 Action: `settings`
@@ -16,3 +14,5 @@ Unavailable effects: `user.gate`
 
 No workflow, tool, network request, package operation, external issue, VCS operation, or other effect ran.
 Safe alternative: preserve project state and return a manual, non-executed handoff for the requested operation.
+
+<!-- Generated by WTF-P adapter compiler v5 from protocol/actions/settings; do not edit. -->

package/vendors/copilot/project/.github/prompts/wtfp-submit-milestone.prompt.md

@@ -5,8 +5,6 @@ agent: agent
 tools: []
 ---
 
-<!-- Generated by WTF-P adapter compiler v5 from protocol/actions/submit-milestone; do not edit. -->
-
 WTFP_ACTION_UNAVAILABLE
 
 Action: `submit-milestone`
@@ -16,3 +14,5 @@ Unavailable effects: `user.gate`
 
 No workflow, tool, network request, package operation, external issue, VCS operation, or other effect ran.
 Safe alternative: preserve project state and return a manual, non-executed handoff for the requested operation.
+
+<!-- Generated by WTF-P adapter compiler v5 from protocol/actions/submit-milestone; do not edit. -->

package/vendors/copilot/project/.github/prompts/wtfp-update.prompt.md

@@ -5,8 +5,6 @@ agent: agent
 tools: []
 ---
 
-<!-- Generated by WTF-P adapter compiler v5 from protocol/actions/update; do not edit. -->
-
 WTFP_ACTION_UNAVAILABLE
 
 Action: `update`
@@ -16,3 +14,5 @@ Unavailable effects: `package.update`, `user.gate`
 
 No workflow, tool, network request, package operation, external issue, VCS operation, or other effect ran.
 Safe alternative: preserve project state and return a manual, non-executed handoff for the requested operation.
+
+<!-- Generated by WTF-P adapter compiler v5 from protocol/actions/update; do not edit. -->

package/vendors/copilot/project/.github/prompts/wtfp-verify-work.prompt.md

@@ -5,8 +5,6 @@ agent: agent
 tools: []
 ---
 
-<!-- Generated by WTF-P adapter compiler v5 from protocol/actions/verify-work; do not edit. -->
-
 WTFP_ACTION_UNAVAILABLE
 
 Action: `verify-work`
@@ -16,3 +14,5 @@ Unavailable effects: `user.gate`
 
 No workflow, tool, network request, package operation, external issue, VCS operation, or other effect ran.
 Safe alternative: preserve project state and return a manual, non-executed handoff for the requested operation.
+
+<!-- Generated by WTF-P adapter compiler v5 from protocol/actions/verify-work; do not edit. -->

package/vendors/copilot/project/.github/prompts/wtfp-write-section.prompt.md

@@ -5,8 +5,6 @@ agent: agent
 tools: []
 ---
 
-<!-- Generated by WTF-P adapter compiler v5 from protocol/actions/write-section; do not edit. -->
-
 WTFP_ACTION_UNAVAILABLE
 
 Action: `write-section`
@@ -16,3 +14,5 @@ Unavailable effects: `user.gate`
 
 No workflow, tool, network request, package operation, external issue, VCS operation, or other effect ran.
 Safe alternative: preserve project state and return a manual, non-executed handoff for the requested operation.
+
+<!-- Generated by WTF-P adapter compiler v5 from protocol/actions/write-section; do not edit. -->

package/vendors/copilot/project/.github/skills/wtfp-deliver-research/references/actions.md

@@ -104,7 +104,7 @@ Contract: [protocol/actions/create-slides.json](../../../actions/create-slides.j
 1. Require project identity and enough manuscript or verified results to support a presentation.
 2. Ask for duration, expected slide count, audience, occasion, delivery format, visual style, and desired emphasis.
 3. Derive a timed narrative: audience problem, thesis, minimum background, method, strongest evidence, limitations, implications, and closing takeaway. Allocate time and slides before writing.
-4. Use verified project claims and cite source or manuscript locations in speaker notes or a references slide. Do not introduce novel results to make the story cleaner.
+4. Use verified project claims and cite source or manuscript locations in speaker notes or a references slide. Do not introduce novel results to make the story cleaner. Refuse any claim without a ledger row, never invent speaker or venue metadata, and derive diagrams only from named source files or documents with stated paths.
 5. Prefer one communicative purpose per slide. Use concise text, readable type, high contrast, descriptive titles, accessible color, and alt text or equivalent descriptions for meaningful visuals.
 6. Use existing figures only when provenance and interpretation are known. Mark placeholders and data needs explicitly; never fabricate a chart.
 7. Generate editable slide source and a delivery manifest under `project://deliverables/slides/{artifact}`.
@@ -117,11 +117,11 @@ Completion requires an audience-appropriate editable deck with an honest render
 
 Contract: [protocol/actions/create-poster.json](../../../actions/create-poster.json)
 
-1. Require project identity and verified manuscript findings. Ask for dimensions, orientation, venue rules, audience viewing distance, title, authors, affiliations, contact details, output format, and available visuals.
+1. Require project identity and verified manuscript findings. Ask for dimensions, orientation, venue rules, audience viewing distance, title, authors, affiliations, contact details, output format, and available visuals. Never invent missing metadata; leave a visible placeholder and report it.
 2. Define a non-linear reading hierarchy: one-sentence takeaway, motivation, minimal method, principal evidence, limitations, conclusion, and contact or artifact link.
 3. Budget physical space before writing. Prioritize the title, takeaway, and strongest figure; avoid shrinking prose to preserve excess content.
-4. Use verified claims, values, citations, and figures. Record provenance and include accessible descriptions. Mark missing visuals as placeholders rather than generating false evidence.
-5. Generate editable poster source and a delivery manifest under `project://deliverables/poster/{artifact}`.
+4. Use verified claims, values, citations, and figures, recorded in the claim ledger from `protocol://templates/poster.md`; refuse any statement without a source record, manuscript passage, or named project file. Derive diagrams only from named source files or documents and state their paths. Record provenance and include accessible descriptions. Mark missing visuals as placeholders rather than generating false evidence.
+5. Generate editable, laid-out poster source (the template's HTML grid or the venue's mandated template) and a delivery manifest with the claim ledger under `project://deliverables/poster/{artifact}`.
 6. Check dimensions, orientation, margins, font sizes at final scale, column flow, contrast, image resolution, citation legibility, link or code targets, and overflow.
 7. Render only when requested and a configured host-provided local renderer exists; invoke it under the action's declared `tool.execute` effect and verify the actual artifact dimensions. Distinguish source validity from render success.
 8. Report source and rendered paths, validation results, print-service considerations, and unresolved manual steps.

package/vendors/copilot/project/.github/skills/wtfp-plan-section/references/actions.md

@@ -110,7 +110,7 @@ Contract: [protocol/actions/plan-section.json](../../../actions/plan-section.jso
 2. Read the complete planning context before decomposing work: manifest, config, state, decisions, outline, section record, context, research, source/evidence records, relevant prior summaries, and the bounded `project://validations/*` collection.
 3. Before any specialist dispatch, filter the validation records to candidates whose `subject_uri` is exactly `project://structure/outline` and whose `action_id` is exactly `create-outline`. A candidate is current only when `executed_at >= outline.updated_at`. Because the v1 validation schema carries no outline revision or content hash, disclose that this timestamp test is a conservative freshness proxy.
 4. Require exactly one current candidate and require its `status` to be `passed`. Separately verify that the current outline and target section are consistent with all current locked and deferred author choices: honor locked choices and do not treat deferred choices as resolved. A missing, stale, ambiguous, or non-passing candidate, or a decision contradiction, blocks all specialist dispatch and every plan, section, state, or validation write. Only a recovery checkpoint may be proposed on this blocked path, and it may be written only after a complete record preview and explicit author approval.
-5. If the section is literature-heavy and research obligations remain empty, offer `research-gap`; do not manufacture citations to keep planning moving.
+5. If the section is literature-heavy, require a section-specific research artifact and resolvable source/evidence records for its planned claims before dispatch or approval. Run `research-gap` with the configured CiteNexus backend when available; if coverage remains insufficient, record a research checkpoint and stop. Search candidates alone are not verified citations. Do not manufacture citations to keep planning moving.
 6. Summarize the section goal, claims, evidence, manuscript artifact, dependencies, and open decisions at `config.gates.confirm_plan`.
 7. After the prerequisites pass, require `section-planner` in a bounded delegated pass to create one or more immutable Markdown `project://sections/{section}/plans/{plan}` artifacts. Each plan must declare:
    - stable section and plan identifiers;

package/vendors/copilot/project/.github/skills/wtfp-research-literature/references/actions.md

@@ -54,7 +54,7 @@ Contract: [protocol/actions/research-gap.json](../../../actions/research-gap.jso
    - `standard`: run a focused, reproducible search across the most relevant categories;
    - `deep`: map foundational, recent, competing, gap-defining, and methodological work, including important disagreements and intellectual lineage.
 5. Form search questions and inclusion criteria before searching. Record databases or corpora, query strings, date, filters, and stopping rule.
-6. Search authoritative scholarly sources only after disclosing and receiving approval for the external providers and bounded query set. When using the bundled dispatcher, `citation-search` may run with `--backend=cite-nexus` and an explicit `--providers` list after this gate. Returned results stay candidates, and this action performs no bibliography write. Deduplicate candidates by persistent identifier, then normalized title.
+6. Search authoritative scholarly sources with bounded queries. Two routes need no second per-query author gate: a host connection the operator already configured and authorized for read-only public scholarly metadata search, or the bundled CiteNexus dispatcher in a host session explicitly set to full-auto for this research action when every selected provider is a free, no-key public index (`crossref`, `datacite`, `europe_pmc`, or `arxiv`). Record provider IDs, query strings, date, and result limits in the research artifact. Do not send unpublished manuscript text, private notes, or credentials as search terms. Outside those routes, first disclose the providers and bounded query set and obtain explicit author approval. The dispatcher runs only `citation-search --backend=cite-nexus` with an explicit `--providers` list; honor an operator-set offline flag or any host refusal. Returned results stay candidates, and this action performs no bibliography write. Deduplicate candidates by persistent identifier, then normalized title.
 7. Verify each retained source from its primary record or publication. Create a `project://sources/{source}` record with title, creators, year, source kind, identifiers, citation key, status, provenance, inspection depth, and verification time.
 8. Read enough of each source to distinguish its actual claim, method, population, result, and limitation. Do not cite an abstract-only impression as full-paper evidence.
 9. Create `project://evidence/{evidence}` separately for each retained claim-level interpretation, with relation, locator, limitations, confidence, and inspection depth. Synthesize by question rather than listing papers; identify consensus, disagreement, methodological differences, missing evidence, and defensible positioning.

package/vendors/copilot/project/.github/skills/wtfp-write-section/references/actions.md

@@ -48,7 +48,7 @@ Contract: [protocol/actions/write-section.json](../../../actions/write-section.j
 
 1. Require an exact `project://sections/{section}/plans/{plan}` artifact linked from `project://sections/{section}` and verify its declared inputs, outputs, dependencies, validation, and approval state.
 2. If a corresponding summary or manuscript output exists, show the overwrite or merge impact and require explicit re-execution approval.
-3. Read the plan, `project://manifest`, `project://state`, `project://decisions`, `project://structure/outline`, section context and research, relevant source/evidence records, and enough neighboring prose to maintain continuity.
+3. Read the plan, `project://manifest`, `project://state`, `project://decisions`, `project://structure/outline`, section context and research, relevant source/evidence records, and enough neighboring prose to maintain continuity. For a literature-heavy section, require research and verified source/evidence coverage of the plan's factual claims before drafting. Route missing coverage through `research-gap` and a checkpoint; do not substitute model memory or search candidates for source records.
 4. Present the plan objective, output path, target words, evidence obligations, and checkpoints at the configured writing gate.
 5. Execute tasks in order against the exact `project://paper/{artifact}` output. For each task:
    - establish the paragraph or subsection's rhetorical job;

package/vendors/copilot/project/.github/wtfp/actions/research-gap.json

@@ -96,7 +96,7 @@
     },
     {
       "id": "user.gate",
-      "scope": "the external providers, bounded query set, and research scope and depth"
+      "scope": "unapproved or paid external providers and bounded query set, plus author-owned research scope and depth decisions"
     }
   ]
 }

package/vendors/copilot/project/.github/wtfp/roles/research-synthesizer.md

@@ -42,7 +42,7 @@ Investigate the literature needed to plan and write a specific section well. The
 ## Boundaries
 
 - This is a `mutation-report` role. It may write only the research and suggestion artifacts authorized by the invoking action.
-- When external literature search is approved, `citation-search` may run with `--backend=cite-nexus` and an explicit `--providers` list after the gate. Returned results stay candidates, and this role never performs a bibliography write.
+- An operator-configured, trusted read-only CiteNexus MCP connection may search bounded public scholarly metadata without a second per-query gate. In an explicitly selected full-auto host session for this research action, `citation-search --backend=cite-nexus` may also search `crossref`, `datacite`, `europe_pmc`, or `arxiv` without another gate. Other providers or modes require explicit network approval naming providers and query bounds. Honor offline flags and host refusals. Returned results stay candidates, and this role never performs a bibliography write.
 - Never fabricate a citation, identifier, quotation, metadata field, source conclusion, or claim of exhaustive coverage.
 - Never overwrite an existing `project://sources/{source}` record. Additions remain provisional until identity and provenance are verified by an authorized action.
 - Do not explore alternatives that author decisions explicitly deferred or rejected.

package/vendors/copilot/project/.github/wtfp/skills/wtfp-deliver-research/references/actions.md

@@ -52,7 +52,7 @@ Contract: [protocol/actions/create-slides.json](../../../actions/create-slides.j
 1. Require project identity and enough manuscript or verified results to support a presentation.
 2. Ask for duration, expected slide count, audience, occasion, delivery format, visual style, and desired emphasis.
 3. Derive a timed narrative: audience problem, thesis, minimum background, method, strongest evidence, limitations, implications, and closing takeaway. Allocate time and slides before writing.
-4. Use verified project claims and cite source or manuscript locations in speaker notes or a references slide. Do not introduce novel results to make the story cleaner.
+4. Use verified project claims and cite source or manuscript locations in speaker notes or a references slide. Do not introduce novel results to make the story cleaner. Refuse any claim without a ledger row, never invent speaker or venue metadata, and derive diagrams only from named source files or documents with stated paths.
 5. Prefer one communicative purpose per slide. Use concise text, readable type, high contrast, descriptive titles, accessible color, and alt text or equivalent descriptions for meaningful visuals.
 6. Use existing figures only when provenance and interpretation are known. Mark placeholders and data needs explicitly; never fabricate a chart.
 7. Generate editable slide source and a delivery manifest under `project://deliverables/slides/{artifact}`.
@@ -65,11 +65,11 @@ Completion requires an audience-appropriate editable deck with an honest render
 
 Contract: [protocol/actions/create-poster.json](../../../actions/create-poster.json)
 
-1. Require project identity and verified manuscript findings. Ask for dimensions, orientation, venue rules, audience viewing distance, title, authors, affiliations, contact details, output format, and available visuals.
+1. Require project identity and verified manuscript findings. Ask for dimensions, orientation, venue rules, audience viewing distance, title, authors, affiliations, contact details, output format, and available visuals. Never invent missing metadata; leave a visible placeholder and report it.
 2. Define a non-linear reading hierarchy: one-sentence takeaway, motivation, minimal method, principal evidence, limitations, conclusion, and contact or artifact link.
 3. Budget physical space before writing. Prioritize the title, takeaway, and strongest figure; avoid shrinking prose to preserve excess content.
-4. Use verified claims, values, citations, and figures. Record provenance and include accessible descriptions. Mark missing visuals as placeholders rather than generating false evidence.
-5. Generate editable poster source and a delivery manifest under `project://deliverables/poster/{artifact}`.
+4. Use verified claims, values, citations, and figures, recorded in the claim ledger from `protocol://templates/poster.md`; refuse any statement without a source record, manuscript passage, or named project file. Derive diagrams only from named source files or documents and state their paths. Record provenance and include accessible descriptions. Mark missing visuals as placeholders rather than generating false evidence.
+5. Generate editable, laid-out poster source (the template's HTML grid or the venue's mandated template) and a delivery manifest with the claim ledger under `project://deliverables/poster/{artifact}`.
 6. Check dimensions, orientation, margins, font sizes at final scale, column flow, contrast, image resolution, citation legibility, link or code targets, and overflow.
 7. Render only when requested and a configured host-provided local renderer exists; invoke it under the action's declared `tool.execute` effect and verify the actual artifact dimensions. Distinguish source validity from render success.
 8. Report source and rendered paths, validation results, print-service considerations, and unresolved manual steps.

package/vendors/copilot/project/.github/wtfp/skills/wtfp-plan-section/references/actions.md

@@ -46,7 +46,7 @@ Contract: [protocol/actions/plan-section.json](../../../actions/plan-section.jso
 2. Read the complete planning context before decomposing work: manifest, config, state, decisions, outline, section record, context, research, source/evidence records, relevant prior summaries, and the bounded `project://validations/*` collection.
 3. Before any specialist dispatch, filter the validation records to candidates whose `subject_uri` is exactly `project://structure/outline` and whose `action_id` is exactly `create-outline`. A candidate is current only when `executed_at >= outline.updated_at`. Because the v1 validation schema carries no outline revision or content hash, disclose that this timestamp test is a conservative freshness proxy.
 4. Require exactly one current candidate and require its `status` to be `passed`. Separately verify that the current outline and target section are consistent with all current locked and deferred author choices: honor locked choices and do not treat deferred choices as resolved. A missing, stale, ambiguous, or non-passing candidate, or a decision contradiction, blocks all specialist dispatch and every plan, section, state, or validation write. Only a recovery checkpoint may be proposed on this blocked path, and it may be written only after a complete record preview and explicit author approval.
-5. If the section is literature-heavy and research obligations remain empty, offer `research-gap`; do not manufacture citations to keep planning moving.
+5. If the section is literature-heavy, require a section-specific research artifact and resolvable source/evidence records for its planned claims before dispatch or approval. Run `research-gap` with the configured CiteNexus backend when available; if coverage remains insufficient, record a research checkpoint and stop. Search candidates alone are not verified citations. Do not manufacture citations to keep planning moving.
 6. Summarize the section goal, claims, evidence, manuscript artifact, dependencies, and open decisions at `config.gates.confirm_plan`.
 7. After the prerequisites pass, require `section-planner` in a bounded delegated pass to create one or more immutable Markdown `project://sections/{section}/plans/{plan}` artifacts. Each plan must declare:
    - stable section and plan identifiers;

package/vendors/copilot/project/.github/wtfp/skills/wtfp-research-literature/references/actions.md

@@ -14,7 +14,7 @@ Contract: [protocol/actions/research-gap.json](../../../actions/research-gap.jso
    - `standard`: run a focused, reproducible search across the most relevant categories;
    - `deep`: map foundational, recent, competing, gap-defining, and methodological work, including important disagreements and intellectual lineage.
 5. Form search questions and inclusion criteria before searching. Record databases or corpora, query strings, date, filters, and stopping rule.
-6. Search authoritative scholarly sources only after disclosing and receiving approval for the external providers and bounded query set. When using the bundled dispatcher, `citation-search` may run with `--backend=cite-nexus` and an explicit `--providers` list after this gate. Returned results stay candidates, and this action performs no bibliography write. Deduplicate candidates by persistent identifier, then normalized title.
+6. Search authoritative scholarly sources with bounded queries. Two routes need no second per-query author gate: a host connection the operator already configured and authorized for read-only public scholarly metadata search, or the bundled CiteNexus dispatcher in a host session explicitly set to full-auto for this research action when every selected provider is a free, no-key public index (`crossref`, `datacite`, `europe_pmc`, or `arxiv`). Record provider IDs, query strings, date, and result limits in the research artifact. Do not send unpublished manuscript text, private notes, or credentials as search terms. Outside those routes, first disclose the providers and bounded query set and obtain explicit author approval. The dispatcher runs only `citation-search --backend=cite-nexus` with an explicit `--providers` list; honor an operator-set offline flag or any host refusal. Returned results stay candidates, and this action performs no bibliography write. Deduplicate candidates by persistent identifier, then normalized title.
 7. Verify each retained source from its primary record or publication. Create a `project://sources/{source}` record with title, creators, year, source kind, identifiers, citation key, status, provenance, inspection depth, and verification time.
 8. Read enough of each source to distinguish its actual claim, method, population, result, and limitation. Do not cite an abstract-only impression as full-paper evidence.
 9. Create `project://evidence/{evidence}` separately for each retained claim-level interpretation, with relation, locator, limitations, confidence, and inspection depth. Synthesize by question rather than listing papers; identify consensus, disagreement, methodological differences, missing evidence, and defensible positioning.

package/vendors/copilot/project/.github/wtfp/skills/wtfp-write-section/references/actions.md

@@ -8,7 +8,7 @@ Contract: [protocol/actions/write-section.json](../../../actions/write-section.j
 
 1. Require an exact `project://sections/{section}/plans/{plan}` artifact linked from `project://sections/{section}` and verify its declared inputs, outputs, dependencies, validation, and approval state.
 2. If a corresponding summary or manuscript output exists, show the overwrite or merge impact and require explicit re-execution approval.
-3. Read the plan, `project://manifest`, `project://state`, `project://decisions`, `project://structure/outline`, section context and research, relevant source/evidence records, and enough neighboring prose to maintain continuity.
+3. Read the plan, `project://manifest`, `project://state`, `project://decisions`, `project://structure/outline`, section context and research, relevant source/evidence records, and enough neighboring prose to maintain continuity. For a literature-heavy section, require research and verified source/evidence coverage of the plan's factual claims before drafting. Route missing coverage through `research-gap` and a checkpoint; do not substitute model memory or search candidates for source records.
 4. Present the plan objective, output path, target words, evidence obligations, and checkpoints at the configured writing gate.
 5. Execute tasks in order against the exact `project://paper/{artifact}` output. For each task:
    - establish the paragraph or subsection's rhetorical job;

package/vendors/copilot/project/.github/wtfp/templates/poster.md

@@ -2,65 +2,148 @@
 
 Source structure for `project://deliverables/poster/{artifact}`. A poster is a standing argument read at two distances: the title and headline claim from three metres, the panels from one. It is not a slide deck and not a compressed paper.
 
-Copy the body below, replace every bracketed placeholder from the manuscript and its evidence records, and delete any panel the work does not support. WTF-P writes poster source only; it declares no rendering effect and runs no renderer. If the author wants a rendered PDF, hand back the exact command for their own toolchain.
+The deliverable is a laid-out page, not a text outline. Write it as one self-contained HTML file (for example `project://deliverables/poster/poster.html`) using the skeleton below, which fixes the page size, grid, hierarchy, palette, and type scale in CSS. The author opens it in any browser to see the layout and prints it to PDF at the page size. If the venue mandates a LaTeX or PowerPoint template, use that template instead and carry over the same grid, hierarchy, and type scale. WTF-P writes poster source only; it declares no rendering effect and runs no renderer. If the author wants a rendered PDF, hand back the exact command or print step for their own toolchain.
+
+Follow this scaffold literally. Replace every bracketed placeholder from the manuscript and its evidence records, and delete any panel the work does not support rather than filling it.
 
 ## Confirm before writing
 
-Dimensions and orientation, the venue's template or branding requirement, the session audience, the single claim the poster must land, and which figures already exist as artifacts.
+Dimensions and orientation, the venue's template or branding requirement, the session audience, the single claim the poster must land, which figures already exist as artifacts, and the exact author names, affiliations, contact, funding, and venue line. Ask for any of these the manifest does not record.
+
+## Evidence gate
+
+Complete this gate before writing any poster text, and repeat it on the finished file.
+
+1. Build a claim ledger: one row per claim, number, comparison, or figure the poster will carry, each naming its support as a manuscript passage, a `project://sources/{source}` record, a `project://evidence/{evidence}` record, or a named project file path.
+2. Refuse any row without support. Do not rephrase it into a softer claim; cut it. Statements about other systems, tools, or prior work (for example how another framework divides responsibilities) need a cited source record, never general knowledge.
+3. Never invent author names, affiliations, emails, funding, grant numbers, venue, or dates. When the manifest or the author does not supply one, leave a visible placeholder such as `[AFFILIATION NEEDED]` in the poster and list it under unresolved items in the report.
+4. Keep the ledger in the delivery manifest next to the poster so a reviewer can check every row.
+
+## Diagram provenance
+
+Every diagram is evidence, not decoration.
 
-## Budgets
+- Reuse an existing manuscript figure when one exists, and cite its path.
+- When the subject is software, derive architecture and flow diagrams only from named source files or documentation in the project the author pointed to. Read those files first. Every box and arrow must correspond to a module, component, call, or data path that exists in them.
+- State the source paths under each diagram, for example `Source: src/router/dispatch.ts, docs/ARCHITECTURE.md`.
+- Draw diagrams as inline SVG or Mermaid source so they stay editable. If no grounded source exists, leave a labeled placeholder box stating which files are needed; never draw an invented architecture.
 
-A readable poster carries 400 to 800 words total. Body text sits at 24pt or larger, panel headings at 36pt or larger, the title at 72pt or larger. If a panel exceeds its budget the content belongs in the paper, not the poster.
+## Layout and design
+
+| Element | Rule |
+| --- | --- |
+| Page | Confirmed size; default 48 × 36 in landscape (A0 841 × 1189 mm portrait is the common alternative) |
+| Margins and gutters | 1 in outer margin, 0.75 in gutter between columns |
+| Grid | Landscape uses three columns; portrait uses two. Results may span two columns |
+| Reading order | Title band across the full width, headline claim band beneath it, then panels top to bottom within each column, left to right |
+| Hierarchy | Title 90 to 110 pt bold, headline claim 54 to 60 pt, panel headings 40 to 48 pt, body 26 to 32 pt, captions and references 20 to 24 pt |
+| Palette | One dark ink, one light ground, one primary accent for headings and the claim band, one secondary accent for highlights in figures. Text contrast of at least 4.5:1. Use venue or institution colours only when the author supplies them |
+| Figures | The strongest result figure is the largest element after the title. Each figure carries a one-line reading and its source path |
+| Density | 400 to 800 words total. If a panel exceeds its budget, the content belongs in the paper, not the poster |
 
 | Panel | Words | Purpose |
 | --- | --- | --- |
-| Title block | 25 | Title, authors, affiliations, contact or code link |
+| Title band | 25 | Title, authors, affiliations, contact or code link |
 | Headline claim | 30 | The finding, stated as a sentence a reader can repeat |
 | Motivation | 80 | The problem and why the audience should care |
-| Approach | 120 | What was built or done, with one diagram |
+| Approach | 120 | What was built or done, with one grounded diagram |
 | Results | 150 | Two or three figures, each with a one-line reading |
 | What it means | 80 | The consequence, and the boundary of the claim |
 | References and provenance | 60 | Cited sources, funding, and artifact links |
 
 ---
 
-# [Title: the claim, not the topic]
-
-**[Author names]** · [Affiliations] · [contact or repository link]
-
-## [Headline claim in one sentence]
-
-## Why this matters
-
-- [Problem, in the audience's terms]
-- [What breaks today, with the number that shows it]
-
-## What we did
-
-- [Approach in one sentence]
-- [The one design decision a reader would ask about]
-
-![Approach diagram]([project://paper/{artifact} figure reference])
-
-## What we found
-
-![Primary result]([figure reference])
-
-- [One-line reading of the primary figure, with the measured value]
-- [Second result, with its condition]
-- [What the result does not show]
-
-## What it means
-
-- [Consequence for the audience]
-- [Stated limitation]
-
-## References
-
-[Only sources with a `project://sources/{source}` record. Include the funding acknowledgement and artifact or data links the venue requires.]
+```html
+<!doctype html>
+<html lang="en">
+<head>
+<meta charset="utf-8">
+<title>[Poster title]</title>
+<style>
+  @page { size: 48in 36in; margin: 0; }
+  :root {
+    --ink: #1b1f24; --ground: #fbfaf7; --accent: #1f4e79; --highlight: #c8553d; --muted: #5a6270;
+    --margin: 1in; --gutter: 0.75in;
+  }
+  * { box-sizing: border-box; }
+  html, body { margin: 0; background: var(--ground); color: var(--ink); }
+  body { width: 48in; height: 36in; padding: var(--margin); font: 28pt/1.35 "Source Sans 3", "Helvetica Neue", Arial, sans-serif;
+         display: grid; grid-template-rows: auto auto 1fr auto; gap: var(--gutter); }
+  header h1 { font-size: 100pt; line-height: 1.05; margin: 0 0 0.2in; }
+  header .byline { font-size: 34pt; color: var(--muted); }
+  .claim { background: var(--accent); color: var(--ground); font-size: 56pt; font-weight: 600; padding: 0.4in 0.6in; }
+  main { display: grid; grid-template-columns: repeat(3, 1fr); gap: var(--gutter); align-items: start; }
+  section h2 { font-size: 44pt; color: var(--accent); border-bottom: 4pt solid var(--accent); margin: 0 0 0.25in; }
+  section + section { margin-top: var(--gutter); }
+  .span-2 { grid-column: span 2; }
+  figure { margin: 0.2in 0; }
+  figure img, figure svg { width: 100%; height: auto; }
+  figcaption, .source { font-size: 22pt; color: var(--muted); }
+  footer { font-size: 22pt; color: var(--muted); display: flex; justify-content: space-between; gap: var(--gutter); }
+  .placeholder { outline: 4pt dashed var(--highlight); padding: 0.3in; color: var(--highlight); }
+</style>
+</head>
+<body>
+  <header>
+    <h1>[Title: the claim, not the topic]</h1>
+    <div class="byline">[Author names from manifest or AUTHORS NEEDED] · [Affiliations or AFFILIATION NEEDED] · [contact or repository link]</div>
+  </header>
+
+  <div class="claim">[Headline claim in one sentence, backed by a ledger row]</div>
+
+  <main>
+    <div class="column">
+      <section>
+        <h2>Why this matters</h2>
+        <ul>
+          <li>[Problem, in the audience's terms]</li>
+          <li>[What breaks today, with the number that shows it and its source]</li>
+        </ul>
+      </section>
+      <section>
+        <h2>What we did</h2>
+        <p>[Approach in one sentence]</p>
+        <figure>
+          [Inline SVG or Mermaid diagram derived from the named files, or a .placeholder box naming the files needed]
+          <figcaption>[What the diagram shows] <span class="source">Source: [paths]</span></figcaption>
+        </figure>
+      </section>
+    </div>
+
+    <div class="column span-2">
+      <section>
+        <h2>What we found</h2>
+        <figure>
+          <img src="[figure path inside the project]" alt="[accessible description]">
+          <figcaption>[One-line reading of the primary figure, with the measured value] <span class="source">Source: [path or record]</span></figcaption>
+        </figure>
+        <ul>
+          <li>[Second result, with its condition]</li>
+          <li>[What the result does not show]</li>
+        </ul>
+      </section>
+      <section>
+        <h2>What it means</h2>
+        <ul>
+          <li>[Consequence for the audience]</li>
+          <li>[Stated limitation]</li>
+        </ul>
+      </section>
+    </div>
+  </main>
+
+  <footer>
+    <div>[References: only sources with a project://sources/{source} record]</div>
+    <div>[Funding acknowledgement or FUNDING NEEDED] · [artifact or data links]</div>
+  </footer>
+</body>
+</html>
+```
+
+For portrait pages, change `@page` and the `body` size to the confirmed dimensions, set `main` to `repeat(2, 1fr)`, and drop the `span-2` class.
 
 ---
 
 ## Attribution rules
 
-Every number, figure, and claim on the poster must trace to a manuscript passage or an evidence record. Carry the source attribution onto the poster itself for any figure reused from another work. Do not introduce a claim, a number, or a citation that appears nowhere in the project's records.
+Every number, figure, and claim on the poster must trace to a row in the claim ledger. Carry the source attribution onto the poster itself for any figure reused from another work. Do not introduce a claim, a number, a citation, or a piece of author metadata that appears nowhere in the project's records or the author's answers.

package/vendors/copilot/project/.github/wtfp/templates/slides.md

@@ -6,7 +6,11 @@ Copy the body below, replace every bracketed placeholder from the manuscript and
 
 ## Confirm before writing
 
-Talk length, audience, venue format, whether questions are inside or outside the slot, and the single thing the audience should remember.
+Talk length, audience, venue format, whether questions are inside or outside the slot, the single thing the audience should remember, and the exact speaker name, affiliation, and venue line. Ask for any of these the manifest does not record.
+
+## Evidence gate
+
+Before writing, build a claim ledger with one row per claim, number, comparison, or figure, each naming its support as a manuscript passage, a `project://sources/{source}` record, a `project://evidence/{evidence}` record, or a named project file path. Cut any row without support; statements about other systems or prior work need a cited source record, never general knowledge. Never invent speaker names, affiliations, emails, funding, venue, or dates; leave a visible placeholder such as `[AFFILIATION NEEDED]` and report it as unresolved. When the subject is software, derive every diagram from named source files or documentation, state those paths on the slide, and leave a labeled placeholder rather than an invented architecture.
 
 ## Budgets
 
@@ -25,7 +29,7 @@ Backup slides sit after the closing slide and answer the questions the work invi
 
 ## [Title slide]
 
-[Title] · [Speaker] · [Affiliation] · [Venue and date]
+[Title] · [Speaker or SPEAKER NEEDED] · [Affiliation or AFFILIATION NEEDED] · [Venue and date or VENUE NEEDED]
 
 ## [The problem, in one image or one sentence]
 
@@ -42,7 +46,7 @@ Backup slides sit after the closing slide and answer the questions the work invi
 
 ## [Approach]
 
-[One diagram. Speaker note: walk it left to right; do not read the labels aloud.]
+[One diagram derived from named source files or documents. Source: [paths]. Speaker note: walk it left to right; do not read the labels aloud.]
 
 ## [Key design decision]
 
@@ -80,4 +84,4 @@ Backup slides sit after the closing slide and answer the questions the work invi
 
 ## Attribution rules
 
-Every number and figure must trace to a manuscript passage or an evidence record. Reused figures carry their original attribution on the slide. Speaker notes are part of the deliverable and follow the same evidence rule as the slides: do not put a claim in a note that the records do not support.
+Every number, figure, and claim must trace to a row in the claim ledger. Reused figures carry their original attribution on the slide. Speaker notes are part of the deliverable and follow the same evidence rule as the slides: do not put a claim in a note that the records do not support.

package/vendors/copilot/project/.github/wtfp/workflows/create-poster.md

@@ -21,10 +21,10 @@ Manuscript prose and supporting context, research, plan, review, summary, handof
 
 ## Procedure
 
-1. Confirm audience, dimensions, format, and emphasis, following the confirmation list in `protocol://templates/poster.md`.
-1a. Start from the panel structure and word budgets in `protocol://templates/poster.md`. Delete any panel the manuscript does not support rather than filling it.
-2. Select only claims supported by manuscript and evidence, then design a legible poster with source attribution.
-3. Write the poster source and its assets under the declared deliverable URI without changing project records except through a separately declared action. This action produces poster source, not a rendered image or PDF: WTF-P declares no rendering effect and runs no renderer. If the author asks for a rendered artifact, return a labeled handoff naming the exact command they can run in their own toolchain.
+1. Confirm audience, dimensions, format, emphasis, and the exact author, affiliation, contact, funding, and venue metadata, following the confirmation list in `protocol://templates/poster.md`. Never invent missing metadata; leave the visible placeholder the template names.
+1a. Start from the layout, panel structure, and word budgets in `protocol://templates/poster.md`. Delete any panel the manuscript does not support rather than filling it.
+2. Run the evidence gate in `protocol://templates/poster.md`: build the claim ledger and refuse every statement, comparison, or figure without a cited source record, manuscript passage, or named project file. Derive each diagram from named source files or documents and state their paths beneath it.
+3. Write the poster as laid-out source (the template's HTML skeleton, or the venue's mandated template carrying the same grid and type scale) plus its assets and claim ledger under the declared deliverable URI, without changing project records except through a separately declared action. This action produces poster source, not a rendered image or PDF: WTF-P declares no rendering effect and runs no renderer. If the author asks for a rendered artifact, return a labeled handoff naming the exact command they can run in their own toolchain.
 
 ## Safety and completion
 

package/vendors/copilot/project/.github/wtfp/workflows/create-slides.md

@@ -21,9 +21,9 @@ Manuscript prose and supporting context, research, plan, review, summary, handof
 
 ## Procedure
 
-1. Confirm audience, duration, format, and speaking goal, following the confirmation list in `protocol://templates/slides.md`.
+1. Confirm audience, duration, format, speaking goal, and the exact speaker, affiliation, and venue metadata, following the confirmation list in `protocol://templates/slides.md`. Never invent missing metadata; leave a visible placeholder.
 1a. Derive the slide count from the confirmed duration using the budget table in `protocol://templates/slides.md`, not from the manuscript's section count.
-2. Build a narrative arc from supported manuscript claims and include citations or attribution where needed.
+2. Build a narrative arc from supported manuscript claims only, running the evidence gate in `protocol://templates/slides.md`: refuse every statement, comparison, or figure without a cited source record, manuscript passage, or named project file, and derive each diagram from named source files or documents with their paths stated on the slide.
 3. Write slide source and assets under the declared deliverable URI; preview before replacing an existing deliverable. This action produces slide source, not a rendered deck: WTF-P declares no rendering effect and runs no renderer. If the author asks for a rendered artifact, return a labeled handoff naming the exact command they can run in their own toolchain.
 
 ## Safety and completion

package/vendors/copilot/project/.github/wtfp/workflows/plan-section.md

@@ -24,8 +24,9 @@ Manuscript prose and supporting context, research, plan, review, summary, handof
 1. Resolve one section record, load its linked context, research, evidence, decisions, and outline constraints, and enumerate the bounded `project://validations/*` collection before any specialist dispatch.
 2. Filter those records to candidates whose `subject_uri` is exactly `project://structure/outline` and whose `action_id` is exactly `create-outline`. A candidate is current only when `executed_at >= outline.updated_at`. Because the v1 validation schema carries no outline revision or content hash, disclose that this timestamp test is a conservative freshness proxy.
 3. Require exactly one current candidate and require its `status` to be `passed`. Separately verify that the current outline and target section are consistent with all current locked and deferred author choices: honor locked choices and do not treat deferred choices as resolved. A missing, stale, ambiguous, or non-passing candidate, or a decision contradiction, blocks all specialist dispatch and every plan, section, state, or validation write. Only a recovery checkpoint may be proposed on this blocked path, and it may be written only after a complete record preview and explicit author approval.
-4. Only after those prerequisites pass, delegate a bounded plan to `section-planner`, then require a fresh `plan-checker` pass over claim coverage, dependencies, file scope, citations, and decision fidelity.
-5. At confirm_plan, preview the plan and validation; on approval link the plan, update section status to planned, and reconcile state. Create a checkpoint for unresolved judgment instead of bypassing the required checker.
+4. For a literature-heavy section, first require a section-specific research artifact plus resolvable source/evidence records that cover the planned claims. If they are absent or insufficient, run `research-gap` with the configured CiteNexus backend when available, verify candidate metadata against the returned records, and stop planning with an explicit research checkpoint if evidence remains insufficient. Never invent citations or treat search candidates as verified sources.
+5. Only after those prerequisites pass, delegate a bounded plan to `section-planner`, then require a fresh `plan-checker` pass over claim coverage, dependencies, file scope, citations, and decision fidelity. Dispatch the exact WTF-P specialist roles; generic coder and verifier roles do not satisfy this workflow.
+6. At confirm_plan, preview the plan and validation; on approval link the plan, update section status to planned, and reconcile state. Create a checkpoint for unresolved judgment instead of bypassing the required checker.
 
 ## Safety and completion
 

package/vendors/copilot/project/.github/wtfp/workflows/research-gap.md

@@ -22,7 +22,7 @@ Manuscript prose and supporting context, research, plan, review, summary, handof
 ## Procedure
 
 1. Resolve the research question and section scope against locked/deferred decisions; agree on depth and source constraints.
-2. Search declared scholarly services only after the gate names the providers and bounded query set. When using the bundled dispatcher, `citation-search` may run with `--backend=cite-nexus` and an explicit `--providers` list after this gate. Returned results stay candidates, and this action performs no bibliography write. Verify source identity and inspection depth, and separate source records from claim-level evidence.
+2. Prefer an operator-configured, trusted read-only CiteNexus MCP connection for bounded public metadata searches when the host has already authorized it. In an explicitly selected full-auto host session for this research action, the bundled CiteNexus dispatcher may also search the free no-key public indexes `crossref`, `datacite`, `europe_pmc`, and `arxiv` without a second per-query author gate; use only selected relevant indexes with an explicit `--providers` list. Record provider IDs, queries, date, and result limits; never send unpublished manuscript text or private notes as search terms. For any other route, first obtain explicit author approval naming the providers and bounded query set. Results remain candidates and this action performs no bibliography write. Verify source identity and inspection depth, and separate source records from claim-level evidence.
 3. Synthesize supported, conflicting, and missing evidence into a Markdown research artifact; link new records and disclose limitations.
 
 ## Bundled tool execution
@@ -33,7 +33,7 @@ The declared `tool.execute` effect authorises exactly one command, run from the
 node protocol://tools/wtfp-tool.js [--offline] <command> [arguments]
 ```
 
-Run it with `list` first to read the declared commands, their arguments, their bounds, and the effects each one applies; `protocol://tools/README.md` carries the same table. A command whose effects include `network.*` performs outbound requests. Until network use has been approved for this run, pass `--offline` (or set `WTFP_TOOL_OFFLINE=1`), which makes the dispatcher refuse those commands instead of relying on prose restraint. Never execute another module in this package, never pass a logical `project://` or `wtfp://` URI as a shell argument, and treat every returned record as candidate evidence until it is verified and written to a source or evidence record.
+Run it with `list` first to read the declared commands, their arguments, their bounds, and the effects each one applies; `protocol://tools/README.md` carries the same table. A command whose effects include `network.*` performs outbound requests. Pass `--offline` (or set `WTFP_TOOL_OFFLINE=1`) until the provider/query gate is approved, except for this action's explicit full-auto public-index route. On that route omit `--offline` only for `citation-search --backend=cite-nexus` with bounded queries and `--providers` drawn from `crossref,datacite,europe_pmc,arxiv`; never override an operator-set offline flag or a host refusal. Never execute another module in this package, never pass a logical `project://` or `wtfp://` URI as a shell argument, and treat every returned record as candidate evidence until it is verified and written to a source or evidence record.
 
 ## Safety and completion
 

package/vendors/copilot/project/.github/wtfp/workflows/write-section.md

@@ -22,7 +22,7 @@ Manuscript prose and supporting context, research, plan, review, summary, handof
 ## Procedure
 
 1. Require one approved plan and resolve all linked context, research, source/evidence records, decisions, prior summary, existing target, and necessary neighboring prose before choosing create or update.
-2. Draft only the declared manuscript artifact; cite only resolvable sources, preserve author constraints, and stop at blocking decisions.
+2. Before drafting a literature-heavy section, verify that its linked research artifact and source/evidence records cover the plan's factual claims. If coverage is missing, use the declared research workflow and pause at a checkpoint until verified records exist. Draft only the declared manuscript artifact; cite only resolvable sources, preserve author constraints, and stop at blocking decisions. A plausible bibliography entry, search candidate, or model memory is not a verified citation.
 3. Read the persisted manuscript text back and calculate its actual body word count with one deterministic method; never copy a worker self-report, plan target, or summary count into project records. Validate the persisted draft against its plan and word budget.
 4. Create or update the required Markdown summary with that measured count, then read back both manuscript and summary. Missing, empty, or inconsistent output is a failed completion condition, not permission to link a path that does not exist.
 5. Persist the validation, synchronize the manuscript URI in `manifest.artifacts.manuscripts`, and reconcile section/state records only after manuscript, summary, and validation readback succeeds. If blocked, create the declared checkpoint and stop; do not commit or merge automatically.