memento-mori-jester 0.1.94 → 0.1.96
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +12 -0
- package/README.md +6 -2
- package/ROADMAP.md +4 -0
- package/docs/MAINTAINER_TRIAGE.md +2 -2
- package/docs/PRODUCTION_READINESS.md +3 -3
- package/docs/RELEASE_NOTES_v0.1.95.md +58 -0
- package/docs/RELEASE_NOTES_v0.1.96.md +58 -0
- package/examples/support/README.md +5 -3
- package/examples/support/backlog-records.json +78 -0
- package/examples/support/backlog-records.md +57 -0
- package/examples/support/backlog-review.json +90 -0
- package/examples/support/backlog-review.md +40 -0
- package/package.json +1 -1
- package/scripts/check-production-readiness.mjs +35 -0
- package/scripts/check-support-triage.mjs +278 -0
package/CHANGELOG.md
CHANGED
|
@@ -4,6 +4,18 @@ All notable changes to Memento Mori Jester are tracked here.
|
|
|
4
4
|
|
|
5
5
|
## Unreleased
|
|
6
6
|
|
|
7
|
+
## 0.1.96
|
|
8
|
+
|
|
9
|
+
- Added a checked public-safe support backlog review checklist for deciding whether backlog records remain docs clarifications, fixture backlog items, rule-review candidates, or close with no action.
|
|
10
|
+
- Extended `npm run support:check` and production-readiness checks so review decisions, source records, required checks, and privacy guidance stay aligned with support backlog records.
|
|
11
|
+
- Updated README, maintainer triage docs, support examples, production-readiness docs, roadmap, and release notes for deterministic backlog aging review.
|
|
12
|
+
|
|
13
|
+
## 0.1.95
|
|
14
|
+
|
|
15
|
+
- Added checked public-safe support backlog records for turning closed/prioritized support outcomes into docs clarification, fixture backlog, or rule-review candidate artifacts.
|
|
16
|
+
- Extended `npm run support:check` and production-readiness checks so backlog record IDs, evidence thresholds, required checks, and privacy guidance stay aligned with the support lifecycle.
|
|
17
|
+
- Updated README, maintainer triage docs, support examples, production-readiness docs, roadmap, and release notes for deterministic support backlog recording.
|
|
18
|
+
|
|
7
19
|
## 0.1.94
|
|
8
20
|
|
|
9
21
|
- Added a checked public-safe support outcome prioritization guide for deciding whether closed support reports become docs clarifications, fixture backlog items, or rule-review candidates.
|
package/README.md
CHANGED
|
@@ -76,7 +76,7 @@ For trust-building output examples, see [examples/reports](examples/reports). `n
|
|
|
76
76
|
|
|
77
77
|
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.
|
|
78
78
|
|
|
79
|
-
Maintainers can use the checked [support lifecycle overview](examples/support/support-lifecycle.md), [outcome prioritization guide](examples/support/outcome-prioritization.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.
|
|
79
|
+
Maintainers can use the checked [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.
|
|
80
80
|
|
|
81
81
|
Expected vibe:
|
|
82
82
|
|
|
@@ -452,6 +452,8 @@ More setup examples:
|
|
|
452
452
|
- [Report Gallery Feedback Template](examples/reports/feedback-template.md)
|
|
453
453
|
- [Support Lifecycle Overview](examples/support/support-lifecycle.md)
|
|
454
454
|
- [Support Outcome Prioritization](examples/support/outcome-prioritization.md)
|
|
455
|
+
- [Support Backlog Records](examples/support/backlog-records.md)
|
|
456
|
+
- [Support Backlog Review](examples/support/backlog-review.md)
|
|
455
457
|
- [Support Triage Playbook](examples/support)
|
|
456
458
|
- [Maintainer Response Snippets](examples/support/response-snippets.md)
|
|
457
459
|
- [Support Closeout Checklist](examples/support/closeout-checklist.md)
|
|
@@ -478,6 +480,8 @@ Framework CI examples:
|
|
|
478
480
|
- [Report Gallery Feedback Template](examples/reports/feedback-template.md)
|
|
479
481
|
- [Support Lifecycle Overview](examples/support/support-lifecycle.md)
|
|
480
482
|
- [Support Outcome Prioritization](examples/support/outcome-prioritization.md)
|
|
483
|
+
- [Support Backlog Records](examples/support/backlog-records.md)
|
|
484
|
+
- [Support Backlog Review](examples/support/backlog-review.md)
|
|
481
485
|
- [Support Triage Playbook](examples/support)
|
|
482
486
|
- [Maintainer Response Snippets](examples/support/response-snippets.md)
|
|
483
487
|
- [Support Closeout Checklist](examples/support/closeout-checklist.md)
|
|
@@ -537,7 +541,7 @@ Maintainers can use [docs/MAINTAINER_TRIAGE.md](docs/MAINTAINER_TRIAGE.md) to tu
|
|
|
537
541
|
Run `npm run fixtures:check` before merging fixture changes; it catches duplicate IDs, missing rule metadata, weak descriptions, unsafe-looking content, and duplicate content.
|
|
538
542
|
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.
|
|
539
543
|
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.
|
|
540
|
-
Run `npm run support:check` after editing issue templates, support docs, the report gallery feedback path, the [support lifecycle overview](examples/support/support-lifecycle.md), [outcome prioritization guide](examples/support/outcome-prioritization.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.
|
|
544
|
+
Run `npm run support:check` after editing issue templates, support docs, the report gallery feedback path, the [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.
|
|
541
545
|
Run `npm run promo:card` to regenerate the repo-local social preview card after changing its copy or design.
|
|
542
546
|
Run `npm run promo:check` after editing promo assets; it checks the current demo video, stills, docs, and fixture evidence numbers stay in sync.
|
|
543
547
|
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
CHANGED
|
@@ -6,6 +6,8 @@ Memento Mori Jester is usable today as a CLI, MCP server, GitHub Action, and git
|
|
|
6
6
|
|
|
7
7
|
## Recently Shipped
|
|
8
8
|
|
|
9
|
+
- Checked support backlog review in v0.1.96, helping maintainers revisit backlog records and keep them as docs, fixture, or rule-review work, or close them with no action when evidence goes stale.
|
|
10
|
+
- Checked support backlog records in v0.1.95, turning closed and prioritized support outcomes into public-safe docs clarification, fixture backlog, or rule-review candidate artifacts.
|
|
9
11
|
- Checked support outcome prioritization in v0.1.94, helping maintainers turn closed support reports into docs, fixture backlog, or rule-review work based on public-safe evidence thresholds.
|
|
10
12
|
- Checked support lifecycle overview in v0.1.93, tying report-gallery feedback, triage playbook entries, response snippets, and closeout records together by outcome.
|
|
11
13
|
- Checked support closeout checklist in v0.1.92, recording whether docs clarifications shipped or queued, fixture backlogs were created, or rule-review candidates were opened.
|
|
@@ -84,6 +86,8 @@ Memento Mori Jester is usable today as a CLI, MCP server, GitHub Action, and git
|
|
|
84
86
|
## Product Ideas
|
|
85
87
|
|
|
86
88
|
- Collect real-world reports and fold the strongest redacted cases into more framework tuning cookbook recipes.
|
|
89
|
+
- Add a small checked maintainer dashboard or report that summarizes open support backlog review states from public-safe JSON.
|
|
90
|
+
- Use support backlog record counts to choose the next docs, fixture, report-gallery, or rule-guidance batch.
|
|
87
91
|
- Use repeated prioritized support outcomes to choose the next redacted fixture, report-gallery update, or rule-guidance review.
|
|
88
92
|
- Add a hosted-page option or GitHub Pages instructions once the static page has settled.
|
|
89
93
|
|
|
@@ -21,7 +21,7 @@ For users who just need to understand what a healthy report looks like, point th
|
|
|
21
21
|
|
|
22
22
|
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.
|
|
23
23
|
|
|
24
|
-
When a report has enough public-safe detail to triage, start with the checked [support lifecycle overview](../examples/support/support-lifecycle.md) to see the whole path from report to closeout. 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.
|
|
24
|
+
When a report has enough public-safe detail to triage, start with the checked [support lifecycle overview](../examples/support/support-lifecycle.md) to see the whole path from report to closeout. 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.
|
|
25
25
|
|
|
26
26
|
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).
|
|
27
27
|
|
|
@@ -65,7 +65,7 @@ Use the playbook outcomes consistently:
|
|
|
65
65
|
- `fixture-backlog`: the reduced report looks safe and should become a pass or quiet-pass fixture.
|
|
66
66
|
- `rule-review-candidate`: repeated sanitized reports suggest guidance or matching may need review, but not from a single report.
|
|
67
67
|
|
|
68
|
-
Use the matching lifecycle row and response snippet for the first public reply, then adapt only the project-neutral parts: the rule id, minimal command summary, fixture id, and next command. After the reply, record the closeout with the matching checklist entry so the issue has a public-safe decision record. If follow-up work remains, choose its priority from the outcome prioritization guide before opening a docs, fixture, or rule-review backlog item. Do not add private code, private paths, tokens, full logs, or exploitable details to the response, closeout, or backlog
|
|
68
|
+
Use the matching lifecycle row and response snippet for the first public reply, then adapt only the project-neutral parts: the rule id, minimal command summary, fixture id, and next command. After the reply, record the closeout with the matching checklist entry so the issue has a public-safe decision record. If follow-up work remains, choose its priority from the outcome prioritization guide before opening a docs, fixture, or rule-review backlog item, then record that choice with the matching backlog record. During later reviews, keep the item as docs clarification, fixture backlog, or rule-review candidate only when the public-safe evidence still holds; otherwise close it as `closed-no-action`. Do not add private code, private paths, tokens, full logs, or exploitable details to the response, closeout, backlog item, or backlog review.
|
|
69
69
|
|
|
70
70
|
After editing report support docs or issue templates, run:
|
|
71
71
|
|
|
@@ -47,7 +47,7 @@ This checklist defines what "production grade" means for Memento Mori Jester rig
|
|
|
47
47
|
- `README.md` leads with a no-write first run, project bootstrap, agent setup, and optional hooks/CI.
|
|
48
48
|
- `docs/GETTING_STARTED.md`, `docs/CLI.md`, `docs/RELEASE.md`, and `docs/TRUSTED_PUBLISHING.md` cover the core adoption and release paths.
|
|
49
49
|
- `examples/reports` provides checked, public-safe report examples for fresh install diagnostics, summary output, blocked command reviews, and report-gallery feedback.
|
|
50
|
-
- `examples/support` provides a checked support lifecycle overview, outcome prioritization guide, maintainer triage playbook, response snippets, and closeout checklist for first response, classification, follow-up outcomes, public-safe decision records,
|
|
50
|
+
- `examples/support` provides a checked support lifecycle overview, outcome prioritization guide, backlog records, backlog review checklist, maintainer triage playbook, response snippets, and closeout checklist for first response, classification, follow-up outcomes, public-safe decision records, backlog prioritization, backlog artifacts, and aging review from sanitized support reports.
|
|
51
51
|
- `site/index.html` gives maintainers a static one-page share surface that reuses the demo, social card, start command, and public links.
|
|
52
52
|
- Every public release has matching `CHANGELOG.md` notes and `docs/RELEASE_NOTES_vX.Y.Z.md`.
|
|
53
53
|
|
|
@@ -60,14 +60,14 @@ This checklist defines what "production grade" means for Memento Mori Jester rig
|
|
|
60
60
|
- GitHub issue templates collect bug reports, false-positive reports, report-gallery feedback, and feature requests with the diagnostic context maintainers need.
|
|
61
61
|
- `SECURITY.md` routes vulnerability reports away from public issues and asks for redacted diagnostics.
|
|
62
62
|
- `docs/MAINTAINER_TRIAGE.md` explains how to turn useful false-positive reports into fixture coverage before changing rule logic.
|
|
63
|
-
- `examples/support` shows maintainers how to audit the support lifecycle, 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,
|
|
63
|
+
- `examples/support` shows maintainers how to audit the support lifecycle, 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.
|
|
64
64
|
- `npm run fixtures:check` validates fixture IDs, metadata, unsafe-looking content, duplicate content, and explicit expected/absent rule intent.
|
|
65
65
|
- `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.
|
|
66
66
|
- `npm run framework:tuning:check` keeps the framework tuning guide, cookbook JSON, cookbook README, and fixture IDs aligned.
|
|
67
67
|
- `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.
|
|
68
68
|
- `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.
|
|
69
69
|
- `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.
|
|
70
|
-
- `npm run support:check` verifies issue templates, support docs, the report gallery feedback template, the support lifecycle overview, outcome prioritization guide, maintainer triage playbook, response snippets, and closeout checklist stay public-safe and ask for useful redacted context.
|
|
70
|
+
- `npm run support:check` verifies issue templates, support docs, the report gallery feedback template, the 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.
|
|
71
71
|
- `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.
|
|
72
72
|
- `npm run site:check` verifies the static landing page before maintainers post or host it.
|
|
73
73
|
- npm publish has a manual workflow fallback, but the normal release path is tag-driven trusted publishing.
|
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
# Memento Mori Jester v0.1.95
|
|
2
|
+
|
|
3
|
+
## Summary
|
|
4
|
+
|
|
5
|
+
This release adds checked public-safe support backlog records. It helps maintainers turn a closed and prioritized support outcome into a docs clarification, fixture backlog item, or rule-review candidate without changing rule behavior first.
|
|
6
|
+
|
|
7
|
+
## What Changed
|
|
8
|
+
|
|
9
|
+
- Added `examples/support/backlog-records.md`.
|
|
10
|
+
- Added `examples/support/backlog-records.json`.
|
|
11
|
+
- Extended `scripts/check-support-triage.mjs` to validate backlog record IDs, outcome mapping, source closeouts, evidence thresholds, required checks, and privacy review guidance.
|
|
12
|
+
- Extended production-readiness checks for the backlog records.
|
|
13
|
+
- Updated README, maintainer triage docs, support examples, production-readiness docs, roadmap, and changelog.
|
|
14
|
+
|
|
15
|
+
## Public Interface
|
|
16
|
+
|
|
17
|
+
- No CLI command changes.
|
|
18
|
+
- No MCP tool changes.
|
|
19
|
+
- No config schema changes.
|
|
20
|
+
- No review rule, scoring, matching, or verdict behavior changes.
|
|
21
|
+
- No GitHub Action input changes.
|
|
22
|
+
- Support docs and package examples now include checked follow-up backlog records.
|
|
23
|
+
|
|
24
|
+
## Release Validation
|
|
25
|
+
|
|
26
|
+
```powershell
|
|
27
|
+
npm.cmd test
|
|
28
|
+
npm.cmd run support:check
|
|
29
|
+
npm.cmd run reports:check
|
|
30
|
+
npm.cmd run demo:svg:check
|
|
31
|
+
npm.cmd run promo:card:check
|
|
32
|
+
npm.cmd run promo:check
|
|
33
|
+
npm.cmd run fixtures:report
|
|
34
|
+
npm.cmd run fixtures:report -- --json
|
|
35
|
+
npm.cmd run fixtures:report -- --markdown
|
|
36
|
+
npm.cmd run pack:dry
|
|
37
|
+
git diff --check
|
|
38
|
+
node .\dist\cli.js doctor
|
|
39
|
+
node .\dist\cli.js summary --kind command "git reset --hard"
|
|
40
|
+
git diff | node .\dist\cli.js diff --fail-on block --subject "v0.1.95 checked support backlog records"
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
Expected:
|
|
44
|
+
|
|
45
|
+
- `support:check` verifies issue templates, feedback templates, the support lifecycle overview, outcome prioritization guide, backlog records, maintainer triage playbook, response snippets, and closeout checklist.
|
|
46
|
+
- `reports:check` still verifies the installed-package report gallery.
|
|
47
|
+
- fixture report still shows `Fixtures: 222`.
|
|
48
|
+
- GitHub Release and npm Publish complete from the `v0.1.95` tag.
|
|
49
|
+
|
|
50
|
+
After publish:
|
|
51
|
+
|
|
52
|
+
```powershell
|
|
53
|
+
npm.cmd view memento-mori-jester version --silent
|
|
54
|
+
npx.cmd -y memento-mori-jester@latest doctor
|
|
55
|
+
npx.cmd -y memento-mori-jester@latest summary --kind command "git reset --hard"
|
|
56
|
+
npm.cmd run support:check
|
|
57
|
+
npm.cmd run reports:check -- --package memento-mori-jester@latest
|
|
58
|
+
```
|
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
# Memento Mori Jester v0.1.96
|
|
2
|
+
|
|
3
|
+
## Summary
|
|
4
|
+
|
|
5
|
+
This release adds a checked public-safe support backlog review checklist. It helps maintainers revisit backlog records over time and decide whether each item remains a docs clarification, fixture backlog item, rule-review candidate, or closes with no action.
|
|
6
|
+
|
|
7
|
+
## What Changed
|
|
8
|
+
|
|
9
|
+
- Added `examples/support/backlog-review.md`.
|
|
10
|
+
- Added `examples/support/backlog-review.json`.
|
|
11
|
+
- Extended `scripts/check-support-triage.mjs` to validate review decisions, source records, cadence, criteria, required checks, and privacy review guidance.
|
|
12
|
+
- Extended production-readiness checks for the backlog review checklist.
|
|
13
|
+
- Updated README, maintainer triage docs, support examples, production-readiness docs, roadmap, and changelog.
|
|
14
|
+
|
|
15
|
+
## Public Interface
|
|
16
|
+
|
|
17
|
+
- No CLI command changes.
|
|
18
|
+
- No MCP tool changes.
|
|
19
|
+
- No config schema changes.
|
|
20
|
+
- No review rule, scoring, matching, or verdict behavior changes.
|
|
21
|
+
- No GitHub Action input changes.
|
|
22
|
+
- Support docs and package examples now include checked backlog aging review guidance.
|
|
23
|
+
|
|
24
|
+
## Release Validation
|
|
25
|
+
|
|
26
|
+
```powershell
|
|
27
|
+
npm.cmd test
|
|
28
|
+
npm.cmd run support:check
|
|
29
|
+
npm.cmd run reports:check
|
|
30
|
+
npm.cmd run demo:svg:check
|
|
31
|
+
npm.cmd run promo:card:check
|
|
32
|
+
npm.cmd run promo:check
|
|
33
|
+
npm.cmd run fixtures:report
|
|
34
|
+
npm.cmd run fixtures:report -- --json
|
|
35
|
+
npm.cmd run fixtures:report -- --markdown
|
|
36
|
+
npm.cmd run pack:dry
|
|
37
|
+
git diff --check
|
|
38
|
+
node .\dist\cli.js doctor
|
|
39
|
+
node .\dist\cli.js summary --kind command "git reset --hard"
|
|
40
|
+
git diff | node .\dist\cli.js diff --fail-on block --subject "v0.1.96 checked support backlog review"
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
Expected:
|
|
44
|
+
|
|
45
|
+
- `support:check` verifies issue templates, feedback templates, the support lifecycle overview, outcome prioritization guide, backlog records, backlog review checklist, maintainer triage playbook, response snippets, and closeout checklist.
|
|
46
|
+
- `reports:check` still verifies the installed-package report gallery.
|
|
47
|
+
- fixture report still shows `Fixtures: 222`.
|
|
48
|
+
- GitHub Release and npm Publish complete from the `v0.1.96` tag.
|
|
49
|
+
|
|
50
|
+
After publish:
|
|
51
|
+
|
|
52
|
+
```powershell
|
|
53
|
+
npm.cmd view memento-mori-jester version --silent
|
|
54
|
+
npx.cmd -y memento-mori-jester@latest doctor
|
|
55
|
+
npx.cmd -y memento-mori-jester@latest summary --kind command "git reset --hard"
|
|
56
|
+
npm.cmd run support:check
|
|
57
|
+
npm.cmd run reports:check -- --package memento-mori-jester@latest
|
|
58
|
+
```
|
|
@@ -2,9 +2,9 @@
|
|
|
2
2
|
|
|
3
3
|
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.
|
|
4
4
|
|
|
5
|
-
Start with the checked [support lifecycle overview](support-lifecycle.md) when you need the whole path in one place. The lifecycle source is [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.
|
|
5
|
+
Start with the checked [support lifecycle overview](support-lifecycle.md) when you need the whole path in one place. The lifecycle source is [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.
|
|
6
6
|
|
|
7
|
-
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).
|
|
7
|
+
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).
|
|
8
8
|
|
|
9
9
|
| ID | Source | Classification | Follow-up |
|
|
10
10
|
| --- | --- | --- | --- |
|
|
@@ -25,10 +25,12 @@ The checked source is [triage-playbook.json](triage-playbook.json). Use [respons
|
|
|
25
25
|
6. Close with the next command the user can run.
|
|
26
26
|
7. Use the matching response snippet so replies stay public-safe and consistent.
|
|
27
27
|
8. Record the closeout with the matching checklist entry: docs clarification shipped or queued, fixture backlog created, or rule-review candidate opened.
|
|
28
|
+
9. If follow-up work remains, create the matching backlog record: docs clarification, fixture backlog item, or rule-review candidate.
|
|
29
|
+
10. Review backlog records over time as `remains-docs-clarification`, `remains-fixture-backlog`, `remains-rule-review-candidate`, or `closed-no-action`.
|
|
28
30
|
|
|
29
31
|
## Checks
|
|
30
32
|
|
|
31
|
-
Run this after editing support docs, issue templates, the lifecycle overview, outcome prioritization, the playbook, response snippets, or closeout checklist:
|
|
33
|
+
Run this after editing support docs, issue templates, the lifecycle overview, outcome prioritization, backlog records, backlog review, the playbook, response snippets, or closeout checklist:
|
|
32
34
|
|
|
33
35
|
```powershell
|
|
34
36
|
npm run support:check
|
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
[
|
|
2
|
+
{
|
|
3
|
+
"id": "docs-clarification-backlog-record",
|
|
4
|
+
"outcome": "docs-example",
|
|
5
|
+
"priority": "low",
|
|
6
|
+
"sourceCloseout": "docs-clarification-closeout",
|
|
7
|
+
"prioritizationSource": "outcome-prioritization.json",
|
|
8
|
+
"backlogType": "docs clarification",
|
|
9
|
+
"publicTitle": "Clarify checked report-gallery wording",
|
|
10
|
+
"publicSummary": "Update docs or report-gallery wording so expected behavior is easier to compare with local output.",
|
|
11
|
+
"evidence": [
|
|
12
|
+
"Nearest checked report or docs page is identified.",
|
|
13
|
+
"Observed output matches current behavior or differs only in wording/context.",
|
|
14
|
+
"No rule behavior change is requested before a clearer explanation is tried."
|
|
15
|
+
],
|
|
16
|
+
"nextAction": "Open or update a docs issue with the public-safe wording change and link the matching checked report.",
|
|
17
|
+
"privacyReview": [
|
|
18
|
+
"No secrets, private code, private paths, customer data, full logs, or unredacted SARIF are included.",
|
|
19
|
+
"Any private project names are replaced with placeholders.",
|
|
20
|
+
"Sensitive reports are routed to SECURITY.md instead of a public backlog item."
|
|
21
|
+
],
|
|
22
|
+
"requiredChecks": [
|
|
23
|
+
"npm run reports:check",
|
|
24
|
+
"npm run support:check"
|
|
25
|
+
]
|
|
26
|
+
},
|
|
27
|
+
{
|
|
28
|
+
"id": "fixture-backlog-record",
|
|
29
|
+
"outcome": "fixture-backlog",
|
|
30
|
+
"priority": "medium",
|
|
31
|
+
"sourceCloseout": "fixture-backlog-closeout",
|
|
32
|
+
"prioritizationSource": "outcome-prioritization.json",
|
|
33
|
+
"backlogType": "pass or quiet-pass fixture",
|
|
34
|
+
"publicTitle": "Add a quiet-pass fixture for a minimized false-positive boundary",
|
|
35
|
+
"publicSummary": "Track a redacted fixture candidate before changing matching, scoring, or verdict behavior.",
|
|
36
|
+
"evidence": [
|
|
37
|
+
"Smallest sanitized command, plan, diff, or final-answer text is available.",
|
|
38
|
+
"Rule id and redacted `jester tune <rule-id> --json` evidence are available.",
|
|
39
|
+
"The safe boundary is not already covered by an existing pass or quiet-pass fixture."
|
|
40
|
+
],
|
|
41
|
+
"nextAction": "Open a fixture backlog item with the candidate rule id, expected verdict, and absentRuleIds or expectedRuleIds.",
|
|
42
|
+
"privacyReview": [
|
|
43
|
+
"No secrets, private code, private paths, customer data, full logs, or unredacted SARIF are included.",
|
|
44
|
+
"The reduced reproduction uses placeholders such as <repo>, <path>, or <redacted>.",
|
|
45
|
+
"Sensitive reports are routed to SECURITY.md instead of a public backlog item."
|
|
46
|
+
],
|
|
47
|
+
"requiredChecks": [
|
|
48
|
+
"npm run fixtures:check",
|
|
49
|
+
"npm run fixtures:report",
|
|
50
|
+
"npm run support:check"
|
|
51
|
+
]
|
|
52
|
+
},
|
|
53
|
+
{
|
|
54
|
+
"id": "rule-review-candidate-backlog-record",
|
|
55
|
+
"outcome": "rule-review-candidate",
|
|
56
|
+
"priority": "high",
|
|
57
|
+
"sourceCloseout": "rule-review-closeout",
|
|
58
|
+
"prioritizationSource": "outcome-prioritization.json",
|
|
59
|
+
"backlogType": "rule-review candidate",
|
|
60
|
+
"publicTitle": "Compare repeated sanitized reports for a rule boundary",
|
|
61
|
+
"publicSummary": "Track repeated public-safe reports so maintainers can compare fixture evidence before changing guidance or matching.",
|
|
62
|
+
"evidence": [
|
|
63
|
+
"At least two sanitized reports or checked examples point at the same rule boundary.",
|
|
64
|
+
"Redacted `jester tune <rule-id> --json` or fixture report evidence is referenced.",
|
|
65
|
+
"The candidate explains why docs clarification or a single fixture backlog item is not enough."
|
|
66
|
+
],
|
|
67
|
+
"nextAction": "Open a rule-review candidate issue linking the sanitized examples, fixture evidence, and current guidance.",
|
|
68
|
+
"privacyReview": [
|
|
69
|
+
"No secrets, private code, private paths, customer data, full logs, or unredacted SARIF are included.",
|
|
70
|
+
"Repeated examples are summarized without exposing private project details.",
|
|
71
|
+
"Sensitive reports are routed to SECURITY.md instead of a public backlog item."
|
|
72
|
+
],
|
|
73
|
+
"requiredChecks": [
|
|
74
|
+
"npm run fixtures:report -- --markdown",
|
|
75
|
+
"npm run support:check"
|
|
76
|
+
]
|
|
77
|
+
}
|
|
78
|
+
]
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
# Support Backlog Records
|
|
2
|
+
|
|
3
|
+
Use this after the [support lifecycle overview](support-lifecycle.md), [outcome prioritization guide](outcome-prioritization.md), and [closeout checklist](closeout-checklist.md) have identified follow-up work. The checked source is [backlog-records.json](backlog-records.json).
|
|
4
|
+
|
|
5
|
+
These records show how a closed, prioritized, public-safe support outcome becomes a backlog artifact without changing rule behavior first.
|
|
6
|
+
|
|
7
|
+
| Outcome | Priority | Backlog record | Destination | Required checks |
|
|
8
|
+
| --- | --- | --- | --- | --- |
|
|
9
|
+
| `docs-example` | low | `docs-clarification-backlog-record` | docs clarification | `npm run reports:check`, `npm run support:check` |
|
|
10
|
+
| `fixture-backlog` | medium | `fixture-backlog-record` | pass or quiet-pass fixture | `npm run fixtures:check`, `npm run fixtures:report`, `npm run support:check` |
|
|
11
|
+
| `rule-review-candidate` | high | `rule-review-candidate-backlog-record` | rule-review candidate | `npm run fixtures:report -- --markdown`, `npm run support:check` |
|
|
12
|
+
|
|
13
|
+
## Docs Clarification
|
|
14
|
+
|
|
15
|
+
Use `docs-clarification-backlog-record` when the behavior is expected but the checked report, README, or guide made it hard to compare local output with the known-good example.
|
|
16
|
+
|
|
17
|
+
Enough evidence:
|
|
18
|
+
|
|
19
|
+
- nearest checked report or docs page,
|
|
20
|
+
- observed output summary,
|
|
21
|
+
- confirmation that no rule behavior change is requested before clearer wording is tried.
|
|
22
|
+
|
|
23
|
+
Next action: open or update a docs issue with the public-safe wording change and link the matching checked report.
|
|
24
|
+
|
|
25
|
+
## Fixture Backlog
|
|
26
|
+
|
|
27
|
+
Use `fixture-backlog-record` when a minimized false-positive report looks safe but should be protected by a pass or quiet-pass fixture before any matcher changes are considered.
|
|
28
|
+
|
|
29
|
+
Enough evidence:
|
|
30
|
+
|
|
31
|
+
- smallest sanitized command, plan, diff, or final-answer text,
|
|
32
|
+
- candidate rule id plus redacted `jester tune <rule-id> --json` evidence,
|
|
33
|
+
- confirmation that no existing pass or quiet-pass fixture covers the safe boundary.
|
|
34
|
+
|
|
35
|
+
Next action: open a fixture backlog item with the candidate rule id, expected verdict, and `absentRuleIds` or `expectedRuleIds`.
|
|
36
|
+
|
|
37
|
+
## Rule-Review Candidate
|
|
38
|
+
|
|
39
|
+
Use `rule-review-candidate-backlog-record` when repeated sanitized reports point at the same rule boundary and a docs clarification or single fixture backlog item is not enough.
|
|
40
|
+
|
|
41
|
+
Enough evidence:
|
|
42
|
+
|
|
43
|
+
- at least two sanitized reports or checked examples,
|
|
44
|
+
- fixture report or tune evidence for the rule,
|
|
45
|
+
- a short explanation of why the decision needs rule-review attention.
|
|
46
|
+
|
|
47
|
+
Next action: open a rule-review candidate issue linking the sanitized examples, fixture evidence, and current guidance.
|
|
48
|
+
|
|
49
|
+
## Privacy
|
|
50
|
+
|
|
51
|
+
Do not create a public backlog record when the report includes secrets, private code, private paths, customer data, full CI logs, unredacted SARIF, credential-handling details, command-execution vulnerability details, package publishing compromise, or MCP data exposure. Use [SECURITY.md](../../SECURITY.md) instead.
|
|
52
|
+
|
|
53
|
+
Run this after editing support backlog records:
|
|
54
|
+
|
|
55
|
+
```powershell
|
|
56
|
+
npm run support:check
|
|
57
|
+
```
|
|
@@ -0,0 +1,90 @@
|
|
|
1
|
+
[
|
|
2
|
+
{
|
|
3
|
+
"id": "docs-clarification-review",
|
|
4
|
+
"sourceRecord": "docs-clarification-backlog-record",
|
|
5
|
+
"reviewDecision": "remains-docs-clarification",
|
|
6
|
+
"outcome": "docs-example",
|
|
7
|
+
"cadence": "Review before a docs release or when the linked report-gallery example changes.",
|
|
8
|
+
"decisionCriteria": [
|
|
9
|
+
"The nearest checked report or docs page is still confusing for a fresh reader.",
|
|
10
|
+
"Observed output still matches current behavior and differs only in wording/context.",
|
|
11
|
+
"No rule behavior change is needed before clearer wording is tried."
|
|
12
|
+
],
|
|
13
|
+
"nextAction": "Keep the backlog item as a docs clarification and run the report/support checks after editing copy.",
|
|
14
|
+
"requiredChecks": [
|
|
15
|
+
"npm run reports:check",
|
|
16
|
+
"npm run support:check"
|
|
17
|
+
],
|
|
18
|
+
"privacyReview": [
|
|
19
|
+
"No secrets, private code, private paths, customer data, full logs, or unredacted SARIF are included.",
|
|
20
|
+
"Any stale private project names are replaced with placeholders before the review is recorded.",
|
|
21
|
+
"Sensitive reports are routed to SECURITY.md instead of public backlog review notes."
|
|
22
|
+
]
|
|
23
|
+
},
|
|
24
|
+
{
|
|
25
|
+
"id": "fixture-backlog-review",
|
|
26
|
+
"sourceRecord": "fixture-backlog-record",
|
|
27
|
+
"reviewDecision": "remains-fixture-backlog",
|
|
28
|
+
"outcome": "fixture-backlog",
|
|
29
|
+
"cadence": "Review before a fixture curation batch or when similar false-positive reports arrive.",
|
|
30
|
+
"decisionCriteria": [
|
|
31
|
+
"The smallest sanitized reproduction still describes a safe boundary worth preserving.",
|
|
32
|
+
"The rule id and redacted `jester tune <rule-id> --json` evidence still point at the same rule.",
|
|
33
|
+
"No existing pass or quiet-pass fixture now covers the same boundary."
|
|
34
|
+
],
|
|
35
|
+
"nextAction": "Keep the item as fixture backlog and add or update the redacted fixture before changing rule behavior.",
|
|
36
|
+
"requiredChecks": [
|
|
37
|
+
"npm run fixtures:check",
|
|
38
|
+
"npm run fixtures:report",
|
|
39
|
+
"npm run support:check"
|
|
40
|
+
],
|
|
41
|
+
"privacyReview": [
|
|
42
|
+
"No secrets, private code, private paths, customer data, full logs, or unredacted SARIF are included.",
|
|
43
|
+
"The reproduction still uses placeholders such as <repo>, <path>, or <redacted>.",
|
|
44
|
+
"Sensitive reports are routed to SECURITY.md instead of public backlog review notes."
|
|
45
|
+
]
|
|
46
|
+
},
|
|
47
|
+
{
|
|
48
|
+
"id": "rule-review-candidate-review",
|
|
49
|
+
"sourceRecord": "rule-review-candidate-backlog-record",
|
|
50
|
+
"reviewDecision": "remains-rule-review-candidate",
|
|
51
|
+
"outcome": "rule-review-candidate",
|
|
52
|
+
"cadence": "Review before changing guidance or matching, and whenever another sanitized report is linked.",
|
|
53
|
+
"decisionCriteria": [
|
|
54
|
+
"At least two sanitized reports or checked examples still point at the same rule boundary.",
|
|
55
|
+
"Fixture report or tune evidence still shows why docs clarification or a single fixture item is not enough.",
|
|
56
|
+
"The candidate still avoids changing matching without supporting fixtures around the boundary."
|
|
57
|
+
],
|
|
58
|
+
"nextAction": "Keep the item as a rule-review candidate and compare current fixture evidence before any behavior change.",
|
|
59
|
+
"requiredChecks": [
|
|
60
|
+
"npm run fixtures:report -- --markdown",
|
|
61
|
+
"npm run support:check"
|
|
62
|
+
],
|
|
63
|
+
"privacyReview": [
|
|
64
|
+
"No secrets, private code, private paths, customer data, full logs, or unredacted SARIF are included.",
|
|
65
|
+
"Repeated examples are summarized without exposing private project details.",
|
|
66
|
+
"Sensitive reports are routed to SECURITY.md instead of public backlog review notes."
|
|
67
|
+
]
|
|
68
|
+
},
|
|
69
|
+
{
|
|
70
|
+
"id": "closed-no-action-review",
|
|
71
|
+
"sourceRecord": "<backlog-record-id>",
|
|
72
|
+
"reviewDecision": "closed-no-action",
|
|
73
|
+
"outcome": "closed-no-action",
|
|
74
|
+
"cadence": "Review when evidence is stale, duplicated, no longer reproduces, or has already been resolved elsewhere.",
|
|
75
|
+
"decisionCriteria": [
|
|
76
|
+
"The report no longer reproduces on the current package or is already covered by a checked docs/fixture/rule-review artifact.",
|
|
77
|
+
"The remaining evidence is too thin, private, or security-sensitive for a public backlog item.",
|
|
78
|
+
"Closing the item will not hide a known regression because current checks still pass."
|
|
79
|
+
],
|
|
80
|
+
"nextAction": "Close the public backlog item with a short no-action note, link the replacement artifact if one exists, and keep sensitive details out of the thread.",
|
|
81
|
+
"requiredChecks": [
|
|
82
|
+
"npm run support:check"
|
|
83
|
+
],
|
|
84
|
+
"privacyReview": [
|
|
85
|
+
"No secrets, private code, private paths, customer data, full logs, or unredacted SARIF are included.",
|
|
86
|
+
"The closeout note uses placeholders instead of private project names or paths.",
|
|
87
|
+
"Sensitive reports are routed to SECURITY.md instead of public backlog review notes."
|
|
88
|
+
]
|
|
89
|
+
}
|
|
90
|
+
]
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
# Support Backlog Review
|
|
2
|
+
|
|
3
|
+
Use this when maintainers review public-safe backlog records over time. The checked source is [backlog-review.json](backlog-review.json). It pairs with [backlog-records.md](backlog-records.md), [outcome-prioritization.md](outcome-prioritization.md), and the [support lifecycle overview](support-lifecycle.md).
|
|
4
|
+
|
|
5
|
+
The review decision should keep each item in one of four states:
|
|
6
|
+
|
|
7
|
+
| Review decision | Source record | Keep when | Required checks |
|
|
8
|
+
| --- | --- | --- | --- |
|
|
9
|
+
| `remains-docs-clarification` | `docs-clarification-backlog-record` | wording or a checked report is still confusing | `npm run reports:check`, `npm run support:check` |
|
|
10
|
+
| `remains-fixture-backlog` | `fixture-backlog-record` | a minimized safe boundary still needs a pass or quiet-pass fixture | `npm run fixtures:check`, `npm run fixtures:report`, `npm run support:check` |
|
|
11
|
+
| `remains-rule-review-candidate` | `rule-review-candidate-backlog-record` | repeated sanitized reports still point at the same rule boundary | `npm run fixtures:report -- --markdown`, `npm run support:check` |
|
|
12
|
+
| `closed-no-action` | any backlog record | evidence is stale, duplicated, private, security-sensitive, or already resolved | `npm run support:check` |
|
|
13
|
+
|
|
14
|
+
## Review Flow
|
|
15
|
+
|
|
16
|
+
1. Re-read the original public-safe backlog record.
|
|
17
|
+
2. Confirm the linked docs, report-gallery example, fixture evidence, or rule guidance still exists.
|
|
18
|
+
3. Re-run the required checks for the current decision.
|
|
19
|
+
4. Choose one review decision: `remains-docs-clarification`, `remains-fixture-backlog`, `remains-rule-review-candidate`, or `closed-no-action`.
|
|
20
|
+
5. Record only the public-safe summary, next action, and check result.
|
|
21
|
+
|
|
22
|
+
## Decision Notes
|
|
23
|
+
|
|
24
|
+
Use `remains-docs-clarification` when current behavior is correct but the wording still makes a checked example hard to compare with local output.
|
|
25
|
+
|
|
26
|
+
Use `remains-fixture-backlog` when the smallest sanitized reproduction still describes a safe boundary worth preserving and no existing pass or quiet-pass fixture covers it.
|
|
27
|
+
|
|
28
|
+
Use `remains-rule-review-candidate` when at least two sanitized reports or checked examples still point at the same rule boundary and fixture evidence should be compared before any behavior change.
|
|
29
|
+
|
|
30
|
+
Use `closed-no-action` when the report no longer reproduces on the current package, has been resolved by another checked artifact, is too thin to act on, or should be routed through [SECURITY.md](../../SECURITY.md) instead of public backlog review.
|
|
31
|
+
|
|
32
|
+
## Privacy
|
|
33
|
+
|
|
34
|
+
Do not include secrets, private code, private paths, customer data, full CI logs, unredacted SARIF, credential-handling details, command-execution vulnerability details, package publishing compromise, or MCP data exposure in public backlog review notes. Use placeholders such as `<repo>`, `<path>`, or `<redacted>`, and route sensitive reports through [SECURITY.md](../../SECURITY.md).
|
|
35
|
+
|
|
36
|
+
Run this after editing support backlog review records:
|
|
37
|
+
|
|
38
|
+
```powershell
|
|
39
|
+
npm run support:check
|
|
40
|
+
```
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "memento-mori-jester",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.96",
|
|
4
4
|
"description": "A local court-jester sidecar for AI coding agents: review plans, commands, diffs, and final claims before they get too pleased with themselves.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"repository": {
|
|
@@ -94,6 +94,10 @@ for (const path of [
|
|
|
94
94
|
"examples/reports/feedback-template.md",
|
|
95
95
|
"examples/reports/report-gallery.json",
|
|
96
96
|
"examples/support/README.md",
|
|
97
|
+
"examples/support/backlog-review.md",
|
|
98
|
+
"examples/support/backlog-review.json",
|
|
99
|
+
"examples/support/backlog-records.md",
|
|
100
|
+
"examples/support/backlog-records.json",
|
|
97
101
|
"examples/support/closeout-checklist.md",
|
|
98
102
|
"examples/support/closeout-checklist.json",
|
|
99
103
|
"examples/support/outcome-prioritization.md",
|
|
@@ -136,6 +140,8 @@ requireText("README.md", /response-snippets\.md/, "support response snippets lin
|
|
|
136
140
|
requireText("README.md", /closeout-checklist\.md/, "support closeout checklist link");
|
|
137
141
|
requireText("README.md", /support-lifecycle\.md/, "support lifecycle overview link");
|
|
138
142
|
requireText("README.md", /outcome-prioritization\.md/, "support outcome prioritization link");
|
|
143
|
+
requireText("README.md", /backlog-review\.md/, "support backlog review link");
|
|
144
|
+
requireText("README.md", /backlog-records\.md/, "support backlog records link");
|
|
139
145
|
requireText("README.md", /report gallery feedback/i, "report gallery feedback guidance");
|
|
140
146
|
requireText("README.md", /License: PolyForm Noncommercial/, "the noncommercial license badge");
|
|
141
147
|
requireText("docs/PRODUCTION_READINESS.md", /npm package/i, "npm package readiness");
|
|
@@ -161,6 +167,8 @@ requireText("docs/PRODUCTION_READINESS.md", /response snippets/i, "support respo
|
|
|
161
167
|
requireText("docs/PRODUCTION_READINESS.md", /closeout checklist/i, "support closeout checklist readiness");
|
|
162
168
|
requireText("docs/PRODUCTION_READINESS.md", /support lifecycle overview/i, "support lifecycle overview readiness");
|
|
163
169
|
requireText("docs/PRODUCTION_READINESS.md", /outcome prioritization guide/i, "support outcome prioritization readiness");
|
|
170
|
+
requireText("docs/PRODUCTION_READINESS.md", /backlog review/i, "support backlog review readiness");
|
|
171
|
+
requireText("docs/PRODUCTION_READINESS.md", /backlog records/i, "support backlog records readiness");
|
|
164
172
|
requireText("docs/PRODUCTION_READINESS.md", /quiet-pass/, "quiet-pass fixture readiness");
|
|
165
173
|
requireText("docs/CLI.md", /jester doctor --json/, "doctor JSON CLI docs");
|
|
166
174
|
requireText("docs/CLI.md", /quiet-pass fixture/, "quiet-pass fixture CLI docs");
|
|
@@ -189,6 +197,8 @@ requireText("docs/MAINTAINER_TRIAGE.md", /response-snippets\.md/, "support respo
|
|
|
189
197
|
requireText("docs/MAINTAINER_TRIAGE.md", /closeout-checklist\.md/, "support closeout checklist link");
|
|
190
198
|
requireText("docs/MAINTAINER_TRIAGE.md", /support-lifecycle\.md/, "support lifecycle overview link");
|
|
191
199
|
requireText("docs/MAINTAINER_TRIAGE.md", /outcome-prioritization\.md/, "support outcome prioritization link");
|
|
200
|
+
requireText("docs/MAINTAINER_TRIAGE.md", /backlog-review\.md/, "support backlog review link");
|
|
201
|
+
requireText("docs/MAINTAINER_TRIAGE.md", /backlog-records\.md/, "support backlog records link");
|
|
192
202
|
requireText("docs/MAINTAINER_TRIAGE.md", /docs-example/, "docs example triage outcome");
|
|
193
203
|
requireText("docs/MAINTAINER_TRIAGE.md", /fixture-backlog/, "fixture backlog triage outcome");
|
|
194
204
|
requireText("docs/MAINTAINER_TRIAGE.md", /rule-review-candidate/, "rule review triage outcome");
|
|
@@ -225,6 +235,8 @@ requireText("examples/support/README.md", /response-snippets\.md/, "support resp
|
|
|
225
235
|
requireText("examples/support/README.md", /closeout-checklist\.md/, "support closeout checklist link");
|
|
226
236
|
requireText("examples/support/README.md", /support-lifecycle\.md/, "support lifecycle overview link");
|
|
227
237
|
requireText("examples/support/README.md", /outcome-prioritization\.md/, "support outcome prioritization link");
|
|
238
|
+
requireText("examples/support/README.md", /backlog-review\.md/, "support backlog review link");
|
|
239
|
+
requireText("examples/support/README.md", /backlog-records\.md/, "support backlog records link");
|
|
228
240
|
requireText("examples/support/README.md", /docs-example/, "support triage docs outcome");
|
|
229
241
|
requireText("examples/support/README.md", /fixture-backlog/, "support triage fixture outcome");
|
|
230
242
|
requireText("examples/support/README.md", /rule-review-candidate/, "support triage rule-review outcome");
|
|
@@ -262,6 +274,27 @@ requireText("examples/support/outcome-prioritization.md", /at least two sanitize
|
|
|
262
274
|
requireText("examples/support/outcome-prioritization.json", /docs-clarification-closeout/, "support outcome prioritization docs closeout");
|
|
263
275
|
requireText("examples/support/outcome-prioritization.json", /fixture-backlog-closeout/, "support outcome prioritization fixture closeout");
|
|
264
276
|
requireText("examples/support/outcome-prioritization.json", /rule-review-closeout/, "support outcome prioritization rule-review closeout");
|
|
277
|
+
requireText("examples/support/backlog-records.md", /Support Backlog Records/, "support backlog records heading");
|
|
278
|
+
requireText("examples/support/backlog-records.md", /backlog-records\.json/, "support backlog records JSON link");
|
|
279
|
+
requireText("examples/support/backlog-records.md", /docs-clarification-backlog-record/, "support docs backlog record");
|
|
280
|
+
requireText("examples/support/backlog-records.md", /fixture-backlog-record/, "support fixture backlog record");
|
|
281
|
+
requireText("examples/support/backlog-records.md", /rule-review-candidate-backlog-record/, "support rule-review backlog record");
|
|
282
|
+
requireText("examples/support/backlog-records.md", /jester tune <rule-id> --json/, "support backlog tuning evidence");
|
|
283
|
+
requireText("examples/support/backlog-records.md", /SECURITY\.md/, "support backlog security redirect");
|
|
284
|
+
requireText("examples/support/backlog-records.json", /docs-clarification-backlog-record/, "support docs backlog record JSON");
|
|
285
|
+
requireText("examples/support/backlog-records.json", /fixture-backlog-record/, "support fixture backlog record JSON");
|
|
286
|
+
requireText("examples/support/backlog-records.json", /rule-review-candidate-backlog-record/, "support rule-review backlog record JSON");
|
|
287
|
+
requireText("examples/support/backlog-review.md", /Support Backlog Review/, "support backlog review heading");
|
|
288
|
+
requireText("examples/support/backlog-review.md", /backlog-review\.json/, "support backlog review JSON link");
|
|
289
|
+
requireText("examples/support/backlog-review.md", /remains-docs-clarification/, "support docs backlog review decision");
|
|
290
|
+
requireText("examples/support/backlog-review.md", /remains-fixture-backlog/, "support fixture backlog review decision");
|
|
291
|
+
requireText("examples/support/backlog-review.md", /remains-rule-review-candidate/, "support rule-review backlog review decision");
|
|
292
|
+
requireText("examples/support/backlog-review.md", /closed-no-action/, "support closed no-action review decision");
|
|
293
|
+
requireText("examples/support/backlog-review.md", /SECURITY\.md/, "support backlog review security redirect");
|
|
294
|
+
requireText("examples/support/backlog-review.json", /docs-clarification-review/, "support docs backlog review JSON");
|
|
295
|
+
requireText("examples/support/backlog-review.json", /fixture-backlog-review/, "support fixture backlog review JSON");
|
|
296
|
+
requireText("examples/support/backlog-review.json", /rule-review-candidate-review/, "support rule-review backlog review JSON");
|
|
297
|
+
requireText("examples/support/backlog-review.json", /closed-no-action-review/, "support closed no-action review JSON");
|
|
265
298
|
requireText("examples/tuning/README.md", /framework-tuning-cookbook\.json/, "framework tuning cookbook JSON link");
|
|
266
299
|
requireText("examples/tuning/README.md", /framework:tuning:doctor/, "framework tuning doctor guidance");
|
|
267
300
|
requireText("examples/tuning/README.md", /jester tune <rule-id> --json|jester tune [a-z0-9-]+ --json/, "framework tuning command guidance");
|
|
@@ -299,6 +332,8 @@ requireText("scripts/check-support-triage.mjs", /response-snippets\.json/, "supp
|
|
|
299
332
|
requireText("scripts/check-support-triage.mjs", /closeout-checklist\.json/, "support closeout checklist guard");
|
|
300
333
|
requireText("scripts/check-support-triage.mjs", /support-lifecycle\.json/, "support lifecycle overview guard");
|
|
301
334
|
requireText("scripts/check-support-triage.mjs", /outcome-prioritization\.json/, "support outcome prioritization guard");
|
|
335
|
+
requireText("scripts/check-support-triage.mjs", /backlog-records\.json/, "support backlog records guard");
|
|
336
|
+
requireText("scripts/check-support-triage.mjs", /backlog-review\.json/, "support backlog review guard");
|
|
302
337
|
requireText("scripts/check-support-triage.mjs", /unsafeContentPatterns/, "support triage unsafe content checks");
|
|
303
338
|
requireText("package.json", /"fixtures:check": "node scripts\/check-fixtures\.mjs"/, "fixture authoring check script");
|
|
304
339
|
requireText("package.json", /"fixtures:report": "node scripts\/report-fixtures\.mjs"/, "fixture coverage report script");
|
|
@@ -25,6 +25,10 @@ const supportFiles = [
|
|
|
25
25
|
".github/ISSUE_TEMPLATE/config.yml",
|
|
26
26
|
"examples/reports/feedback-template.md",
|
|
27
27
|
"examples/reports/README.md",
|
|
28
|
+
"examples/support/backlog-review.md",
|
|
29
|
+
"examples/support/backlog-review.json",
|
|
30
|
+
"examples/support/backlog-records.md",
|
|
31
|
+
"examples/support/backlog-records.json",
|
|
28
32
|
"examples/support/closeout-checklist.md",
|
|
29
33
|
"examples/support/closeout-checklist.json",
|
|
30
34
|
"examples/support/outcome-prioritization.md",
|
|
@@ -84,6 +88,8 @@ requireText("examples/reports/README.md", /npm run support:check/, "support chec
|
|
|
84
88
|
requireText("examples/reports/README.md", /examples\/support|Maintainer Triage Playbook/i, "maintainer triage playbook link");
|
|
85
89
|
|
|
86
90
|
requireText("examples/support/README.md", /Maintainer Triage Playbook/, "maintainer playbook heading");
|
|
91
|
+
requireText("examples/support/README.md", /backlog-review\.md/, "support backlog review link");
|
|
92
|
+
requireText("examples/support/README.md", /backlog-records\.md/, "support backlog records link");
|
|
87
93
|
requireText("examples/support/README.md", /support-lifecycle\.md/, "support lifecycle overview link");
|
|
88
94
|
requireText("examples/support/README.md", /outcome-prioritization\.md/, "support outcome prioritization link");
|
|
89
95
|
requireText("examples/support/README.md", /closeout-checklist\.md/, "support closeout checklist link");
|
|
@@ -139,6 +145,39 @@ requireText("examples/support/outcome-prioritization.md", /SECURITY\.md/, "prior
|
|
|
139
145
|
requireText("examples/support/outcome-prioritization.json", /docs-clarification-closeout/, "docs prioritization closeout");
|
|
140
146
|
requireText("examples/support/outcome-prioritization.json", /fixture-backlog-closeout/, "fixture prioritization closeout");
|
|
141
147
|
requireText("examples/support/outcome-prioritization.json", /rule-review-closeout/, "rule-review prioritization closeout");
|
|
148
|
+
requireText("examples/support/backlog-records.md", /Support Backlog Records/, "support backlog records heading");
|
|
149
|
+
requireText("examples/support/backlog-records.md", /backlog-records\.json/, "support backlog records JSON link");
|
|
150
|
+
requireText("examples/support/backlog-records.md", /support lifecycle overview/, "support lifecycle backlog link");
|
|
151
|
+
requireText("examples/support/backlog-records.md", /outcome prioritization guide/, "support prioritization backlog link");
|
|
152
|
+
requireText("examples/support/backlog-records.md", /closeout checklist/, "support closeout backlog link");
|
|
153
|
+
requireText("examples/support/backlog-records.md", /docs-clarification-backlog-record/, "docs backlog record");
|
|
154
|
+
requireText("examples/support/backlog-records.md", /fixture-backlog-record/, "fixture backlog record");
|
|
155
|
+
requireText("examples/support/backlog-records.md", /rule-review-candidate-backlog-record/, "rule-review backlog record");
|
|
156
|
+
requireText("examples/support/backlog-records.md", /docs-example/, "docs backlog outcome");
|
|
157
|
+
requireText("examples/support/backlog-records.md", /fixture-backlog/, "fixture backlog outcome");
|
|
158
|
+
requireText("examples/support/backlog-records.md", /rule-review-candidate/, "rule-review backlog outcome");
|
|
159
|
+
requireText("examples/support/backlog-records.md", /jester tune <rule-id> --json/, "tune JSON backlog evidence");
|
|
160
|
+
requireText("examples/support/backlog-records.md", /SECURITY\.md/, "backlog security redirect");
|
|
161
|
+
requireText("examples/support/backlog-records.md", /npm run support:check/, "support checker backlog command");
|
|
162
|
+
requireText("examples/support/backlog-records.json", /docs-clarification-backlog-record/, "docs backlog record JSON");
|
|
163
|
+
requireText("examples/support/backlog-records.json", /fixture-backlog-record/, "fixture backlog record JSON");
|
|
164
|
+
requireText("examples/support/backlog-records.json", /rule-review-candidate-backlog-record/, "rule-review backlog record JSON");
|
|
165
|
+
requireText("examples/support/backlog-review.md", /Support Backlog Review/, "support backlog review heading");
|
|
166
|
+
requireText("examples/support/backlog-review.md", /backlog-review\.json/, "support backlog review JSON link");
|
|
167
|
+
requireText("examples/support/backlog-review.md", /backlog-records\.md/, "support backlog records review link");
|
|
168
|
+
requireText("examples/support/backlog-review.md", /outcome-prioritization\.md/, "support prioritization review link");
|
|
169
|
+
requireText("examples/support/backlog-review.md", /support lifecycle overview/, "support lifecycle review link");
|
|
170
|
+
requireText("examples/support/backlog-review.md", /remains-docs-clarification/, "docs clarification review decision");
|
|
171
|
+
requireText("examples/support/backlog-review.md", /remains-fixture-backlog/, "fixture backlog review decision");
|
|
172
|
+
requireText("examples/support/backlog-review.md", /remains-rule-review-candidate/, "rule-review review decision");
|
|
173
|
+
requireText("examples/support/backlog-review.md", /closed-no-action/, "closed no-action review decision");
|
|
174
|
+
requireText("examples/support/backlog-review.md", /jester tune <rule-id> --json|fixture evidence|quiet-pass fixture/, "review fixture evidence guidance");
|
|
175
|
+
requireText("examples/support/backlog-review.md", /SECURITY\.md/, "review security redirect");
|
|
176
|
+
requireText("examples/support/backlog-review.md", /npm run support:check/, "support checker review command");
|
|
177
|
+
requireText("examples/support/backlog-review.json", /docs-clarification-review/, "docs review record JSON");
|
|
178
|
+
requireText("examples/support/backlog-review.json", /fixture-backlog-review/, "fixture review record JSON");
|
|
179
|
+
requireText("examples/support/backlog-review.json", /rule-review-candidate-review/, "rule-review review record JSON");
|
|
180
|
+
requireText("examples/support/backlog-review.json", /closed-no-action-review/, "closed no-action review record JSON");
|
|
142
181
|
requireText("examples/support/response-snippets.md", /Maintainer Response Snippets/, "response snippets heading");
|
|
143
182
|
requireText("examples/support/response-snippets.md", /response-snippets\.json/, "response snippets JSON link");
|
|
144
183
|
requireText("examples/support/response-snippets.md", /docs-example/, "docs response outcome");
|
|
@@ -156,6 +195,8 @@ requireText("docs/MAINTAINER_TRIAGE.md", /report_gallery_feedback\.yml/, "report
|
|
|
156
195
|
requireText("docs/MAINTAINER_TRIAGE.md", /examples\/support/, "maintainer playbook triage link");
|
|
157
196
|
requireText("docs/MAINTAINER_TRIAGE.md", /support-lifecycle\.md/, "support lifecycle triage link");
|
|
158
197
|
requireText("docs/MAINTAINER_TRIAGE.md", /outcome-prioritization\.md/, "support prioritization triage link");
|
|
198
|
+
requireText("docs/MAINTAINER_TRIAGE.md", /backlog-review\.md/, "support backlog review triage link");
|
|
199
|
+
requireText("docs/MAINTAINER_TRIAGE.md", /backlog-records\.md/, "support backlog records triage link");
|
|
159
200
|
requireText("docs/MAINTAINER_TRIAGE.md", /closeout-checklist\.md/, "support closeout checklist triage link");
|
|
160
201
|
requireText("docs/MAINTAINER_TRIAGE.md", /response-snippets\.md/, "maintainer response snippets triage link");
|
|
161
202
|
requireText("docs/MAINTAINER_TRIAGE.md", /docs-example/, "docs example triage outcome");
|
|
@@ -166,6 +207,8 @@ requireText("docs/PRODUCTION_READINESS.md", /support:check/, "support checker re
|
|
|
166
207
|
requireText("README.md", /feedback-template\.md/, "feedback template README link");
|
|
167
208
|
requireText("README.md", /support-lifecycle\.md/, "support lifecycle README link");
|
|
168
209
|
requireText("README.md", /outcome-prioritization\.md/, "support prioritization README link");
|
|
210
|
+
requireText("README.md", /backlog-review\.md/, "support backlog review README link");
|
|
211
|
+
requireText("README.md", /backlog-records\.md/, "support backlog records README link");
|
|
169
212
|
requireText("README.md", /closeout-checklist\.md/, "support closeout checklist README link");
|
|
170
213
|
requireText("README.md", /examples\/support/, "maintainer triage playbook README link");
|
|
171
214
|
requireText("README.md", /response-snippets\.md/, "maintainer response snippets README link");
|
|
@@ -179,6 +222,8 @@ checkResponseSnippets();
|
|
|
179
222
|
checkCloseoutChecklist();
|
|
180
223
|
checkSupportLifecycle();
|
|
181
224
|
checkOutcomePrioritization();
|
|
225
|
+
checkBacklogRecords();
|
|
226
|
+
checkBacklogReview();
|
|
182
227
|
|
|
183
228
|
if (failures.length > 0) {
|
|
184
229
|
console.error("Support triage check failed:");
|
|
@@ -665,3 +710,236 @@ function checkOutcomePrioritization() {
|
|
|
665
710
|
}
|
|
666
711
|
}
|
|
667
712
|
}
|
|
713
|
+
|
|
714
|
+
function checkBacklogRecords() {
|
|
715
|
+
const path = "examples/support/backlog-records.json";
|
|
716
|
+
const records = readJson(path);
|
|
717
|
+
if (!records) {
|
|
718
|
+
return;
|
|
719
|
+
}
|
|
720
|
+
|
|
721
|
+
if (!Array.isArray(records) || records.length !== 3) {
|
|
722
|
+
failures.push(`${path} should contain exactly three support backlog records.`);
|
|
723
|
+
return;
|
|
724
|
+
}
|
|
725
|
+
|
|
726
|
+
const expected = [
|
|
727
|
+
{
|
|
728
|
+
id: "docs-clarification-backlog-record",
|
|
729
|
+
outcome: "docs-example",
|
|
730
|
+
priority: "low",
|
|
731
|
+
sourceCloseout: "docs-clarification-closeout",
|
|
732
|
+
backlogType: "docs clarification",
|
|
733
|
+
checks: ["npm run reports:check", "npm run support:check"],
|
|
734
|
+
evidence: ["Nearest checked report", "Observed output", "No rule behavior change"]
|
|
735
|
+
},
|
|
736
|
+
{
|
|
737
|
+
id: "fixture-backlog-record",
|
|
738
|
+
outcome: "fixture-backlog",
|
|
739
|
+
priority: "medium",
|
|
740
|
+
sourceCloseout: "fixture-backlog-closeout",
|
|
741
|
+
backlogType: "pass or quiet-pass fixture",
|
|
742
|
+
checks: ["npm run fixtures:check", "npm run fixtures:report", "npm run support:check"],
|
|
743
|
+
evidence: ["Smallest sanitized", "jester tune <rule-id> --json", "existing pass or quiet-pass fixture"]
|
|
744
|
+
},
|
|
745
|
+
{
|
|
746
|
+
id: "rule-review-candidate-backlog-record",
|
|
747
|
+
outcome: "rule-review-candidate",
|
|
748
|
+
priority: "high",
|
|
749
|
+
sourceCloseout: "rule-review-closeout",
|
|
750
|
+
backlogType: "rule-review candidate",
|
|
751
|
+
checks: ["npm run fixtures:report -- --markdown", "npm run support:check"],
|
|
752
|
+
evidence: ["At least two sanitized", "fixture report evidence", "single fixture backlog item is not enough"]
|
|
753
|
+
}
|
|
754
|
+
];
|
|
755
|
+
const seenIds = new Set();
|
|
756
|
+
|
|
757
|
+
for (const [index, record] of records.entries()) {
|
|
758
|
+
const expectedRecord = expected[index];
|
|
759
|
+
if (record?.id !== expectedRecord.id) {
|
|
760
|
+
failures.push(`${path} entry ${index + 1} should have id ${expectedRecord.id}.`);
|
|
761
|
+
continue;
|
|
762
|
+
}
|
|
763
|
+
|
|
764
|
+
if (seenIds.has(record.id)) {
|
|
765
|
+
failures.push(`${path} has duplicate id ${record.id}.`);
|
|
766
|
+
}
|
|
767
|
+
seenIds.add(record.id);
|
|
768
|
+
|
|
769
|
+
if (record.outcome !== expectedRecord.outcome) {
|
|
770
|
+
failures.push(`${record.id}.outcome should be ${expectedRecord.outcome}.`);
|
|
771
|
+
}
|
|
772
|
+
|
|
773
|
+
if (record.priority !== expectedRecord.priority) {
|
|
774
|
+
failures.push(`${record.id}.priority should be ${expectedRecord.priority}.`);
|
|
775
|
+
}
|
|
776
|
+
|
|
777
|
+
if (record.sourceCloseout !== expectedRecord.sourceCloseout) {
|
|
778
|
+
failures.push(`${record.id}.sourceCloseout should be ${expectedRecord.sourceCloseout}.`);
|
|
779
|
+
}
|
|
780
|
+
|
|
781
|
+
if (record.prioritizationSource !== "outcome-prioritization.json") {
|
|
782
|
+
failures.push(`${record.id}.prioritizationSource should be outcome-prioritization.json.`);
|
|
783
|
+
}
|
|
784
|
+
|
|
785
|
+
if (record.backlogType !== expectedRecord.backlogType) {
|
|
786
|
+
failures.push(`${record.id}.backlogType should be ${expectedRecord.backlogType}.`);
|
|
787
|
+
}
|
|
788
|
+
|
|
789
|
+
if (typeof record.publicTitle !== "string" || record.publicTitle.length < 20) {
|
|
790
|
+
failures.push(`${record.id}.publicTitle should be a useful public title.`);
|
|
791
|
+
}
|
|
792
|
+
|
|
793
|
+
if (typeof record.publicSummary !== "string" || record.publicSummary.length < 50) {
|
|
794
|
+
failures.push(`${record.id}.publicSummary should be a useful public summary.`);
|
|
795
|
+
}
|
|
796
|
+
|
|
797
|
+
if (typeof record.nextAction !== "string" || record.nextAction.length < 40) {
|
|
798
|
+
failures.push(`${record.id}.nextAction should describe the backlog action.`);
|
|
799
|
+
}
|
|
800
|
+
|
|
801
|
+
if (!Array.isArray(record.evidence) || record.evidence.length !== 3) {
|
|
802
|
+
failures.push(`${record.id}.evidence should contain exactly three evidence items.`);
|
|
803
|
+
} else {
|
|
804
|
+
const evidenceText = record.evidence.join("\n");
|
|
805
|
+
for (const expectedEvidence of expectedRecord.evidence) {
|
|
806
|
+
if (!evidenceText.includes(expectedEvidence)) {
|
|
807
|
+
failures.push(`${record.id}.evidence should include ${expectedEvidence}.`);
|
|
808
|
+
}
|
|
809
|
+
}
|
|
810
|
+
}
|
|
811
|
+
|
|
812
|
+
if (!Array.isArray(record.privacyReview) || record.privacyReview.length !== 3) {
|
|
813
|
+
failures.push(`${record.id}.privacyReview should contain exactly three privacy checks.`);
|
|
814
|
+
} else {
|
|
815
|
+
const privacyText = record.privacyReview.join("\n");
|
|
816
|
+
if (!/secret|private|SECURITY\.md|redacted|placeholder/i.test(privacyText)) {
|
|
817
|
+
failures.push(`${record.id}.privacyReview should include privacy and security routing guidance.`);
|
|
818
|
+
}
|
|
819
|
+
}
|
|
820
|
+
|
|
821
|
+
if (!Array.isArray(record.requiredChecks)) {
|
|
822
|
+
failures.push(`${record.id}.requiredChecks should be an array.`);
|
|
823
|
+
continue;
|
|
824
|
+
}
|
|
825
|
+
|
|
826
|
+
for (const check of expectedRecord.checks) {
|
|
827
|
+
if (!record.requiredChecks.includes(check)) {
|
|
828
|
+
failures.push(`${record.id}.requiredChecks should include ${check}.`);
|
|
829
|
+
}
|
|
830
|
+
}
|
|
831
|
+
}
|
|
832
|
+
}
|
|
833
|
+
|
|
834
|
+
function checkBacklogReview() {
|
|
835
|
+
const path = "examples/support/backlog-review.json";
|
|
836
|
+
const reviews = readJson(path);
|
|
837
|
+
if (!reviews) {
|
|
838
|
+
return;
|
|
839
|
+
}
|
|
840
|
+
|
|
841
|
+
if (!Array.isArray(reviews) || reviews.length !== 4) {
|
|
842
|
+
failures.push(`${path} should contain exactly four support backlog review decisions.`);
|
|
843
|
+
return;
|
|
844
|
+
}
|
|
845
|
+
|
|
846
|
+
const expected = [
|
|
847
|
+
{
|
|
848
|
+
id: "docs-clarification-review",
|
|
849
|
+
sourceRecord: "docs-clarification-backlog-record",
|
|
850
|
+
reviewDecision: "remains-docs-clarification",
|
|
851
|
+
outcome: "docs-example",
|
|
852
|
+
checks: ["npm run reports:check", "npm run support:check"],
|
|
853
|
+
criteria: ["nearest checked report", "Observed output", "No rule behavior change"]
|
|
854
|
+
},
|
|
855
|
+
{
|
|
856
|
+
id: "fixture-backlog-review",
|
|
857
|
+
sourceRecord: "fixture-backlog-record",
|
|
858
|
+
reviewDecision: "remains-fixture-backlog",
|
|
859
|
+
outcome: "fixture-backlog",
|
|
860
|
+
checks: ["npm run fixtures:check", "npm run fixtures:report", "npm run support:check"],
|
|
861
|
+
criteria: ["smallest sanitized reproduction", "jester tune <rule-id> --json", "pass or quiet-pass fixture"]
|
|
862
|
+
},
|
|
863
|
+
{
|
|
864
|
+
id: "rule-review-candidate-review",
|
|
865
|
+
sourceRecord: "rule-review-candidate-backlog-record",
|
|
866
|
+
reviewDecision: "remains-rule-review-candidate",
|
|
867
|
+
outcome: "rule-review-candidate",
|
|
868
|
+
checks: ["npm run fixtures:report -- --markdown", "npm run support:check"],
|
|
869
|
+
criteria: ["At least two sanitized", "Fixture report or tune evidence", "supporting fixtures"]
|
|
870
|
+
},
|
|
871
|
+
{
|
|
872
|
+
id: "closed-no-action-review",
|
|
873
|
+
sourceRecord: "<backlog-record-id>",
|
|
874
|
+
reviewDecision: "closed-no-action",
|
|
875
|
+
outcome: "closed-no-action",
|
|
876
|
+
checks: ["npm run support:check"],
|
|
877
|
+
criteria: ["no longer reproduces", "private, or security-sensitive", "current checks still pass"]
|
|
878
|
+
}
|
|
879
|
+
];
|
|
880
|
+
const seenIds = new Set();
|
|
881
|
+
|
|
882
|
+
for (const [index, review] of reviews.entries()) {
|
|
883
|
+
const expectedReview = expected[index];
|
|
884
|
+
if (review?.id !== expectedReview.id) {
|
|
885
|
+
failures.push(`${path} entry ${index + 1} should have id ${expectedReview.id}.`);
|
|
886
|
+
continue;
|
|
887
|
+
}
|
|
888
|
+
|
|
889
|
+
if (seenIds.has(review.id)) {
|
|
890
|
+
failures.push(`${path} has duplicate id ${review.id}.`);
|
|
891
|
+
}
|
|
892
|
+
seenIds.add(review.id);
|
|
893
|
+
|
|
894
|
+
if (review.sourceRecord !== expectedReview.sourceRecord) {
|
|
895
|
+
failures.push(`${review.id}.sourceRecord should be ${expectedReview.sourceRecord}.`);
|
|
896
|
+
}
|
|
897
|
+
|
|
898
|
+
if (review.reviewDecision !== expectedReview.reviewDecision) {
|
|
899
|
+
failures.push(`${review.id}.reviewDecision should be ${expectedReview.reviewDecision}.`);
|
|
900
|
+
}
|
|
901
|
+
|
|
902
|
+
if (review.outcome !== expectedReview.outcome) {
|
|
903
|
+
failures.push(`${review.id}.outcome should be ${expectedReview.outcome}.`);
|
|
904
|
+
}
|
|
905
|
+
|
|
906
|
+
if (typeof review.cadence !== "string" || review.cadence.length < 40) {
|
|
907
|
+
failures.push(`${review.id}.cadence should explain when to review the backlog item.`);
|
|
908
|
+
}
|
|
909
|
+
|
|
910
|
+
if (typeof review.nextAction !== "string" || review.nextAction.length < 50) {
|
|
911
|
+
failures.push(`${review.id}.nextAction should describe the maintainer action.`);
|
|
912
|
+
}
|
|
913
|
+
|
|
914
|
+
if (!Array.isArray(review.decisionCriteria) || review.decisionCriteria.length !== 3) {
|
|
915
|
+
failures.push(`${review.id}.decisionCriteria should contain exactly three criteria.`);
|
|
916
|
+
} else {
|
|
917
|
+
const criteriaText = review.decisionCriteria.join("\n");
|
|
918
|
+
for (const expectedCriterion of expectedReview.criteria) {
|
|
919
|
+
if (!criteriaText.includes(expectedCriterion)) {
|
|
920
|
+
failures.push(`${review.id}.decisionCriteria should include ${expectedCriterion}.`);
|
|
921
|
+
}
|
|
922
|
+
}
|
|
923
|
+
}
|
|
924
|
+
|
|
925
|
+
if (!Array.isArray(review.privacyReview) || review.privacyReview.length !== 3) {
|
|
926
|
+
failures.push(`${review.id}.privacyReview should contain exactly three privacy checks.`);
|
|
927
|
+
} else {
|
|
928
|
+
const privacyText = review.privacyReview.join("\n");
|
|
929
|
+
if (!/secret|private|SECURITY\.md|redacted|placeholder/i.test(privacyText)) {
|
|
930
|
+
failures.push(`${review.id}.privacyReview should include privacy and security routing guidance.`);
|
|
931
|
+
}
|
|
932
|
+
}
|
|
933
|
+
|
|
934
|
+
if (!Array.isArray(review.requiredChecks)) {
|
|
935
|
+
failures.push(`${review.id}.requiredChecks should be an array.`);
|
|
936
|
+
continue;
|
|
937
|
+
}
|
|
938
|
+
|
|
939
|
+
for (const check of expectedReview.checks) {
|
|
940
|
+
if (!review.requiredChecks.includes(check)) {
|
|
941
|
+
failures.push(`${review.id}.requiredChecks should include ${check}.`);
|
|
942
|
+
}
|
|
943
|
+
}
|
|
944
|
+
}
|
|
945
|
+
}
|