SHIP

A simpler design — one Lambda invocation reviewing every flagged fragment in a PR, one after another — works fine for a PR with one or two issues. It stops working once a PR has enough flagged issues that reviewing all of them, one at a time, takes longer than that single Lambda invocation is allowed to run: AWS Lambda has a hard ceiling of 900 seconds on how long one invocation may run, and nothing resets that clock partway through. A review that hits the ceiling stops with no error surfaced anywhere; the fragments reviewed before the cutoff are recorded and the rest never get a turn.

Making each fragment its own independent, queued job removes the shared clock entirely: every fragment gets its own full time budget, and fragments belonging to the same PR run concurrently rather than waiting in line behind each other. A PR with several flagged issues now takes about as long as its slowest single issue, not the sum of all of them.

Every alert write is idempotent regardless of which path a fragment took to get there: the alert's own ID is derived from the specific violation (repo, PR, file, category, and the fragment text itself), not a random ID. A retried or redelivered fragment that reaches the same real violation overwrites the same row rather than creating a duplicate — and a write can never re-freeze or overwrite an alert a human has already resolved.

One function, derive_commit_status, maps stored alerts to a state, and every path that posts a verdict uses it: the webhook, the fragment processor, Gate and Relay's voice decisions. Concurrent writers therefore converge on the same answer, and ordering stops mattering. The status goes to the pull request's current head commit, read from GitHub. The commit stored on an alert is only the fallback if that lookup fails, so a decision made long after the commit it was found on can't leave a stale status on the head.

The review ledger keeps a green result honest. Each fragment ticks itself off when it finishes, whether or not it found anything, and a duplicate SQS delivery counts once. A newer commit replaces the ledger, and a result for an older commit is ignored. If the ledger can't be read, the check stays pending and the reason is logged. A blocked finding is released by the next commit: the webhook compares that commit's flagged fragments with each held block and releases the ones whose fragment is gone. If that step fails, the finding keeps blocking.

Screener's job is to notice a candidate — a keyword, an import, a call shape — cheaply and without judgment. Detector's job is to decide whether it's real. The two are graded together: every detector above is verified against genuine violations and deliberate look-alikes engineered to trip a naive pattern match (a non-agent backup job that happens to call a dangerous function, a profile field that's merely displayed rather than scored, PII that's already hashed before use). A detector that flags the look-alike as a violation is not considered working, no matter how well it catches the real case.

The pipeline underneath is mechanically generic enough to flag other kinds of risk too, but staying scoped to AI-specific patterns is deliberate: it's the whole differentiation from a general-purpose static-analysis tool that has never heard of an LLM call. Widening scope to catch things like SQL injection would dilute that, not strengthen it.

The ASGI app is built fresh inside the handler on every Lambda invocation, not once at import time. The MCP Python SDK's Streamable HTTP session manager can enter its lifespan once per instance, and a warm container reusing a module-level app crashes the second request with "SessionManager .run() can only be called once per instance". Responses are plain JSON rather than an event stream, which a Lambda Function URL in buffered mode requires. One consequence: every invocation starts a session manager that has never seen a client, so no MCP session id can carry state between calls. That shaped the decision design below.

What SHIP exists to catch is not "a decision happened over voice". It is "a decision happened without a person engaging with what they were deciding". A person who asked to see the findings, had them rendered on a screen and then says why has done what human oversight requires. Sending them to a web form instead adds friction and no safety. What must never work is "ignore it, go ahead" with no review at all, which is the TLGP-002 shape this project flags in other people's code.

What the skill checks before Relay is called. In the guided review, plain code reads each answer and no model is involved. It asks only about findings Relay recorded as seen, and takes a decision only from a decision word in the answer, so a bare yes never decides anything. The reason is the person's own answer, and one with fewer than two content words is asked for once more and then taken as said. Each decision is staged as it is made, and only the person's yes at the end of the pull request applies the batch. For a full sentence in one go, the model reaches four tools (release_status, display_on, stage_decisions, proceed) and never sees finding text. A decision is staged only for a pull request that was shown to this person, and only as the exact word allow or block. The reason must be built from words the person said (at least two content words beyond the command, a number or a screen name, and at least 60 percent of them present in what was said this turn or in the last three exchanges). The model says "the second one"; code turns that into a finding id using the number each finding had on the screen that displayed it, and Relay only ever receives ids. A number two seen findings both claim is dropped, not guessed. Staging and proceeding never happen in one turn, and only the person's plain confirmation applies a staged batch. Saying no, cancel or stop drops it. Relay does not check that a reason is in the person's own words or that a confirmation was spoken; a client that calls Relay directly supplies both itself.

The record of what was shown is keyed on the finding with a ten-minute window (ship-recent-reviews), not on an MCP session, because a session manager built fresh on every invocation has nothing for a session id to continue. The record also stores the number the finding carried on that screen. Findings that arrive or get decided afterwards therefore can't move "the second one" onto a different finding. See docs/voice-resolution-workflow.md for the flow and the exact sentences.

A genuine compliance event happens on the order of weeks, not seconds. A display polling every few seconds would spend nearly all its traffic finding nothing changed. An idle WebSocket costs nothing until there is something to say. Every send is time-capped because the skill is waiting on Relay: each WebSocket post has a 1.0 s connect and 1.5 s read timeout, at most six connections per name are tried, and the whole push stops after 2 s. A notification send takes at most 2 s and the set stops after 2.5 s.

Feeding Detector the raw text of recent human decisions doesn't scale: after a month or two there are too many to fit in a prompt, and picking a recent subset is arbitrary. Instead, a batch job extracts a small, bounded set of generalized patterns from accumulated allowed findings, merging new evidence into existing patterns rather than appending, so the set stays small regardless of how much history exists.

Silent stalls. A disabled SQS event source mapping would leave the webhook returning 200 "accepted, queued for review" for every delivery while reviewing nothing. ship-repos tracks last_event_at alongside last_reviewed_at. A gap between the two past a 20-minute grace window (generous against the ~440 s worst Detector latency observed on a cold AgentCore container) shows as a "stuck" badge on Gate's connected-repos view.

Audit lines. Relay writes one line to CloudWatch for every decision and every refusal: the tool, the outcome, the pull request, the finding ids (first 12 characters), a short reason code, small counts and the Lambda request id. They never carry the reason a person gave or any finding text.

Delivery that survives retries. The PR comment and the Echo alert for a finding are each claimed under a short lease and marked only after a successful send. A retry finishes whichever step is missing without repeating the one already done, and a finding a person has already decided gets no new comment.