backend-java-web-development

backend-java-web-development Router

Purpose

This is the package-level routing entry for this skill package. It owns entry interpretation and stage routing, not requirement content, implementation work, or review content. The package still exports the stage skills under ./skills/, so each stage skill must repeat its own prerequisite checks. This router determines the current task stage from the fixed task documents plus the implementation-to-review handoff boundary, decides the only legal next stage, and rejects illegal jumps.

The workflow is fixed:

1. requirement-analysis
2. feasibility-analysis
3. apcp-web-api-plan
4. apcp-web-api-implementation
5. apcp-web-api-self-review
6. apcp-plugin-implementation

Do not invent parallel stage names. Do not bypass this flow with natural-language assumptions.

Fixed Task Document Contract

Every task must use exactly this folder layout:

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

The old single-file task contract is removed completely. Do not read it, write it, migrate it, reference it, or preserve compatibility for it.

Task Initialization Rule

For a brand-new task, the only legal entry is still requirement-analysis. If tasks/<task-name>/ or tasks/<task-name>/requirement.md does not exist yet, route only to requirement-analysis. That stage must first:

• initialize tasks/<task-name>/
• create or reopen tasks/<task-name>/requirement.md
• write the user's raw request into ## 原始需求 before any analysis, confirmation, or downstream routing continues

Default Request Interpretation Rule

For a fresh raw user request, default to requirement-analysis. Here, a fresh raw user request means a new or unbound request that has not yet been tied to an existing tasks/<task-name>/ stage state. If the current work is explicitly continuing or reopening an existing task whose stage state is already established in the fixed task documents, follow that stage state first instead of reclassifying the request as fresh requirement input, unless the current message explicitly sends the work back to the requirement path.

Only treat the request as a non-requirement-stage entry when the user explicitly opts out of starting from requirement-analysis and explicitly chooses direct implementation handling or direct review handling outside the six-stage workflow. For direct implementation fallback, the same current message must not also assert requirement-first or no-implementation intent. For direct review fallback, requirement-first intent still hard-vetoes entry, and no-implementation wording alone never selects review; direct review still requires an explicit direct review choice. The router does not infer a downstream workflow stage from that opt-out. A fresh request that bypasses requirement-analysis leaves the router-managed six-stage workflow and must use explicit direct fallback handling instead.

Technical detail alone is never enough to bypass the requirement stage. Class names, method names, endpoint names, validation rules, bug descriptions, file paths, stack traces, or code pointers do not by themselves justify a direct jump into planning, implementation, self-review, or CodeLaw fallback skills. Nor can 开始吧, 继续吧, or similar execution wording override an explicit requirement-first or no-implementation instruction in the same message.

Current-turn Intent Priority Rule

When interpreting the current user message, explicit stage intent has higher priority than conversational push words or technical detail. Apply these rules before treating 开始吧, 继续吧, class names, method names, file paths, stack traces, code snippets, validation detail, or similar context as routing signals.

1. If the current message explicitly says 这是需求, 先走需求分析, or 回到需求分析, prioritize the requirement path immediately.
   • Route to requirement-analysis or return to the requirement path for the bound task.
   • Do not let 开始吧, 继续吧, or technical detail reinterpret the request as implementation, self-review, plugin work, or direct CodeLaw fallback.
2. If the current message explicitly says 不进入实现, 先别写代码, or an equivalent no-implementation instruction, hard-veto apcp-web-api-implementation and codelaw-implementation.
   • This veto does not by itself authorize direct review or any other downstream fallback.
3. Explicit direct implementation fallback is valid only when the user also clearly opts out of starting from requirement-analysis and does not simultaneously assert requirement-first or no-implementation intent.
4. Explicit direct review fallback is valid only when the user also clearly opts out of starting from requirement-analysis and explicitly chooses direct review.
   • No-implementation wording alone is never enough to select review.
5. If the same message explicitly asks for requirement-analysis and also explicitly asks for direct implementation or direct review, do not guess.
   • Ask one concise clarifying question before routing.

Gate-driven Routing Rules

Routing must be based on explicit stage state, not only on file existence. For document-gated transitions, each downstream stage must read the upstream document's ## 阶段状态 block and respect both:

• gate: <value>
• next: <value>

The implementation -> self-review boundary is special:

• self-review.md is created by the self-review stage itself
• so review entry is controlled by the implementation stage's explicit review-ready handoff, not by a separate pre-existing task document

Required gate values

• requirement.md

  • gate: requirement-confirmed
  • next: feasibility-analysis

