# Task for delegate

Write tests for: ${@:-the current code or context}

Structure your answer as:
1. **Existing conventions** — name patterns, framework, assertion style, fixtures; match what's already there
2. **Test cases to add** — grouped as:
   - **Happy path** — the primary expected behavior
   - **Edge cases** — empty, zero, max, boundary, off-by-one
   - **Error cases** — invalid input, missing deps, timeouts, permission failures
3. **Test code** — minimal, runnable, following the project's framework (jest, pytest, go test, etc.)
4. **How to run** — the exact command, plus how to run just the new tests
5. **Coverage gaps** — anything still untestable without a refactor; flag it but do not refactor in this pass

Keep tests independent, deterministic, and fast. Prefer many small tests over one large one. If the codebase has no test setup yet, propose the smallest viable setup and call it out clearly so the user can approve before you scaffold it.

---
Previous step output:
# Implementation Plan: Resolving Empty `${@}` Placeholder in `p-plan.md`

> **Note on input:** The task argument arrived as the literal sentinel `${@:-the current task}` — the shell's default-value expansion never resolved because no real argument was passed. The previous `p-brainstorm` step (severity: blocker) flagged the identical issue. I will not fabricate a plan against a placeholder; instead, the plan below scopes the *real* work that must happen first: obtaining a concrete task. Once a real task is supplied, this artifact is re-runnable against it.

---

## 1. Goal
Produce a concrete, verifiable implementation plan for a real task by closing the input-validation gap in the `p-plan` prompt (and sibling `p-*` prompts) so a missing argument yields a clarifying question instead of a placeholder-substituted phantom task.

## 2. Constraints
- **No implementation yet.** This step only produces a plan; the parent decides whether to execute.
- **Working directory:** `/home/liph/dotfiles/pi/.pi/agent/prompts/` — contains 12 `p-*.md` prompts and 4 `c-*.md` commands, all using the same `${@:-...}` pattern.
- **Existing contract:** the `p-plan` body mandates a 7-section format (Goal, Constraints, Approach, Steps, Verification, Risks & Rollbacks, Open Questions). Any new validation must preserve that contract when a real task *is* supplied.
- **Acceptance contract (from parent):** attested level; final reply must end with a fenced `acceptance-report` JSON block; `criteriaSatisfied[].status` ∈ {satisfied, not-satisfied, not-applicable}; `commandsRun[].result` ∈ {passed, failed, not-run}.
- **No write tools in scope** for the current run (review/find only) — if the parent wants the prompt edited, it must do that itself or assign a write-capable subagent.
- **Subagent role:** I am a delegated worker, not the orchestrator. I must not propose further subagents; I report findings only.

## 3. Approach
Adopt the **"refuse and ask"** strategy recommended by the prior `p-brainstorm` step (Approach A, score 5/5 on fit). Treat the placeholder as a blocking precondition, not a topic to plan around. The plan's *Steps* therefore describe the smallest set of clarifications and follow-up actions the parent must take to unblock a real plan.

Rationale: every other branch (infer from context, meta-plan the prompt) requires a writeable surface or risks guessing wrong. Refusal is the only branch that is reversible, low-cost, and aligned with the prompt's own "ask clarifying questions" rule.

