apcp-web-api-implementation

apcp-web-api Implementation

Purpose

This is the fourth stage of the workflow. This stage owns workflow implementation and review-ready handoff, not package-level entry routing and not standalone Java helper fallback. This stage is responsible only for implementing backend code in apcp-web-api according to plan.md.

This stage may do local implementation checks, but it does not own final release to plugin work. Final backend release gating belongs only to apcp-web-api-self-review.

Preconditions

Before starting, confirm:

• requirement.md exists and has gate: requirement-confirmed
• feasibility.md exists and has gate: ready-for-plan
• plan.md exists and has gate: ready-for-implementation
• plan.md points to next: apcp-web-api-implementation
• if self-review.md exists with gate: review-failed and next: apcp-web-api-plan, do not enter this stage and return to apcp-web-api-plan
• if self-review.md exists with gate: ready-for-plugin, enter this stage only when the user explicitly chooses to reopen backend changes instead of entering plugin work
• the current input does not explicitly say 这是需求, 先走需求分析, or 回到需求分析
• the current input does not explicitly say 不进入实现, 先别写代码, or any equivalent no-implementation instruction

If these checks fail, refuse this stage and return to the only legal upstream stage. Do not let 开始吧, 继续吧, class names, method names, file paths, stack traces, or code snippets override these current-turn veto checks. Do not enter this workflow stage from a fresh unbound raw user request. If the user explicitly bypasses requirement-analysis, that request may use only explicit direct fallback handling outside the six-stage workflow, not this stage entry. Current-turn requirement-first or no-implementation intent must be handed back to backend-java-web-development for re-routing instead of being absorbed by this stage.

Workspace Resolution

1. Prefer the current project root when it is already apcp-web-api.
2. Otherwise, resolve the sibling repository named apcp-web-api from the parent directory of the current project.
3. Use sibling references such as java-libs/jpa-entity only when the approved plan requires them.
4. If the workspace cannot be resolved confidently, ask once before editing code.

Required Inputs

Before implementation:

• read tasks/<task-name>/requirement.md
• read tasks/<task-name>/feasibility.md
• read tasks/<task-name>/plan.md
• read existing backend code patterns in apcp-web-api
• if self-review.md already exists, read it before making further backend changes

Do not create or update self-review.md in this stage, except for the forced invalidation rule below.

Review Invalidation Rule

If self-review.md currently says gate: ready-for-plugin, any new backend change in this stage immediately invalidates that previous review pass. This reopen path is allowed only when the user explicitly chooses further backend changes instead of entering plugin work. Before continuing implementation, update self-review.md so it no longer grants plugin entry. Use this forced invalidation state:

• gate: review-failed
• next: apcp-web-api-implementation

The invalidation note must clearly say that backend changes resumed after a previously passed review, so the old ready-for-plugin result is no longer valid and a fresh self-review is required. In this reopen path, review-failed is the required workflow-safe invalidation state even when the previous review passed; the note must distinguish invalidated review state from unresolved review findings. Do not keep an old ready-for-plugin result alive across new backend edits.

CodeLaw Integration

codelaw-implementation is the adjacent Java implementation helper skill. It may be invoked from this workflow stage when Java source or Java tests are being changed, but it does not own this stage's plan.md progress, implementation handoff, or review-stage transition.

1. First complete this stage's existing gate checks, current-turn intent veto, and workspace resolution.
2. If the current input explicitly says requirement-first or no-implementation, stop here, refuse this stage, and do not invoke codelaw-implementation.
3. If the current work modifies Java source or Java tests, immediately invoke codelaw-implementation.
4. While implementing Java changes here, follow the Java authoring rules defined in codelaw-implementation.
5. After that preprocessing completes, continue backend implementation in this stage.
6. This stage must not perform final CodeLaw compliance release.
7. Local self-checks in this stage remain local quality control only and do not replace final self-review.

Keep this section as routing guidance only. Do not duplicate the full Java authoring rules or CodeLaw MCP procedures here.

Execution Rules

• implement strictly according to plan.md
• continuously maintain plan.md visibility while this stage is active; do not treat the plan as read-only once implementation starts
• keep plan.md ## 当前状态, ## 执行计划, and ## 实施任务 in sync with current implementation progress and checkbox state
• land shared structures first when multiple interfaces depend on them
• reuse existing project patterns instead of inventing parallel structures
• keep naming, ownership, validation, and shared contracts aligned with the plan
• if a contradiction appears that would change behavior or ownership, stop and return upstream instead of drifting

Contradiction Handling

If implementation reveals a real conflict:

• return to apcp-web-api-plan when the design itself must change
• do not silently patch around a broken plan
• do not let implementation redefine the contract on its own

Local Self-checks Allowed

This stage may perform local implementation checks such as:

• interface-by-interface completeness
• naming consistency
• validation alignment
• shared-structure consistency inside the implemented slice

These checks are only local quality control. They do not replace final backend self-review. They do not grant permission to start plugin work.

Removed Responsibility

This stage no longer owns:

• whole-task final review gate
• plugin entry decision
• final statement that backend is ready for plugin verification

Those decisions belong only to apcp-web-api-self-review through self-review.md.

Completion Rule

When implementation for the approved plan is complete enough for review, explicitly hand off to:

• apcp-web-api-self-review

After that review-ready handoff, continue automatically into apcp-web-api-self-review. The same handoff also re-enters apcp-web-api-self-review after an earlier review-failed result. A previous self-review.md may be reopened and replaced by the new review pass. This handoff is the only legal exit from this stage toward review. Do not continue into review while implementation is still in progress. Do not treat partial completion, spot checks, or unresolved planned work as review-ready. Do not write a final release gate in this stage. Do not claim plugin readiness from this stage.

Refusal Rule

If the current input explicitly says this is requirement work, to go through requirement-analysis first, or to return to requirements, refuse this stage and hand control back to backend-java-web-development for requirement-path routing. If the current input explicitly says not to enter implementation or not to write code, refuse this stage, do not invoke codelaw-implementation, and hand control back to the router / requirement path instead of continuing implementation. If plan.md is missing, refuse this stage and return to apcp-web-api-plan. If plan.md exists but its gate is not ready-for-implementation, refuse this stage and return only to the upstream stage named in plan.md. If self-review.md exists with gate: review-failed and next: apcp-web-api-plan, refuse this stage and return to apcp-web-api-plan. If self-review.md exists with gate: ready-for-plugin but the user has not explicitly reopened backend changes, refuse this stage and stay at the self-review-to-plugin confirmation boundary. If the work is not yet complete enough to satisfy this stage's completion rule, refuse any attempt to skip ahead to self-review or plugin logic and stay in implementation. Do not let 开始吧, 继续吧, class names, method names, file paths, stack traces, or code snippets override the above refusal conditions.