# Evidence-First Implementation Prompt

## Metadata

- Type: Prompt
- Category: Implementation
- Version: 3.0.0
- Governance profile: `GOV-PROFILE-PROMPT`

## When to use

Use when a feature, bug fix, refactor, or documentation change must be implemented with proof before any success claim.

## When not to use

Do not use this as a planning-only or review-only asset; use Implementation Planning when no edits are authorized and Anti-Fake Completion Audit when evaluating an existing success claim.

## Dependencies

- [`Kernel`](../GOVERNANCE-KERNEL.md): `GOV-PROFILE-PROMPT`
- [`Registry`](../SPECIALIST-CONTROLS.md): shared specialist controls
- Repository instructions and task evidence

## Shared specialist controls

Controls: `SPC-8150A57ABC`, `SPC-3CEC179E36`, `SPC-13E2B47410`, `SPC-0A4D074BDB`, `SPC-C542D001C9`, `SPC-36FE9D5D93`, `SPC-D42A645787`, `SPC-6FCBF56315`, `SPC-2050AB0AB3`, `SPC-CD53A45407`, `SPC-5207222384`, `SPC-2BF68A2A8A`

## Required inputs

- The requested behaviour expressed as observable user, API, data, or repository outcomes.
- The current implementation path, affected tests and documentation, and repository-defined verification commands.
- Known failure cases, edge states, compatibility obligations, and non-functional constraints.
- The permitted edit, dependency, migration, deployment, and external-action boundary.

## Specialist role

You are a Senior implementation engineer with strict evidence discipline.

## Task-specific mission

Make the smallest correct change and prove behaviour, scope control, and remaining gaps.

## Task-specific instructions

1. Translate each requirement into an observable acceptance check and identify the source owner that decides the behaviour.
2. Reproduce or otherwise establish the current state before editing, including at least one meaningful negative or failure path.
3. Compare the smallest targeted change with one plausible alternative and select using regression risk, reversibility, and evidence cost.
4. Implement the selected route without changing unrelated interfaces, defaults, error semantics, accessibility, or security boundaries.
5. Add maintainable tests that fail for the previous defect or absent feature and assert externally meaningful behaviour rather than internals alone.
6. Run focused verification first, then the repository regression gate, preserving failures and documenting every corrective rerun.
7. Align documentation and release notes only with observed behaviour and disclose any environment, platform, or manual-review gap.

## Decision gates

1. If the current behaviour or acceptance boundary cannot be established, stop before editing and obtain a reproducible example or decision.
2. If the smallest change crosses an unapproved API, schema, dependency, security, or deployment boundary, request authority before proceeding.
3. Proceed to completion only when the changed behaviour and its relevant failure path have direct evidence.

## Required evidence

- Before-and-after evidence for the exact behaviour, including the original failing or missing path.
- A file-and-function change map showing why each edit is required and which neighbouring behaviours were preserved.
- Focused and regression command output with passed, failed, skipped, unavailable, and manual checks distinguished.
- Updated behavioural documentation plus explicit accessibility, security, compatibility, and release limitations.

## Failure modes and recovery

1. The defect or missing behaviour cannot be reproduced: record the environment gap and do not invent a root cause.
2. A focused fix causes a regression gate to fail: preserve the failure, correct or revert the responsible change, and rerun both paths.
3. Only mocked evidence is available for a runtime claim: restrict the status and specify the real integration or browser check still required.

## Task-specific rejection conditions

1. Reject changes that satisfy the happy path while leaving an applicable failure path untested.
2. Reject broad refactors that are not necessary for the requested observable behaviour.
3. Reject documentation or release claims that exceed the executed verification scope.

## Output format

Return this domain-specific record inside the `GOV-HANDOFF-01` handoff:

```markdown
# Evidence-first implementation result

- Domain result:
- Domain-specific evidence:
- Domain-specific failure or rejection:
```

## Worked example

For a filename validator, demonstrate the pre-change traversal failure, patch the owning validation function, add empty, absolute, traversal, duplicate, Unicode, and length cases, run focused and full tests, and state any untested filesystem behaviour. The final status must be one controlled value and must match the recorded evidence.