apcp-plugin-implementation

apcp-plugin Implementation

Purpose

This is the sixth stage of the workflow. This stage is for plugin-side verification support only. It consumes a stable backend contract and must not redefine backend behavior.

Preconditions

Before starting, confirm all of the following:

• tasks/<task-name>/requirement.md exists and has gate: requirement-confirmed
• tasks/<task-name>/feasibility.md exists and has gate: ready-for-plan
• tasks/<task-name>/plan.md exists and has gate: ready-for-implementation
• tasks/<task-name>/self-review.md exists and has gate: ready-for-plugin
• self-review.md points to next: apcp-plugin-implementation
• the user has explicitly confirmed continuing from apcp-web-api-self-review into this stage

If any check fails, refuse this stage and return to the only legal upstream stage.

Hard Dependency

This stage explicitly depends on self-review.md. Without self-review.md and gate: ready-for-plugin, plugin implementation is forbidden. Even with gate: ready-for-plugin, this stage is still forbidden until the user explicitly confirms entering plugin work. If later backend changes invalidate the previous review result, plugin implementation stays forbidden until a fresh ready-for-plugin result is written again.

Do not treat backend implementation completion by itself as sufficient. Do not treat plan.md by itself as sufficient.

Workspace Resolution

1. If the current project is already apcp-plugin, use it as the plugin root.
2. Otherwise, resolve the sibling repository named apcp-plugin from the parent directory of the current project.
3. Resolve apcp-web-api and task documents from the same workspace when backend references are needed.
4. If the plugin repository cannot be identified confidently, ask once before editing code.

Consumption Rules

Before coding, read:

• requirement.md
• feasibility.md
• plan.md
• self-review.md
• the implemented backend contract
• the existing plugin structure

Plugin work must consume the stable backend contract only. It must not reopen backend requirement, feasibility, plan, implementation, or self-review decisions on its own.

Plugin Scope Rules

• implement only the verification-support capability needed for the current task
• reuse existing popup, content script, manifest, messaging, and session flow when possible
• keep parameters, action flow, and displayed result structure aligned with the reviewed backend contract
• keep the plugin modular so more backend task modules can be appended later without redesigning the architecture

Forbidden Drift

Do not invoke any CodeLaw skill in this stage.

Strictly forbid the following in this stage:

• redefining backend request or response semantics
• compensating for missing backend planning with plugin-side invention
• using plugin work as a substitute for backend self-review
• backfilling backend design from plugin convenience

If plugin work reveals that backend design is still unstable, stop and return to the stage named by the actual problem source.

Refusal Rule

If this skill is called directly without self-review.md being ready-for-plugin, refuse and point back to:

• apcp-web-api-self-review
• or the upstream fallback stage declared in self-review.md

If the user has not explicitly confirmed entering plugin work yet, refuse and stay at the self-review-to-plugin confirmation boundary.