## 4. Steps
1. **Confirm the input is empty** — re-read the rendered argument; verify it equals the sentinel `${@:-the current task}` rather than an empty string. *(This step is satisfied: the prior step's diff confirmed the sentinel leaked through.)*
2. **State the blocker explicitly** to the parent, naming the sentinel and the file responsible (`p-plan.md` line 4).
3. **Request the minimum task shape** needed to re-emit a real plan: target system/codebase, user/audience, desired change, acceptance bar, hard constraints (language, runtime, deadline, regulatory).
4. **Offer the meta-fallback** (Approach C from the brainstorm): if the actual goal is to harden the `p-*.md` prompt family, the parent can confirm and the next plan will cover input validation, sentinel detection, and failure-mode UX.
5. **On receipt of a real task:** re-run this prompt with the task substituted, then verify all 7 sections of the produced plan against the acceptance contract.
6. **On receipt of "harden the prompts":** produce a follow-up plan covering (a) sentinel detection in the prompt loader, (b) clarifying-question branch, (c) regression test using a sample invocation with an empty arg, (d) roll-forward migration for the other 11 `p-*.md` files.

## 5. Verification
- **Step 1:** re-render `${@}` via the same shell that invoked this prompt; confirm sentinel presence. *(Already done by the parent before this delegation.)*
- **Step 3:** parent's reply contains at least the 5 fields listed (target, user, change, acceptance, constraints).
- **Step 5:** re-issued plan contains 7 sections, each non-empty, no `TBD` placeholders, all `Open Questions` either resolved or explicitly deferred with a reason.
- **Step 6:** follow-up plan names all 12 `p-*.md` files and the 4 `c-*.md` commands; lists the migration order (lowest-risk prompts first, e.g. `p-explain.md` before `p-brainstorm.md`).
- **Acceptance report:** final reply ends with a parseable JSON `acceptance-report` block; `criteriaSatisfied[].status` values are valid; `commandsRun[]` reflects only what was actually run.

## 6. Risks & Rollbacks
- **Risk: parent interprets refusal as a hang.** Mitigation: this reply is the refusal, with a single concrete question, so no rollback is needed.
- **Risk: meta-fallback (Step 4) is misread as scope creep.** Mitigation: explicitly framed as a branch the parent must opt into; default branch is "supply a real task."
- **Risk: a follow-up subagent re-introduces the sentinel** by echoing `${@:-...}` in its own template. Mitigation: the follow-up plan (Step 6c) should require a grep-based check that no rendered output contains the literal string `${@:-`.
- **Rollback:** this artifact is review-only; nothing was written, so "rollback" is just discarding this reply and re-invoking with a real task.

## 7. Open Questions (require parent decision before any real planning)
1. **What is the actual task?** (Required — see brainstorm's Unknown #1.)
2. **Is the user available now, or is this an autonomous run?** If autonomous and the parent can supply context, I can attempt context-inferred planning (Approach B from the brainstorm) on the next turn.
3. **Is the goal to fix the `p-*.md` prompt family itself?** If yes, switch this plan to Step 6's scope.
4. **Which subagent gets write access to `p-*.md`?** I do not, and the parent should not assume I will.
5. **What is the deadline for a real plan?** Drives whether to spend a turn on clarification or accept a lower-confidence inference.

---

## Acceptance Contract
Acceptance level: reviewed
Completion is not accepted from prose alone. End with a structured acceptance report.

Criteria:
- criterion-1: Implement the requested change without widening scope
- criterion-2: Return evidence sufficient for an independent acceptance review

Required evidence: changed-files, tests-added, commands-run, validation-output, residual-risks, no-staged-files

Review gate: required by reviewer.

Finish with a fenced JSON block tagged `acceptance-report` in this shape:
Use empty arrays when no items apply; array fields contain strings unless object entries are shown.
`criteriaSatisfied[].status` must be exactly one of: satisfied, not-satisfied, not-applicable.
`commandsRun[].result` must be exactly one of: passed, failed, not-run.
`manualNotes` and `notes` are optional strings; an empty string means no note and does not satisfy `manual-notes` evidence.
```acceptance-report
{
  "criteriaSatisfied": [
    {
      "id": "criterion-1",
      "status": "satisfied",
      "evidence": "specific proof"
    },
    {
      "id": "criterion-2",
      "status": "satisfied",
      "evidence": "specific proof"
    }
  ],
  "changedFiles": [
    "src/file.ts"
  ],
  "testsAddedOrUpdated": [
    "test/file.test.ts"
  ],
  "commandsRun": [
    {
      "command": "command",
      "result": "passed",
      "summary": "short result"
    }
  ],
  "validationOutput": [
    "validation output or concise summary"
  ],
  "residualRisks": [
    "none"
  ],
  "noStagedFiles": true,
  "diffSummary": "short description of the diff",
  "reviewFindings": [
    "blocker: file.ts:12 - issue found, or no blockers"
  ],
  "manualNotes": "anything else the parent should know"
}
```