Ship Web

---
description: Plan → review → implement → PR pipeline for an srs-web feature. Autonomous between human checkpoints.
argument-hint: <feature description, or issue #N>
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, Agent, TodoWrite, WebFetch
---

# /ship-web — srs-web feature pipeline

You are running the full delivery pipeline for this srs-web feature:

> $ARGUMENTS

Run autonomously between stages — do not pause for minor decisions you can resolve from context. Use TodoWrite to track the stages below and work through them in order.

The pipeline runs to a **single terminal state inside this session**: PR open with CI green, everything (including dogfooding) verified pre-merge. It does **not** wait for a human to merge and then resume — never schedule a follow-up routine to "come back after merge". The issue auto-closes via `Closes #N` on merge.

There are two **deliberate human checkpoints** where you stop and wait for input:

| Checkpoint | Stage | When |
|---|---|---|
| WASM/spec gate | 1.5 | Feature requires a new WASM binding or spec change → file dependency issue, stop |
| Design decisions | 2 | Long-term architectural choices → present trade-offs, wait for input |

The pipeline then ends at **Stage 9** (PR open + CI green) — a terminal handoff, not a resume point.

Outside the two checkpoints, keep going. If a stage is genuinely blocked (auth failure, unresolvable rebase conflict, missing WASM binding, ambiguous requirement), stop and report.

All web work happens in `srs-web/`. Run `git` from `srs-web/`, never from the `semanticops/` parent (it is not a git repo).

---

## Stage 0 — Preflight

1. Confirm a commit-signing method is available (commits will fail otherwise). The required check depends on the environment:
   ```bash
   if ssh-add -l 2>/dev/null | grep -q "SHA256:vHuO6si5w3RLL4IJZofWbyvEi42WA2fYX7bM"; then
     echo "OK: local SSH signing key loaded in agent"
   elif [ ! -f "$HOME/.ssh/id_ed25519_git_signing.pub" ]; then
     echo "OK: cloud/remote environment — platform provides its own commit signing, ssh-agent not used"
   else
     echo "SIGNING KEY NOT LOADED — local key file present but not in agent"
   fi

• Local (the signing key file exists under ~/.ssh): the key must be loaded in the ssh-agent. If you see SIGNING KEY NOT LOADED, stop and tell the user — do not bypass signing.
• Cloud / remote agent (no local signing key file, e.g. a scheduled CCR run): the ssh-agent is not used — the platform signs commits with its own method. Proceed; do not stop on the ssh-agent check.

In both environments use plain git commit — never --no-gpg-sign. 2. Confirm gh auth status succeeds. If not, stop. 3. Confirm you are working in srs-web/ (/home/greenman/dev/semanticops/srs-web). This command is for srs-web only — redirect Rust or spec work to /ship.

Stage 1 — Issue

• If $ARGUMENTS references an existing issue (#N or a URL), fetch it with gh issue view N --repo the-greenman/srs-web and use it as the brief.
• Otherwise create one:

  gh issue create --repo the-greenman/srs-web \
    --title "<concise title>" \
    --body "<one-paragraph problem statement>"
  

  Capture the issue number — every later stage refers to it.

Stage 1.5 — Dependency gate

Before writing any plan, determine whether this feature requires:

(A) A new or changed WASM binding — i.e., a new method on the WASM API surface that doesn't yet exist in srs-rust. This is required if the feature needs to:

• call a new SRS operation (create/update/delete/validate/query) not already exposed,
• return a new payload shape, or
• accept new input parameters not in the current WASM API.

Check the existing WASM surface in srs-web/src/wasm/ or the current srs-rust bindings.

(B) A change to the SRS specification (srs/ repo) — new field, type, relation type, extension, or changed validation semantics.

If either is required:

1. File a dependency issue in the appropriate repo:
   • WASM binding: gh issue create --repo the-greenman/srs-rust --title "WASM: <binding needed>" --label "wasm,enhancement" --body "<what method is needed, its signature, and which srs-web feature depends on it>"
   • Spec change: gh issue create --repo the-greenman/srs --title "RFC: <title>" --label "rfc" --body "<problem, proposed change, open questions>"
2. Post a comment on the srs-web issue linking the dependency and explaining that implementation is blocked.
3. Stop — return to the user with the dependency issue URL. No planning, no implementation until the dependency is resolved.

If no dependency is required: state this explicitly (one sentence) and continue to Stage 2.

Stage 2 — Plan

1. Read the template at srs-web/plans/TEMPLATE.md and the role definitions at srs-web/plans/agents.md. Review the agent list — if this feature needs a role not yet defined, add it to agents.md before writing the plan.
2. Write a draft plan to srs-web/plans/<slug>.md, filling every section of the template. A plan that needs human interpretation at execution time is incomplete.
3. ADR check: read every file in srs-web/docs/adr/. Identify:
   • Existing ADRs that govern choices in this plan (cite them in the Architecture Decisions table — at minimum reference ADR-001).
   • Choices that require a new ADR — any decision that establishes a new architectural constraint, rejects a plausible alternative others might revisit, or changes a prior decision.
4. Design decision pause: before finalising the plan, identify any decision with long-term consequences — a new WASM API shape that srs-rust will need to implement, a new component architecture or routing pattern, a new TS type contract, or anything that would be painful to reverse later. For each such decision, present it clearly to the user with the trade-offs and wait for their input before continuing. Record their decision in the plan's Architecture Decisions table (an