engagement-codex-deploy¶
The deploy edition of the Engagement Codex. It renders the
Solution Thesis for an engagement, in four tones, from the
archaeology folder that rosetta-archaeology-deploy writes. It runs in
Claude Code inside an engagement repository, needs no network, and
never writes to Rosetta.
| Version | 0.1.1 |
| Command | /engagement-codex-deploy:solution-thesis-render |
| Skill | solution-thesis-render |
| Reads | <ENGAGEMENT_DIR>/archaeology/ and the library at the repository root |
| Writes | <ENGAGEMENT_DIR>/deliverables/ only |
| Tools | Read, Write, Edit, Glob, Grep |
Quick start¶
At the root of an engagement repository (a clone of rosetta-deploy cut
from a release tag, with customer/<customer>/ filled from
customer/_template/), after the archaeology edition has passed at
least Phase 3:
/engagement-codex-deploy:solution-thesis-render ENGAGEMENT_DIR=customer/<customer>
/engagement-codex-deploy:solution-thesis-render ENGAGEMENT_DIR=customer/<customer> TONE=seller
/engagement-codex-deploy:solution-thesis-render ENGAGEMENT_DIR=customer/<customer> TONE=customer
/engagement-codex-deploy:solution-thesis-render ENGAGEMENT_DIR=customer/<customer> TONE=leadership
Optional: LIBRARY_DIR=<path> (when the library is not an ancestor of
the engagement folder), PRIOR=<file> (the prior render to supersede
against), --reset-rhetorical (fresh §1 / §2.0 after a backup), and
--as-of=YYYY-MM-DD (the run date).
Allow it to read its own files. The rules, references and templates
live in the plugin's folder, outside your repository. On the first run
Claude Code asks to read that folder: allow it, or add the folder to the
session once with /add-dir.
What it renders, and from what¶
The Solution Thesis is the executive story of an engagement: the
evidence, the readiness verdict, the recommendation. It is rendered,
not authored: every rendered: true section is projected from the
archaeology record, and re-rendering after the record changes brings
the document up to date. Hand-edits to those sections are discarded on
the next render (and kept in a backup). The rhetorical sections — §1
Future Announcement and §2.0 Thesis Statement — are drafted by the
renderer and become the seller's own the moment the seller edits them.
The one source is <ENGAGEMENT_DIR>/archaeology/:
| Input | File |
|---|---|
| Context Artifacts and how they depend on each other, DecisionTraces, promotion state, readiness node, forensic metrics | archaeology/twin.json |
| Eleven-dimension readiness verdict, ruled-out library patterns | archaeology/research/classification-readiness-verdict.md |
| BusinessIntents, org topology | archaeology/research/survey-brief.md |
| Findings, components, anti-patterns | archaeology/research/excavation-inventory.md |
| Knowledge-gap queries | archaeology/site-package/queries/knowledge-gap-queries.md |
| Evidence class of each dossier file | archaeology/site-package/manifest.md |
| Phase status (the gate record) | archaeology/MANIFEST.md |
Some fields the source codex read are not in the archaeology record
(stakeholder names, finding severity, a gap list with owners and
costs, off-ramp conditions, the POV duration). The render treats each
as a gap the seller answers, or leaves the section out with a
warning; skills/solution-thesis-render/references/archaeology-inputs.md
§3.1 lists them.
Library ids the record cites (cp-g-014, ADR-G-003, …) resolve
against the library at the repository root: release-manifest.json
must list the id and the file must exist. The audit tone cites each by
path and id (CP/cp-g-014.md, cp-g-014). Content from a library file
marked "Draft — not SME-reviewed; advisory only." is labelled advisory
in every tone.
Without an archaeology folder that has passed Phase 3, the render stops and tells you to run the archaeology edition first.
Where it writes¶
<ENGAGEMENT_DIR>/deliverables/
├── solution-thesis.<tone>.md <tone> ∈ audit | seller | customer | leadership
├── solution-thesis.<tone>.<YYYY-MM-DD>.md byte-identical dated sibling, one per day
├── solution-thesis.<tone>.bak.<YYYY-MM-DD>.md the prior render, on supersession
└── RENDER-LOG.md one row per render: tone, date, inputs, result, warnings
Do not edit RENDER-LOG.md or the dated siblings: together they are the render ledger the supersession contract reads.
The four tones¶
| Tone | Audience | Gap discipline | Front matter |
|---|---|---|---|
audit (default) |
Internal / reviewer only — the internal diagnostic surface. Never hand it to an AE/SE or a customer. | «TBD-N» inline + a closing inventory |
visible YAML |
seller |
AE/SE working document | [from customer: <description>] inline + an answers table the seller fills |
HTML comment |
customer |
Customer deliverable | none allowed: HARD FAIL on any gap | none |
leadership |
Decision room | «to confirm» + one consolidated table; an 11-section decision-brief spine |
HTML comment |
The audit tone is the deterministic Pass 1. The seller, customer and leadership tones get a narrative Pass 2 — an executive summary first, plumbing moved to a colophon, internal ids moved to a traceability appendix, gaps written as named asks in one "What we need from you" box — under a conformance lint that falls back to the Pass-1 output if the prose changed any fact.
The customer hard fail¶
A customer render succeeds only when nothing is open. A gap is a value
the record does not carry (for example the POV duration, the CTA
owner, a stakeholder name) or a value carried by a node marked
provenance: simulated. On any gap the render writes no customer file,
prints the gap list, and adds a FAILED row to RENDER-LOG.md. The fix:
- Render the seller tone.
- In
deliverables/solution-thesis.seller.md, fill the Answer cell of each row in the "What we need from you" table. - Render the customer tone again.
Gaps that come from the record itself — a library id that does not resolve, a simulated node — are fixed by re-running the archaeology phase that wrote them, not in the seller file.
Supersession¶
Rendering a tone again supersedes its prior render, the file
deliverables/solution-thesis.<tone>.md (or the file named by
PRIOR=<file>). The prior file is classified and backed up:
- Mode 1 — §1 or §2.0 header renamed or missing: a warning, a backup, the section re-resolved.
- Mode 2 — a hand-edit to a rendered section: a warning, a backup, the section re-rendered from the record.
- Mode 3 — front-matter drift: the file is kept as
.failed.<date>, the active file is not touched, the render stops. - Mode 4 — no drift: a backup, then the new render.
Seller-authored §1 / §2.0 prose and the seller's answers carry forward
across renders and tones. --reset-rhetorical drafts §1 / §2.0 fresh
(after the backup).
What stays with Rosetta¶
This edition renders the Solution Thesis only. The SOW and the Spec Manifest are compiled by Rosetta; there is no template, tone or command for them here. The thesis still names them where it hands off (§6.3 Spec Manifest section reservations, §8 questions parked for the SOW).
Lineage¶
- Adapted from
engagement-codex0.12.0 (solution-thesis-renderskill 0.7.0) in rosetta-platform. Kept: the four tones and templates, the two-pass render and its lint, the«TBD-N»numbering, the customer hard fail and the string-sentinel scan, the leadership«to confirm»consolidation, the §1 / §2.0 drafting rules, the Mermaid composition, the tone vocabulary discipline, the narrative style, and the defensive parser. - Changed: one source (the archaeology folder) in place of the live graph and run bundles; supersession keyed on the prior render file; the draft and hand-edit checks read a render ledger instead of a hash; per-engagement vocabulary read from the record; the seller's answers table as the home of customer-side data.
- Dropped: the live path and source selection, the bundle zip input, the SOW and Spec Manifest renders, the browser-runtime contract, and the deferred fallback runtime.
- Built under rosetta-platform work packet E3-S5-WP25 and rosetta-deploy
SM-RDEP-001 E3-S3-WP2. The source lives in rosetta-platform
util/plugins/engagement-codex-deploy/and is copied into rosetta-deployplugins/engagement-codex-deploy/by a reviewed pull request.
License¶
Proprietary (UNLICENSED). The publisher is named in
.claude-plugin/plugin.json.
This page as Markdown — for pasting into Claude or another assistant · llms.txt