memento-mori-jester 0.1.99 → 0.1.101

package/CHANGELOG.md

@@ -4,6 +4,18 @@ All notable changes to Memento Mori Jester are tracked here.
 
 ## Unreleased
 
+## 0.1.101
+
+- Added a checked public-safe support examples index so maintainers can choose between the lifecycle map, blank worksheet, and filled synthetic example.
+- Added `support-examples-index.json` plus `npm run support:check` and production-readiness coverage so use-cases, public-safe markers, stage path, and required checks stay aligned.
+- Updated README, maintainer triage docs, support examples, production-readiness docs, roadmap, and release notes for the support examples manifest.
+
+## 0.1.100
+
+- Added a checked synthetic filled support lifecycle worksheet example showing one `docs-example` report through report, triage, response, closeout, prioritization, backlog record, and backlog review.
+- Added `support-lifecycle-filled-example.json` plus `npm run support:check` and production-readiness coverage so the completed example stays public-safe, deterministic, and aligned with the blank worksheet.
+- Updated README, maintainer triage docs, support examples, production-readiness docs, roadmap, and release notes for the filled worksheet example.
+
 ## 0.1.99
 
 - Added a checked public-safe support lifecycle worksheet for reviewing one report across report, triage, response, closeout, prioritization, backlog record, and backlog review stages.

package/README.md

