contract-status

name	contract-status
description	Show the current status of a contract (or all in-flight contracts) right in the CLI — phase, SLA time-left (IST + UTC), readiness, and the next action. Use when the user says "status", "where are we", "what's in flight", "time left", or invokes `/status [<ID>]`.

Contract status

A quick "where does this stand" view, computed deterministically — no LLM guessing about phase or time. Powered by validate.mjs --status.

Usage

• /status <ID> — one contract
• /status — every contract currently in flight (status promoted and not yet landed), most-urgent first

One contract

Run:

node <plugin-root>/scripts/validate.mjs --status .manifest/contracts/<ID>.md

It prints (deterministically from the contract frontmatter):

AUTH-12 — Resend OTP on login
  phase:     ② In review
  ⏳ SLA: 23h 14m left (due 2026-05-21 13:30 IST / 2026-05-21 08:00 UTC)
  readiness: review_needed  ·  promotable: ✅ (0 blockers, 2 advisory warnings)
  next:      promote, or address warnings first

Relay it as-is. If --status exits non-zero, the SLA is overdue — call that out. Lead with promotable (0 open blockers) — that's the real gate. When promotable is true, say so even if readiness is review_needed; open warnings are advisory and never block, so a dev isn't stuck. (Read open blocker/warning counts from the latest <ID>.findings.json if present.)

Who holds the ball (PM accountability). If the contract has a pickup.ballLog, compute the ledger — node scripts/ready-check.mjs --ledger <ballLog.json> <slaHrs> <promotedAt> — and lead with it when the ball is with the PM. The SLA is charged only for dev-side time, so report the effective SLA (paused while blocked on PM), not raw elapsed:

🟡 blocked on PM 2d 4h (SLA paused) · dev used 6h/48h · 2 bounces
   → nudge the PM, or proceed on the dev's assumption

This is the anti-blame line: a dev is never shown as overdue for time the PRD gap left the ball with the PM.

All in-flight (the dashboard)

1. List .manifest/contracts/*.md (exclude .findings.md, .r*.md, .deploy-*, .launch-report-*, .bug-log.md, .decomposition.md, and .fixes/).
2. For each whose status is promoted and landed is unset, run --status.
3. Sort by SLA urgency: overdue first, then least time left.
4. Print a compact table:

IN FLIGHT (3)

⚠️  AUTH-12  ② In review        SLA OVERDUE by 1h 20m        → review + merge
⏳⚠️ SC-007   ③ Canary rollout    3h 10m left                  → approve next stage
⏳  PAY-3    ② Building          18h left                     → @claude /implement PAY-3

Epics: AUTH-30 (3/4 children shipped)

5. If nothing is in flight, say so and suggest /contract new or /fix.

Epic rollup — /status <epic-ID> (multi-person feature view)

When the ID is an epic (type: epic with children: [...]), show the whole feature in one glance instead of per-contract. This is the coordination view for a feature worked by several people across repos.

1. Read the child contracts listed in children. For each, collect { id, owner, repo, size, status, landed, dependsOn }.
2. Compute the rollup deterministically: node scripts/ready-check.mjs --rollup <children.json>. It returns per-child state (landed / blocked / ready / in-flight status), each blocked child's blockedBy, the critical path, done/total, and landed (true only when every child has landed).
3. Render — lead with the finish line and the critical path, group by owner:

EPIC  SC-100 · Saved cards at checkout        2/4 shipped · not landed
critical path:  SC-a → SC-b → SC-d
success metric: +6% checkout conversion (measured once the feature lands)

  @be-dev    SC-a  backend  ✅ landed
  @fe-dev-1  SC-b  web      ② building
             SC-d  web      ⛔ blocked — waiting on SC-b, SC-c
  @fe-dev-2  SC-c  web      ▶ ready to start (deps met)

next: SC-c is unblocked — @fe-dev-2 can start. SC-d is the critical-path tail.

4. Feature accountability — a feature isn't "done" because one dev finished; it lands only when all children land and the metric moves. Lead with any cross-child block (who's waiting on whom) so nobody stalls silently, and pair it with the PM ledger (blocked-on-PM) where relevant.

Notes

• Times always show BOTH IST and UTC (the validator's formatter does this; don't reformat).
• This is read-only — it never changes a contract. Safe to run anytime.
• For an epic, show child progress (how many children have landed).
• Phase and next-action come from derivePhase in the validator, so they're consistent with what every other update shows.

Anti-patterns

• Don't recompute phase or time-left by hand — use --status so it matches every other surface.
• Don't list landed/closed contracts in the in-flight view (only promoted-and-not-landed).