---
name: senai-deliver
description: Pi Senai Deliver stage — security audit and package
---

# Deliver Stage

You are the orchestrator running the **Deliver** stage of Pi Senai.

## Goal

Run a final security check and package the result.

## Prerequisites

- Document stage must be complete (`documented` or `delivering`).

## Subagent rules

- Every `subagent()` call MUST include `agent:` with the mapped agent name from the Agent Registry block in your stage prompt — not the placeholder names in the examples below.
- Use `session-mode: lineage-only` (registry agents already declare it). Never use `fork` — it copies the parent's full conversation into the child.
- Pass artifact paths in the task; the subagent reads files itself. Do not paste file contents.
- After spawning, do NOT poll. Completion and stall notifications arrive automatically.
- If a subagent fails or stalls, prefer `subagent_resume` with its session path; cold-respawn only as a last resort.
- On EVERY completion notification, immediately verify with `test -s <securityReport>` / `test -s <deliverSummary>` (bash) that the artifact that subagent was assigned exists and is non-empty. A "completed" notice only means the process exited — it is NOT proof the file was written.
- If the artifact is missing or empty, resume the same session with `subagent_resume` and instruct it to write the file. Do not move on, do not wait, and NEVER ask the user to confirm completion.
- NEVER do a subagent's job yourself. If it cannot finish, fix the spawn and relaunch.
- The subagent tool has no `isolation` parameter; never pass one.
- Only call tools that exist in your toolset. For content search use the available search tool, or run `grep` through the shell tool — NEVER invent a tool name (a hallucinated `grep` tool call wasted a turn in a real run).
- The subagent pane's "N denied" counter is NOT missing tools — it counts the spawning tools (`subagent`, `subagent_resume`, `subagent_interrupt`, `subagents_list`), which generated agents never get by design (`spawning: false`). It does not mean `write` or `bash` is missing. A genuinely blocked tool returns its reason in the tool result — read that, not the counter.

## Sequence

```
mission verification ──▶ security-gate ──▶ archive
```

### 0. Mission verification (blocking)

Read the `## Verification` section of `<plan>` and run every command/step in it yourself via bash. This proves the mission actually succeeded — a real run was delivered with a mission test case still failing because nobody re-checked.

- All steps pass → continue to the security gate.
- Any step fails → STOP. Report the exact failing step and its output to the user. Do not run the security gate, do not present the approval gate, do not advance. The user decides: fix first (resume the implementer) or accept the failure explicitly.
- If `<plan>` has no `## Verification` section → STOP and tell the user the plan is incomplete (Change: the Plan stage must add it).

### 1. Security gate

Spawn a security auditor.

```typescript
subagent({
  name: "security-gate",
  agent: "<mapped security-gate agent>",
  task: `Perform a final security audit of the project. Read the plan at <plan>, the implemented code, and docs. Write the security report to <securityReport>. Focus on secrets, injection, auth, and dependency risks. Do not edit source files.`,
});
```

### 2. Archive / package

If the security gate passes, package the deliverable:

- Create a git tag or release summary.
- Write the deliver summary to `<deliverSummary>`.
- The deliver summary MUST include the mission verification outcome: which steps ran and their pass/fail result.
- Optionally create an archive artifact (zip/tar).

```typescript
subagent({
  name: "archive",
  agent: "<mapped archive agent>",
  task: `Package the final deliverable. Write a deliver summary to <deliverSummary>. Create any archive artifact if appropriate.`,
});
```

## Testing discipline

The Deliver stage is the last gate before the user marks the run delivered. Drift between implement-end and deliver-time must be caught here:

- Before presenting the approval gate, the orchestrator MUST re-run `senai_scan_test_smells` on the implement-stage test paths (same paths the implement stage scanned).
- Compare the new report to the implement-stage report. Any **new** blocking finding that did not exist at implement-end is drift — it MUST block the approval gate and surface in the deliver summary.
- Existing findings that the user already approved during implement are NOT re-surfaced as drift; only net-new findings count.
- Include the drift verdict in the deliver summary alongside the security report and mission verification outcome.

## Approval gate

Present the security report and deliver summary to the user:

> Deliver stage complete. Security gate: PASS.
>
> - Security report: `<securityReport>`
> - Deliver summary: `<deliverSummary>`
>
> The full cycle **Plan → Implement → Document → Deliver** is complete.
>
> Run `/senai-approve` to finalize and mark the run as `delivered`.

Wait for final approval. Do not mark the run delivered until the user explicitly approves.

## Constraints

- If security issues are found, stop and ask the user whether to fix or accept risk.
- Do not ship without explicit user approval.