gps-denied-onboard/.cursor/skills/autodev/flows/meta-repo.md

Meta-Repo Workflow

Workflow for meta-repositories — repos that aggregate multiple components via git submodules, npm/cargo/pnpm/go workspaces, or ad-hoc conventions. The meta-repo itself has little or no source code of its own; it orchestrates cross-cutting documentation, CI/CD, and component registration.

This flow differs fundamentally from greenfield and existing-code:

• No problem/research/plan phases — meta-repos don't build features, they coordinate existing ones
• No test spec / run tests — the meta-repo has no code to test
• implement is scoped to suite-level work only — cross-repo concerns, repo/folder renames, suite-root infra additions (e.g., .gitmodules, _infra/, suite e2e/). Per-component implementation lives in each component's own workspace /autodev cycle. The meta-repo's implement step (Step 3.5) executes only when _docs/tasks/todo/ is non-empty AND the user explicitly opts in; placement is before the sync skills so subsequent Doc/E2E/CICD sync propagates the post-implementation state.
• No _docs/00_problem/ artifacts — documentation target is _docs/*.md unified docs, not per-feature _docs/NN_feature/ folders
• Primary artifact is _docs/_repo-config.yaml — generated by monorepo-discover, read by every other step

Step Reference Table

Step	Name	Sub-Skill	Internal SubSteps
1	Discover	monorepo-discover/SKILL.md	Phase 1–10
2	Config Review	(human checkpoint, no sub-skill)	—
2.5	Glossary & Architecture Vision	(inline, no sub-skill)	Steps 1–5
3	Status	monorepo-status/SKILL.md	Sections 1–5
3.5	Suite Implement	implement/SKILL.md (suite-level invocation context)	Steps 1–14 + 16 (Step 14.5 + Step 15 skipped); conditional on _docs/tasks/todo/ non-empty AND user opt-in
4	Document Sync	monorepo-document/SKILL.md	Phase 1–7 (conditional on doc drift)
4.5	Integration Test Sync	monorepo-e2e/SKILL.md	Phase 1–6 (conditional on suite-e2e drift; skipped if suite_e2e: block absent in config)
5	CICD Sync	monorepo-cicd/SKILL.md	Phase 1–7 (conditional on CI drift)
6	Loop	(auto-return to Step 3 on next invocation)	—

Onboarding is NOT in the auto-chain. Onboarding a new component is always user-initiated (monorepo-onboard directly, or answering "yes" to the optional onboard branch at end of Step 5). The autodev does NOT silently onboard components it discovers.

Detection Rules

Resolution: when a state file exists, state.step + state.status drive detection and the conditions below are not consulted. When no state file exists (cold start), walk the rules in order — first match wins. Meta-repo uses _docs/_repo-config.yaml (and its confirmed_by_user flag) as its primary folder-probe signal rather than per-step artifact folders.

---

Step 1 — Discover

Condition: _docs/_repo-config.yaml does NOT exist

Action: Read and execute .cursor/skills/monorepo-discover/SKILL.md. After completion, auto-chain to Step 2 (Config Review).

---

Step 2 — Config Review (session boundary)

Condition: _docs/_repo-config.yaml exists AND top-level confirmed_by_user: false

Action: This is a hard session boundary. The skill cannot proceed until a human reviews the generated config and sets confirmed_by_user: true. Present using Choose format:

══════════════════════════════════════
 DECISION REQUIRED: Config review pending
══════════════════════════════════════
 _docs/_repo-config.yaml was generated by monorepo-discover
 but has confirmed_by_user: false.

 A) I've reviewed — proceed to Status
 B) Pause — I'll review the config and come back later
══════════════════════════════════════
 Recommendation: B — review the inferred mappings (tagged
 `confirmed: false`), unresolved questions, and assumptions
 before flipping confirmed_by_user: true.
══════════════════════════════════════

• If user picks A → verify confirmed_by_user: true is now set in the config. If still false, re-ask. If true, auto-chain to Step 2.5 (Glossary & Architecture Vision).
• If user picks B → mark Step 2 as in_progress, update state file, end the session. Tell the user to invoke /autodev again after reviewing.

Do NOT auto-flip confirmed_by_user. Only the human does that.

---

Step 2.5 — Glossary & Architecture Vision (one-shot)

Condition (folder fallback): _docs/_repo-config.yaml exists AND confirmed_by_user: true AND (_docs/glossary.md does NOT exist OR the cross-cutting architecture doc identified in docs.cross_cutting does NOT contain a ## Architecture Vision section). State-driven: reached by auto-chain from Step 2 (user picked A).

Goal: Capture meta-repo-wide terminology and the user's architecture vision once, after the config is confirmed but before any sync skill runs. Without this, monorepo-document will faithfully propagate per-component changes but never surface a unified mental model of the meta-repo to the user, and the AI will keep re-inferring the same project terminology on every invocation.

Why inline (no sub-skill): monorepo-discover is hard-guarded to write only _repo-config.yaml; monorepo-document only edits existing docs. Glossary and architecture-vision creation is a first-time, user-confirmed write that crosses both guarantees, so it lives directly in the flow.

Inputs:

• _docs/_repo-config.yaml (component list, doc map, conventions, assumptions log)
• Cross-cutting docs listed under docs.cross_cutting (existing architecture doc, if any)
• Each component's primary_doc (read-only, for terminology + responsibility extraction)
• Root README.md if repo.root_readme is referenced

Outputs:

• _docs/glossary.md (or <docs.root>/glossary.md if docs.root ≠ _docs/) — NEW
• The cross-cutting architecture doc updated in place: a ## Architecture Vision section is prepended (or merged into an existing "Vision" / "Overview" heading)
• One new entry appended to _docs/_repo-config.yaml under assumptions_log: recording the run
• A new top-level config entry: glossary_doc: <path> so future monorepo-status and monorepo-document runs treat the glossary as a known cross-cutting doc

Procedure:

1. Draft glossary from _repo-config.yaml + each component's primary doc. Include:

   • Component codenames as they appear in the config (name field) and any rename pairs the user noted in unresolved: resolutions
   • Domain terms that recur across ≥2 component docs
   • Acronyms / abbreviations
   • Convention names from conventions: (e.g., commit prefix, deployment tier names)
   • Stakeholder personas if cross-cutting docs reference them Each entry: one-line definition + source (source: components.<name>.primary_doc or source: _repo-config.yaml conventions). Skip generic terms.

2. Draft architecture vision from the meta-repo perspective:

   • One paragraph: what the system as a whole is, what each component contributes, the runtime topology (one binary / N services / N clients + 1 server / hybrid), how components communicate (REST / gRPC / queue / DB-shared / file-shared)
   • Components & responsibilities (one-line each), pulled directly from _repo-config.yaml components: list
   • Cross-cutting concerns ownership: which doc owns which concern (auth, schema, deployment, etc.) — pulled from docs.cross_cutting[].owns
   • Architectural principles / non-negotiables the user has implied across components (e.g., "all components share a single Postgres", "submodules own their own CI", "deployment is per-tier, not per-component")
   • Open questions / structural drift signals: components missing from docs.cross_cutting, components in registry but not in config (registry mismatch), or contradictions between component primary docs

3. Present condensed view to the user (NOT the full draft files):

   ══════════════════════════════════════
    REVIEW: Meta-Repo Glossary + Architecture Vision
   ══════════════════════════════════════
    Glossary (N terms drafted from config + component docs):
      - <Term>: <one-line definition>
      - ...
   
    Architecture Vision — meta-repo level:
      <one-paragraph synopsis>
   
      Components / responsibilities:
        - <component>: <one-line>
        - ...
   
      Cross-cutting ownership:
        - <concern> → <doc>
        - ...
   
      Principles / non-negotiables:
        - <principle>
        - ...
   
      Open questions / drift signals:
        - <q1>
        - <q2>
   ══════════════════════════════════════
    A) Looks correct — write the files
    B) Add / correct entries (provide diffs)
    C) Resolve open questions / drift signals first
   ══════════════════════════════════════
    Recommendation: pick C if drift signals exist;
                    otherwise B if components or principles
                    don't match your intent; A only when
                    the inferred vision is exactly right.
   ══════════════════════════════════════
   

4. Iterate:

   • On B → integrate the user's diffs/additions, re-present, loop until A.
   • On C → ask the listed open questions in one batch, integrate answers, re-present.
   • Do NOT proceed to step 5 until the user picks A.

5. Save:

   • Write _docs/glossary.md (alphabetical) with **Status**: confirmed-by-user + date.
   • Update the cross-cutting architecture doc identified in docs.cross_cutting (or create one at _docs/00_architecture.md if none exists and the user's option-B input named one): prepend ## Architecture Vision with the confirmed paragraph + components + ownership + principles. Preserve every existing H2 below verbatim.
   • Append to _docs/_repo-config.yaml:
     • Top-level glossary_doc: <path-relative-to-repo-root> (sibling of docs.root)
     • New assumptions_log: entry: { date: <today>, skill: autodev-meta-repo Step 2.5, run_notes: "Captured glossary + architecture vision", assumptions: [...] }
   • Do NOT flip any confirmed: false → confirmed: true in the config; this step writes its own confirmed artifact, it does not retroactively confirm config inferences.

Self-verification:

• Every glossary entry traces to either the config or a component primary doc
• Every component listed in the vision matches a components: entry in the config
• All open questions are answered or explicitly deferred (with the user's acknowledgement)
• The cross-cutting architecture doc still contains every H2 it had before this step
• User picked option A on the latest condensed view

Idempotency: if both _docs/glossary.md exists AND the architecture doc already has a ## Architecture Vision section, this step is skipped on re-invocation. To refresh, the user invokes /autodev after deleting glossary.md (or running monorepo-discover with structural changes that justify a re-confirmation).

After completion, auto-chain to Step 3 (Status).

---

Step 3 — Status

Condition (folder fallback): _docs/_repo-config.yaml exists AND confirmed_by_user: true AND (_docs/glossary.md exists OR glossary_doc: is recorded in the config). State-driven: reached by auto-chain from Step 2.5, or entered on any re-invocation after a completed cycle.

Action: Read and execute .cursor/skills/monorepo-status/SKILL.md.

The status report identifies:

• Components with doc drift (commits newer than their mapped docs)
• Components with CI coverage gaps
• Registry/config mismatches
• Unresolved questions

Based on the report, auto-chain branches in this evaluation order (first match wins):

1. Registry mismatch (new components not in config, or config component not in registry) → present the Choose format below FIRST. After the user resolves it (A: refresh discover, B: onboard, C: continue with mismatch acknowledged), proceed to the next rule. This rule has priority because a stale config would mislead Step 3.5's ownership-envelope synthesis and any sync skill's component scope.
2. Pre-routing gate (Step 3.5 detection) — check _docs/tasks/todo/ for suite-level task files (*.md excluding files starting with _). If ≥1 task is present, auto-chain to Step 3.5 (Suite Implement). After Step 3.5 returns (regardless of A/B outcome), the post-implement re-status applies rules 3–6 below to the post-implementation state.
3. If doc drift found → auto-chain to Step 4 (Document Sync)
4. Else if CI drift (only) found → auto-chain to Step 5 (CICD Sync)
5. Else if suite-e2e drift (only) found → auto-chain to Step 4.5 (Integration Test Sync) (only when suite_e2e: block exists in config)
6. Else → workflow done for this cycle.

Registry mismatch Choose format (rule 1):

══════════════════════════════════════
 DECISION REQUIRED: Registry drift detected
══════════════════════════════════════
 Components in registry but not in config: <list>
 Components in config but not in registry: <list>

 A) Run monorepo-discover to refresh config
 B) Run monorepo-onboard for each new component (interactive)
 C) Ignore for now — continue
══════════════════════════════════════
 Recommendation: A — safest; re-detect everything, human reviews
══════════════════════════════════════

When rule 6 fires (no drift, no todo tasks), report "No drift. Meta-repo is in sync." and end the cycle. Loop waits for next invocation.

---

Step 3.5 — Suite Implement

Condition (folder fallback): _docs/tasks/todo/ exists AND contains ≥1 file matching *.md excluding files starting with _ (e.g., _dependencies_table.md is excluded by convention).

State-driven: reached by auto-chain from Step 3 when the pre-routing gate detected todo tasks. Inserted before the sync skills (Step 4 / 4.5 / 5) by deliberate design: implementing renames + cross-repo edits first means the subsequent sync skills propagate the actual landed state rather than the pre-change state, avoiding a second cycle to fix downstream drift.

Skip condition: _docs/tasks/todo/ is empty, missing, or contains only _* files. In that case Step 3.5 is skipped entirely and the cycle proceeds with Step 3's existing drift-based routing.

Goal: Execute suite-level implementation tasks — cross-repo concerns (e.g., autopilot + ui + suite e2e/ cutover in a coordinated change-set), folder renames (e.g., git mv flights missions + .gitmodules edit + _infra/ path refs), and suite-root infrastructure additions (e.g., _infra/dev/docker-compose.dev.yml). Per-component implementation work stays in each component's own workspace /autodev cycle.

Why this exists: the meta-repo's existing sync skills (monorepo-document, monorepo-cicd, monorepo-e2e) only propagate changes that already landed. They cannot execute a task spec. Without Step 3.5, suite-level tickets like AZ-543 (B4 repo rename) or AZ-506 (new dev compose) have no flow path forward — they require operator action outside autodev.

Inputs:

• _docs/tasks/todo/*.md (excluding _*) — task specs in the existing format (Task / Component / Dependencies / Acceptance criteria headers)
• _docs/_repo-config.yaml — components[].path list, used to compute the suite-level OWNED envelope (workspace root EXCLUDING any path under a component's folder)
• _docs/tasks/_dependencies_table.md — synthesized by this step if missing (see Procedure)
• _docs/tasks/_suite_module_layout.md — synthesized by this step if missing (see Procedure)

Procedure:

1. Detection (already done by Step 3 pre-routing gate). List task files in _docs/tasks/todo/ (excluding _*). If 0 → skip Step 3.5. If ≥1 → continue.

2. Present Choose:

   ══════════════════════════════════════
    DECISION REQUIRED: <N> suite-level task(s) in _docs/tasks/todo/
   ══════════════════════════════════════
    Task(s) detected:
      - AZ-XXX: <title>           (deps: <list or "—">)
      - AZ-YYY: <title>           (deps: <list or "—">)
      ...
   
    A) Run implement skill on these task(s) now (then continue to Doc / E2E / CICD sync)
    B) Skip implement this cycle — continue to Doc / E2E / CICD sync without executing tasks
    C) Pause — review the tasks before deciding (end session, no state changes)
   ══════════════════════════════════════
    Recommendation: A — running implement BEFORE syncs means subsequent
                    sync skills propagate the post-implementation state.
                    B is appropriate when tasks are blocked on user input
                    or external coordination. C when the tasks themselves
                    need owner clarification before execution.
   ══════════════════════════════════════
   

3. On user A — Pre-flight:

   a. Working tree clean check. Run git status --porcelain. If non-empty, surface to the user with a Choose A/B/C identical to the implement skill's prerequisite gate (commit/stash manually; agent commits as chore: WIP pre-implement; abort).

   b. Synthesize _docs/tasks/_dependencies_table.md if missing. Parse each in-scope task's Dependencies: field. Write a minimal table of the form:

   # Suite-Level Task Dependencies
   
   | Task ID | Depends on | Notes |
   |---------|------------|-------|
   | AZ-XXX  | (none)     | — |
   | AZ-YYY  | AZ-XXX     | — |
   

   If a task lists a dependency that is neither in todo/ nor done/, log a warning in the synthesized file but do not block — implement skill's Step 1 (Parse) will surface the issue if it actually blocks execution.

   c. Synthesize _docs/tasks/_suite_module_layout.md if missing. Default content:

   # Suite-Level Module Layout (synthetic)
   
   Generated by autodev meta-repo Step 3.5. The suite root has no per-feature decomposition; ownership is defined at the component-boundary level only.
   
   ## Per-Component Mapping
   
   | Component | Owns                             | Imports from |
   |-----------|----------------------------------|--------------|
   | suite     | (workspace root) excluding any path listed under `_repo-config.yaml.components[].path` | (read-only) every component's primary doc + `_docs/*.md` |
   
   Suite-level tasks operate on: `.gitmodules`, `_infra/**`, `_docs/**` (excluding `_docs/tasks/_*` regenerated files), root `README.md`, `e2e/**` (suite e2e harness only).
   
   Forbidden paths for suite-level tasks: `<component>/**` for every component listed in `_repo-config.yaml.components[].path` — those edits live in the component's own workspace `/autodev` cycle.
   

   d. Prepare invocation context:

   suite_level: true
   TASKS_DIR: _docs/tasks/
   module_layout_path: _docs/tasks/_suite_module_layout.md
   

4. Invoke implement skill. Read and execute .cursor/skills/implement/SKILL.md with the prepared context. The skill's "Suite-level invocation context" subsection (added in tandem with this flow change) honors the three flags above and skips:

   • Step 14.5 (cumulative code review) — no architecture_compliance_baseline.md exists at the suite level; cross-task drift is captured by the next monorepo-status cycle instead.
   • Step 15 (Product Implementation Completeness Gate) — the gate's inputs (_docs/02_document/architecture.md, system-flows.md, components/*/description.md) do not exist in the meta-repo artifact layout. Suite tasks are infrastructure / coordination work, not feature implementation.

   All other implement skill steps (1–14, 16) execute unchanged. Tracker integration (Step 5: In Progress, Step 12: In Testing) runs normally.

