@caddis/cli 0.4.52 → 0.4.53

package/bundles/antigravity-plugin/skills/spawn-hub/SKILL.md

@@ -1,341 +0,0 @@
----
-name: spawn-hub
-description: Hand the Advisory Hub role to a fresh session — run the mechanical audit, then generate the succession prompt with a context self-check the new Hub must pass
----
-
-# /caddis:spawn-hub — hand the Hub role to a fresh session
-
-> **The Hub is a ROLE, not a conversation.** It outlives any one session and hands to the next through
-> **files** — never chat history. This command is the handoff. Until it existed, every Hub was spawned
-> by a hand-written prompt, which meant the pattern only worked for someone who already knew what to
-> put in one.
-
-**This command does not start the new session.** It leaves the outgoing Hub's context in a state a
-fresh one can pick up, then prints the prompt to paste. The human runs it.
-
----
-
-## When to spawn — do not guess, and do not wait for the crash
-
-**The default seam is a MILESTONE BOUNDARY.** A milestone ends with a deploy, a smoke test and a
-handoff; that is already the plan's own `/handoff` → `/clear` point. Carrying a Hub across a deploy is
-where staleness bites — the outgoing Hub's picture of prod is exactly what just changed.
-
-**Spawn at the next milestone boundary if ANY of these is true:**
-
-- the current Hub has validated **≥5 phases**
-- it has executed **≥2 deploys**
-- it has done substantial work *outside* phase validation (fleet changes, tooling, plugin releases) —
-  that consumes context far faster than validation does
-- **its own context is filling** — this one overrides the milestone seam entirely
-
-> **Observed, not theorised:** on the reference project, Hubs 1–4 each ended because context ran out,
-> never because a milestone did. A Hub covers roughly **4–6 phases / 1–2 milestones** before that
-> happens. So treat the milestone as the *planned* seam and context as the *real* constraint, and run
-> this command at whichever arrives first.
-
-**Do not wait until context is nearly gone.** Step 1 is a real audit that needs room to run, and the
-outgoing Hub is the only session that can do it. A handoff written from a nearly-full context is the
-one most likely to omit exactly what the next Hub needs.
-
----
-
-## Step 0 — resolve the context file, and refuse cleanly when you cannot
-
-Use `$ARGUMENTS` if given. Otherwise look for `<plan-stem>-advisory-context.md` beside every plan in
-`.caddis/plans/`.
-
-- **None found → STOP and say so.** This project is not running an Advisory Hub, so there is no role to
-  hand over. Do not scaffold one here: that decision belongs to `/caddis:feature-plan` Step 3b, at
-  planning time, when the phase count and risk are actually known.
-- **More than one → ask which**, listing them with each plan's status. Never guess: handing over the
-  wrong plan's Hub is worse than not handing over.
-- **Already handed over?** Check the succession table. If the last row has no end reason, this is a
-  fresh handover. **If the last row is already closed and a new one opened, STOP** — a previous run
-  completed and re-running would double-close it and re-open a duplicate. Re-running this command is
-  safe only when the tree still shows the outgoing Hub as current.
-
-## Step 1 — the mechanical audit (MANDATORY, and it is not a formality)
-
-**Do not ask yourself "are there gaps?" — assume there are, and find them mechanically.** The outgoing
-Hub's instinct is always *"yes, this is ready"*, because it is judging against its own memory of the
-session rather than against the document. **That instinct is wrong by default.** On the reference
-project the first answer to "can we hand off" was yes; a mechanical audit then found **seven gaps** —
-including that mutation testing, by then the single highest-value technique in use, was written down
-nowhere a fresh Hub would find it.
-
-1. **List every technique, decision and correction actually used this session** — from your own
-   actions, not from the context doc. Re-ran a cross-review with a second provider after a timeout?
-   Mutation-tested a seam? Fixed something directly rather than only flagging it? Corrected a gate
-   rather than the code? Each is a candidate line item.
-2. **For each, check whether the advisory context already tells a fresh Hub to do the same thing.**
-   Not "does the word appear" — whether *the instruction* is there.
-3. **Land every real gap as a durable rule** in the advisory context — its *Standing gotchas*,
-   *Hub techniques*, *Environment facts* or *Succession* section. **Cite sections BY NAME, never by
-   number:** numbers drift between a project's hand-grown file and the shipped template, and this
-   command previously named §7/§9/§13, which matched one project and no template.
-   **A correction that lives only in a verdict file dies with the session that wrote it.**
-4. **Audit in BOTH directions.** As well as what is missing, look for what is now **obsolete** — a
-   gotcha since promoted to `AGENTS.md`, or one a committed test now enforces, compresses to a line
-   and a pointer. The context doc is append-only by design and every incoming Hub must read it end to
-   end; without a diet it becomes the thing it exists to prevent.
-
-> **The caveat that will burn you: a literal-string grep over prose throws false MISSINGs.** The same
-> audit that found seven real gaps also produced three false negatives — content that *was* present,
-> phrased differently. `0 matches` means "not this exact string", not "not covered". Search by concept
-> and read the surrounding paragraph.
-
-## Step 2 — close the record
-
-- Every validated phase has a **verdict file**, and its `verdict:` frontmatter is one of
-  `accept` / `accept-with-correction` / `reject`.
-- Every **ACCEPT-WITH-CORRECTION** either has its corrections landed, or they are in the carried-open
-  list. An unlanded correction that nobody is tracking is the worst thing to hand over.
-- The plan's **Tracker rows** match reality. Check them; they get silently skipped, and on the
-  reference project four completed rows were reverted to "not started" by a stray staged edit and only
-  caught two milestones later.
-- `git status` is clean, or every uncommitted change is deliberate and named in the handoff.
-
-## Step 3 — update the succession table
-
-In the advisory context's succession section: close the outgoing Hub's row (what it covered, why it
-ended) and open the next one.
-
-**Then update the carried-open list — APPEND AND CLOSE, never rewrite.**
-
-Each Hub used to *rewrite* this list, which means an open item can vanish between generations with
-nothing to show it ever existed. Nobody notices, because the only evidence was the list itself.
-
-So: every item gets a stable id and is **never deleted**.
-
-```markdown
-- **[C7] Break-glass is DB-engine-dependent** — raised Hub 4. <what, and enough to act on>
-  → **CLOSED by Hub 6**: fixed in `abc1234`, verified on prod.
-- **[C9] `files.py` sibling-prefix traversal** — raised Hub 4. <detail>
-  → still open.
-```
-
-Closing an item requires **saying who closed it and why** — a line, not a deletion. That makes a
-disappearance impossible: an item either carries a close reason or it is still open, and both are
-visible. It also lets a later Hub see that something was closed *wrongly*, which a deletion hides
-forever.
-
-**ARTIFACT CONSERVATION — the same check, for the files you wrote.** The ledger check above catches
-an id that *disappeared*. Nothing caught a file that *exists and is invisible*, which is the inverted
-failure and just as silent:
-
-```bash
-python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" hub-artifacts --reports .caddis/advisory-hub-reports
-```
-
-Exit 1 means you wrote a phase prompt the successor will never learn about. It will find no prompt,
-write a fresh one, and lose whatever reasoning yours carried — plausibly and completely. Name every
-prompt you authored in this spawn doc before handing over. (Degrades open: no handover yet, or no
-script, means proceed.)
-
-**CONSERVATION CHECK — mechanical, and it fails the spawn.** Every id in the predecessor's ledger
-must appear in the outgoing one as either still-open or closed-with-a-reason. An id that is simply
-absent is a silent loss: **stop and restore it before handing over.** Do not ask "did anything
-vanish?" — diff the ids. That is the same design move as the handoff audit, for the same reason.
-
-**One ledger, one home.** A verdict may *raise* an item, but it is not raised until it has an id in
-the context doc's ledger, in the same commit. Two uncoordinated lists drift, and the drift is
-invisible.
-
-Carry the whole list forward, closed items included. It is short, and its history is the cheapest
-audit trail this pattern has.
-
-## Step 4 — generate the prompt
-
-**"From the files, not from memory" is an instruction you cannot follow by intending to. Run the
-generator:**
-
-```
-python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_spawn.py" preflight
-python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_inventory.py" --with-tests
-```
-
-`preflight` **refuses on a dirty tree**: the incoming Hub pulls, so uncommitted work is invisible to
-it. Commit first, or name every uncommitted file in the handover.
-(falls back to `scripts/caddis_inventory.py` in a source checkout; skip the step if absent — it
-degrades open like every other machine step here.)
-
-Paste its output into the prompt as a **Repository inventory** section, verbatim. It enumerates
-plans, PRDs, prompts, handoffs, KB notes, the parking-lot backlog, open comms, every script and its
-purpose, and any generated artefact committed before its generator last changed. `--with-tests`
-runs the suite instead of reporting a remembered number — one handover claimed 20 tests when there
-were 19, and the incoming Hub found the discrepancy before anyone else.
-
-**Why a generator and not care.** Nine corrective round trips were needed to bring one Hub to a
-usable state, and the user caught six of the nine: no reports listed, no documents, no KB notes, no
-scripts, planned work absent, and confusion over which of two prompts actually existed. Every one of
-those is a directory listing. They were missed because an outgoing agent recalls *what it did*
-rather than enumerating *what exists* — and the incoming Hub cannot know what it was not told.
-
-Then write the judgement half yourself. It must contain:
-
-1. **The role and the one rule** — re-derive, do not trust; validate, do not implement.
-2. **The read order**: advisory context (all of it, especially the succession section and the
-   carried-open list) → the plan's milestones / execution protocol / tracker → the project's
-   measurement rules → the most recent 2–3 verdicts.
-3. **A context self-check the new Hub must answer BEFORE touching a phase**, from the files, including:
-   - re-derive **one anchor number live** (not quote it)
-   - name the decisions that are **accepted but reversible**, and what would reverse them
-   - state **where the next deploy gate is and how it determined that** (read the milestone table —
-     never state a deploy boundary from memory)
-   - name **one thing a green automated check does NOT prove**, with the example that taught it
-   - **verify the tree independently** — `git fetch`, count divergence, and `git status`/diff any dirty
-     file before treating it as authority
-   > **THE NEW HUB MUST NOT MARK ITS OWN SELF-CHECK.** Until 2026-09-08 nothing graded these
-   > answers: this command does not start the new session, so nothing routed them back. A
-   > self-marked exam tests willingness, not comprehension. Run the handshake instead — the
-   > incoming Hub answers, **you re-derive each answer from the files**, then you send the
-   > verdict:
-   >
-   > ```bash
-   > python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_spawn.py" handshake open   --id <id>
-   > python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_spawn.py" handshake status --id <id>
-   > python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_spawn.py" handshake record --id <id> --event answers
-   > python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_spawn.py" handshake close  --id <id>
-   > ```
-   >
-   > It reports whether this runtime can message a peer at all and falls back to the paste route
-   > on agy and Codex, which have no `SendMessage`. `close` refuses until the incoming Hub has
-   > acknowledged the verdict. See `/caddis:spawn-session` for the full direction table and the
-   > chase rule.
-   >
-   > **This does not soften the single-writer rule below.** You stay ALIVE to grade; you stop
-   > WRITING when the prompt is issued. Both hold.
-
-4. **At least one question whose naive answer is WRONG.** This is the load-bearing part. A Hub that
-   only skimmed must fail *visibly* rather than silently.
-
-   > **USE A DIFFERENT TRAP THAN THE PREVIOUS HUB'S.** Check the last spawn prompt in
-   > `.caddis/advisory-hub-reports/` and pick a fresh one. A trap reused across generations stops
-   > testing comprehension and starts testing whether the new Hub read the old prompt — which it can
-   > pass while understanding nothing. Rotate it, and prefer a fact the *most recent* milestone
-   > established, since that is what the incoming Hub is least likely to have absorbed.
-
-   > **DERIVE the questions from what CHANGED — do not choose them.** An agent that picks its own
-   > exam picks what it remembers, which is the thing under test. Spread them: the oldest settled
-   > decisions catch a Hub that read only the recent sections; the most recent changes catch one
-   > that read only the summary; **a SUPERSEDED fact is the highest-signal question of all**,
-   > because the obvious answer is the stale one.
-
-   > **Every question must be answerable from a committed file. Prove it, do not assume it:**
-   >
-   > ```
-   > python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_spawn.py" verify-question \
-   >   --answer-in .caddis/kb/some-note.md --needle "the phrase that answers it"
-   > ```
-   >
-   > A question whose answer is not written down tests memory — the thing this mechanism exists to
-   > replace. It is not a harder question; it is the old failure wearing an exam's clothes.
-
-   > **Store NO answer key.** Re-derive each answer from the repo when the incoming Hub replies. A
-   > stored key freezes your belief at capture time: if you were wrong, the key is wrong and the
-   > check certifies the error. Re-deriving validates the DOCUMENT as well as the reader — which is
-   > exactly what `.caddis/parking-lot/done/004-*` found missing, where a Hub passed a
-   > thirteen-question check on a handover carrying four factual errors.
-
-   Good traps share a shape: a figure that looks obvious, a correct value that differs, and a reason
-   rooted in the data rather than in the code. On the reference project, one generation asked why the
-   funnel's `offered` is not `SUM(OfferedInd)` (naive 3,814, correct 4,783 — the raw flags do not
-   nest); the next asked why an abandonment rate moved from 7.6% to 5.9% (the old figure was not a
-   rate at all — 72% of its numerator sat outside its own denominator).
-5. **What is carried open — INLINE THE OPEN ITEMS VERBATIM, do not link to them.** (Closed items stay
-   in the context file for the audit trail; they do not belong in the prompt.) A pointer costs a file hop at
-   exactly the moment the new Hub has least context, and a carried-open item that is not read is
-   indistinguishable from one that was closed.
-6. **The next work**, with its batching (`Session: continue` = batchable, `fresh` = not) and any
-   standing constraint the new Hub would not otherwise know — a stalled upstream load, a deploy hold,
-   an environment that is mid-change.
-7. **The standing authorisations**: deploys are user-authorised **every time**; a previous yes does not
-   carry.
-8. **What comes after this, and why the order matters.** Not only what is done and what is carried
-   open — **what this is building towards**, for the next two or three phases. A Hub that does not
-   know what comes next can design the current phase in a way that blocks it, and it will never find
-   out, because nothing it can read says so. One live handover omitted a planned model comparison
-   entirely; the user caught it. A section covering only the past reads complete and is not.
-9. **The deliverable.** Name the thing this workstream must eventually produce, and the step that
-   produces it. One handover carried every phase faithfully and never mentioned the report that was
-   the whole point of the exercise. The user caught that too.
-10. **A standing instruction to maintain the tracker.** Put this in the prompt, in these words or
-    close to them:
-
-    > **Maintain the tracker.** Your in-session task list does not survive this session.
-    > `.caddis/relay.md` does. Mirror your working list into it as you go, and include its current
-    > state in every progress report. Anything not written there is lost.
-
-    The succession table records **who held the role**; `relay.md` records **where the work is**. The
-    table is written when a Hub *ends*, so nothing covers the hours while a Hub is *working* — which
-    is the whole period this mechanism exists to protect. A real spawned Hub read `relay.md`,
-    answered a thirteen-question context check correctly, found four genuine defects in its
-    handover, **and created no tracker at all**, because nothing asked it to.
-
-    Note for the incoming Hub: `relay.md` is gitignored and machine-local. Anything a successor **on
-    another machine** will need belongs in the advisory context or the next spawn prompt, not only
-    there.
-11. **`.caddis/kb/environment-map.md`, INLINE AND VERBATIM.** Hosts, which login works, where other
-    repositories actually live. It is short, it is the first thing an incoming Hub needs, and it is
-    the category most often missing — one incoming Hub searched the filesystem for a repository that
-    lived in Gitea, and the user had to stop it. A pointer is not enough here: this is exactly the
-    file a cold session does not know to open.
-
-**Write it to `.caddis/advisory-hub-reports/hub-NN.spawn.md`** (frontmatter `type: hub-spawn`,
-`hub: NN`), then print it. Until this file existed, every succession prompt lived and died in chat —
-which made two of this command's own instructions unimplementable: "rotate the trap by checking the
-last spawn prompt" had nothing to check, and the ledger conservation check below had nothing to diff
-against.
-
-Print the prompt in a fenced block, ready to paste. **Say plainly that it starts a NEW session** — a
-Hub spawned inside the outgoing session's context inherits exactly the staleness this whole mechanism
-exists to shed.
-
-### Check the prompt before you hand it over
-
-```
-python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" handover-check \
-  --doc .caddis/advisory-hub-reports/hub-NN.spawn.md
-python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_spawn.py" check \
-  --doc .caddis/advisory-hub-reports/hub-NN.spawn.md
-```
-
-The second one blocks on a **commit hash or test count given as current state**. Both go stale
-within the hour — measured twice — and the fix is never a fresher number, it is to write the command
-that produces it. A historical hash is only noted, not blocked: those are durable, and flagging them
-is how a check earns a reputation for crying wolf.
-
-It fails when the prompt names a file that does not exist. **Validate the DOCUMENT, not just the
-reader.** The context self-check in Step 4 proves the incoming Hub read carefully; it proves nothing
-about whether what it read was true. One incoming Hub passed a thirteen-question check on a handover
-containing four factual errors — it found them *despite* the check, not because of it.
-
-### The single-writer rule — state it in the prompt
-
-**The outgoing Hub stops writing to the repository the moment the succession prompt is issued.** Say
-so in the prompt itself, so both sides know which one owns the tree.
-
-This is not tidiness. Two sessions committed to one repository concurrently and the incoming Hub's
-work landed inside the outgoing Hub's commit. Only committed objects are safe from another session's
-checkout; a shared working tree is process-shared state, not session-private.
-
-## Step 5 — report
-
-Output: the audit result (candidates → gaps → where each landed), the succession table update, what is
-carried open, and the prompt. Then stop.
-
-**Do not begin validating the next phase.** You are the outgoing Hub; that work belongs to the session
-about to be spawned, and doing it here re-creates the context problem you just solved.
-
----
-
-## Anti-patterns
-
-- **Spawning without the audit.** The prompt will look fine and quietly omit the session's best
-  technique.
-- **Writing the prompt from memory.** Build it from the files; memory is what is being discarded.
-- **Handing over a stale carried-open list.** An item that was closed hours ago and still appears
-  teaches the new Hub to distrust the whole list.
-- **Waiting until context is nearly gone.** The audit needs room. Spawn early and cheaply.
-- **Continuing to work after generating the prompt.** Two Hubs holding the role is worse than one.

