Best Version — Agent-EA v2 Engagement Playbook

Best Version — Agent-EA v2 Engagement Playbook

Iteration: #1 · Score: 12/12 · Date: 2026-05-31 Mirrors the live target ../engagement.md at its highest-scoring state. If the live file is edited, re-run auto-research and refresh this snapshot.

Agent-EA v2 — Engagement Playbook

How to run a lean, D1-first EA engagement end to end. The deliverable is unchanged from the transgesco build: LeanIX v4 catalogs → Macroscope A-code pages, published as an editorial client portal. What's disciplined here is the flow and the gates.

Golden rule: D1 is the source of truth. Data is corrected in the catalog (CSV → D1), never in the HTML. Every page is regenerable from D1 alone.

Stages & gates

Stage Exit gate Owner
Scope (Routing) Engagement type chosen → A-code bundle selected (see Contract scoping — Routing below) Consulting (intake)
Contract Deliverable list (subset of A-codes) locked and a per-page data contract signed for each Consulting
Model Client D1 seeded; LeanIX v4 validation passes; orphan-relations query clean EA modeler
Publish Every contracted page generated from data.js; review panel live Engine / Framework (Francois)
Review Client corrections resolved in D1; delta republished; each page status accepté Consulting + client
Handover D1 export bundle ({client}.sqlite + CSV) delivered; client can self-run Consulting

Running the automated stages (commands)

The three script stages run from pipeline/ (zero deps; node:sqlite needs Node ≥ 22.5). Full quickstart: ../README.md.

cd pipeline
# Model    — load schema + seeds into SQLite, report counts (validation gate)
node seed.mjs --schema ../schema/leanix-v4.sql --seed-dir <seedDir> --db <client>.sqlite
# Publish  — Layer-1 export + Layer-2 copy + token-filled templates (does NOT push)
node publish.mjs examples/<client>.manifest.json
# Handover — portable bundle: {client}.sqlite + catalogs/objects/relations CSV
node d1-export.mjs --db <client>.sqlite --out <bundle-dir>

Then git push the out/ folder to the client's Cloudflare Pages repo (jct-{client}). Contract and Review are human gates — no script. Corrections from Review re-enter D1 and rerun publish for the delta.

Adding a mandate to an existing client: re-enter at Contract with a new deliverable subset. The new mandate is one (or more) new catalog row(s) with a fresh dae value in the same client DB — never a new database. Templates and pipeline are reused as-is.

Contract scoping — engagement Routing (do this first)

Before locking the deliverable list, route the request to an engagement type. Not every A-code is needed for every mandate (Macroscope rule: adapt the method to context). The engagement type selects the A-code bundle, which then drives the per-page data contracts below.

Preliminary questions asked on every new request:

  1. Engagement type? — pick one (or a custom subset):

    Engagement type A-code bundle
    Current-state assessment (AS-IS) A140, A200, A250, A251, A170, A370, A620
    Target-state design + roadmap A130, A240, A230, A100, A280, A270 (+ AS-IS socle)
    Application portfolio rationalization A250, A200, A620, A100, A280, A290
    Organizational change program A140, A275, A280, A715, A270
    Custom hand-pick the relevant A-codes

  2. Deliverable list confirmed? — lock the exact A-code subset (this is the Contract exit gate above).

  3. Per-page data contract — fill the checklist below for each contracted page.

A-code reference: code meanings (A140 Context · A130 Scenarios · A240 Requirements · A200 Capabilities · A230 Orientation · A250 Applications · A251 Processes · A170 Information · A370 Technology · A100 Solution · A280 Impacts · A290 Costs · A270 Roadmap · A275 Org change · A620 Evaluation) are canonical in ../../digital-talent/frameworks/enterprise-architecture/macroscope/framework-guide.md. Use the Macroscope names with the client; LeanIX field keys internally.

Pattern (Ada catalog): this is Routing at the head of the pipeline, feeding Prompt Chaining (the stages) guarded by Quality Gates + Approval Gates, over a Shared State (D1). DAE-0007 Transgesco was a hybrid: AS-IS assessment + partial target-state (A250, catalogue-changements, A100, A230, A270).

The merged publish model (resolves the old contradiction)

v1 had two competing specs: TFD-0022 (review panel) and the 2026-05-22 EA Site Delivery Standard. In v2 they are one flow, not two:

  • The 2026-05-22 standard is the Contract → Publish process above.
  • TFD-0022's review panel is simply the correction mechanism inside the Review stage.
  • Because D1 is the source of truth, "corrections enter D1, not HTML" is automatic. No conflict remains.

Per-page data contract (checklist template)

For each contracted A-code page, fill before leaving Contract:

  • Page: A___ — <title>
  • Source catalog(s): <catalog code(s)> in the client DB
  • Object types consumed: e.g. CAP, PRO, APP, ITC, CO
  • Required fields per object: (the attrs keys the page renders — e.g. crit, dec, opex)
  • Data owner (client side): named person/direction who signs the data
  • Workshop source: date + attendees (stored in object notes / attrs.src)
  • Gaps policy: objects flagged attrs.gap=true render on the gaps view (derived, not hand-listed)

Catalog conventions (bind to these — don't invent fields)

  • Objects vs changement organisationnel are separate catalogs (kind='object' vs kind='co'). CO is strictly change-by-object; change_type rides the object↔CO junction.
  • Delivery / AO / Epics are NOT in the CO catalog. EA hierarchy: Initiative > Projet (PRJ noun phrase) > Epic (verb+object); objects link to Epics via epicId FK.
  • Gaps are derived: attrs.gap=true, a CO row with no resolving Epic, or an object marked "À compléter".

Acceptance proof (v2 done criteria)

Recorded here after Phase B B6: the Transgesco follow-on mandate ran Contract→Publish on its deliverable subset using only the template pack + pipeline, with zero per-client HTML hand-editing.

✅ Parity gate PASSED (2026-05-31) — Edward-v4 migration Phase 4. DAE-0007 run through the engine publish.mjs (renderer-adapter build) produced 273 objects → 4 Macroscope pages. Verified empirically:

  • Talent == engine (structural): ea-hlsd v4 stages 6–8 delegate directly to export-datajs.mjs / publish.mjs / d1-export.mjs (Bash) — the talent never hand-renders; the engine is the single deterministic renderer.
  • Determinism: two independent publish runs → all 9 output files byte-identical.
  • Verbatim editorial layer: out/data.js === source curated data.js (byte-for-byte) — no editorial mutation by the pipeline.
  • Zero hand-editing: every generated HTML page === its token-filled template (only {{CLIENT}}/{{DAE}}/{{HOST}} substituted), confirming no per-client manual edits.
  • Durable backup: Layer-1 catalog-data.js generated alongside, independent of output format.

Harness: ad-hoc Node parity check over examples/transgesco-dae-0007.manifest.json; regression locked by pipeline/publish.test.mjs (suite 8/8 green).

References & open issues

  • Spec / plan: docs/superpowers/specs/2026-05-30-agent-ea-v2-lean-design.md · docs/superpowers/plans/2026-05-30-agent-ea-v2-lean.md
  • Engine: ../README.md (layout, quickstart, status) · schema ../schema/leanix-v4.sql
  • Open — change-org model duplication: reconcile D1 TES-CO vs editorial PROJ/CHG before a new mandate relies on the changes view. Tracked in README "Remaining".
  • Open — seed location: canonical client seeds = OneDrive/clients/{slug}/dae-NNNN/ (TFD-0025); the worked example points at experiments/dae-catalog-d1 (proof only).