# Task for delegate

Generate a commit message for: ${@:-the current uncommitted changes (run git status / git diff first)}

Structure your answer as:
1. **Type & scope** — one of: feat, fix, refactor, perf, test, docs, build, ci, chore, style; scope is the affected module/subsystem
2. **Subject** — imperative mood, ≤72 chars, no trailing period, no emoji
3. **Body** — wrapped at 72 cols, explain *why* not *what*. Use bullet points for multiple distinct changes.
4. **Footer** — `BREAKING CHANGE: …` if applicable; `Refs: #123` for linked issues
5. **PR description** (if the change is non-trivial) — Summary, Motivation, Changes, Test plan, Risks

Format the final message in a single fenced block ready to copy. If the change spans multiple logical commits, propose a split with one subject per commit and the file groups that belong in each.

Read the diff before writing — never invent files, symbols, or behavior. If `git status` is empty or the diff is unclear, ask before fabricating.

---
Previous step output:
I've now verified the full situation:

1. The task arrived as the literal string `Write tests for: ${@:-the current code or context}` — the `${@:-...}` is the prompt template, and the shell expansion has resolved the inner default value to `the current code or context` only because the argument was empty. There is no actual file, function, or feature named.
2. The working directory is a dotfiles repo containing pi agent prompt markdown files — no source code, no test framework, no `package.json` at the repo root, no build system. The only code-shaped assets are two unrelated `package.json` files for pi extensions.
3. I have read tools (this subagent) but no write/edit tools, and even if I did, there is no code in this directory to test.

The honest, useful response is to apply the same "refuse and ask" strategy the previous step used, then show what I *would* produce the moment a real target arrives. Let me also verify the only realistic alternative (treating the p-test.md / p-plan.md prompt family itself as the test target) before declining.

**Decision: stop and ask for the actual target.** I will not invent tests for unspecified code.

---

## Status: blocked on the same `${@:-...}` placeholder the previous step flagged

I am the `p-test` subagent. My template's first line is literally `Write tests for: ${@:-the current code or context}`. The shell that invoked me passed no arguments, so the default-value expansion substituted `the current code or context` — a description, not a target.

### What I confirmed in this session
- **Argument was empty** — `echo $#` → `0`; quoted expansion rendered the default.
- **No code exists in the working directory** — `/home/liph/dotfiles/pi/.pi/agent/prompts/` contains 12 `p-*.md` prompt templates, 4 `c-*.md` command templates, and a `Doc/` folder. No `*.ts`, `*.js`, `*.py`, `*.go`, or test files. Only `package.json` files (extension manifest metadata) exist anywhere in the repo, and they have no test scripts.
- **The blocker is identical to the one `p-plan` flagged** — same `${@:-...}` sentinel, same family of files. The previous step's plan explicitly said "any new validation must preserve that contract when a real task *is* supplied" and listed "re-render `${@}` via the same shell" as Step 1 verification. I re-rendered it; sentinel confirmed.

### The minimum I need to produce real tests
Reply with **at least one** of the following so I have a real target:

1. **A concrete file or function** — e.g. `src/foo.ts:bar()`, or a directory to scan.
2. **A concrete feature** — e.g. "the retry logic in extension X", "the parser in tool Y".
3. **The "harden the prompt family" meta-target** — explicit confirmation that you want tests for the `${@:-...}` sentinel-detection behavior in `p-*.md` / `c-*.md` itself (I can then test the *loader* contract, not the markdown content).

Once I have a target I will deliver the 5-section answer the template asks for: conventions → cases → code → run command → coverage gaps.

### What I will *not* do
- I will not invent tests against `the current code or context`. "Context" is not a test target; "the current code" is a phrase, not a function.
- I will not refactor the `p-*.md` files in this pass even if asked, because (a) I do not have write tools in this delegation, and (b) the previous step's plan said to wait for parent direction before touching them.
- I will not propose further subagents — I am a worker, not the orchestrator.

### Coverage gaps I can already flag (pre-emptive, no code needed)
- **No test framework is installed** at the repo root. The smallest viable setup for the prompt-family hardening target would be a single `test/prompts.test.ts` using `node --test` (Node 20+ built-in) — no `npm install` required. I will scaffold it only after the parent approves.
- **No fixtures exist** for the placeholder expansion. If the target is the loader, the first thing the test needs is a captured rendering of `p-test.md` invoked with empty `$@` — that capture does not yet exist.

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

Criteria:
- criterion-1: Implement the requested change without widening scope

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

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"
    }
  ],
  "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"
}
```