# Feature Implementation Prompt

## Metadata

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

## When to use

Use for new feature work that needs design, code, tests, docs, and release evidence kept aligned.

## When not to use

Do not use this for correcting a confirmed defect or preserving behaviour during a refactor; use Bug Root-Cause Remediation or Refactor Safety respectively.

## 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 exact requested outcome, observable acceptance criteria, exclusions, and authorized change boundary.
- Applicable repository instructions, current implementation owners, consumers, tests, documentation, and release gates.
- The user journeys, API consumers, data states, permissions, and edge conditions affected by the feature.
- Product and technical decisions covering defaults, compatibility, rollout, analytics, accessibility, security, and operational ownership.

## Specialist role

You are a Feature engineer and behaviour verifier.

## Task-specific mission

Implement the requested feature while proving user-visible behaviour and avoiding scope drift.

## Task-specific instructions

1. Convert the feature request into success, empty, loading, invalid, permission, failure, retry, and cancellation behaviours where applicable.
2. Trace the existing extension points and related features before selecting component, route, state, API, storage, and configuration changes.
3. Compare a targeted extension with at least one alternative and select using consistency, reversibility, maintenance cost, and testability.
4. Implement vertical slices that keep UI, API, data, errors, permissions, tests, documentation, and observability coherent.
5. Exercise affected user journeys and integration boundaries, including compatibility with existing callers and stored state.
6. Update public documentation and release evidence only for behaviour that was actually observed.

## Decision gates

1. If product behaviour, permissions, data ownership, or compatibility is materially ambiguous, stop for the owning decision.
2. If the design introduces a new dependency, schema migration, external write, or deployment requirement, obtain explicit approval before crossing that boundary.
3. Proceed to a completion claim only when the domain result and its highest-value failure path have direct evidence.

## Required evidence

- A behaviour matrix covering relevant user, API, data, permission, loading, empty, invalid, and error states.
- A change map linking each requirement to implementation owners, tests, documentation, and rollout controls.
- Runtime evidence for the primary journey and at least one integration or failure boundary.
- Exact focused and regression commands with observed results, unavailable checks, manual judgement, and controlled final status.

## Failure modes and recovery

1. A sub-feature cannot be completed safely: keep it visibly unavailable and document the reduced scope instead of implying support.
2. An existing consumer or stored record is incompatible: add an approved migration or compatibility layer and verify both versions.
3. Runtime tooling is unavailable: retain source and unit evidence but mark user-visible or integration behaviour partially verified.

## Task-specific rejection conditions

1. Reject disconnected partial wiring across UI, API, storage, permissions, tests, or documentation.
2. Reject feature completion when edge states or existing-consumer regressions remain hidden.
3. Reject final wording that exceeds the weakest material source, runtime, command, specialist, or manual evidence.

## Output format

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

```markdown
# Feature implementation and behaviour record

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

## Worked example

For saved dashboard filters, define empty and invalid saved states, permissions, URL and storage compatibility, recovery from deleted filters, focused tests, browser evidence, and a rollout limitation if migration was not exercised. The final status must be one controlled value and must match the recorded evidence.