TFD-0025: Agent-EA Source Folder — Per-Client Partition

TFD-0025: Agent-EA Source Folder — Per-Client Partition

Status: Accepted Date: 2026-05-27 Decision makers: CEO (Oscar / Bruno board) Consulted: Elena (Enterprise Architect), Diego (Deployment Specialist), Camille (Client Intake Manager), Ivan (Infrastructure Engineer — author TFD-0019), Nora (Nomenclature Specialist), Pablo (Production Line Architect) Refines: TFD-0019 (storage isolation), TFD-0010

Context

OneDrive - STM\agent-ea\demandes-ae\ is currently a flat directory mixing 10 DAEs across at least 2 distinct customers :

  • DAE-0007 = Transgesco (a separate customer from STM, with its own IT-autonomy / PL-104 / LCOM compliance posture — confirmed in TFD-0019 §1)
  • DAE-0001 (Vigie), DAE-0006, DAE-0008, DAE-0010 = STM
  • DAE-0001-exemple is a template, not a real DAE
  • DAE-0002/3/4/5/9 = to be re-classified per actual customer

The folder name itself (OneDrive - STM) is misleading because it hosts Transgesco content. TFD-0019 already enforces hard isolation at the storage layer (1 D1 per customer, separate Pages, no cross-customer queries, naming = customer slug). The source layer must mirror that boundary or the storage decision is undermined (an operator could upload a Transgesco DAE into the STM D1 by accident — silent compliance breach).

A second naming inconsistency surfaced: CON-0005-sdm-automatisation-fiches-cadenassage in the factory is mislabeled — the real customer is STM (PLB Ligne Bleue extension); SDM appears to be the vendor on site. To be re-titled in a separate PR (not part of this TFD).

Decision

Adopt per-client folder partition inside the existing OneDrive root:

OneDrive - STM\agent-ea\
  clients/
    transgesco/
      dae-0007-evaluation-systemes/
      ...
    stm/
      dae-0001-vigie-technique/
      dae-0006-processus-mandat/
      dae-0008-rr-plan-directeur/
      dae-0010-convention-collective/
      ...
  _templates/
    dae-0001-exemple/         (template — re-classed out of /clients/ since it has no real customer)
  _shared/                    (cross-client tooling, conventions, scripts if any)

Each clients/<slug>/ is treated as a hard partition — no cross-references across client folders, no scripts that enumerate clients/*/dae-*/ without explicit per-client iteration, and packaging exports always scope to one client folder.

The OneDrive root may be renamed later from OneDrive - STM to OneDrive - EA (or similar) — cosmetic action, deferred (forces a OneDrive re-sync for the operator). Until renamed, the path is treated as the factory's EA workspace, not a STM-owned space.

Options Considered

Option Verdict
A — Mono-client : one OneDrive per customer Rejected — heavy migration, dual-OneDrive overhead, loses factory-side template/tooling mutualisation. Would re-emerge if scale grows past ~5 customers, but premature now.
B — Multi-client with clients/{slug}/ partition Accepted — aligns TFD-0019 at the source layer, retains factory economy of scale, light migration.
C — Flat structure + mandatory client: frontmatter Rejected — conflicts with TFD-0019 hard isolation, metadata easily forgotten or falsified, path remains misleading, structural accident recurs at every new customer. Operational vetoes from Camille and Diego.

Rationale

  • TFD-0019 alignment without cost duplication. TFD-0019 mandates per-customer hard isolation at the storage layer (D1, Pages). Option B mirrors that isolation at the source layer via explicit partition, without forcing two OneDrive accounts. Each clients/<slug>/ maps 1-1 to its D1 customer.
  • Factory economy of scale preserved. Macroscope rendering templates (MET-0008), CSV→D1→Pages scripts, PDF exporters all live under _shared/ (factory-level) and serve every customer. Option A would duplicate this layer.
  • Lightweight migration. Move 10 folders under clients/{slug}/, update hardcoded path references via grep-replace. No re-sync of OneDrive root. No code rewrites beyond path strings.

Actions

  1. ✅ Renumber the colliding TFD-0022-rendering-layer-ownership to TFD-0024; downstream files updated.
  2. Write this decision as TFD-0025-agent-ea-client-folder-partition.md.
  3. Classify each DAE-NNNN by its actual customer (table below — to be confirmed with Bruno before moving).
  4. Execute the OneDrive migration: mv DAE-NNNN-{slug} clients/{customer}/dae-NNNN-{slug} per row.
  5. grep-replace hardcoded demandes-ae/DAE-XXXX/ paths in repo + portail mirrors.
  6. Update memory client-solution-structure to reflect the new path standard.
  7. Update memory note agent-ea-client-structure-issue → mark resolved.
  8. ✅ Done same day: renamed CON-0005-sdm-automatisation-fiches-cadenassage → CON-0005-stm-plb-cadenassage-automatisation (request.md title updated, client correctly identified as STM PLB).
  9. Followup (deferred): rename OneDrive root OneDrive - STM → OneDrive - EA once stable.

Migration mapping (provisional — to confirm before move)

DAE Slug actuel Client présumé À confirmer ?
DAE-0001-exemple template (template, hors clients/) déplacer vers _templates/
DAE-0001-vigie-technique vigie-technique STM (Vigie) oui
DAE-0002-azure-vs-sap-integration azure-vs-sap STM ? oui
DAE-0003-acte-portee-v2 acte-portee-v2 STM ? oui
DAE-0004-scada-ignition scada-ignition STM ? oui
DAE-0005-electrification electrification STM ? oui
DAE-0006-processus-mandat processus-mandat STM oui
DAE-0007-trangesco-evaluation-systemes trangesco Transgesco confirmé
DAE-0008-rr-plan-directeur rr-plan-directeur STM (CSA) oui
DAE-0009-modele-donnees-maitresses mdm STM ? oui
DAE-0010-convention-collective convention-collective STM oui

Consequences

  • OneDrive - STM\agent-ea\demandes-ae\ becomes OneDrive - STM\agent-ea\clients\ (or stays as transitional alias).
  • Every new client engagement triggers mkdir clients/<new-slug>/ plus the existing DAE scaffold.
  • Memory and documentation references to demandes-ae/DAE-NNNN must be updated.
  • Live portails (Cloudflare Pages, eg. transgesco.jacksoncreektech.ca) read from C:\tmp\jct-{client} — the git mirror is unaffected by the OneDrive move, but the editorial pipeline (OneDrive → git mirror) must be re-pointed at the new paths.
  • This TFD does NOT mandate moving anything in talent-factory repo; that repo's production-lines/ already separates correctly.

References

  • TFD-0019 — EA Catalog Storage & Delivery Model (per-customer D1 + Pages, hard isolation)
  • TFD-0010 — Framework Library Ownership
  • TFD-0024 — Rendering Layer Ownership (former TFD-0022, renumbered to resolve collision)
  • Memory client-solution-structure, delivery-model-foundry-not-hosted, agent-ea-client-structure-issue