• feasibility.md

  • gate: ready-for-plan or gate: blocked
  • next: apcp-web-api-plan or next: requirement-analysis

• plan.md

  • gate: ready-for-implementation or gate: blocked
  • next: apcp-web-api-implementation or an upstream fallback stage

• self-review.md

  • gate: ready-for-plugin or gate: review-failed
  • next: apcp-plugin-implementation or apcp-web-api-implementation or apcp-web-api-plan

Router Decision Table

Apply these checks in order.

0. If the same message explicitly asks for requirement-analysis and also explicitly asks for direct implementation or direct review:
   • do not guess
   • ask one concise clarifying question before routing

0a. If the current input explicitly says 这是需求, explicitly asks for requirement-analysis, or explicitly asks to return to requirements:

• prioritize the requirement path immediately
• do not let 开始吧, 继续吧, or technical detail reclassify the request as plan, implementation, self-review, plugin, or direct CodeLaw fallback

0b. If the current input explicitly says not to enter implementation or not to write code, and the same message also explicitly opts out of starting from requirement-analysis and explicitly chooses direct review:

• hard-veto apcp-web-api-implementation and codelaw-implementation
• allow only explicit direct review fallback
• do not reinterpret the no-implementation veto as permission for direct implementation

0c. If the current input explicitly says not to enter implementation or not to write code:

• hard-veto apcp-web-api-implementation and codelaw-implementation
• do not reinterpret that veto as direct review authorization by itself
• if the request is still only a fresh raw request, the only legal entry remains requirement-analysis
• if the task is already bound to an existing workflow state and no other legal non-implementation stage is explicitly selected, ask one concise clarifying question instead of falling through to implementation-stage routing

0d. If the current input is only a fresh raw user request, no existing fixed-document stage state has been selected for it yet, and the user has not explicitly opted out of starting from requirements:

• interpret it as requirement-stage input
• only legal entry: requirement-analysis

0e. If the current input is only a fresh raw user request, no existing fixed-document stage state has been selected for it yet, and the user explicitly opts out of starting from requirement-analysis without conflicting requirement-first intent:

• do not route it into a six-stage workflow stage by guesswork
• allow only explicit direct fallback handling chosen by the user
• do not infer plan, implementation, self-review, or plugin entry from technical detail alone

1. If tasks/<task-name>/ does not exist:

   • only legal stage: requirement-analysis
   • that stage must initialize the task directory and persist the raw request first

2. If requirement.md does not exist:

   • only legal stage: requirement-analysis
   • that stage must create requirement.md and write ## 原始需求 first

3. If requirement.md exists but its gate is not requirement-confirmed:

   • only legal stage: requirement-analysis

4. If requirement.md is requirement-confirmed and points to feasibility-analysis:

   • stop and wait for user confirmation before entering feasibility-analysis

5. If feasibility.md does not exist after that confirmation boundary:

   • only legal stage: feasibility-analysis

6. If feasibility.md exists and:

   • gate: blocked
   • or next: requirement-analysis then the declared fallback stage is the only legal route

7. If feasibility.md is ready-for-plan and next: apcp-web-api-plan:

   • stop and wait for user confirmation before entering apcp-web-api-plan

8. If plan.md does not exist after that confirmation boundary:

   • only legal stage: apcp-web-api-plan

9. If plan.md exists and:

   • gate: blocked
   • or next points to requirement-analysis or feasibility-analysis then implementation is forbidden until the declared fallback stage is completed

10. If self-review.md is ready-for-plugin and next: apcp-plugin-implementation:

• plugin work is now legally unlocked
• stop and wait for user confirmation before entering apcp-plugin-implementation
• if the user explicitly chooses to resume backend changes instead of entering plugin work, the only legal route becomes apcp-web-api-implementation
• that reopened implementation pass must immediately invalidate the old ready-for-plugin result before further backend edits continue

11. If self-review.md exists and:

• gate: review-failed
• and next points to apcp-web-api-implementation or apcp-web-api-plan then plugin work is forbidden
• the immediate automatic recovery route is the stage named by next
• if next: apcp-web-api-plan, return to apcp-web-api-plan for the recovery pass, and once plan.md is rewritten to a new explicit stage state, resume routing from that new plan.md state
• if next: apcp-web-api-implementation, return to apcp-web-api-implementation for the recovery pass and stay there until a fresh review-ready handoff is reached
• do not let an old review-failed result keep overriding a newly completed upstream stage forever

12. If backend implementation explicitly reaches review-ready handoff:

• apcp-web-api-self-review becomes the only legal next stage
• the router may continue automatically into apcp-web-api-self-review
• this applies both when self-review.md does not yet exist and when a previous review-failed result is being replaced by a new review pass

