TFD-0029: Consolidate Edward (agent-ea talent) onto the v4 D1-First Engine

TFD-0029: Consolidate Edward (agent-ea talent) onto the v4 D1-First Engine

Status: Accepted — one v4-native EA representation; canonical source = B (factory talent); persona names are factory-internal only (deployments carry no persona name). CEO-confirmed 2026-05-30. Date: 2026-05-30 Decision makers: CEO (Bruno) Consulted: Francois (Framework / engine owner), Philippe (Consulting), Diego (Deployment Specialist), Edward (EA talent — subject) Refines: TFD-0019, TFD-0024, TFD-0025

Context

On 2026-05-30 the v4 D1-first engine was built and proven end-to-end (production-lines/agent-ea/: schema + Macroscope template pack + thin .mjs pipeline + engagement playbook; Phases A+B, commits 436db25, 65c6e18, 0700614; 5 tests green on real DAE-0007 data). See spec/plan docs/superpowers/{specs,plans}/2026-05-30-agent-ea-v2-lean*.

That rebuild scoped only the catalog→publish machinery. The v2-lean spec mentions ea:leanix-catalog-extract twice (to upgrade it to v4) and never mentions the deployed talent — Edward, /ea-hlsd, the 8-stage skill chain, diagram-generate, ea-livrable-assembler, or ea-publish-jct. As a result the two drifted:

Edward today (talents/agent-ea-v2/agent.md) v4 engine (built today)
Catalog schema LeanIX v3.1 LeanIX v4
Diagram /toolkit:diagram-generate (CSV→HTML) —
Deliverable single livrable.html → JCT Macroscope A100–A270 from data.js, D1 handover bundle

This is not a designed divergence — the talent was left behind. Edward is the WO-0001 deliverable (STM EA agent handover), which is the factory's #1 revenue blocker (production-line-strategy). Shipping STM a talent the factory has already deprecated internally is unacceptable.

The canonical direction is unambiguous: the v2-lean plan indexes the v1 assets (WO-0001/0002, CON-0008, MET-*) as "superseded by production-lines/agent-ea"; the schema-migration note states "no active DAE should still use v1–v3 CSVs"; memory ea-catalog-architecture records the D1 model "replaces CSV→HTML."

Decision

There is one Enterprise Architecture representation: Edward, v4-native. The factory-owned engine (production-lines/agent-ea/) is not a parallel product — it is Edward's back end.

  • Front half retained — stages 1–4 (ea-exigences-note, -note-revue, human RÉPONSE, ea-exigences-intrant) and the /ea-hlsd orchestrator + quality gates. The engine has no intake front end; this is the part only Edward provides.
  • Catalog step retained, upgraded — /ea:leanix-catalog-extract stays, but emits v4. CSV remains the human-correctable intermediate (per manipulable-output-format); D1 loads from the validated CSV. D1 is the source of record.
  • Back half rewired — stages 6–8 are replaced by the v4 pipeline: export-datajs (D1→data.js) → publish (Macroscope A-code templates) → d1-export (handover bundle). The .mjs scripts become Edward's tools.
  • Retired — /toolkit:diagram-generate as a standalone stage and /ea-livrable-assembler (single livrable.html) fold into publish. /ea-publish-jct keeps its concept (commit→Cloudflare→JSM) but publishes the Macroscope page set + handover bundle, not a lone livrable.html.
  • Sequencing — Edward migrates to v4 before the STM (WO-0001) handover (TFD-0029 §Actions). The v4 work is already done and proven, so the migration is a rewire, not new build.

Options Considered

Option Verdict
A — Merge: Edward becomes v4-native, single representation Accepted — one source of truth, no drift surface, foundry/self-run preserved via d1-export.
B — Two representations with a boundary (Edward self-serve v3.1-light; engine for factory engagements) Rejected — maintaining two EA chains with a fuzzy boundary is exactly the failure mode being cleaned up here. Every v4 change would need a parallel Edward change; the first miss recreates this drift.
C — Retire Edward; deliver EA only as a factory consulting engagement Rejected — Edward is the WO-0001 STM handover deliverable, the #1 revenue blocker. No deployable EA talent contradicts the foundry model (delivery-model-foundry-not-hosted).

Rationale

  • Eliminates the drift surface. One chain, one schema, one publish path. The bug that triggered this TFD becomes structurally impossible.
  • Foundry model preserved. d1-export already produces {client}.sqlite + CSV "so the client can self-run" — merging does not sacrifice client autonomy; it upgrades it.
  • STM gets the better talent. v4 is built and proven; STM receives a current, Macroscope-grade deliverable instead of a frozen v3.1 chain.
  • Engine stops being an orphan. Today the .mjs pipeline has no user-facing front end; Edward gives it intake + orchestration + gates.