package/bundles/antigravity-plugin/skills/statusline/SKILL.md

@@ -1,6 +0,0 @@
----
-name: statusline
-description: Renamed to /caddis:install-statusline (alias, removed next release)
----
-
-This command was renamed to /caddis:install-statusline. Run /caddis:install-statusline now with the same arguments ($ARGUMENTS), and tell the user once: "/caddis:statusline is renamed to /caddis:install-statusline; the old name will be removed in the next release."

package/bundles/antigravity-plugin/skills/validate-phase/SKILL.md

@@ -1,143 +0,0 @@
----
-name: validate-phase
-description: Advisory Hub phase validation — consume a phase report, RE-DERIVE its claims independently, and return ACCEPT / ACCEPT-WITH-CORRECTION / REJECT
----
-
-# /caddis:validate-phase — the Advisory Hub validates a phase (never trusts it)
-
-> **THE RULE: re-derive, do not trust.** A phase report is a self-assessment. Reading it and nodding
-> makes you a rubber stamp, and a rubber stamp is worse than no check at all — it manufactures false
-> confidence. Every step below exists to prevent exactly that. Skipping the re-derivation is the one way
-> this command can fail at its actual job while still producing a plausible-looking verdict.
-
-Full methodology, templates, and rationale: the **`advisory-hub`** skill. This command is the thin,
-operational driver — run it after an implementing session (usually `/caddis:implement` in Advisory-Hub
-mode) has filed a phase report.
-
-## Step 0 — resolve inputs
-
-Use **$ARGUMENTS** if given. Otherwise, find the newest `phase-*.report.md` file in
-`.caddis/advisory-hub-reports/` that has no matching `phase-NN.verdict.md` sibling yet — that is the
-one awaiting validation. Read its `PLAN:` and `ADVISORY CTX:` header fields and load both files.
-
-**If no `<slug>-advisory-context.md` exists** for the plan named in the report: say so explicitly, offer
-to bootstrap one from the `advisory-hub` skill's §A template, and continue in **degraded mode** — state in
-the verdict exactly which checks (§4 locked-decision adjudication, §5 safety-rule re-check) were
-unavailable without it. Never silently skip a check without recording that you skipped it.
-
-**A degraded verdict must be machine-distinguishable, not just annotated in prose.** Write
-`verdict: accept-degraded` (not plain `accept`) in the frontmatter. `/caddis:implement` reads only the
-`verdict:` field to decide whether the next phase may start, so a degraded accept spelled `accept` is
-indistinguishable from a full one — the gate cannot tell a partial check from a real one, which is
-precisely the false confidence this whole pattern exists to prevent. Use `reject-degraded` likewise if
-you are rejecting without the context doc.
-
-## Step 1 — read the report once as a document
-
-Before validating a single claim, check the report against itself: does CROSS-REVIEW agree with
-DEVIATIONS? Does MODEL/LANE name a vendor's model that doesn't match the claimed lane? On the reference
-run this pattern's design was validated against, two of three real findings in one phase came from
-exactly this kind of internal contradiction — not from re-checking the code.
-
-## Step 2 — re-derive (the Hub validation checklist)
-
-Run every item in the `advisory-hub` skill's §D checklist yourself:
-1. Re-derive every VALUE CHECK using the method advisory-context §3a names — actually run it, don't read
-   the reported result.
-2. Re-run the exit gates, at minimum the fast ones (unit tests, lint, type-check).
-3. `git log` / `git show --stat` the commits — do they match the phase's claimed touches? Anything
-   unexpected, especially tooling/config/CI that never appeared in DEVIATIONS?
-4. Re-check every rule in advisory-context §5, or record `N/A — none declared`.
-5. Flag any deviation that touches a §4 locked decision — this is step 3 below, not your call to make here.
-6. Flag any surprise that contradicts the plan's `## Current state` — this is step 4 below.
-7. If this milestone boundary ships to a real deployed environment, smoke-test it there, not in dev.
-
-Also apply the `advisory-hub` skill's §E techniques where they fit — mutation-test any seam a new test
-claims to prove, and if a cross-review provider timed out, try the other configured provider before
-recording "inconclusive."
-
-## Step 3 — adjudicate deviations
-
-For each deviation the report lists: is it a locked decision in advisory-context §4? If so, this is a
-**Hub decision, never the implementer's** — rule allowed / reverted / plan amended, and record the reason.
-
-## Step 4 — plan drift
-
-If the report's SURPRISES / CONTRADICTIONS section is non-empty: correct the plan file's
-`## Current state` **now, in this step** — do not defer it to a note in the verdict. This is the Hub's
-job and the step most likely to be skipped (`advisory-hub` skill §F).
-
-## Step 5 — write the verdict
-
-Write `.caddis/advisory-hub-reports/phase-NN.verdict.md` beside the report, using the `advisory-hub`
-skill's §C template in full, including the mandatory **WHAT IS NOW STRUCTURAL** table.
-
-> **Give it OKF frontmatter — `type` is REQUIRED and its absence is a defect.**
-> Keep it flat (scalar `key: value` only; nested maps and lists defeat simple parsers):
-> ```yaml
-> ---
-> type: phase-verdict
-> plan: <path to the plan>
-> phase: 12          # or 10-11 for a batched pair
-> milestone: M4
-> verdict: accept | accept-with-correction | reject
-> ---
-> ```
-> `verdict` is the one field a tool can read to answer *"was this phase signed off"* without parsing prose — and a prose scraper gets that wrong quietly.
-
-
-## Step 6 — push every correction into `advisory-context.md`
-
-A correction that lives only in this verdict file dies with the session that reads it; a correction told
-to the implementing session dies with that session too, which has already closed. Every correction in
-"WHAT IS NOW STRUCTURAL" must actually be landed in the named section of `advisory-context.md` in this
-step, not just described.
-
-## Step 7 — update the reports-directory index
-
-Add or update this phase's row in `.caddis/advisory-hub-reports/README.md` (Phase | Report | Verdict |
-Outcome | Date).
-
-## Step 8 — tell the implementing session (Claude Code only, optional)
-
-The verdict file is the decision. This step only saves the user from carrying it by hand.
-
-If `ListAgents` is available, look for a peer session whose name starts with **this repo's directory
-name** — sessions are auto-named `<repo-dir>-<hash>`, so in a repo directory called `acme-api`,
-`acme-api-91` is a session in this repo and `other-project-e8` is not. If exactly one such peer
-exists, it is the implementer:
-
-```
-SendMessage({to: "<peer-name>", summary: "phase-05 verdict",
-             message: "phase-05.verdict.md written — verdict: accept-with-correction. "
-                      "Corrections are in the file and in advisory-context.md."})
-```
-
-Send the **headline and the filename**, never the whole verdict. The file is the record; the message
-is a doorbell. A chat message cannot be re-read next week; `phase-05.verdict.md` can.
-
-**Do not do any of this if:**
-
-- there is no `ListAgents` — caddis also runs on agy and Codex, which have no cross-session
-  messaging. The file-based flow is the portable one and works everywhere. This step is an
-  accelerant, not a requirement.
-- **more than one** same-repo peer is listed. Guessing which is the implementer is worse than not
-  sending — say so to the user and let them name it.
-- you are headless. There is no one to save a copy-paste for.
-
-**Never ask the peer to run something your own session was denied.** Permission boundaries are
-per-session; routing blocked work through another session launders the user's decision. Route it back
-to the user instead.
-
-## Rules
-
-- **Fail closed.** A gate you could not re-run is `NOT RE-RUN`, never `PASS`. A claim you could not
-  reproduce is `UNVERIFIABLE`, never `AGREES: YES`.
-- **Never accept a claim on the report's own word.** That is the one failure mode this command exists to
-  prevent.
-- If a cross-review provider times out, try the other configured provider before recording
-  "inconclusive" — a single provider's outage is not grounds for skipping independent review.
-- **The Hub is not exempt from its own contract.** If a fault traces back to advice the Hub itself gave
-  earlier, the verdict says so plainly rather than attributing it to the implementer.
-- Read-only toward the implementing session — it has already closed. Corrections land in files
-  (`advisory-context.md`, the plan), never fed back to a session that no longer exists.

