# 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 | `/archaeology/` and the library at the repository root | | Writes | `/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//` filled from `customer/_template/`), after the archaeology edition has passed at least Phase 3: ``` /engagement-codex-deploy:solution-thesis-render ENGAGEMENT_DIR=customer/ /engagement-codex-deploy:solution-thesis-render ENGAGEMENT_DIR=customer/ TONE=seller /engagement-codex-deploy:solution-thesis-render ENGAGEMENT_DIR=customer/ TONE=customer /engagement-codex-deploy:solution-thesis-render ENGAGEMENT_DIR=customer/ TONE=leadership ``` Optional: `LIBRARY_DIR=` (when the library is not an ancestor of the engagement folder), `PRIOR=` (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 `/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 ``` /deliverables/ ├── solution-thesis..md ∈ audit | seller | customer | leadership ├── solution-thesis...md byte-identical dated sibling, one per day ├── solution-thesis..bak..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: ]` 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: 1. Render the seller tone. 2. In `deliverables/solution-thesis.seller.md`, fill the Answer cell of each row in the "What we need from you" table. 3. 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..md` (or the file named by `PRIOR=`). 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.`, 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-codex` 0.12.0 (`solution-thesis-render` skill 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-deploy `plugins/engagement-codex-deploy/` by a reviewed pull request. ## License Proprietary (`UNLICENSED`). The publisher is named in `.claude-plugin/plugin.json`.