Actions

  1. ✅ Record this decision as TFD-0029-consolidate-edward-onto-v4-engine.md.
  2. Write the migration plan: docs/superpowers/plans/2026-05-30-edward-v4-migration.md (phased, checkbox steps).
  3. Upgrade /ea:leanix-catalog-extract to emit v4 (CSV intermediate → seed D1).
  4. Rewire Edward stages 6–8 → export-datajs → publish (Macroscope) → d1-export; retire diagram-generate/ea-livrable-assembler as standalone stages; repoint ea-publish-jct.
  5. Update talent docs: agent.md skill-chain table, CLAUDE.md, MODEL-CONFIG.md, role.md, README.md.
  6. Re-validate the merged chain end-to-end on DAE-0007 (already v4); confirm parity with the engine pipeline.
  7. Package WO-0001 with the v4-native Edward; update the deployment manifest. Then proceed to STM handover.
  8. Update memories agent-ea-v2, ea-catalog-architecture, production-line-strategy to reflect the merge.
  9. Resume the deferred work that prompted the discovery: regenerate Edward's how-it-works diagram against the merged v4 chain.

Consequences

  • WO-0001 STM handover waits on the migration (Action 1–7). Per 2A, this is the accepted sequence: migrate first, hand over second.
  • The v1/v3.1 chain (diagram-generate → livrable.html) is frozen; no new DAE uses it.
  • /ea:leanix-catalog-extract is shared between "Edward the talent" and "factory engagement" usage — there is now only one consumer model (v4), so no fork.
  • The how-it-works diagram prototype that surfaced this drift (C:/tmp/diagram-examples/agent-ea-admin.html) is superseded — it documented the engine pipeline, not the merged talent chain. Redraw after migration (Action 9).
  • This TFD does not move client data; TFD-0025 partition is unaffected.

Addendum (2026-05-30, same day) — the real topology is FOUR copies, not two

Discovered while mapping for execution (a parallel ceo-brief session had been working this same area today: model bumps Opus 4.7→4.8 6a1eaca, handover-agenda v2, STATUS.md, and the WO-0001 re-validation checklist). The "Edward vs engine" framing above was incomplete. Actual state:

Tag Path Persona Skills Structure Status
A production-lines/agent-ea/ — (engine) .mjs pipeline, v4/D1 — built today
B production-lines/digital-talent/talents/agent-ea-v2/ Edward 7 (ea-*) flat factory build home; thinnest copy; this session's Phase 1–3 edits target it
C orders/WO-0001-stm-ea-agent/output/v2-skills/ — (delta) archi-cible tiers + hlsd + patches — upgrade delta, deploys into D
D OneDrive - STM/agent-ea/ Arnaud 17 (/ea:*) demandes-ae/{CLIENT}/PROG-/DAE LIVE deployed product, edited today, still has Confluence back half

Conflicts beyond the schema version:

  1. Persona name: B = "Edward", D = "Arnaud" (client-facing). Same talent, two names.
  2. Folder convention: D uses demandes-ae/{CLIENT}/PROG-/DAE-NNNN; TFD-0025 mandates clients/{client}/DAE-NNNN. D predates/ignores it.
  3. Skill surface (CORRECTED): B has 7, D has 17 — but D's extra 10 (archi-catalogue, archi-extraction, qualite-validation, commun-diagramme, diagramme-hautniveau, changement-solution, commun-publication, a100-a280-page, plus changement-couts/changement-feuilleroute/qualite-cra/archi-orientation) are the v1 skill set that v2 deliberately RETIRED (memory's documented "Dropped from v1": replaced by the shared /ea:leanix-catalog-extract, the A engine, /toolkit:diagram-generate; four others explicitly deferred to v2.1). B is lean by design, NOT incomplete. Pulling D's skills into B would regress B to v1. The only genuine v2 skill B currently lacks is ea-archi-cible (the tiered target-architecture skill, which lives in C).
  4. D is the v1 product mid-upgrade, not "the most complete v2 product." Front half partly namespaced/v4; back half still v1/Confluence. The migration direction is D → B's lean v2 design, not B → D.

Recommended single source of truth (CONFIRMED 2026-05-30: B canonical; persona names factory-internal only — STM deployment carries no persona name)

Make B the canonical factory source (correct home = digital-talent production line; repo-tracked). Corrected consolidation:

  1. Do NOT pull D's 17 skills into B — that regresses to v1. Keep B's lean v2 skill set.
  2. Fold only ea-archi-cible + its tier templates (from C) into B — the one real v2 skill B lacks.
  3. Apply the v4 back-half rewire — this session's Phase 1–3 edits already did this and stand (B is canonical).
  4. Re-deploy B's lean design onto D, dropping D's 10 retired v1 skills + Confluence (commun-publication), adopting the TFD-0025 folder convention, keeping D's client DATA (DAE-0001..0010). Strip persona "Arnaud" from D (deployments carry no persona name).
  5. Wire A (engine) as B's back end (already done in the command-file edits).
  6. Thereafter B → deploy → D (OneDrive) → STM, one-directional; D stops being independently edited.

Collapses 4 copies + 1 engine → 1 factory source + 1 deployment + 1 engine back-end. The migration plan 2026-05-30-edward-v4-migration.md expands to cover steps 2 + 4 (it currently covers 3 + 5).

References

  • 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
  • TFD-0019 — EA Catalog Storage & Delivery Model · TFD-0024 — Rendering Layer Ownership · TFD-0025 — Per-Client Source Partition
  • Memory: agent-ea-v2, ea-catalog-architecture, delivery-model-foundry-not-hosted, production-line-strategy, stm-opportunities, manipulable-output-format