aidp-fusion-incremental

aidp-fusion-incremental — guarded daily delta runner

Wraps run --mode incremental (delta-merge using prior watermarks from fusion_autopilot_state) with the prechecks an incremental run actually needs. Like /aidp-fusion-seed, it shells out to the CLI and never touches state directly. Incremental is less destructive than seed (row-grain nodes MERGE on the natural key; replace-marts still CREATE OR REPLACE), so the guard is lighter — but incremental has its own failure modes that seed doesn't, and this skill front-runs them.

When to use

• "run incremental", "refresh the marts", "daily delta", "pull the latest", "incremental supplier_spend / just bronze / the marts".
• Routine refresh after an initial seed.

When NOT to use

• First build / nothing materialized → /aidp-fusion-seed (incremental needs prior watermarks).
• A single known CLI invocation you already have.

Workflow

1 — Parse intent (reuse the seed parser, mode=incremental)

Assemble known node ids (bundle datasets + content-pack info <pack> --json silver+gold), then:

python3 ../aidp-fusion-seed/intent.py "<phrase>" --mode incremental --known-nodes "<ids>"

Honour ambiguous / unknown_tokens (list pack nodes, ask) and needs_run_id (for resume) exactly as the seed skill does. argv comes back as run --mode incremental <scope>.

2 — Preconditions (reuse the shared checker)

python3 ../aidp-fusion-seed/preconditions.py --bundle bundle.yaml --config aidp.config.yaml --env <env>

Act on missing via the same ladder as seed: bundle → init/fix; config → /aidp-fusion-config; profile → /aidp-fusion-bootstrap (or use-pack if the node is in an unwired overlay); cluster → start it. Re-run until ok: true.

3 — Incremental-specific prechecks (this is what seed doesn't do)

These are the failure modes incremental adds — front-run them so the operator gets a clear next step instead of a deep cluster error:

• Watermark cursor present? Incremental delta-merges from each node's prior last_watermark in fusion_autopilot_state. A node that was never seeded raises IncrementalCursorMissingError (it lists the offending datasets). → tell the operator to /aidp-fusion-seed those nodes first. (Use /aidp-fusion-status to see which nodes have a prior successful run.)
• Plan unchanged since last seed? If the node's YAML / SQL / tenant profile changed since it was seeded, the run fails with AIDPF-4040 plan-hash drift. → re-seed that node (run --mode seed) to re-pin the plan-hash (or revert the change). Incremental requires plan continuity with the seed that pinned it. Row-grain MERGE nodes (silver dims, gl_balance) increment cleanly after a seed — the plan-hash is mode-normalized (LIMITS.md P-incr-L1, resolved 2026-06-15), so the watermark predicate rendering 1=1 (seed) vs col > :watermark (incremental) no longer false-trips 4040. A 4040 now means a genuine plan-shape change. If you edited the SQL/profile on purpose and don't want a full re-seed, pass the hidden --repin-plan-hash flag to repin the new hash (writes a mode='plan_hash_repin' audit row); otherwise re-seed or revert.
• New chart of accounts added? A profile change that ONLY adds a new chartOfAccounts.byChart arm (existing charts byte-identical) is a proven additive change: incremental absorbs it automatically — no re-seed and no --repin-plan-hash needed. The per-node gate accepts the plan-hash advance (recording coa_additive_accept_reason) once the post-land COA checkpoint passes. A mutating COA change (an existing chart's segment moved/removed) is NOT additive and still routes to --mode seed (AIDPF-1048/4040) — an incremental would leave that chart's already-classified rows stale. So: adding a chart → incremental; correcting an existing chart → seed.
• Fusion-PVO / bronze drift? Incremental fires the drift gates — AIDPF-2072 (live PVO column renamed/removed vs the pinned snapshot), AIDPF-4070/4071 (source-schema), AIDPF-2012 (bronze-table fingerprint). On any of these → hand to /fusion-drift-doctor, which classifies the drift and routes to bootstrap --refresh (a declared candidate still matches) or /medallion-author (a new column the pack never anticipated). Do NOT paper over it with --force-fingerprint-skip outside dev. An absent bronze table (a dataset whose extract never succeeded — e.g. the LIMITS.md L2-blocked PVO) no longer aborts the fingerprint gate: it is tolerated with a WARN and baseline-filled from the pinned schema snapshot, so every present table stays drift-checked and --force-fingerprint-skip is NOT needed for that case. If the snapshot is missing/desynced the gate still fails closed — run bootstrap --refresh to back-fill it (no repin needed).