@@ -76,7 +76,7 @@ For trust-building output examples, see [examples/reports](examples/reports). `n
 
 If one of those reports is confusing or stale, use the public-safe [report gallery feedback template](examples/reports/feedback-template.md). It asks for version, nearest gallery example, sanitized command/output summaries, and redacted diagnostics without private repo code or secrets.
 
-Maintainers can use the checked [support lifecycle map](examples/support/support-lifecycle-map.md), [support lifecycle worksheet](examples/support/support-lifecycle-worksheet.md), [support lifecycle overview](examples/support/support-lifecycle.md), [outcome prioritization guide](examples/support/outcome-prioritization.md), [support backlog records](examples/support/backlog-records.md), [support backlog review](examples/support/backlog-review.md), [support triage playbook](examples/support), [response snippets](examples/support/response-snippets.md), and [support closeout checklist](examples/support/closeout-checklist.md) to turn sanitized reports into a docs example, fixture backlog item, or rule-review candidate without changing behavior first.
+Maintainers can use the checked [support examples index](examples/support/support-examples-index.md), [support lifecycle map](examples/support/support-lifecycle-map.md), [support lifecycle worksheet](examples/support/support-lifecycle-worksheet.md), synthetic [filled worksheet example](examples/support/support-lifecycle-filled-example.md), [support lifecycle overview](examples/support/support-lifecycle.md), [outcome prioritization guide](examples/support/outcome-prioritization.md), [support backlog records](examples/support/backlog-records.md), [support backlog review](examples/support/backlog-review.md), [support triage playbook](examples/support), [response snippets](examples/support/response-snippets.md), and [support closeout checklist](examples/support/closeout-checklist.md) to turn sanitized reports into a docs example, fixture backlog item, or rule-review candidate without changing behavior first.
 
 Expected vibe:
 
@@ -450,8 +450,10 @@ More setup examples:
 - [Consumer Quickstart Smoke](examples/consumer-quickstart)
 - [Real-World Report Gallery](examples/reports)
 - [Report Gallery Feedback Template](examples/reports/feedback-template.md)
+- [Support Examples Index](examples/support/support-examples-index.md)
 - [Support Lifecycle Map](examples/support/support-lifecycle-map.md)
 - [Support Lifecycle Worksheet](examples/support/support-lifecycle-worksheet.md)
+- [Filled Support Lifecycle Worksheet Example](examples/support/support-lifecycle-filled-example.md)
 - [Support Lifecycle Overview](examples/support/support-lifecycle.md)
 - [Support Outcome Prioritization](examples/support/outcome-prioritization.md)
 - [Support Backlog Records](examples/support/backlog-records.md)
@@ -480,8 +482,10 @@ Framework CI examples:
 - [Consumer Quickstart Smoke](examples/consumer-quickstart)
 - [Real-World Report Gallery](examples/reports)
 - [Report Gallery Feedback Template](examples/reports/feedback-template.md)
+- [Support Examples Index](examples/support/support-examples-index.md)
 - [Support Lifecycle Map](examples/support/support-lifecycle-map.md)
 - [Support Lifecycle Worksheet](examples/support/support-lifecycle-worksheet.md)
+- [Filled Support Lifecycle Worksheet Example](examples/support/support-lifecycle-filled-example.md)
 - [Support Lifecycle Overview](examples/support/support-lifecycle.md)
 - [Support Outcome Prioritization](examples/support/outcome-prioritization.md)
 - [Support Backlog Records](examples/support/backlog-records.md)
@@ -545,7 +549,7 @@ Maintainers can use [docs/MAINTAINER_TRIAGE.md](docs/MAINTAINER_TRIAGE.md) to tu
 Run `npm run fixtures:check` before merging fixture changes; it catches duplicate IDs, missing rule metadata, weak descriptions, unsafe-looking content, and duplicate content.
 Run `npm run fixtures:report` to see fixture coverage by rule, rule family, preset slice, kind, verdict, quiet-pass boundaries, feasible pass-case gaps, and curation-next guidance before choosing the next fixture. Use `npm run fixtures:report -- --markdown` when you want a paste-ready summary for release notes or GitHub issues.
 Run `npm run reports:check` after editing [examples/reports](examples/reports); it verifies the public report gallery against an installed package in a temporary consumer project.
-Run `npm run support:check` after editing issue templates, support docs, the report gallery feedback path, the [support lifecycle map](examples/support/support-lifecycle-map.md), [support lifecycle worksheet](examples/support/support-lifecycle-worksheet.md), [support lifecycle overview](examples/support/support-lifecycle.md), [outcome prioritization guide](examples/support/outcome-prioritization.md), [support backlog records](examples/support/backlog-records.md), [support backlog review](examples/support/backlog-review.md), [support triage playbook](examples/support), [response snippets](examples/support/response-snippets.md), or [support closeout checklist](examples/support/closeout-checklist.md); it verifies the public templates ask for useful redacted context without inviting secrets or private code.
+Run `npm run support:check` after editing issue templates, support docs, the report gallery feedback path, the [support examples index](examples/support/support-examples-index.md), [support lifecycle map](examples/support/support-lifecycle-map.md), [support lifecycle worksheet](examples/support/support-lifecycle-worksheet.md), [filled worksheet example](examples/support/support-lifecycle-filled-example.md), [support lifecycle overview](examples/support/support-lifecycle.md), [outcome prioritization guide](examples/support/outcome-prioritization.md), [support backlog records](examples/support/backlog-records.md), [support backlog review](examples/support/backlog-review.md), [support triage playbook](examples/support), [response snippets](examples/support/response-snippets.md), or [support closeout checklist](examples/support/closeout-checklist.md); it verifies the public templates ask for useful redacted context without inviting secrets or private code.
 Run `npm run promo:card` to regenerate the repo-local social preview card after changing its copy or design.
 Run `npm run promo:check` after editing promo assets; it checks the current demo video, stills, docs, and fixture evidence numbers stay in sync.
 Run `npm run site:check` after editing the repo-local landing page; it verifies the start command, demo links, social card, repo, release, and npm links.

package/ROADMAP.md

@@ -6,6 +6,8 @@ Memento Mori Jester is usable today as a CLI, MCP server, GitHub Action, and git
 
 ## Recently Shipped
 
+- Checked support examples index in v0.1.101, telling maintainers when to use the lifecycle map, blank worksheet, and filled synthetic example.
+- Checked filled support lifecycle worksheet example in v0.1.100, showing a synthetic `docs-example` report through report, triage, response, closeout, prioritization, backlog record, and backlog review.
 - Checked support lifecycle worksheet in v0.1.99, turning the compact map into an active-review checklist with stage checks, record fields, and stop conditions.
 - Compact checked support lifecycle map in v0.1.98, giving maintainers a quick scan of report, triage, response, closeout, prioritization, backlog record, and backlog review.
 - Full checked support lifecycle overview in v0.1.97, extending the index from report, triage, response, and closeout through prioritization, backlog records, and backlog review.
@@ -89,9 +91,10 @@ Memento Mori Jester is usable today as a CLI, MCP server, GitHub Action, and git
 ## Product Ideas
 
 - Collect real-world reports and fold the strongest redacted cases into more framework tuning cookbook recipes.
+- Add a tiny generated support artifact status summary if the checked support examples index grows beyond the current map, worksheet, and filled example.
 - Add a small checked maintainer dashboard or report that summarizes open support backlog review states from public-safe JSON.
 - Add a generated support lifecycle status summary if backlog review records grow beyond the compact map.
-- Add a checked anonymized example of a completed lifecycle worksheet once support reports accumulate.
+- Add synthetic filled worksheet examples for `fixture-backlog` and `rule-review-candidate` if maintainers need more public-safe training cases.
 - Use support backlog record counts to choose the next docs, fixture, report-gallery, or rule-guidance batch.
 - Use repeated prioritized support outcomes to choose the next redacted fixture, report-gallery update, or rule-guidance review.
 - Add a hosted-page option or GitHub Pages instructions once the static page has settled.

package/docs/MAINTAINER_TRIAGE.md

@@ -21,7 +21,7 @@ For users who just need to understand what a healthy report looks like, point th
 
 For users who say a gallery report is confusing, stale, or hard to compare with their local output, point them at [examples/reports/feedback-template.md](../examples/reports/feedback-template.md) or the GitHub [report gallery feedback issue template](../.github/ISSUE_TEMPLATE/report_gallery_feedback.yml). It asks for the nearest checked example, sanitized command and output summaries, version, and redacted diagnostics without asking for private code.
 
-When a report has enough public-safe detail to triage, start with the checked [support lifecycle map](../examples/support/support-lifecycle-map.md) for a quick scan of the path, then use the checked [support lifecycle worksheet](../examples/support/support-lifecycle-worksheet.md) to record each stage during active review. Use the full [support lifecycle overview](../examples/support/support-lifecycle.md) to see the whole path from report to backlog review. Then compare it with the checked [support triage playbook](../examples/support). The playbook walks sanitized report-gallery and false-positive reports through first response, classification, and a follow-up outcome. Use [response-snippets.md](../examples/support/response-snippets.md) to reply consistently after choosing the outcome, then use [closeout-checklist.md](../examples/support/closeout-checklist.md) to record whether the docs clarification shipped or queued, fixture backlog was created, or rule-review candidate was opened. Use [outcome-prioritization.md](../examples/support/outcome-prioritization.md) after closeout to decide whether the follow-up work is low-priority docs, medium-priority fixture backlog, or high-priority rule review. Use [backlog-records.md](../examples/support/backlog-records.md) when that prioritized follow-up needs a public-safe backlog artifact, then use [backlog-review.md](../examples/support/backlog-review.md) to revisit whether that artifact remains active or closes with no action.
+When a report has enough public-safe detail to triage, start with the checked [support examples index](../examples/support/support-examples-index.md) to choose the right support artifact. Use the checked [support lifecycle map](../examples/support/support-lifecycle-map.md) for a quick scan of the path, then use the checked [support lifecycle worksheet](../examples/support/support-lifecycle-worksheet.md) to record each stage during active review. Use the synthetic [filled lifecycle worksheet example](../examples/support/support-lifecycle-filled-example.md) when you need to compare a real public-safe report against one completed `docs-example` path. Use the full [support lifecycle overview](../examples/support/support-lifecycle.md) to see the whole path from report to backlog review. Then compare it with the checked [support triage playbook](../examples/support). The playbook walks sanitized report-gallery and false-positive reports through first response, classification, and a follow-up outcome. Use [response-snippets.md](../examples/support/response-snippets.md) to reply consistently after choosing the outcome, then use [closeout-checklist.md](../examples/support/closeout-checklist.md) to record whether the docs clarification shipped or queued, fixture backlog was created, or rule-review candidate was opened. Use [outcome-prioritization.md](../examples/support/outcome-prioritization.md) after closeout to decide whether the follow-up work is low-priority docs, medium-priority fixture backlog, or high-priority rule review. Use [backlog-records.md](../examples/support/backlog-records.md) when that prioritized follow-up needs a public-safe backlog artifact, then use [backlog-review.md](../examples/support/backlog-review.md) to revisit whether that artifact remains active or closes with no action.
 
 Do not ask users to paste secrets, private code, customer data, live credentials, complete CI logs, or unredacted SARIF. If the report involves credential exposure, command execution, unexpected network access, private code disclosure, package publishing, or MCP data exposure, route it through [SECURITY.md](../SECURITY.md).
 

package/docs/PRODUCTION_READINESS.md

@@ -47,7 +47,7 @@ This checklist defines what "production grade" means for Memento Mori Jester rig
 - `README.md` leads with a no-write first run, project bootstrap, agent setup, and optional hooks/CI.
 - `docs/GETTING_STARTED.md`, `docs/CLI.md`, `docs/RELEASE.md`, and `docs/TRUSTED_PUBLISHING.md` cover the core adoption and release paths.
 - `examples/reports` provides checked, public-safe report examples for fresh install diagnostics, summary output, blocked command reviews, and report-gallery feedback.
-- `examples/support` provides a compact checked support lifecycle map, an active-review worksheet, and a full support lifecycle overview covering report, triage, response, closeout, prioritization, backlog record, and backlog review, plus the supporting outcome prioritization guide, backlog records, backlog review checklist, maintainer triage playbook, response snippets, and closeout checklist.
+- `examples/support` provides a checked support examples index, compact support lifecycle map, active-review worksheet, synthetic filled worksheet example, and full support lifecycle overview covering report, triage, response, closeout, prioritization, backlog record, and backlog review, plus the supporting outcome prioritization guide, backlog records, backlog review checklist, maintainer triage playbook, response snippets, and closeout checklist.
 - `site/index.html` gives maintainers a static one-page share surface that reuses the demo, social card, start command, and public links.
 - Every public release has matching `CHANGELOG.md` notes and `docs/RELEASE_NOTES_vX.Y.Z.md`.
 
@@ -60,14 +60,14 @@ This checklist defines what "production grade" means for Memento Mori Jester rig
 - GitHub issue templates collect bug reports, false-positive reports, report-gallery feedback, and feature requests with the diagnostic context maintainers need.
 - `SECURITY.md` routes vulnerability reports away from public issues and asks for redacted diagnostics.
 - `docs/MAINTAINER_TRIAGE.md` explains how to turn useful false-positive reports into fixture coverage before changing rule logic.
-- `examples/support` shows maintainers how to scan the support lifecycle map, use the support lifecycle worksheet during active review, audit the full lifecycle overview, classify sanitized reports as a docs example, fixture backlog item, or rule-review candidate before changing behavior, then reply with public-safe response snippets, record the closeout, prioritize follow-up work, create a public-safe backlog record, and review aging records for keep-or-close decisions.
+- `examples/support` shows maintainers how to choose the right support artifact from the examples index, scan the support lifecycle map, use the support lifecycle worksheet during active review, compare against a synthetic filled worksheet example, audit the full lifecycle overview, classify sanitized reports as a docs example, fixture backlog item, or rule-review candidate before changing behavior, then reply with public-safe response snippets, record the closeout, prioritize follow-up work, create a public-safe backlog record, and review aging records for keep-or-close decisions.
 - `npm run fixtures:check` validates fixture IDs, metadata, unsafe-looking content, duplicate content, and explicit expected/absent rule intent.
 - `npm run fixtures:report` shows fixture coverage by rule, rule family, preset slice, kind, verdict, quiet-pass rule boundaries, and feasible pass-case gaps so maintainers can pick the next fixture target; `npm run fixtures:report -- --markdown` produces a paste-ready maintainer snapshot.
 - `npm run framework:tuning:check` keeps the framework tuning guide, cookbook JSON, cookbook README, and fixture IDs aligned.
 - `npm run framework:tuning:doctor` runs the cookbook tune commands through the built CLI with temporary preset configs, so package consumers do not inherit stale recipes.
 - `npm run consumer:quickstart:check` installs the package into a temporary minimal project and runs `doctor`, `summary`, and packaged framework tuning checks from that consumer side.
 - `npm run reports:check` installs the package into a temporary minimal project and runs the report gallery's `doctor`, `summary`, and blocked-command examples through that consumer side.
-- `npm run support:check` verifies issue templates, support docs, the report gallery feedback template, the support lifecycle map, support lifecycle worksheet, support lifecycle overview, outcome prioritization guide, backlog records, backlog review checklist, maintainer triage playbook, response snippets, and closeout checklist stay public-safe and ask for useful redacted context.
+- `npm run support:check` verifies issue templates, support docs, the report gallery feedback template, support examples index, support lifecycle map, support lifecycle worksheet, filled worksheet example, support lifecycle overview, outcome prioritization guide, backlog records, backlog review checklist, maintainer triage playbook, response snippets, and closeout checklist stay public-safe and ask for useful redacted context.
 - `npm run promo:card` regenerates the deterministic social preview card, and `npm run promo:check` verifies current repo-local promo assets against the current fixture evidence before maintainers post or refresh the demo.
 - `npm run site:check` verifies the static landing page before maintainers post or host it.
 - npm publish has a manual workflow fallback, but the normal release path is tag-driven trusted publishing.

package/docs/RELEASE_NOTES_v0.1.100.md

@@ -0,0 +1,45 @@
+# Memento Mori Jester v0.1.100
+
+## Summary
+
+This release adds a checked synthetic filled support lifecycle worksheet example so maintainers can see one public-safe `docs-example` report move through the whole support chain.
+
+## Changes
+
+- Added `examples/support/support-lifecycle-filled-example.md` with a completed synthetic support case for:
+  `report -> triage -> response -> closeout -> prioritization -> backlog-record -> backlog-review`.
+- Added `examples/support/support-lifecycle-filled-example.json` as the deterministic source for the filled example fields, stage checks, privacy review notes, required checks, and synthetic guardrail.
+- Extended `npm run support:check` and `npm run production:check` so the filled example stays aligned with the support lifecycle worksheet, map, and overview.
+- Updated README, maintainer triage docs, support examples, production-readiness docs, roadmap, and changelog.
+
+## Public Interface Changes
+
+- No CLI, MCP, config schema, rule, scoring, GitHub Action, or release automation changes.
+- New package docs/examples only:
+  - `examples/support/support-lifecycle-filled-example.md`
+  - `examples/support/support-lifecycle-filled-example.json`
+
+## Release Validation
+
+```powershell
+npm.cmd test
+npm.cmd run demo:svg:check
+npm.cmd run promo:card:check
+npm.cmd run promo:check
+npm.cmd run support:check
+npm.cmd run production:check
+npm.cmd run pack:dry
+git diff --check
+node .\dist\cli.js doctor
+node .\dist\cli.js summary --kind command "git reset --hard"
+git diff | node .\dist\cli.js diff --fail-on block --subject "v0.1.100 filled support lifecycle worksheet"
+```
+
+## Post-Publish Smoke
+
+```powershell
+npm.cmd view memento-mori-jester version --silent
+npx.cmd -y memento-mori-jester@latest doctor
+npx.cmd -y memento-mori-jester@latest summary --kind command "git reset --hard"
+npm.cmd run support:check
+```

package/docs/RELEASE_NOTES_v0.1.101.md

@@ -0,0 +1,47 @@
+# Memento Mori Jester v0.1.101
+
+## Summary
+
+This release adds a checked public-safe support examples index so maintainers can quickly choose between the lifecycle map, blank worksheet, and filled synthetic example.
+
+## Changes
+
+- Added `examples/support/support-examples-index.md` with:
+  - artifact use-cases for the lifecycle map, blank worksheet, and filled synthetic example,
+  - required public-safe markers for each artifact,
+  - a quick maintainer path for report, triage, response, closeout, prioritization, backlog record, and backlog review.
+- Added `examples/support/support-examples-index.json` as the deterministic manifest for artifact links, use-cases, markers, stage records, privacy guardrails, and required checks.
+- Extended `npm run support:check` and `npm run production:check` so the index stays aligned with the support lifecycle artifacts.
+- Updated README, maintainer triage docs, support examples, production-readiness docs, roadmap, and changelog.
+
+## Public Interface Changes
+
+- No CLI, MCP, config schema, rule, scoring, GitHub Action, or release automation changes.
+- New package docs/examples only:
+  - `examples/support/support-examples-index.md`
+  - `examples/support/support-examples-index.json`
+
+## Release Validation
+
+```powershell
+npm.cmd test
+npm.cmd run demo:svg:check
+npm.cmd run promo:card:check
+npm.cmd run promo:check
+npm.cmd run support:check
+npm.cmd run production:check
+npm.cmd run pack:dry
+git diff --check
+node .\dist\cli.js doctor
+node .\dist\cli.js summary --kind command "git reset --hard"
+git diff | node .\dist\cli.js diff --fail-on block --subject "v0.1.101 support examples index"
+```
+
+## Post-Publish Smoke
+
+```powershell
+npm.cmd view memento-mori-jester version --silent
+npx.cmd -y memento-mori-jester@latest doctor
+npx.cmd -y memento-mori-jester@latest summary --kind command "git reset --hard"
+npm.cmd run support:check
+```

package/examples/support/README.md

@@ -2,7 +2,7 @@
 
 This playbook shows how to handle sanitized adopter reports without turning every surprise into an immediate rule change. It pairs with [docs/MAINTAINER_TRIAGE.md](../../docs/MAINTAINER_TRIAGE.md), the [report gallery feedback template](../reports/feedback-template.md), and the GitHub issue templates.
 
-Start with the compact checked [support lifecycle map](support-lifecycle-map.md) when you need a quick scan of the path: report, triage, response, closeout, prioritization, backlog record, and backlog review. Use the checked [support lifecycle worksheet](support-lifecycle-worksheet.md) during an active review so every stage has concrete checks and record fields. Use the full checked [support lifecycle overview](support-lifecycle.md) when you need the outcome table in one place. The lifecycle sources are [support-lifecycle-map.json](support-lifecycle-map.json), [support-lifecycle-worksheet.json](support-lifecycle-worksheet.json), and [support-lifecycle.json](support-lifecycle.json). Use [outcome-prioritization.md](outcome-prioritization.md) after closeout to decide whether follow-up work should become docs, fixture backlog, or rule-review work. Use [backlog-records.md](backlog-records.md) to turn that decision into a public-safe backlog artifact, then use [backlog-review.md](backlog-review.md) to decide whether the item stays active or closes with no action.
+Start with the checked [support examples index](support-examples-index.md) when you need to choose the right artifact. Use the compact checked [support lifecycle map](support-lifecycle-map.md) when you need a quick scan of the path: report, triage, response, closeout, prioritization, backlog record, and backlog review. Use the checked [support lifecycle worksheet](support-lifecycle-worksheet.md) during an active review so every stage has concrete checks and record fields, and compare against the synthetic [filled worksheet example](support-lifecycle-filled-example.md) when you need to see one completed `docs-example` path. Use the full checked [support lifecycle overview](support-lifecycle.md) when you need the outcome table in one place. The lifecycle sources are [support-examples-index.json](support-examples-index.json), [support-lifecycle-map.json](support-lifecycle-map.json), [support-lifecycle-worksheet.json](support-lifecycle-worksheet.json), [support-lifecycle-filled-example.json](support-lifecycle-filled-example.json), and [support-lifecycle.json](support-lifecycle.json). Use [outcome-prioritization.md](outcome-prioritization.md) after closeout to decide whether follow-up work should become docs, fixture backlog, or rule-review work. Use [backlog-records.md](backlog-records.md) to turn that decision into a public-safe backlog artifact, then use [backlog-review.md](backlog-review.md) to decide whether the item stays active or closes with no action.
 
 The checked source is [triage-playbook.json](triage-playbook.json). Use [response-snippets.md](response-snippets.md) for copy-paste replies after a report is classified. The snippet source is [response-snippets.json](response-snippets.json). Use [closeout-checklist.md](closeout-checklist.md) to record what happened after the response. The closeout source is [closeout-checklist.json](closeout-checklist.json). The backlog source is [backlog-records.json](backlog-records.json). The review source is [backlog-review.json](backlog-review.json).
 

package/examples/support/support-examples-index.json

@@ -0,0 +1,106 @@
+{
+  "title": "Support Examples Index",
+  "artifacts": [
+    {
+      "id": "lifecycle-map",
+      "label": "Support Lifecycle Map",
+      "file": "examples/support/support-lifecycle-map.md",
+      "source": "examples/support/support-lifecycle-map.json",
+      "useWhen": "Use when you need the shortest scan of the support path before reading detailed checklists.",
+      "requiredMarkers": [
+        "report -> triage -> response -> closeout -> prioritization -> backlog-record -> backlog-review",
+        "SECURITY.md",
+        "npm run support:check"
+      ],
+      "publicSafe": true,
+      "synthetic": false
+    },
+    {
+      "id": "blank-worksheet",
+      "label": "Support Lifecycle Worksheet",
+      "file": "examples/support/support-lifecycle-worksheet.md",
+      "source": "examples/support/support-lifecycle-worksheet.json",
+      "useWhen": "Use during an active review of one public support report when each stage needs concrete fields to record.",
+      "requiredMarkers": [
+        "stage checklist",
+        "record fields",
+        "stop conditions",
+        "SECURITY.md",
+        "npm run support:check"
+      ],
+      "publicSafe": true,
+      "synthetic": false
+    },
+    {
+      "id": "filled-synthetic-example",
+      "label": "Filled Support Lifecycle Worksheet Example",
+      "file": "examples/support/support-lifecycle-filled-example.md",
+      "source": "examples/support/support-lifecycle-filled-example.json",
+      "useWhen": "Use when comparing an active report with one completed synthetic docs-example path from report through backlog review.",
+      "requiredMarkers": [
+        "synthetic-report-gallery-docs-example",
+        "placeholder links",
+        "privacy review notes",
+        "SECURITY.md",
+        "npm run support:check"
+      ],
+      "publicSafe": true,
+      "synthetic": true
+    }
+  ],
+  "quickPath": [
+    {
+      "stage": "report",
+      "artifact": "examples/reports/feedback-template.md",
+      "maintainerQuestion": "Is the report redacted, minimal, and safe to discuss publicly?",
+      "record": ["source issue", "package version", "sanitized summary", "safe to discuss publicly"]
+    },
+    {
+      "stage": "triage",
+      "artifact": "examples/support/triage-playbook.json",
+      "maintainerQuestion": "Is this expected docs behavior, fixture backlog, or rule-review work?",
+      "record": ["selected outcome", "rule id or report id", "why the outcome fits"]
+    },
+    {
+      "stage": "response",
+      "artifact": "examples/support/response-snippets.json",
+      "maintainerQuestion": "Which checked public-safe reply should go back to the reporter?",
+      "record": ["snippet id", "next command", "public-safe follow-up link"]
+    },
+    {
+      "stage": "closeout",
+      "artifact": "examples/support/closeout-checklist.json",
+      "maintainerQuestion": "Did the immediate support decision ship, queue, or open follow-up?",
+      "record": ["closeout id", "decision status", "follow-up link placeholder"]
+    },
+    {
+      "stage": "prioritization",
+      "artifact": "examples/support/outcome-prioritization.json",
+      "maintainerQuestion": "Is the follow-up low-priority docs, medium fixture work, or high rule review?",
+      "record": ["priority", "minimum evidence", "not enough evidence guardrail"]
+    },
+    {
+      "stage": "backlog-record",
+      "artifact": "examples/support/backlog-records.json",
+      "maintainerQuestion": "Is there a public-safe backlog artifact with evidence and checks?",
+      "record": ["backlog record id", "backlog type", "next action", "required checks"]
+    },
+    {
+      "stage": "backlog-review",
+      "artifact": "examples/support/backlog-review.json",
+      "maintainerQuestion": "Does the item remain active, or should it close with no action?",
+      "record": ["review decision", "review cadence", "next action", "checks run"]
+    }
+  ],
+  "requiredPublicSafeMarkers": [
+    "synthetic examples are labelled synthetic",
+    "placeholder links are used for public issue and follow-up links",
+    "SECURITY.md redirects sensitive reports away from public issues",
+    "no secrets, private code, private paths, customer data, full logs, unredacted SARIF, package publishing credentials, MCP data exposure, or exploitable security details"
+  ],
+  "requiredChecks": [
+    "npm run support:check",
+    "npm run production:check"
+  ],
+  "privacyGuardrail": "Keep support examples public-safe: label synthetic material, use placeholders, avoid secrets and private details, and route credential exposure, package publishing compromise, MCP data exposure, command execution risk, or exploitable security details through SECURITY.md."
+}

package/examples/support/support-examples-index.md

@@ -0,0 +1,42 @@
+# Support Examples Index
+
+This public-safe index tells maintainers which checked support artifact to use during a report review. It keeps the compact map, blank worksheet, and filled synthetic example together so a support issue can move from first report to backlog review without guessing.
+
+The checked source is [support-examples-index.json](support-examples-index.json). It points at the [support lifecycle map](support-lifecycle-map.md), [support lifecycle worksheet](support-lifecycle-worksheet.md), and [filled lifecycle worksheet example](support-lifecycle-filled-example.md).
+
+## Which Artifact To Use
+
+| Artifact | Use when | Required public-safe markers |
+| --- | --- | --- |
+| [support-lifecycle-map.md](support-lifecycle-map.md) | You need the shortest scan of the support path before reading details. | Stage order, outcome scan, `SECURITY.md`, and `npm run support:check`. |
+| [support-lifecycle-worksheet.md](support-lifecycle-worksheet.md) | You are actively reviewing one public support report and need fields to record. | Stage checklist, record fields, stop conditions, `SECURITY.md`, and `npm run support:check`. |
+| [support-lifecycle-filled-example.md](support-lifecycle-filled-example.md) | You want to compare the active report with one completed synthetic `docs-example` path. | `synthetic-report-gallery-docs-example`, placeholder links, privacy review notes, `SECURITY.md`, and `npm run support:check`. |
+
+## Quick Maintainer Path
+
+| Stage | Maintainer question | Use this artifact | Record |
+| --- | --- | --- | --- |
+| `report` | Is the report redacted, minimal, and safe to discuss publicly? | [feedback-template.md](../reports/feedback-template.md) | source issue, package version, sanitized summary, safe to discuss publicly |
+| `triage` | Is this expected docs behavior, fixture backlog, or rule-review work? | [triage-playbook.json](triage-playbook.json) | selected outcome, rule id or report id, why the outcome fits |
+| `response` | Which checked public-safe reply should go back to the reporter? | [response-snippets.md](response-snippets.md) | snippet id, next command, public-safe follow-up link |
+| `closeout` | Did the immediate support decision ship, queue, or open follow-up? | [closeout-checklist.md](closeout-checklist.md) | closeout id, decision status, follow-up link placeholder |
+| `prioritization` | Is the follow-up low-priority docs, medium fixture work, or high rule review? | [outcome-prioritization.md](outcome-prioritization.md) | priority, minimum evidence, not enough evidence guardrail |
+| `backlog-record` | Is there a public-safe backlog artifact with evidence and checks? | [backlog-records.md](backlog-records.md) | backlog record id, backlog type, next action, required checks |
+| `backlog-review` | Does the item remain active, or should it close with no action? | [backlog-review.md](backlog-review.md) | review decision, review cadence, next action, checks run |
+
+## Public-Safe Markers
+
+Keep every public support artifact aligned with these markers:
+
+- say when an example is synthetic,
+- use placeholders for issue links and follow-up links,
+- include the `SECURITY.md` redirect for sensitive reports,
+- avoid secrets, private code, private paths, customer data, full logs, unredacted SARIF, package publishing credentials, MCP data exposure, or exploitable security details,
+- keep rule behavior unchanged unless a separate checked rule-review change exists.
+
+## Checks
+
+```powershell
+npm run support:check
+npm run production:check
+```

package/examples/support/support-lifecycle-filled-example.json

@@ -0,0 +1,160 @@
+{
+  "title": "Filled Support Lifecycle Worksheet Example",
+  "sourceWorksheet": "examples/support/support-lifecycle-worksheet.json",
+  "synthetic": true,
+  "caseId": "synthetic-report-gallery-docs-example",
+  "outcome": "docs-example",
+  "flow": [
+    "report",
+    "triage",
+    "response",
+    "closeout",
+    "prioritization",
+    "backlog-record",
+    "backlog-review"
+  ],
+  "stages": [
+    {
+      "id": "report",
+      "artifact": "examples/reports/feedback-template.md",
+      "fields": {
+        "sourceIssue": "<public-issue-url>",
+        "packageVersion": "0.1.100",
+        "sanitizedSummary": "A reporter says the checked destructive-command-summary gallery item is useful but unclear about whether the block is expected.",
+        "safeToDiscussPublicly": true
+      },
+      "checks": [
+        "Confirmed the report references the checked destructive-command-summary gallery item instead of a private repository command.",
+        "Confirmed the report includes only a sanitized command summary and redacted doctor --json fragments.",
+        "Confirmed there are no secrets, private code, private paths, customer data, full logs, unredacted SARIF, or exploitable details."
+      ],
+      "privacyReview": [
+        "The issue link is a placeholder rather than a real user report.",
+        "The command is a public demo command already used in docs.",
+        "Security-sensitive details would be redirected to SECURITY.md."
+      ]
+    },
+    {
+      "id": "triage",
+      "artifact": "examples/support/triage-playbook.json",
+      "fields": {
+        "selectedOutcome": "docs-example",
+        "ruleIdOrReportId": "destructive-command-summary",
+        "whyOutcomeFits": "The block is expected behavior for destructive git history changes, but the report-gallery wording can be clearer."
+      },
+      "checks": [
+        "Reproduced the checked report-gallery summary with the published command shape.",
+        "Compared the output to the existing report-gallery expected fragments.",
+        "Chose docs-example because no rule behavior, fixture boundary, or scoring change is needed."
+      ],
+      "privacyReview": [
+        "The reproduction uses only the public demo command.",
+        "The triage note does not include private repository output.",
+        "No secret material or exploit detail is needed to classify the report."
+      ]
+    },
+    {
+      "id": "response",
+      "artifact": "examples/support/response-snippets.json",
+      "fields": {
+        "snippetId": "docs-example-response",
+        "nextCommand": "npx -y memento-mori-jester@latest summary --kind command \"git reset --hard\"",
+        "publicSafeFollowUpLink": "<docs-follow-up-url>"
+      },
+      "checks": [
+        "Used the checked docs-example response snippet rather than writing a one-off reply.",
+        "Asked only for redacted diagnostics if local output still differs from the gallery.",
+        "Gave the reporter one command to compare with the checked report."
+      ],
+      "privacyReview": [
+        "The response asks for redacted diagnostics only.",
+        "The follow-up link is a placeholder until a public docs issue or pull request exists.",
+        "Any credential exposure, private code, or command execution concern belongs in SECURITY.md."
+      ]
+    },
+    {
+      "id": "closeout",
+      "artifact": "examples/support/closeout-checklist.json",
+      "fields": {
+        "closeoutId": "docs-clarification-closeout",
+        "decisionStatus": "shipped-or-queued",
+        "followUpLinkPlaceholder": "<docs-pr-url-or-issue>"
+      },
+      "checks": [
+        "Recorded that the immediate support decision is a docs clarification.",
+        "Linked only a placeholder public follow-up artifact.",
+        "Kept rule behavior, matching, scoring, and CLI policy unchanged."
+      ],
+      "privacyReview": [
+        "The closeout can be explained using only public docs and report-gallery context.",
+        "No private code or user-specific terminal output is required.",
+        "Security-sensitive follow-up is explicitly out of scope for the public closeout."
+      ]
+    },
+    {
+      "id": "prioritization",
+      "artifact": "examples/support/outcome-prioritization.json",
+      "fields": {
+        "priority": "low",
+        "minimumEvidence": "Nearest checked report, observed output, and no rule behavior change.",
+        "notEnoughEvidenceGuardrail": "Do not open fixture or rule-review work from a docs-only confusion report."
+      },
+      "checks": [
+        "Used the outcome prioritization guide for the docs-example path.",
+        "Confirmed the minimum evidence threshold is met by the existing checked gallery item.",
+        "Confirmed there is enough public-safe evidence to queue a docs clarification."
+      ],
+      "privacyReview": [
+        "The priority does not depend on private reports.",
+        "The evidence is already public and synthetic.",
+        "No secrets, private paths, or full logs are needed."
+      ]
+    },
+    {
+      "id": "backlog-record",
+      "artifact": "examples/support/backlog-records.json",
+      "fields": {
+        "backlogRecordId": "docs-clarification-backlog-record",
+        "backlogType": "docs clarification",
+        "nextAction": "Update the report-gallery wording so the destructive command summary clearly says the block is expected and shows the next comparison command.",
+        "requiredChecks": ["npm run reports:check", "npm run support:check"]
+      },
+      "checks": [
+        "Created a public-safe backlog record from the closeout and prioritization decision.",
+        "Included a public title, public summary, next action, and required checks.",
+        "Verified the backlog item does not ask for rule behavior changes."
+      ],
+      "privacyReview": [
+        "The backlog item references only checked docs and placeholder links.",
+        "The public summary is redacted and synthetic.",
+        "Any real private report detail would be removed before publishing."
+      ]
+    },
+    {
+      "id": "backlog-review",
+      "artifact": "examples/support/backlog-review.json",
+      "fields": {
+        "reviewDecision": "remains-docs-clarification",
+        "reviewCadence": "next monthly support review",
+        "nextAction": "Keep the docs clarification open until the gallery wording or docs example lands.",
+        "checksRun": ["npm run reports:check", "npm run support:check"]
+      },
+      "checks": [
+        "Revisited whether the item still belongs in the docs clarification lane.",
+        "Confirmed the report has not become a fixture backlog or rule-review candidate.",
+        "Confirmed the current public checks still pass before keeping it active."
+      ],
+      "privacyReview": [
+        "The review does not include private user names, repositories, paths, or logs.",
+        "The review can close as closed-no-action later if evidence becomes stale or duplicated.",
+        "Security-sensitive evidence would be removed from the public lifecycle and routed through SECURITY.md."
+      ]
+    }
+  ],
+  "requiredChecks": [
+    "npm run reports:check",
+    "npm run support:check",
+    "npm run production:check"
+  ],
+  "privacyGuardrail": "This filled worksheet is synthetic. Do not add secrets, private code, private paths, customer data, full logs, unredacted SARIF, package publishing credentials, MCP data exposure, or exploitable security details; route those through SECURITY.md."
+}