PRISM v2.15.0 → v2.19.0 — the promotion arc (Foundations → Core-slimming)

[Ronkupper]

Five releases land together as one dependency-ordered arc — consolidating a live engagement's learnings into the framework, then slimming the core that carries them. All on main, each at its own signed tag (GitHub-verified) and GitHub Release. The framework stays a single attachable markdown file (PRISM.md) that also installs as a Claude Skill; the Lens Library is unchanged at v0.15.

The arc

v2.15.0 — Foundations

SP-21 (trust structure / self-report advisory) + SP-22 (surface translation); the retrieved | inferred finding-basis axis; filename-authoritative vendor reconciliation; SP-16 visual channel, SP-10 widened, SP-13 self-ID note; defects D1/D2/D3/D5; M10-rerun vs Follow-up; M2 clobbered-pointer tie-break; Setup stakeholder-positioning; Setup-artifact re-audit; accumulate-never-overwrite.

v2.16.0 — Operating-model backbone

the lanes / roles model; PRISM Desk (Planner/Steward) + PRISM Meta standing lanes with the PRISM UI and <Lane>-<N> numbering; the append-only cross-lane OPEN_ITEMS inbox + commit-discipline; bundle-load integrity; SETUP_ONBOARDING (Setup-generated SI + two-project model) and SETUP_QUICKMODE; M5 self-banding; the /prism-meta command.

v2.17.0 — Dispatch round-trip

the dispatch lifecycle (five stages, build → reconcile) names the round-trip end-to-end; late-bound build (pass spec, not a frozen Envelope); a proactive return-handling card + failure leg routed by type; a unique Dispatch ID paired with the copy-through digest for exact-instance reconciliation; the fanned-IVD adjudicate-by-re-derivation refinement; passive pre-fill of self-report; the agentic-browser driver class; a new reference/dispatch-conventions.md bundle; and a transport-integrity bracket (top anchor + terminal sentinel + Self-check Step 0) that catches a mid-stream-truncated paste before the execution session works.

v2.18.0 — Lifecycle & deliverables

the symmetric engagement closure gate (three-layer close sweep bookending three-layer readiness; orphan-sweep, reconcile-at-close, deliverable polish); the comprehensive final report + interactive workbook + presentation house-style codified in a new reference/report-architecture.md bundle; deliverable bump-atomicity (shipped == validated); the external-share family (one-repo-per-engagement, de-coded share archive, share modes, image-redaction) in a new reference/external-share.md bundle with a read-the-repo-not-the-mirror SP-8 tie; and a multi-lane session-legibility operator guide.

v2.19.0 — Core-slimming refactor

a projection-only, behavior-preserving packaging change that sheds the phase-scoped mechanics (Setup, currency, continuity, corpus-access) into four new on-demand bundles keyed to the role that needs them — a ~24% leaner resident core — with fail-loud in-core trigger stubs + an SP-4 self-check, the §3.7.6 phase→bundle manifest, and a minimal in-core recovery floor so a resuming session is never stranded; the execution-hot spine stays resident. Folds in an Appendix C tag-count hygiene fix.

The shape of it

2.15 lays the Standing-Principle and defect-fix foundations → 2.16 adds the lanes / Desk operating backbone → 2.17 makes the dispatch round-trip symmetric and named end-to-end → 2.18 closes the engagement lifecycle and codifies the deliverable → 2.19 slims the core that now carries all of it (projection-only, behavior-preserving). Additive throughout — no construct renumbering.

Get it

• Single file: PRISM.md — or the version-pinned PRISM_v2_19_0.md.
• Claude Skill plugin: plugins/prism — a lean always-loaded core + on-demand reference bundles.
• All releases & tags: https://github.com/Ronkupper/PRISM/releases · release process: RELEASING.md.

Calibration — worth reporting back from real runs

• Does filename-authoritative reconciliation (SP-21) absorb vendor self-ID drift without false halts?
• Does the lanes / Desk model stay invisible to the operator (the net-helpful bar)?
• Does the unique Dispatch ID close re-dispatch reconciliation ambiguity without operator friction?
• Does the engagement-closure gate catch loose ends (un-drained inboxes, shipped≠validated) before "done"?
• Do the in-core trigger stubs + SP-4 self-check reliably load the right bundle at the right moment, and does the leaner core measurably lower M5 context pressure?

Built across five sessions; signed commits + tags, verified through the GitHub API.