apcp-web-api-plan

apcp-web-api Plan

Purpose

This is the third stage of the workflow. This stage is only responsible for tasks/<task-name>/plan.md.

It must consume:

• tasks/<task-name>/requirement.md
• tasks/<task-name>/feasibility.md

It must not absorb self-review responsibility. Self-review belongs to the separate apcp-web-api-self-review stage.

Preconditions

Before starting, confirm:

• requirement.md exists and has gate: requirement-confirmed
• feasibility.md exists and has gate: ready-for-plan
• feasibility.md points to next: apcp-web-api-plan

If these checks fail, refuse this stage and return to the only legal upstream 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 they are relevant to planning.
4. If the repository cannot be identified confidently, ask once before continuing.

Fixed Task Document Contract

During this stage:

• read requirement.md
• read feasibility.md
• create or reopen plan.md
• write only to plan.md

Do not create or update:

• self-review.md

Do not use any legacy single-file task contract.

Document Contract

plan.md must contain at least:

• ## 当前状态
• ## 执行计划
• ## 实施任务
• ## 目标与边界
• ## 接口总览
• ## 共享结构
• ## 设计
• ## 实现顺序
• ## 阶段状态

## 当前状态 is a runtime visibility contract. It must at least show:

• 当前阶段
• 当前进行中

## 执行计划 is a runtime visibility contract. Maintain stage-level progress there with plain markdown checkbox items.

## 实施任务 is a runtime visibility contract. Maintain implementation task items there with plain markdown checkbox items.

Add persistence-related design sections only when the task actually needs them. Do not create fake sections for work that is out of scope.

Required Stage State

## 阶段状态 must end with one of these outcomes:

Ready for implementation

• gate: ready-for-implementation
• next: apcp-web-api-implementation

Blocked

• gate: blocked
• next: requirement-analysis or next: feasibility-analysis

Use the fallback stage that matches the real blocker.

Planning Rules

Do not invoke any CodeLaw skill in this stage.

• establish and maintain plan.md as the cross-tool progress surface for the workflow
• keep ## 当前状态, ## 执行计划, and ## 实施任务 updated as explicit runtime-owned sections, not as optional commentary
• use plain markdown checkbox syntax for stage progress and task progress so Claude Code and Codex can both read the same visibility state
• plan all related backend interfaces in one coherent plan when the requirement clearly spans multiple interfaces
• identify shared structures early
• keep naming and ownership consistent across controller, BO, VO, service, repository, entity, and validation design when they are in scope
• keep the plan aligned with the confirmed requirement and feasibility output
• if a global design contradiction exists, block implementation instead of writing around it

Removed Responsibility

This stage no longer owns final self-review. Do not add sections such as:

• ## 自审结果
• final review gate text
• plugin release permission

Any final implementation assessment belongs only in self-review.md during apcp-web-api-self-review.

Completion Rule

This stage completes only when plan.md contains an explicit ## 阶段状态 block with either:

• gate: ready-for-implementation
• or gate: blocked

Then apply the stage-specific transition rule:

• if the result is ready-for-implementation, continue automatically into apcp-web-api-implementation
• if the result is blocked, stop and wait, and return only to the upstream stage named by next

Do not continue into self-review or plugin work from this stage.

Refusal Rule

If this skill is called without feasibility.md being ready-for-plan, refuse and return to the stage named by the upstream gate.