frontend-code-implementation

name	frontend-code-implementation
description	Implement a vetted legacy-web UX slice in the target repository after requirements and touched-seam harnesses are green. Discovers the real frontend stack, changes code test-first, and records implementation evidence before browser validation and review.

Frontend Code Implementation

Use this skill for code mode, after ux-modernization has designed the target flow. It changes the actual target repository rather than producing only a UX proposal.

Required inputs

• docs/renovation/02-architecture.md: confirmed frontend package roots, routes, API boundaries, and actual seam IDs.
• docs/renovation/03-requirements.md: accepted criteria and edge cases.
• plan.md: an explicit change entry and every touched seam marked green.
• docs/renovation/05-ux/README.md: approved after-flow and removal decisions.
• Figma evidence only when the change opted into Figma review.

Do not start if the harness map is empty, a touched seam is absent, or any touched seam is not green. Return to architecture-recovery or behavior-harness; never invent a seam name to pass this gate.

First action: verify renovation state

Before discovering files or writing code, read plan.md and confirm:

1. gates.grilling: passed.
2. The change has an explicit entry with its actual touched seam IDs.
3. Every declared touched seam exists in harness and is green.
4. If Figma review was requested or a Figma URL/frame is claimed as the baseline, figma_design: approved is recorded with review evidence. Otherwise, figma_design: not_used is recorded.

If any condition is unmet, stop and return to renovate-orchestrator, behavior-harness, or figma-design-review. Do not inspect implementation files as a substitute for state evidence, and do not begin code mode.

Method

1. Discover the real implementation surface. Identify package manifests, lock files, framework/version, test and lint scripts, routes/pages, components, state boundaries, API clients, feature-flag mechanism, and existing accessibility/test selector conventions. Reuse the target repository's patterns.
2. Write a change manifest. Record the accepted requirement IDs, target package, affected route/component/API boundary, touched seams, rollback/feature-flag behavior, and user-visible success criteria in docs/renovation/05-ux/frontend-implementation.md.
3. Invoke test-authoring. Write the smallest failing existing-framework tests for every changed acceptance criterion before editing implementation code. Include loading, error, empty, permission, and relevant bulk/concurrent states.
4. Implement the vertical slice. Make focused route/component/state/API-client changes. Preserve legacy behavior outside the approved slice; use the existing flag or adapter seam when rollout must be reversible. Use stable accessible names or the project's selector convention for browser tests.
5. Run existing validation. Run the target package's relevant unit/component/E2E tests, type check, lint, and build only when those scripts exist. Run the characterization suite for every touched seam.
6. Record evidence. Add commands, results, screenshots/traces if generated, and feature-flag/rollback proof to the implementation evidence. Update the plan.md change entry without marking review complete.
7. Handoff. Invoke web-action-testing against the running real UI, then strict-code-review. The slice is not done until both gates pass.

Non-negotiable safeguards

• Do not delete a legacy route, component, field, or API call solely because it looks unused; require architecture evidence, requirement approval, and green seams.
• Do not replace API contracts, authorization behavior, or error handling with client-only assumptions.
• Do not claim Figma parity unless the change is linked to an approved Figma review.
• Surface validation failures using the target application's established error UI; do not silently drop failed user actions.

Output template and helper script

• Korean template: OUTPUT_TEMPLATE.md
• Scaffold script: scripts/create-frontend-implementation-evidence.sh <repo-root> <target-name>