package/bundles/antigravity-plugin-extras/skills/data-lineage/SKILL.md

@@ -1,158 +0,0 @@
----
-name: data-lineage
-description: Generates End-to-End Data Lineage and Telemetry Specifications linking UI pages, API routes, database datasets, and ETL/SP producers for watch-sight observability.
----
-
-# Data Lineage Skill
-
-This skill generates End-to-End Data Lineage and Telemetry Specifications for enterprise applications. It bridges the gap between frontend user surfaces, backend API routes, relational database objects, and upstream data producers (ETLs, Stored Procedures, and SQL Agent jobs).
-
-The resulting specifications serve as the ground truth for estate-wide observability in **watch-sight** to enable automated dependency graphs, health probing, and blast-radius impact analysis.
-
----
-
-## Mandatory Workflow Steps
-
-### Step 1: Codebase & Infrastructure Discovery
-Conduct targeted research across the target application and observability repositories:
-1. **Frontend Surfaces:** Inspect `frontend/src/routes/` or router configurations to identify all user-facing pages, views, and navigation tabs.
-2. **API Routes:** Inspect `src/api/routes/` or API routers to map every HTTP endpoint invoked by each frontend page.
-3. **Database Repositories & SQL Queries:** Trace API controllers into data services and repositories to identify exact SQL tables, views, and columns accessed.
-4. **Data Producers & Execution Timings (DB Server SPs & ETLs):** Identify the scheduled jobs, batch Python scripts, and SQL Server Stored Procedures that populate, calculate, or refresh each dataset. Discover their exact execution timings, run frequencies, and triggers (e.g. SQL Server Agent schedules, Windows Task Scheduler jobs, cron expressions, email triggers, or polling loops from runbooks and pipeline schedule references).
-5. **Physical Estate Host Resolution:** Query `E:\Projects\watch-sight\config\monitor-targets.json` and `docs/runbooks/estate-pipelines/` to resolve physical server hostnames, IP addresses, ports, database instances, and service accounts.
-
-### Step 2: Markdown Document Authoring
-Draft the canonical Data Lineage Markdown file:
-`docs/<app>/<app>-data-lineage.md`
-
-Follow the standard 5-section lineage structure detailed below.
-
-### Step 3: Confluence XHTML Compilation & Verification
-Compile the Markdown document into Confluence Storage Format XHTML using:
-```powershell
-python scripts/convert_doc_to_confluence.py docs/<app>/<app>-data-lineage.md --output docs/<app>/<app>-data-lineage.html --diagram-type plantuml
-```
-Verify that the output compiles as well-formed XML without errors.
-
----
-
-## Standard Lineage Document Structure (Markdown)
-
-Every lineage document must follow this standardized 5-section structure:
-
-```markdown
----
-type: lineage
-status: current
-feature: <app>-data-lineage
-creation-agent: caddis
-Creating Model: <active model ID, e.g. gemini-3.8-flash>
----
-
-# <App Title> — End-to-End Data Lineage & Telemetry Specification
-
-## 1. Physical Estate & Host Infrastructure
-Detail the physical hosts, IP addresses, ports, database instances, and network access paths:
-- Application Host (Web server, reverse proxy, ports)
-- Primary Database Host (SQL Server, database instance, port, auth mechanism)
-- Ingestion & Staging Host (Batch runner, scheduled jobs, agent services)
-- External Feeds & Gateways (SFTP drops, upstream BSS/mediation systems)
-
-## 2. End-to-End Dependency & Impact Flowchart
-Provide a colorful, professional Mermaid diagram (`flowchart TD` or `flowchart LR`) illustrating the 5-tier dependency pipeline:
-Upstream Ingestion -> Processing / DB Stored Procedures -> Database Tables/Views -> API Routes -> Frontend UI Pages.
-- Use explicit classDef pastel styles (never raw yellow boxes).
-- Group layers into clear subgraphs.
-
-## 3. Comprehensive Database Lineage Matrix
-A comprehensive table specifying the complete end-to-end data lineage across the following mandatory columns:
-| App | UI Page | API Route | Dataset (Tables / Views) | Producer (ETL / SP / Job) | Execution Timing / Trigger | Database | Physical Host |
-|---|---|---|---|---|---|---|---|
-| ... | ... | ... | ... | ... | ... | ... | ... |
-
-Column specifications:
-- **App:** Application identifier (e.g. `billing-portal`).
-- **UI Page:** User interface page path and title (e.g. `/runs (Run Monitor)`).
-- **API Route:** HTTP method and endpoint (e.g. `GET /api/runs`).
-- **Dataset:** Schema-qualified tables or views read (e.g. `[dbo].[CDR_RUN_LOG]`).
-- **Producer:** Exact SQL Agent job name, batch ETL script, or DB Stored Procedure that populates or refreshes the dataset.
-- **Execution Timing / Trigger:** Exact schedule, frequency, and trigger mechanism (e.g. `Daily 07:00 UTC (SQL Agent)`, `Nightly 08:00 UTC (Task Scheduler)`, `Every 5 min polling (Background Service)`).
-- **Database:** Target database name (e.g. `CDR`, `CERILLION`).
-- **Physical Host:** Hostname and IP (e.g. `iegew3ccdr01 (100.126.185.4)`).
-
-## 4. Stored Procedures & Producer Execution Catalog
-Catalog the database server stored procedures and scheduled jobs that populate the datamart:
-- Sequential execution order reference table detailing every job in execution order, execution time, host machine, scheduler, and dependencies.
-- Detailed procedure profiles: Procedure Name, database instance, trigger mechanism, exact schedule, parameters, source tables read, and target tables written.
-
-## 5. watch-sight Telemetry Ingestion Contract
-Provide a machine-readable JSON specification block aligned with `watch-sight/config/monitor-targets.json` implementing the **Three-Tier Real-Time Schedule Discovery Hierarchy**:
-- **All Producers Represented:** Every single producer (ETL script, SQL Agent job, Stored Procedure) cataloged in Section 4 must be represented in the telemetry contract.
-- **Tier 1 (Live Scheduler Discovery):** Define authoritative real-time queries against OS and DB schedulers (`msdb.dbo.sysschedules` / `msdb.dbo.sysjobschedules` for SQL Agent jobs; PowerShell `Get-ScheduledTaskInfo` for Windows Task Scheduler) so monitoring automatically tracks schedule changes made by operators in real time without documentation drift.
-- **Tier 2 (Execution Audit Telemetry):** Define queries against application execution audit tables where available (`[dbo].[ETL_AUDIT_LOG]`, `[dbo].[CDR_LOAD_LOG]`, `[dbo].[cdr_validation_run]`, `msdb.dbo.sysjobhistory`) for actual runtime watermarks, durations, and status. If an application lacks audit tables, Tier 2 is omitted and Tier 1 scheduler status is used.
-- **Tier 3 (Static Baseline Fallback):** Define static baseline fallback schedules and maximum allowable runtimes as a safety guardrail when live probes are momentarily unreachable.
-- `hosts` & `db_ping_targets`
-- `pipeline_producers` (with Tier 1, Tier 2, and Tier 3 blocks)
-- `continuous_services`
-- `application_components`
-- `blast_radius_rules`
-```
-
----
-
-## Diagram and Conversion Standards (Expert Systems Architect & Mermaid Designer)
-
-### 🎨 Design & Styling Principles
-1. **Color Palette & Semantic Styling (Standard/Impact/Existing):**
-   - Use desaturated, modern executive colors. Do not use highly saturated primary colors.
-   - Define exactly 3-4 standard semantic class styles at the top of every diagram:
-     - `existingStyle`: Clean Blue (`fill:#EFF6FF,stroke:#2563EB,stroke-width:2px,color:#1E40AF`) for legacy/established components.
-     - `newStyle`: Warm Red/Crimson (`fill:#FEF2F2,stroke:#DC2626,stroke-width:2px,color:#991B1B`) for greenfield/new components.
-     - `impactedStyle`: Amber/Gold (`fill:#FFFBEB,stroke:#D97706,stroke-width:2px,color:#92400E`) for modified/impacted systems.
-   - Apply classes consistently to the nodes using the triple colon notation (e.g., `NodeName:::newStyle`).
-2. **Diagram Scalability Settings (Initialization Block):**
-   - Always prepend diagrams with a configuration initialization block to control sizing and font scales:
-     ```mermaid
-     %%{init: { 
-       'theme': 'default', 
-       'themeVariables': { 'fontSize': '14px', 'subgraphTitleSize': '16px' }, 
-       'flowchart': { 'useMaxWidth': false, 'htmlLabels': true, 'curve': 'basis' } 
-     } }%%
-     ```
-3. **Readable Text Wrapping:**
-   - Never let a single node have a long horizontal text block. Use `<br/>` tags to stack text vertically.
-   - Format nodes with clear visual hierarchy: Use bolding for titles, bracket notation for IDs, and italics for status:
-     `NodeName["📅 <b>Windows Scheduler</b><br/>[SYS_03]<br/><i>New Component</i>"]`
-
-### 📐 Layout & Real Estate Rules
-1. **The 3-Column Kanban Layout (Side-by-Side):**
-   - When sequential phases are required (e.g., Phase 1 | Phase 2 | Phase 3) but need to prevent horizontal text compression, utilize a "Hybrid Columnar Layout".
-   - **Rule:** Set the top-level flow to Left-to-Right (`flowchart LR`) to align parent containers horizontally, but enforce vertical stacking (`direction TB`) *inside* each subgraph container.
-   - **Example Structure:**
-     ```mermaid
-     flowchart LR
-         subgraph Phase1["Phase 1"]
-             direction TB
-             A --> B --> C
-         end
-         subgraph Phase2["Phase 2"]
-             direction TB
-             D --> E --> F
-         end
-         Phase1 --> Phase2
-     ```
-2. **The Two-Line Grid Layout (Row Stacking):**
-   - When a 3-pillar horizontal layout spans too wide, stack them into rows by setting the top-level structure to Top-to-Bottom (`flowchart TD`).
-   - Group the lower pillars (Phase 2 and Phase 3) side-by-side inside a helper subgraph container that uses `direction LR`. This forces Phase 2 to wrap onto a new line directly below Phase 1.
-3. **Component Types:**
-   - Use standard flowchart shapes to represent structural entities:
-     - `[(Database Node)]` for persistent storage, tables, or file outputs.
-     - `["Application Node"]` for processing scripts, APIs, or services.
-     - `["🖥️ UI Node"]` for user interfaces.
-4. **Dynamic Layout & Sizing:** Do not fix exclusively to Left-to-Right (`flowchart LR`) or Top-to-Bottom (`flowchart TD`). Choose the layout dynamically based on component count and readability:
-   - Use `flowchart LR` for simple linear flows with few components.
-   - Use `flowchart TD` or mixed subgraphs when there are many layers or components to prevent excessive horizontal stretching.
-5. **PlantUML Engine & Crisp Proportioning:** Diagrams convert via `convert_doc_to_confluence.py` using `scale 1.2` for flowcharts, `scale max 2000 width` for sequence diagrams, `skinparam defaultFontSize 11` (no `skinparam dpi 200` to prevent blowout), natural curved splines (omit `polyline` / `ortho`), tightened whitespace (`nodesep 24`, `ranksep 28`, package `Padding 10`), distinct 1.5px border outlines (`#FEF2F2;line:DC2626` for crimson red impacted borders, `#EFF6FF;line:2563EB` for deep blue existing borders), and cross-package `norank` connectors to guarantee sharp, readable, properly proportioned text in Confluence.
-6. **No Cluttered Labels or Overlapping Text:** Omit stereotypes (`<<impacted>>`, `<<service>>`) and status tags (`(New Component)`, `(Existing Platform)`) from component boxes and arrow labels. Multi-line edge labels must be wrapped at ~24 characters.
-7. **No Leaked Tags:** Never emit `<#ghost>` or unsupported formatting tags into Confluence macros. Component and connection classification is handled by the bottom legend.
-8. **Simplified Technical English (ASD-STE100):** Short sentences, active voice, and clear technical descriptions.