# Product Completeness Audit

Working directory: `{{workingDirectory}}`
Milestone: `{{milestoneId}} — {{milestoneTitle}}`
Audit output: `{{productAuditPath}}`

{{skillActivation}}

{{inlinedContext}}

## Mission

Compare the repository's declared finished-product intent against actual evidence from code, tests, docs, deployment artifacts, runbooks, and `.sf` milestone artifacts.

Use repo docs as the product contract. Do not hardcode assumptions from another project. If docs are vague, report that as a product-contract gap only when it blocks confident validation.

## Codebase Inspection

You must inspect the codebase enough to confirm whether declared product capabilities exist. Prefer semantic or structured search when available:

- Start with native `lsp` for symbol search, references, and cross-file codebase mapping. If `lsp` is unavailable for a file type, state that and continue with AST/text search.
- Use AST-aware search (`ast-grep`, native parser tools, or equivalent) for implementation patterns, exported APIs, route handlers, CLI commands, service definitions, config keys, and test coverage.
- Use text search (`rg`) for docs, deployment scripts, runbooks, CI workflows, build targets, and evidence strings.
- Use DeepWiki, Context7, package-intelligence, or project-specific documentation tools when configured for external library/package questions. Do not route local repo file/symbol work through MCP when native `lsp`, AST, and text search cover it.
- Do not rely only on preloaded docs. If a required capability is declared, look for concrete implementation, tests, config, deploy, and operational evidence.
- Do not edit source files in this audit. The only write path is the `audit_product` tool.

## Evidence Rules

- Cite every product expectation with repo-relative `sourceDocs` paths.
- `foundEvidence` must name concrete files, symbols, tests, commands, artifacts, or documented operational procedures.
- `missingEvidence` must be concrete and checkable. Do not write vague TODOs.
- A `no-gaps` verdict is valid only when positive evidence exists for every material product expectation discovered.
- Critical/high gaps are for capabilities required by the declared finished product and missing enough evidence to trust completion.
- Medium/low gaps remain advisory unless the declared finished product requires them.
- Safety warnings are advisory here. This audit does not hard-block completion; it adds follow-up slices for real critical/high product gaps.

## Required Output

Call `audit_product` exactly once with:

```json
{
  "milestoneId": "{{milestoneId}}",
  "verdict": "no-gaps | gaps-found | contract-underspecified",
  "summary": "short evidence-based summary",
  "gaps": [
    {
      "capability": "capability name",
      "expectedEvidence": ["required evidence from product contract"],
      "foundEvidence": ["positive evidence found, with paths"],
      "missingEvidence": ["missing concrete evidence"],
      "severity": "critical | high | medium | low",
      "suggestedSlice": {
        "title": "Implement/verify the missing product capability",
        "demo": "After this: concrete product-readiness proof exists.",
        "risk": "high",
        "depends": []
      },
      "confidence": 0.8,
      "sourceDocs": ["VISION.md", "docs/RUNBOOKS.md"]
    }
  ]
}
```

For no material gaps, pass `gaps: []` and explain the positive evidence in `summary`.

If the finished-product contract is underspecified and that blocks validation, add one high-severity gap whose suggested slice clarifies the product contract.

After the tool call, respond with:

`Product audit {{milestoneId}} complete — <verdict>.`

### Report sf-internal observations

This unit produces observations as its primary output — be especially diligent about filing sf-internal friction you notice along the way. If during this unit you observe sf-the-tool friction — ambiguous prompts, missing context, misleading instructions, surprising behavior, prompt-quality issues, or improvement ideas — file them via `report_issue` before sealing the unit. This is the only way these observations reach forge's backlog and get triaged. Over-reporting is preferred to under-reporting; dedup happens later. Do NOT use this to file bugs in the user's project; only sf-the-tool itself. Do NOT autonomously act on or fix existing backlog entries — your scope is your unit.
