Skip to content

rosetta-archaeology-deploy

Project Archaeology for an engagement, from the library alone. Four phases turn an engagement's discovery dossier into its digital twin: three-layer Context Artifacts, v1.3 DecisionTraces, an eleven-dimension readiness verdict with the Data 360 advisory dimensions, a delivery spine, and the learnings the engagement could give back to the library. Everything is written as files in the engagement folder.

  • Version: 0.1.2 (CHANGES.md)
  • Skill: digital-twin-archaeology (the whole pipeline)
  • Commands: run-all, survey, excavate, classify, preserve
  • License: Proprietary, © 2026 Keenan Vision LLC

Where it runs

In Claude Code, at the root of an engagement repository: a clone of rosetta-deploy cut from a release tag, with the engagement in customer/<customer>/, filled from customer/_template/ (see customer/_template/README.md in the library). The library sits at the repository root, at the tag the engagement was cut from.

The edition uses the Read, Write, Edit, Glob and Grep tools. It needs no shell, no network and no connection to Rosetta, and works when none of them is available.

Allow it to read its own files. The phase steps, 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. A run that cannot read them stops before Phase 1 rather than guess at a schema.

What it reads

  • The library, read-only: the generated folders CP/, ADR/, BI/, EF/, PO/, SE/ and VT/, their README.md indexes, release-manifest.json (the release's source line and the files map) and rosetta.yaml (the release tag and the domains it covers). The library root is found by walking up from the engagement folder to the folder that holds release-manifest.json and rosetta.yaml, or given as LIBRARY_DIR. A library whose statusOverride is set is a pre-flight projection, not a release, and the run stops.
  • The discovery dossier, read-only: customer/<customer>/project-docs/, or DOSSIER=<path>. Any file the Read tool can open. A file it cannot open is listed as unread, never guessed at.

What it writes

Only under the engagement folder (ENGAGEMENT_DIR):

<ENGAGEMENT_DIR>/
├── archaeology/
│   ├── MANIFEST.md                 the run manifest, rewritten by every phase
│   ├── twin.json                   the engagement twin: the record the codex deploy edition reads
│   ├── proposed-learnings.md       Phase 4: learnings for you to send back, if you choose
│   ├── CHECKLIST.md                Phase 4: your review checklist
│   ├── research/                   the review notes, one or two per phase
│   └── site-package/               the Site Package (Manual Chapter 15), dossier listed, not copied
├── CP/CA-<ENG>-NN.md               Phase 3: a draft per Context Artifact
└── ADR/DT-<ENG>-NN.md              Phase 3 and 4: a draft per DecisionTrace

It never edits the dossier, a library file, background/, terminology/ or deliverables/, and never writes outside the engagement folder. The drafts in CP/ and ADR/ are views of twin.json: edit the twin, then re-run Phase 3.

Commands

Command Does
/rosetta-archaeology-deploy:run-all All four phases in one session; halts at the first failed gate. Start here.
/rosetta-archaeology-deploy:survey Phase 1: Business Intent, org topology, the inheritance tree from the library
/rosetta-archaeology-deploy:excavate Phase 2: evidence inventory, Site Package, anti-pattern catalog
/rosetta-archaeology-deploy:classify Phase 3: Context Artifacts, DecisionTraces, readiness verdict, drafts
/rosetta-archaeology-deploy:preserve Phase 4: promotion assessment, proposed learnings, delivery spine, checklist

Every command takes the same arguments:

<engagement-key> ENGAGEMENT_DIR=<path> [LIBRARY_DIR=<path>] [DOSSIER=<path>] [--autonomous] [--as-of=YYYY-MM-DD]

For example, with a fictional engagement:

/rosetta-archaeology-deploy:run-all acme-01 ENGAGEMENT_DIR=customer/acme
  • <engagement-key>: a lowercase slug, required, never guessed.
  • ENGAGEMENT_DIR: the engagement folder, required.
  • --autonomous: draft every authored field without pausing (below).
  • --as-of: the run date; otherwise the session's date.

A phase command runs only when the previous phase's gate is recorded as passed in archaeology/MANIFEST.md.

Emit review

Three kinds of field are authored, never boilerplate: each Context Artifact's purpose, each DecisionTrace's leadershipGloss, and each delivery-spine node's purpose. By default the run drafts them from the evidence, shows them to you, and waits: it writes what you confirm or rewrite, marked human-ratified. With --autonomous (for unattended runs and tests) it writes its drafts without pausing, marked agent-authored, and MANIFEST.md lists every one as pending your review. It never writes an empty value.

What this edition does not do

The source plugin did This edition
Was handed a repo zip, the Manual, a dossier zip and per-phase bundles Reads the engagement repository: the library at its root, the dossier in project-docs/, the state in archaeology/
Read canonical content from the live graph or a content snapshot Reads library files only (CP/ ADR/ BI/ EF/ PO/ SE/ VT/, the indexes, release-manifest.json)
Wrote a graph-load review stack (00- to 30- files) Writes twin.json
Wrote a leaf KnowledgeDomain with domain keys Identifies the engagement by its key and folder
Wrote a Client and Engagement block and ran the existing-client check Names the engagement and customer in the twin.json header, as the dossier gives them
Applied the twin in Phase 4 (publish, engagement create) Ends with files in the folder
Wrote a partner certification request and eval and validation checklists Writes proposed-learnings.md and archaeology/CHECKLIST.md
Rendered a seller Solution Thesis in Phases 3 and 4 Renders no customer document; the codex deploy edition renders the thesis
Shipped a separate inheritance-tree command and skill Renders the inheritance tree as a Phase 1 step
Took target and publish flags, wrote provenance events and partition edges None of these

Two constraints it keeps

  • C-4: the library reads without Rosetta. The edition answers from files in the release. It needs no network and no Rosetta server, and it never writes to Rosetta.
  • C-6: knowledge is distributed; compile methods are not. The edition renders no customer document. The Solution Thesis is rendered from this folder by the codex deploy edition; the SOW and the Spec Manifest are compiled by Rosetta.

Sending a learning back

Phase 4 writes archaeology/proposed-learnings.md: one section per promotion candidate, written generalized, in the five fields the library's contributions/README.md asks for. Nothing is sent without you. Work through its before-you-send checklist (remove customer names, customer data, people's names and credentials; one learning per issue or file), then open an issue or add one file under contributions/ in the library repository. The library repository is mirrored and every reader sees it.

Lineage

  • Adapted from rosetta-archaeology 0.13.1, the Rosetta edition of Project Archaeology (Manual v1.3).
  • Sources in rosetta-platform util/plugins/rosetta-archaeology-deploy/, work packet E3-S5-WP25; copied into rosetta-deploy plugins/rosetta-archaeology-deploy/ by a reviewed pull request.
  • rosetta-deploy SM-RDEP-001 work packet E3-S3-WP1. Its companion is the codex deploy edition, engagement-codex-deploy (E3-S3-WP2), which renders the Solution Thesis from the folder this edition writes.

This page as Markdown — for pasting into Claude or another assistant · llms.txt