5. Post-implement re-status. After the implement skill completes (last batch committed, all originally-todo tasks moved to _docs/tasks/done/), silently re-run Step 3's drift detection logic — do NOT re-render the full Status report; just re-evaluate the drift signals against the post-implementation tree. Then auto-chain per the post-implementation drift findings:

   • Doc drift → Step 4 (Document Sync)
   • Suite-e2e drift only → Step 4.5
   • CI drift only → Step 5
   • No drift → cycle complete

   Note: the post-implement re-status is exactly why Step 3.5 is placed before sync. A repo rename will typically introduce doc + CI drift; the next invocation of Step 4 / Step 5 catches it on the same cycle.

6. On user B (skip) → mark Step 3.5 skipped in state file. Apply Step 3's original drift-based routing (compute from the pre-Step-3.5 Status report).

7. On user C (pause) → end session. Update state to step: 3.5, status: in_progress, sub_step: {phase: 0, name: awaiting-task-review, detail: "<N> tasks pending review"}. Tell the user to invoke /autodev again after deciding. Do NOT modify any files — pre-flight has not run yet.

Self-verification (executed before invoking implement):

• Working tree is clean (or user explicitly chose B in the WIP-stash sub-Choose)
• _docs/tasks/_dependencies_table.md exists (synthesized if it didn't)
• _docs/tasks/_suite_module_layout.md exists (synthesized if it didn't)
• All in-scope task files have a Component: field (skip + report any that don't — don't guess ownership)
• Tracker availability gate satisfied per protocols.md (or tracker: local previously chosen)

Failure handling:

• If implement returns FAILED → standard Failure Handling (protocols.md): retry up to 3 times, then escalate.
• If implement is interrupted mid-batch → next invocation re-detects via the implement skill's resumability protocol (read latest _docs/03_implementation/suite_batch_*.md). Step 3.5 itself is reentrant: on re-entry, if todo/ still has tasks, it presents the Choose again with the remaining set.
• Half-applied state risk (acknowledged): if implement is interrupted between commits, the working tree is clean at the last commit boundary but the in-flight batch is lost. The user is responsible for inspecting and re-invoking. This is intentional — automated rollback of suite-level renames + .gitmodules edits is more dangerous than a human-driven recovery.

Idempotency: if _docs/tasks/todo/ becomes empty after this step (all tasks moved to done/), the next /autodev invocation skips Step 3.5 entirely and proceeds with normal Status → sync flow.

---

Step 4 — Document Sync

State-driven: reached by auto-chain from Step 3 when the status report flagged doc drift.

Action: Read and execute .cursor/skills/monorepo-document/SKILL.md with scope = components flagged by status.

The skill:

1. Runs its own drift check (M7)
2. Asks user to confirm scope (components it will touch)
3. Applies doc edits
4. Skips any component with unconfirmed mapping (M5), reports

After completion:

• If the status report ALSO flagged suite-e2e drift → auto-chain to Step 4.5 (Integration Test Sync)
• Else if the status report ALSO flagged CI drift → auto-chain to Step 5 (CICD Sync)
• Else → end cycle, report done

---

Step 4.5 — Integration Test Sync

State-driven: reached by auto-chain from Step 3 (when status report flagged suite-e2e drift and no doc drift) or from Step 4 (when both doc and suite-e2e drift were flagged).

Skip condition: if _docs/_repo-config.yaml has no suite_e2e: block, this step is skipped entirely — there's no harness to sync. The status report should not flag suite-e2e drift in that case; if it does, that's a status-skill bug.

Action: Read and execute .cursor/skills/monorepo-e2e/SKILL.md with scope = components flagged by status.

The skill:

1. Verifies every path under suite_e2e.* exists (binary fixtures excepted — see the skill's Phase 1)
2. Classifies each flagged change against the suite-e2e impact table
3. Applies edits to e2e/docker-compose.suite-e2e.yml, e2e/fixtures/init.sql, e2e/fixtures/expected_detections.json metadata, and e2e/runner/tests/*.spec.ts selectors as needed
4. Bumps baseline fixture_version with a -stale suffix and appends a _docs/_process_leftovers/ entry whenever the detection model revision changes (binary fixture cannot be regenerated automatically)
5. Reports synced files; does not run the suite e2e itself

After completion:

• If the status report ALSO flagged CI drift → auto-chain to Step 5 (CICD Sync)
• Else → end cycle, report done

---

Step 5 — CICD Sync

State-driven: reached by auto-chain from Step 3 (when status report flagged CI drift and no doc/suite-e2e drift), Step 4, or Step 4.5.

Action: Read and execute .cursor/skills/monorepo-cicd/SKILL.md with scope = components flagged by status.

After completion, end cycle. Report files updated across doc, suite-e2e, and CI sync.

---

Step 6 — Loop (re-entry on next invocation)

State-driven: all triggered steps completed; the meta-repo cycle has finished.

Action: Update state file to step: 3, status: not_started so that next /autodev invocation starts from Status. The meta-repo flow is cyclical — there's no terminal "done" state, because drift can appear at any time as submodules evolve.

On re-invocation:

• If config was updated externally and confirmed_by_user flipped back to false → go back to Step 2
• Otherwise → Step 3 (Status)

Explicit Onboarding Branch (user-initiated)

Onboarding is not auto-chained. Two ways to invoke:

1. During Step 3 registry-mismatch handling — if user picks option B in the registry-mismatch Choose format, launch monorepo-onboard interactively for each new component.

2. Direct user request — if the user says "onboard " during any step, pause the current step, save state, run monorepo-onboard, then resume.

After onboarding completes, the config is updated. Auto-chain back to Step 3 (Status) to catch any remaining drift the new component introduced.

Auto-Chain Rules

Completed Step	Next Action
Discover (1)	Auto-chain → Config Review (2)
Config Review (2, user picked A, confirmed_by_user: true)	Auto-chain → Glossary & Architecture Vision (2.5)
Config Review (2, user picked B)	Session boundary — end session, await re-invocation
Glossary & Architecture Vision (2.5)	Auto-chain → Status (3)
Status (3, todo tasks present)	Auto-chain → Suite Implement (3.5) — pre-routing gate fires before drift-based routing
Status (3, no todo tasks, doc drift)	Auto-chain → Document Sync (4)
Status (3, no todo tasks, suite-e2e drift only)	Auto-chain → Integration Test Sync (4.5)
Status (3, no todo tasks, CI drift only)	Auto-chain → CICD Sync (5)
Status (3, no todo tasks, no drift)	Cycle complete — end session, await re-invocation
Status (3, registry mismatch)	Ask user (A: discover, B: onboard, C: continue)
Suite Implement (3.5, user picked A, success)	Silent re-status; auto-chain per post-implementation drift (Step 4 / 4.5 / 5 / cycle complete)
Suite Implement (3.5, user picked B)	Mark skipped; auto-chain per Step 3's original drift findings
Suite Implement (3.5, user picked C)	Session boundary — end session, await re-invocation
Suite Implement (3.5, FAILED ×3)	Standard Failure Handling escalation (protocols.md)
Document Sync (4) + suite-e2e drift pending	Auto-chain → Integration Test Sync (4.5)
Document Sync (4) + CI drift only pending	Auto-chain → CICD Sync (5)
Document Sync (4) + no further drift	Cycle complete
Integration Test Sync (4.5) + CI drift pending	Auto-chain → CICD Sync (5)
Integration Test Sync (4.5) + no CI drift	Cycle complete
CICD Sync (5)	Cycle complete

Status Summary — Step List

Flow name: meta-repo. Render using the banner template in protocols.md → "Banner Template (authoritative)".

Flow-specific slot values:

• <header-suffix>: empty.
• <current-suffix>: empty.
• <footer-extras>: add a single line:

   Config:  _docs/_repo-config.yaml [confirmed_by_user: <true|false>, last_updated: <date>]
  

#	Step Name	Extra state tokens (beyond the shared set)
1	Discover	—
2	Config Review	IN PROGRESS (awaiting human)
2.5	Glossary & Architecture Vision	SKIPPED (already captured)
3	Status	DONE (no drift), DONE (N drifts)
3.5	Suite Implement	DONE (N tasks), SKIPPED (no todo tasks), SKIPPED (user picked B), IN PROGRESS (batch M of ~N), IN PROGRESS (awaiting-task-review)
4	Document Sync	DONE (N docs), SKIPPED (no doc drift)
4.5	Integration Test Sync	DONE (N files), SKIPPED (no suite-e2e drift), SKIPPED (no suite_e2e config block)
5	CICD Sync	DONE (N files), SKIPPED (no CI drift)

All rows accept the shared state tokens (DONE, IN PROGRESS, NOT STARTED, FAILED (retry N/3)); rows 2.5, 3.5, 4, 4.5, and 5 additionally accept SKIPPED.

Row rendering format:

 Step 1     Discover                          [<state token>]
 Step 2     Config Review                     [<state token>]
 Step 2.5   Glossary & Architecture Vision    [<state token>]
 Step 3     Status                            [<state token>]
 Step 3.5   Suite Implement                   [<state token>]
 Step 4     Document Sync                     [<state token>]
 Step 4.5   Integration Test Sync             [<state token>]
 Step 5     CICD Sync                         [<state token>]

Notes for the meta-repo flow

• Session boundaries: Step 2 (Config Review pending), Step 2.5 (one-shot glossary/vision review), and Step 3.5 (when user picks C "Pause"). Step 3.5's A/B picks do NOT cross a session boundary — they auto-chain to syncs in the same session.
• Cyclical, not terminal: no "done forever" state. Each invocation completes a drift cycle; next invocation starts fresh.
• Tracker integration scope: this flow does NOT create Jira/ADO tickets in its sync skills (Status / Document Sync / E2E / CICD). Step 3.5 (Suite Implement) IS tracker-integrated — it transitions existing tickets In Progress → In Testing per the implement skill's standard tracker handling. Suite-level tickets are authored manually by the operator (typically as children of an Epic that spans multiple components, like AZ-539); the flow doesn't auto-create them.
• Per-component vs. suite-level work:
  • Tickets that touch component source code (<component>/src/**) belong in that component's own workspace /autodev cycle. The meta-repo flow does NOT execute them.
  • Tickets that touch suite-root paths only (.gitmodules, _infra/**, suite e2e/**, root README.md, suite _docs/** outside tasks/_*) are eligible for Step 3.5.
  • Tickets that span both (e.g., AZ-550 B11 consumer cutover, which touches autopilot/, ui/, AND suite e2e/) are NOT executable from a single workspace by design — split the ticket so the suite-level slice can run in Step 3.5 and the component slices run in their owning workspaces.
• Onboarding is opt-in: never auto-onboarded. User must explicitly request.
• Failure handling: uses the same retry/escalation protocol as other flows (see protocols.md).