13. If plan.md is ready-for-implementation and next: apcp-web-api-implementation:

• apcp-web-api-implementation is the only legal downstream stage before review handoff
• the router may continue automatically into apcp-web-api-implementation

14. Otherwise, if backend implementation has not explicitly reached the implementation stage completion rule for review handoff:

• stay in apcp-web-api-implementation

Hard Refusal Rules

Reject illegal jumps explicitly. Examples:

• current message explicitly says 这是需求, 先走需求分析, or 回到需求分析 -> refuse implementation, self-review, plugin, and direct CodeLaw fallback; return to the requirement path
• current message explicitly says 不进入实现 or 先别写代码 -> refuse implementation and direct implementation fallback; do not reinterpret that veto as direct review by itself
• current message explicitly says 不进入实现 or 先别写代码 and also explicitly chooses direct review -> allow only direct review fallback
• current message explicitly asks for requirement-analysis and direct implementation or direct review in the same message -> do not route; ask for clarification
• bound task plus current-turn no-implementation veto without another explicit legal non-implementation target -> ask for clarification instead of falling through to implementation-stage routing
• fresh raw request without an explicit bypass -> refuse plan, implementation, self-review, plugin, and direct CodeLaw fallback; return to requirement-analysis
• fresh raw request with an explicit requirement bypass but without an explicit direct fallback target -> refuse guessed workflow-stage entry; do not infer a downstream stage
• no requirement.md -> refuse feasibility, plan, implementation, self-review, and plugin
• requirement not confirmed -> refuse feasibility, plan, implementation, self-review, and plugin
• feasibility not ready-for-plan -> refuse plan, implementation, self-review, and plugin
• plan not ready-for-implementation -> refuse implementation, self-review, and plugin
• self-review not ready-for-plugin -> refuse plugin

When refusing, state the only legal stage to return to. Do not provide soft wording that leaves room for skipping gates. Do not let 开始吧, 继续吧, or technical detail weaken these refusals.

CodeLaw Policy

This router does not execute CodeLaw itself. It only enforces where CodeLaw may be used inside the six-stage workflow.

Within workflow routing:

• requirement-analysis must not invoke any CodeLaw skill
• feasibility-analysis must not invoke any CodeLaw skill
• apcp-web-api-plan must not invoke any CodeLaw skill
• apcp-web-api-implementation may invoke only codelaw-implementation
• apcp-web-api-self-review may invoke only codelaw-self-review
• apcp-plugin-implementation must not invoke any CodeLaw skill

These stage restrictions apply only to the six-stage workflow. Direct fallback Java implementation tasks may call codelaw-implementation only when the user explicitly opts out of starting from requirement-analysis first, explicitly chooses direct implementation handling outside the six-stage workflow, and the same current message does not also contain requirement-first or no-implementation veto language. Direct fallback Java review tasks may call codelaw-self-review only when the user explicitly opts out of starting from requirement-analysis first and explicitly chooses direct review handling outside the six-stage workflow. Requirement-first intent still vetoes direct review fallback, and no-implementation wording alone never selects review. The router must not guess a downstream workflow stage for such requests.

Stage Transition Confirmation Policy

Use stage-scoped transition rules instead of one blanket confirmation rule:

• requirement-analysis -> feasibility-analysis: stop and wait for user confirmation
• feasibility-analysis -> apcp-web-api-plan: stop and wait for user confirmation when feasibility.md ends with gate: ready-for-plan
• apcp-web-api-plan -> apcp-web-api-implementation: continue automatically when plan.md ends with gate: ready-for-implementation
• apcp-web-api-implementation -> apcp-web-api-self-review: continue automatically only after explicit review-ready handoff
• apcp-web-api-self-review -> apcp-web-api-implementation or apcp-web-api-plan: continue automatically as the immediate upstream recovery hop when self-review.md ends with gate: review-failed and next points upstream; after that recovery pass, resume normal routing from the newly completed upstream state
• apcp-web-api-self-review -> apcp-plugin-implementation: stop and wait for user confirmation even when self-review.md ends with gate: ready-for-plugin; if the user explicitly reopens backend changes instead, return to apcp-web-api-implementation first and invalidate the old review result before more backend edits continue

Do Not Do

• do not use any legacy single-file task contract
• do not infer stage readiness from file existence alone
• do not let apcp-web-api-plan absorb self-review responsibility
• do not let apcp-web-api-implementation grant final plugin entry
• do not let apcp-plugin-implementation redefine backend design