create-yss-spec 1.1.3 → 2.0.0

package/template/.codex/skills/yss-product-lifecycle/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: yss-product-lifecycle
-description: "Use when starting or continuing a YSS product/module/project through opportunity exploration, discovery, business/functional/system/data architecture artifacts, PRD baseline, product design/prototype/interaction design, PRD calibration, OpenAPI Draft/Freeze, engineering baseline, architecture, design review, vertical slices, YSS frontend/backend delivery, review, release, implementation, or retrospective; or when deciding missing artifacts, lifecycle stage, next prompt, or Matt/YSS skill routing."
+description: "Use when starting or continuing a YSS product/module/project through opportunity exploration, discovery, business/functional/system/data architecture artifacts, spec baseline, product design/prototype/interaction design, spec calibration, OpenAPI Draft/Freeze, engineering baseline, architecture, design review, vertical slice tickets, YSS frontend/backend delivery, review, release, implementation, or retrospective; or when deciding missing artifacts, lifecycle stage, next prompt, or Matt/YSS skill routing."
 ---
 
 # YSS Product Lifecycle
@@ -15,19 +15,21 @@ For a small requirement change or iteration on an existing feature, do not resta
 
 ## Documentation Language
 
-For this repository, persistent lifecycle artifacts MUST use Chinese body text by default, because the primary users and reviewers are Chinese readers. This includes discovery notes, PRD, product design, architecture, OpenAPI review/freeze notes, vertical slice issues, Matt skill outputs, review reports, release notes, implementation records, retrospectives, and Git checkpoint explanations.
+For this repository, persistent lifecycle artifacts MUST use Chinese body text by default, because the primary users and reviewers are Chinese readers. This includes discovery notes, specs, product design, architecture, OpenAPI review/freeze notes, vertical slice tickets, Matt skill outputs, review reports, release notes, implementation records, retrospectives, and Git checkpoint explanations.
 
 Keep English identifiers unchanged when they are technical names: file paths, commands, class/method names, API paths, schema names, enum values, error codes, frontmatter keys, YAML/JSON keys, and metadata identifiers. If an upstream skill template uses English section titles, convert the persisted project document to Chinese section titles unless the user explicitly asks for English or the document targets an English-speaking audience.
 
+Treat English skill bodies and templates as source instructions, not as final document language. When writing durable artifacts into this repository, translate section headings, checklist labels, status explanations, review findings, implementation notes, and Git checkpoint explanations into Chinese. Keep only protocol fields, metadata keys, code identifiers, commands, and external product names in English.
+
 Daily execution uses 8 main stages. The previous 21 stage names are governance gates / responsibility points, not a mandatory step-by-step flow for every request. The authoritative mapping of stages, artifacts, templates, and required / conditional gates is `docs/process/lifecycle-artifact-map.md`.
 
 ```text
 intake / lifecycle triage
 -> opportunity and Discovery
--> business / PRD / functional architecture
+-> business / spec / functional architecture
 -> product design and requirement freeze
 -> system / data architecture, engineering contract, and Design Review
--> contract freeze and Issue formalization
+-> contract freeze and ticket formalization
 -> vertical slices and TDD implementation
 -> verification, release, and retrospective
 ```
@@ -38,21 +40,27 @@ Use this lifecycle skill to decide the stage and route to the right workflow. Do
 
 | Layer | Owner | Responsibility | Canonical artifacts |
 |---|---|---|---|
-| Product / requirements | `competitive-intelligence`, `grill-with-docs`, `to-prd` | Clarify market / competitor facts, users, pain, boundaries, acceptance criteria, and PRD scope | `CONTEXT.md`, `docs/adr/`, `docs/discovery/`, `docs/requirements/<feature>-prd.md` |
+| Product / requirements | `competitive-intelligence`, `research`, `grill-with-docs`, `prototype`, `to-spec` | Clarify market / competitor / technical facts, users, pain, boundaries, acceptance criteria, spec scope, and runnable answers to hard design questions | `CONTEXT.md`, `docs/adr/`, `docs/discovery/`, `docs/research/`, `docs/requirements/<feature>-spec.md` |
 | Contract | OpenAPI / YSS API skills, OpenSpec-style Spec Delta | Define and freeze frontend/backend API contracts, plus behavior deltas for medium/high-risk changes | `docs/api/specs/*.yaml`, `docs/specs/<feature>-spec-delta.md`, OpenAPI Draft Review / Freeze records |
-| Delivery planning | `to-issues`, Issue tracker | Split PRD / frozen contract into end-to-end vertical slices | GitLab / GitHub Issues or `docs/requirements/issues/*` |
-| Implementation | `implement`, `tdd`, `diagnosing-bugs`, `code-review` | Build with feedback loops, bug diagnosis, independent review, and fresh verification | tests, review reports, verification records, implementation notes |
+| Delivery planning | `to-tickets`, `wayfinder`, `handoff` / equivalent handoff record, Ticket tracker | Split specs / frozen contracts into end-to-end vertical slice tickets, or map unclear large work before slicing, and preserve context across threads or implementation repos | GitLab / GitHub Issues, local `tickets.md`, `docs/requirements/tickets/*`, `docs/implementation/*` |
+| Implementation | `implement`, `tdd`, `diagnosing-bugs`, `resolving-merge-conflicts`, `code-review` | Build with feedback loops, bug diagnosis, conflict resolution, independent review, and fresh verification | tests, review reports, verification records, implementation notes |
 | YSS engineering | `yss-router` and selected YSS skills | Apply YSS DDD, UI, DTO, Repository, Controller, OpenAPI, and component rules | implementation routing record, Build Architecture Checklist, code/test evidence |
 
 Rules:
 
-- Prefer Matt skills for generic engineering workflow: `grill-with-docs`, `to-prd`, `to-issues`, `implement`, `tdd`, `diagnosing-bugs`, `code-review`, `domain-modeling`, `codebase-design`, and `improve-codebase-architecture`.
-- Use `competitive-intelligence` when market, competitor, pricing, positioning, or customer sentiment facts are needed before Discovery / PRD decisions.
+- Prefer Matt skills for generic engineering workflow: `research`, `grill-with-docs`, `prototype`, `to-spec`, `to-tickets`, `wayfinder`, `implement`, `tdd`, `diagnosing-bugs`, `resolving-merge-conflicts`, `code-review`, `domain-modeling`, `codebase-design`, and `improve-codebase-architecture`.
+- Use `competitive-intelligence` when market, competitor, pricing, positioning, or customer sentiment facts are needed before Discovery / spec decisions.
+- Use `research` when technical facts, standards, third-party API behavior, framework behavior, or official documentation need primary-source evidence before spec, OpenAPI, architecture, or acceptance decisions.
+- Use `prototype` only for throwaway runnable feedback on logic, state-machine, or UI direction questions. Feed the conclusion back into spec, design, ADR, or tickets; do not treat prototype code as production implementation or as the required Ant Design v6 high-fidelity HTML prototype.
 - Preserve OpenAPI 3.1 Draft / Freeze as the API contract gate. Draft is review-only until Freeze.
-- Use OpenSpec-style Spec Delta for API, permission, state-machine, data-model, cross-client, new-module, or high-risk behavior changes. It is a lightweight behavior-delta artifact, not OpenSpec CLI, change-state files, or an extra state machine.
-- After OpenAPI Freeze, route to `to-issues` or an equivalent vertical-slice issue record; do not require extra state-machine artifacts.
+- Use OpenSpec-style Spec Delta only for medium/high-risk behavior changes to an existing frozen Spec baseline, such as API, permission, state-machine, data-model, or cross-client changes. Do not create it for a new product or new module baseline.
+- After OpenAPI Freeze, route to `to-tickets` or an equivalent vertical-slice ticket record; do not require extra state-machine artifacts.
+- Use `wayfinder` before `to-spec` / `to-tickets` when the work is too large or foggy for one session and the destination is not yet clear.
 - Before frontend/backend implementation, first decide whether the impacted frontend/backend runtime projects already exist and can be reused. If an impacted side has no reusable project yet, route to `yss-ddd-scaffold-generator` or `yss-frontend-scaffold-generator` before business implementation.
+- After a YSS DDD backend scaffold is generated, backend build, test, run, OpenAPI generation, README, CI, review, and release commands MUST use the project Maven Wrapper (`./mvnw ...`) from the backend repository root. A bare `mvn ...` command is a process deviation unless an existing repository has a documented wrapper exception and an equivalent verification record.
 - Use `yss-router` before frontend/backend implementation when the task crosses multiple YSS areas. The route output becomes implementation guidance inside the current slice.
+- Use `handoff` or an equivalent handoff record when crossing threads, implementation repositories, prototype branches, or context-window limits.
+- Use `resolving-merge-conflicts` or an equivalent conflict-resolution flow for merge / rebase conflicts before release or merge decisions.
 - Use `code-review` or an independent review agent before merge/release decisions.
 - Require fresh verification evidence before claiming completion.
 
@@ -63,38 +71,43 @@ Architecture artifacts are produced progressively. Do not try to finish every ar
 | Artifact | Lifecycle timing | Primary question | Typical outputs | Diagram support |
 |---|---|---|---|---|
 | Business architecture | Opportunity exploration / Discovery / product definition | Who gets value, in which workflow, and where the product boundary sits | user journey, value stream, role/ecosystem model, capability map | journey map, swimlane, capability map |
-| Product overview design / Functional architecture | PRD baseline / product design / PRD calibration | Which product capabilities, user flows, modules, pages, low-fidelity prototypes, APIs, and data impacts support the MVP boundary | product overview, module map, feature list, priority, dependencies, low-fidelity wireframe, state flow, open questions, PRD gaps | feature/module map, dependency graph, user flow, page map, low-fidelity wireframe |
+| Product overview design / Functional architecture | spec baseline / product design / spec calibration | Which product capabilities, user flows, modules, pages, low-fidelity prototypes, APIs, and data impacts support the MVP boundary | product overview, module map, feature list, priority, dependencies, low-fidelity wireframe, state flow, open questions, spec gaps | feature/module map, dependency graph, user flow, page map, low-fidelity wireframe |
 | System overview design / System architecture | Engineering baseline / architecture review | How the product is built, deployed, integrated, operated, and safely evolved | C4/container view, service boundary, integration, deployment, NFR decisions, rollout/rollback decisions | system architecture, sequence, deployment, DFD |
 | Data architecture | Detailed design before persistence and repository work | How domain data, metadata, versions, lineage, and queries are modeled and stored | conceptual/logical/physical model, meta-model, versioning strategy, lineage/query/index strategy | ER, class, lineage graph, DFD |
 
 For data modeling, metadata management, ER design, versioning, or lineage-analysis products, data architecture is a core product design artifact. It must be explicit before persistence implementation and before OpenAPI Freeze when API schemas depend on the meta-model.
 
-Use `excalidraw-diagram-generator` when diagrams will make boundaries, flows, data structures, or slice dependencies easier to review. Diagrams support the text artifacts; they do not replace PRD, OpenAPI, ADR, issues, or tests.
+Use `excalidraw-diagram-generator` when diagrams will make boundaries, flows, data structures, or slice dependencies easier to review. Diagrams support the text artifacts; they do not replace specs, OpenAPI, ADR, tickets, or tests.
 
 ## Workflow
 
 1. Inspect existing context before asking questions:
    - `CONTEXT.md`
    - `docs/discovery/` and `docs/discovery/reports/`
+   - `docs/research/`
    - `docs/requirements/`
    - `docs/design/`
    - `docs/api/specs/`
    - `docs/architecture/` and `docs/adr/`
-   - `docs/requirements/issues/` and current issue tracker state when available
+   - `docs/requirements/tickets/`, `tickets.md`, and current tracker state when available
 2. Classify the request into one main stage:
-   - intake / lifecycle triage, opportunity and Discovery, business / PRD / functional architecture, product design and requirement freeze, system / data architecture, engineering contract, and Design Review, contract freeze and Issue formalization, vertical slices and TDD implementation, or verification / release / retrospective.
+   - intake / lifecycle triage, opportunity and Discovery, business / spec / functional architecture, product design and requirement freeze, system / data architecture, engineering contract, and Design Review, contract freeze and ticket formalization, vertical slices and TDD implementation, or verification / release / retrospective.
 3. For small changes or iterations, identify the nearest trustworthy existing stage and only expand from the earliest impacted artifact:
    - wording / style / local configuration -> direct minimal change, then verify;
-   - UI behavior or page state -> product design / prototype review / PRD calibration as needed;
+   - UI behavior or page state -> product design / prototype review / spec calibration as needed;
+   - unclear state-machine, complex rules, or UI direction -> `prototype` for throwaway runnable feedback, then feed the conclusion into spec/design/ADR/ticket;
    - API request, response, error, permission, pagination, or concurrency -> system / data architecture, engineering contract, and Design Review with API impact analysis / contract draft / OpenAPI Draft Review / Freeze downstream gates;
    - service boundary, state machine, integration, NFR, rollout, or rollback -> system / data architecture, engineering contract, and Design Review downstream gates;
    - persistence, metadata, versioning, lineage, query, or index -> system / data architecture, engineering contract, and Design Review downstream gates.
 4. Check whether required upstream artifacts exist.
-   - Before PRD calibration, product design, API impact analysis, OpenAPI Draft, requirement freeze, or formal vertical slicing, verify PRD baseline and product overview design / functional architecture exist. If the task does not enter the PRD lifecycle, record the not-applicable reason in the impact assessment.
-   - For UI work, before PRD calibration, API impact analysis, OpenAPI Draft, or requirement freeze, verify low-fidelity `prototype-review` is approved, `docs/design/prototypes/<feature>/index.html` exists as an Ant Design v6 high-fidelity HTML prototype, AntD v6 CLI validation evidence is recorded, and user confirmation is recorded after the prototype is produced. This prototype is a required lifecycle artifact and may be generated automatically by the system / Agent after low-fidelity prototype review; it does not have to be manually supplied by the user.
-   - Before formal vertical slicing, verify PRD, product overview design / functional architecture, OpenAPI Freeze or no-API-impact record, architecture review as needed, and a clear issue destination.
-   - For medium/high-risk API, permission, state-machine, data-model, cross-client, new-module, or safety-sensitive changes, verify an OpenSpec-style Spec Delta exists or record why it is not needed.
+   - Before spec calibration, product design, API impact analysis, OpenAPI Draft, requirement freeze, or formal vertical slicing, verify spec baseline and product overview design / functional architecture exist. If the task does not enter the spec lifecycle, record the not-applicable reason in the impact assessment.
+   - For UI work, before spec calibration, API impact analysis, OpenAPI Draft, or requirement freeze, verify low-fidelity `prototype-review` is approved, `docs/design/prototypes/<feature>/index.html` exists as an Ant Design v6 high-fidelity HTML prototype, AntD v6 CLI validation evidence is recorded, and user confirmation is recorded after the prototype is produced. This prototype is a required lifecycle artifact and may be generated automatically by the system / Agent after low-fidelity prototype review; it does not have to be manually supplied by the user.
+   - Before formal vertical slicing, verify spec, product overview design / functional architecture, OpenAPI Freeze or no-API-impact record, architecture review as needed, and a clear ticket destination.
+   - For medium/high-risk API, permission, state-machine, data-model, cross-client, or safety-sensitive changes to an existing frozen baseline, verify an OpenSpec-style Spec Delta exists or record why it is not needed. New product and new module baselines do not use Spec Delta.
+   - When technical, standard, framework, or third-party API facts influence downstream decisions, verify `research` or an equivalent primary-source record exists and is cited.
    - Before frontend/backend implementation, verify vertical slice scope, implementation repo/location, whether the impacted frontend/backend runtime projects already exist and are reusable, YSS skill routing, Build Architecture Checklist, test command, and review strategy.
+   - For backend slices, verify planned build / test / OpenAPI / CI commands use `./mvnw ...`; if commands use bare `mvn ...`, stop and either correct them or record a controlled wrapper exception before implementation.
+   - Before crossing threads, implementation repos, prototype branches, or long contexts, verify `handoff` or an equivalent handoff record captures source artifacts, current stage, open questions, verification commands, and next owner.
 5. Output the next action:
    - artifact to create/update,
    - specialist skill to invoke,
@@ -109,7 +122,7 @@ Use `excalidraw-diagram-generator` when diagrams will make boundaries, flows, da
 
 ## Stage Git Checkpoints
 
-Lifecycle artifacts are part of the product record, not scratch notes. Do not let PRD, design, OpenAPI, architecture, review, issue, or retrospective outputs remain only in the local worktree across multiple stages.
+Lifecycle artifacts are part of the product record, not scratch notes. Do not let spec, design, OpenAPI, architecture, review, ticket, or retrospective outputs remain only in the local worktree across multiple stages.
 
 At the end of each stage, report:
 
@@ -123,7 +136,7 @@ At the end of each stage, report:
 
 When committing, prefer small checkpoint commits by artifact type or stage, for example:
 
-- `docs: add data modeling discovery and prd artifacts`
+- `docs: add data modeling discovery and spec artifacts`
 - `docs: add data modeling openapi and architecture reviews`
 - `docs: update lifecycle checkpoint rules`
 
@@ -141,9 +154,12 @@ Default routing:
 
 | Intent | Next skill / workflow |
 |---|---|
-| Start a new business product/module | intake -> opportunity and Discovery -> `competitive-intelligence` when market / competitor facts are needed -> `grill-with-docs` -> `to-prd` -> product overview design / functional architecture -> product design and requirement freeze when UI exists |
-| Analyze competitors, substitute workflows, pricing, positioning, or market facts | `competitive-intelligence`; then feed stable findings into `grill-with-docs` and `to-prd` |
-| Design UI flow after PRD baseline | Verify product overview design / functional architecture first, then use `product-design:index` as the primary Product Design router; follow its focused routing such as `$get-context`, `$ideate`, `$prototype`, `$image-to-code`, or `$url-to-code` |
+| Start a new business product/module | intake -> opportunity and Discovery -> `competitive-intelligence` when market / competitor facts are needed -> `grill-with-docs` -> `to-spec` -> product overview design / functional architecture -> product design and requirement freeze when UI exists |
+| Plan a large unclear effort | `wayfinder`; map the destination, decisions, fog, and frontier tickets before `to-spec` / `to-tickets` |
+| Analyze competitors, substitute workflows, pricing, positioning, or market facts | `competitive-intelligence`; then feed stable findings into `grill-with-docs` and `to-spec` |
+| Research technical facts, standards, framework behavior, or third-party APIs | `research`; feed cited findings into spec, OpenAPI, architecture, ADR, or acceptance criteria |
+| Answer a design question that needs runnable feedback | `prototype`; feed the conclusion into spec, design, ADR, or ticket, then delete or absorb throwaway code |
+| Design UI flow after spec baseline | Verify product overview design / functional architecture first, then use `product-design:index` as the primary Product Design router; follow its focused routing such as `$get-context`, `$ideate`, `$prototype`, `$image-to-code`, or `$url-to-code` |
 | Review low-fidelity prototype before high-fidelity design | `prototype-review` |
 | Build high-fidelity interactive HTML prototype | Use `product-design:index` as the primary entrypoint and route to the appropriate Product Design focused workflow for prototype/code output; query AntD v6 design/component/demo/token/semantic facts with `antd` CLI before output; the required stage output must be Ant Design v6 HTML at `docs/design/prototypes/<feature>/index.html`, may be system / Agent generated, must record AntD CLI validation evidence, and must be confirmed by the user before downstream gates |
 | Review contract draft / OpenAPI Draft inside architecture/design review | `yss-openapi-draft-review` |
@@ -151,20 +167,23 @@ Default routing:
 | Clarify architecture artifact timing or gaps | this skill plus `docs/process/lifecycle-artifact-map.md` and `references/artifact-checklist.md` |
 | Create architecture/process/data diagrams | `excalidraw-diagram-generator` as a support skill |
 | Design meta-model / metadata / lineage data architecture | architecture/design workflow plus `yss-domain-modeling` or `yss-domain`; use `excalidraw-diagram-generator` for ER, lineage, DFD, or class diagrams when helpful |
-| Split delivery scope after PRD / OpenAPI Freeze | `to-issues`; record whether impacted frontend/backend projects already exist, and whether scaffold initialization is needed |
+| Split delivery scope after spec / OpenAPI Freeze | `to-tickets`; record whether impacted frontend/backend projects already exist, and whether scaffold initialization is needed |
+| Cross threads, repos, prototype branches, or long contexts | `handoff` or equivalent handoff record; preserve source artifacts, current stage, open questions, verification commands, and next owner |
 | Implement a slice | first check impacted frontend/backend project existence; route missing backend to `yss-ddd-scaffold-generator`, missing frontend to `yss-frontend-scaffold-generator`, then use `implement` plus `tdd`; use `yss-router` first when multiple YSS areas are touched |
 | Fix a bug or test failure | `diagnosing-bugs` then `tdd` |
+| Resolve merge or rebase conflicts | `resolving-merge-conflicts`; record both intents, resolution trade-offs, and fresh verification |
 | Review implementation | `code-review` plus YSS-specific review inputs |
 | Build Vue page | `yss-ui` plus related frontend skills chosen by `yss-router` |
 | Build backend module from scratch | `yss-ddd-scaffold-generator` |
 | Model backend domain | `yss-domain` / `yss-backend-scaffold-domain` |
-| Implement persistence | `yss-repository` plus `yss-mybatis` when data architecture and domain metadata are stable |
-| Implement Web adapter | `yss-web-controller` |
+| Implement Application use case / transaction boundary | `yss-backend-scaffold-application` |
+| Implement persistence | `yss-repository` plus `mapstruct` / `lombok`; add `yss-mybatis` when data architecture and domain metadata are stable |
+| Implement Web adapter | `yss-web-controller` plus `yss-dto` / `mapstruct` / `lombok` when DTO / VO / WebConvertor work is involved |
 
 ## When Not To Use
 
 - For a single YTable height/layout issue, use `yss-use-table-height` directly.
-- For a single Repository / PO / Convertor / GatewayImpl task with stable domain metadata and data architecture, use `yss-repository` directly.
+- For a single Repository / PO / Convertor / GatewayImpl task with stable domain metadata and data architecture, use `yss-repository` directly, and also load `mapstruct` / `lombok` when POJO or Convertor code is generated.
 - For a request that only asks to run a specific Matt skill and already has the needed lifecycle artifacts, use that Matt skill directly.
 
 ## Output Contract
@@ -204,20 +223,24 @@ When the user explicitly asks for a full delivery plan, include stage-by-stage t
 ## Guardrails
 
 - Do not skip opportunity exploration for new product/module work; use `competitive-intelligence` when market/competitor facts are needed, or record why it is not needed.
-- Do not treat Discovery outputs as frozen downstream design. Discovery can provide product capability guidance and downstream impact signals, but PRD, functional architecture, OpenAPI, system architecture, and data architecture still require their own gates.
-- Do not start implementation before PRD is calibrated, product overview design / functional architecture exists, required architecture artifacts are explicit, product design / prototype / interaction design exists, low-fidelity `prototype-review` passes, high-fidelity Ant Design v6 HTML prototype exists when UI exists, OpenAPI Freeze decision, engineering baseline, design review, and vertical slice are clear.
+- Do not make technical, standards, framework, or third-party API claims that affect spec, OpenAPI, architecture, acceptance, or release decisions without `research` or equivalent primary-source evidence.
+- Do not treat Discovery outputs as frozen downstream design. Discovery can provide product capability guidance and downstream impact signals, but spec, functional architecture, OpenAPI, system architecture, and data architecture still require their own gates.
+- Do not treat throwaway `prototype` code as production code, as an implementation shortcut, or as the required Ant Design v6 high-fidelity HTML prototype. Keep the conclusion, delete or absorb the code.
+- Do not start implementation before the spec is calibrated, product overview design / functional architecture exists, required architecture artifacts are explicit, product design / prototype / interaction design exists, low-fidelity `prototype-review` passes, high-fidelity Ant Design v6 HTML prototype exists when UI exists, OpenAPI Freeze decision, engineering baseline, design review, and vertical slice ticket are clear.
 - Do not start implementation before deciding whether the impacted frontend/backend runtime projects already exist and can be reused. Missing or conflicting runtime projects must route back to implementation routing and scaffold initialization first.
 - Do not skip business architecture for new products unless the product boundary, users, ecosystem, and value stream are already captured elsewhere.
-- Do not skip product overview design / functional architecture after PRD baseline. It is a required artifact before PRD calibration, product design / prototype / interaction design, API impact analysis, OpenAPI Draft, requirement freeze, or implementation. Only tasks that do not enter the PRD lifecycle may record a not-applicable reason in the impact assessment.
+- Do not skip product overview design / functional architecture after spec baseline. It is a required artifact before spec calibration, product design / prototype / interaction design, API impact analysis, OpenAPI Draft, requirement freeze, or implementation. Only tasks that do not enter the spec lifecycle may record a not-applicable reason in the impact assessment.
 - Do not skip system architecture when services, deployment, integrations, performance, security, reliability, or operations are affected.
 - Do not skip data architecture before persistence / repository work. For data modeling, metadata, versioning, or lineage products, treat it as mandatory before Design Review and OpenAPI Freeze.
-- Do not let Excalidraw diagrams invent requirements or architecture decisions; diagrams must point back to source artifacts and any findings must be written back to PRD, OpenAPI, ADR, or issues.
+- Do not let Excalidraw diagrams invent requirements or architecture decisions; diagrams must point back to source artifacts and any findings must be written back to spec, OpenAPI, ADR, or tickets.
 - Do not treat an OpenAPI Draft as an implementation or generated-client contract before OpenAPI Freeze. It is review-only until engineering baseline, system/data architecture, Design Review, and Freeze have approved it.
-- Do not treat OpenSpec-style Spec Delta as a replacement for PRD, OpenAPI, Design Review, or vertical slice Issues. It only captures behavior differences, acceptance scenarios, and test / verification mapping.
+- Do not treat OpenSpec-style Spec Delta as a replacement for spec, OpenAPI, Design Review, or vertical slice tickets. It only captures behavior differences, acceptance scenarios, and test / verification mapping.
 - Do not require Spec Delta for small wording, local style, configuration, or low-risk bug fixes unless the change expands into API, permission, state-machine, data-model, cross-client, or security impacts.
 - Do not move an OpenAPI Draft into Engineering Baseline / YSS DDD Review until `yss-openapi-draft-review` or an equivalent persistent review verifies P0 feature coverage, page action to endpoint mapping, YSS response wrappers, error structures, permissions, concurrency, security red lines, and contract test seams.
 - Do not route directly to frontend/backend skills before `yss-router` when the task crosses multiple YSS areas.
+- Do not cross threads, implementation repos, prototype branches, or context-window limits without `handoff` or an equivalent handoff record when downstream agents need continuity.
 - Do not generate production code from this skill; hand off to the selected specialist skill.
+- Do not complete merge/rebase conflict work without documenting resolution intent and rerunning relevant checks.
 - Treat TDD as the default for business behavior implementation; generated code, configuration, or throwaway prototypes may use a documented exception with a verification command.
 - Require independent review and fresh verification evidence before calling work complete.
 - Flag security red lines from `AGENTS.md` as human-review items.

package/template/.codex/skills/yss-product-lifecycle/references/artifact-checklist.md

@@ -6,44 +6,46 @@ Use this checklist to decide whether the current request can move forward or mus
 
 | Artifact | Typical location | Ready when |
 |---|---|---|
-| Domain context | `CONTEXT.md` | Key domain terms, actors, workflows, and invariants are clear enough for PRD / code naming |
+| Domain context | `CONTEXT.md` | Key domain terms, actors, workflows, and invariants are clear enough for spec / code naming |
 | Discovery | `docs/discovery/<feature>-discovery.md` or issue note | User, pain, why now, MVP, non-goals, and success criteria are explicit |
-| Competitive intelligence | `docs/discovery/reports/<feature>-competitive-intelligence.md`, `<feature>-competitive-matrix.md`, or issue note | Competitors / substitutes, evidence sources, feature / pricing / positioning comparison, confidence, and PRD implications are explicit |
-| PRD | `docs/requirements/<feature>-prd.md` or issue | User stories, acceptance criteria, out of scope, OpenAPI impact, test decisions, and human-review points are clear |
-| Business architecture | `docs/architecture/<feature>-business-architecture.md` or PRD section | User journey, value stream, roles, external systems, and capability map are clear |
-| Functional architecture | `docs/architecture/<feature>-functional-architecture.md` or PRD/design section | Product capabilities, module boundaries, priority, dependencies, and MVP scope are clear |
-| Product overview design | `docs/design/<feature>-product-overview-design.md` | Pages, flows, states, permissions, API candidates, and PRD gaps are clear |
+| Competitive intelligence | `docs/discovery/reports/<feature>-competitive-intelligence.md`, `<feature>-competitive-matrix.md`, or ticket note | Competitors / substitutes, evidence sources, feature / pricing / positioning comparison, confidence, and spec implications are explicit |
+| Spec | `docs/requirements/<feature>-spec.md` or tracker ticket | User stories, acceptance criteria, out of scope, OpenAPI impact, test decisions, and human-review points are clear |
+| Business architecture | `docs/architecture/<feature>-business-architecture.md` or spec section | User journey, value stream, roles, external systems, and capability map are clear |
+| Functional architecture | `docs/architecture/<feature>-functional-architecture.md` or spec/design section | Product capabilities, module boundaries, priority, dependencies, and MVP scope are clear |
+| Product overview design | `docs/design/<feature>-product-overview-design.md` | Pages, flows, states, permissions, API candidates, and spec gaps are clear |
 | Prototype / interaction review | `docs/design/<feature>-prototype-review.md` or issue comment | UI paths, empty/error/loading states, permission states, and API backflow list are reviewed |
-| High-fidelity HTML prototype | `docs/design/prototypes/<feature>/index.html` | Ant Design v6 interactive HTML prototype exists after low-fidelity review and before PRD calibration / API Draft |
-| API impact / OpenAPI Draft | `docs/api/specs/<feature>.yaml`, issue note, or API impact record | Request/response, wrappers, errors, pagination, permissions, concurrency, and contract test seams are reviewable |
-| OpenAPI Freeze | `docs/api/<feature>-openapi-freeze.md` or issue comment | Draft has been reviewed and marked stable for frontend/backend implementation |
+| High-fidelity HTML prototype | `docs/design/prototypes/<feature>/index.html` | Ant Design v6 interactive HTML prototype exists after low-fidelity review and before spec calibration / API Draft |
+| API impact / OpenAPI Draft | `docs/api/specs/<feature>.yaml`, ticket note, or API impact record | Request/response, wrappers, errors, pagination, permissions, concurrency, and contract test seams are reviewable |
+| OpenAPI Freeze | `docs/api/<feature>-openapi-freeze.md` or ticket comment | Draft has been reviewed and marked stable for frontend/backend implementation |
 | Engineering baseline | `docs/architecture/<feature>-engineering-baseline-review.md` | YSS DDD module boundary, dependency direction, DTO/VO/CMD/Query conventions, and scaffold constraints are reviewed |
 | System architecture | `docs/architecture/<feature>-system-overview-design.md`, `<feature>-system-architecture.md`, or `<feature>-architecture.md` | Service/module boundaries, deployment, integration, security, performance, reliability, observability, rollout, rollback, and architecture review questions are clear |
 | Data architecture | `docs/architecture/<feature>-data-architecture.md` | Conceptual/logical/physical model, metadata, versioning, lineage, query, index, storage, and migration constraints are clear |
-| Design review | `docs/architecture/<feature>-architecture-review.md` or issue comment | Open questions, risks, safety red lines, and implementation constraints have an explicit review outcome |
-| Vertical slice Issue | GitLab / GitHub Issue or `docs/requirements/issues/<feature>-slice.md` | Slice is end-to-end, independently demoable/verifiable, and not split by technical layer only |
-| Implementation routing | `docs/requirements/issues/<feature>-implementation-routing.md` using `docs/templates/implementation-routing-template.md` or issue note | Required YSS skills, impacted frontend/backend project existence decision, scaffold initialization plan when needed, verification command, review strategy, and rollback points are clear |
-| Build Architecture Checklist | `docs/implementation/<feature>-build-architecture-checklist.md`, implementation plan, or issue note | Architecture constraints are bound to slice IDs and have status/evidence/follow-up |
-| Review report | MR / PR comment or `docs/requirements/issues/<feature>-review.md` | Independent review covers spec fidelity, coding standards, tests, contract alignment, and safety red lines |
-| Fresh verification | `docs/testing/<feature>-verification.md`, issue / MR comment, or release note | Verification command, timestamp, result, failures, and residual risks are recorded |
-| Release / rollout | `docs/releases/`, `docs/implementation/`, issue / MR comment | Release steps, rollback, monitoring, and user-facing notes are clear when applicable |
-| Retrospective | `docs/process/sprint-retros/` or issue note | Process learnings, architecture drift, review findings, and follow-up changes are captured |
+| Design review | `docs/architecture/<feature>-architecture-review.md` or ticket comment | Open questions, risks, safety red lines, and implementation constraints have an explicit review outcome |
+| Vertical slice ticket | GitLab / GitHub Issue, local `tickets.md`, or `docs/requirements/tickets/<feature>-slice.md` | Slice is end-to-end, independently demoable/verifiable, and not split by technical layer only |
+| Implementation routing | `docs/requirements/tickets/<feature>-implementation-routing.md`, `docs/templates/implementation-routing-template.md`, or ticket note | Required YSS skills, impacted frontend/backend project existence decision, scaffold initialization plan when needed, verification command, review strategy, and rollback points are clear |
+| Build Architecture Checklist | `docs/implementation/<feature>-build-architecture-checklist.md`, implementation plan, or ticket note | Architecture constraints are bound to slice IDs and have status/evidence/follow-up |
+| Review report | MR / PR comment or `docs/requirements/tickets/<feature>-review.md` | Independent review covers spec fidelity, coding standards, tests, contract alignment, and safety red lines |
+| Fresh verification | `docs/testing/<feature>-verification.md`, ticket / MR comment, or release note | Verification command, timestamp, result, failures, and residual risks are recorded |
+| Release / rollout | `docs/releases/`, `docs/implementation/`, ticket / MR comment | Release steps, rollback, monitoring, and user-facing notes are clear when applicable |
+| Retrospective | `docs/process/sprint-retros/` or ticket note | Process learnings, architecture drift, review findings, and follow-up changes are captured |
 
 ## Lifecycle Gate Checks
 
 - Discovery is enough to explain user, pain, MVP, non-goals, success criteria, and downstream UI/API/data/architecture impact.
-- Competitive intelligence uses current public evidence, separates facts from inference, and feeds PRD / MVP decisions instead of becoming requirements by itself.
-- PRD is enough to derive vertical slice acceptance tests and identify OpenAPI impact.
+- Competitive intelligence uses current public evidence, separates facts from inference, and feeds spec / MVP decisions instead of becoming requirements by itself.
+- Spec is enough to derive vertical slice acceptance tests and identify OpenAPI impact.
 - UI work with user-facing flows has product design, interaction states, and prototype review evidence.
 - API changes have OpenAPI Draft Review and Freeze evidence before implementation.
 - Persistence, metadata, versioning, lineage, query, or index changes have data architecture before Repository / MyBatis implementation.
 - Service boundary, integration, deployment, reliability, performance, or operations changes have system architecture before implementation.
-- Vertical slice Issues are end-to-end and independently verifiable.
+- Vertical slice tickets are end-to-end and independently verifiable.
 - Impacted frontend/backend runtime projects are confirmed to exist and be reusable before implementation; otherwise scaffold initialization is recorded and completed first.
+- Backend build, test, OpenAPI generation, CI, review, and release commands use the backend repository root `./mvnw ...`; bare `mvn ...` has a documented controlled exception or is corrected before implementation / completion.
+- Durable project documents use Chinese body text and Chinese section titles; English skill/template wording is treated as source guidance and not copied verbatim into deliverables.
 - `yss-router` has selected the minimal YSS implementation skills before frontend/backend implementation when multiple YSS areas are touched.
 - Build Architecture Checklist is established before implementing high-risk or architecture-sensitive slices.
 - Fresh verification evidence exists before any complete / merge / release claim.
-- Excalidraw diagrams, when used, are referenced by the corresponding Discovery, PRD, design, architecture, or issue artifact and do not stand alone as decisions.
+- Excalidraw diagrams, when used, are referenced by the corresponding Discovery, spec, design, architecture, or ticket artifact and do not stand alone as decisions.
 
 ## Missing Artifact Response
 

package/template/.codex/skills/yss-product-lifecycle/references/stage-routing.md

@@ -7,26 +7,26 @@ Use this reference after reading current repo context. It maps request shape to
 | Stage | Use when | Inputs to inspect | Output | Next route |
 |---|---|---|---|---|
 | 1. Intake / lifecycle triage | 新需求、继续需求、Bug、小调整、流程不清、缺失资产判断 | User request, `CONTEXT.md`, docs, issues, git state | stage decision, nearest trustworthy artifact, minimal skill list | route to earliest impacted stage |
-| 2. Opportunity and Discovery | 模糊想法、竞品/市场输入、用户痛点尚不清楚 | discovery docs, market/user facts, stakeholder notes | user, pain, why now, MVP, non-goals, success criteria, downstream impact | `competitive-intelligence` when market / competitor facts are needed, then `grill-with-docs` / PRD |
-| 3. Business / PRD / functional architecture | 需要明确用户故事、验收标准、功能边界、模块依赖 | discovery, `CONTEXT.md`, ADRs, existing PRD | PRD, business architecture, functional architecture, PRD review notes | product design or contract design |
-| 4. Product design and requirement freeze | 有 UI、页面、交互、状态矩阵、权限状态、空/错/加载态、高保真体验 | PRD, design system, existing UI, component docs | product overview design, interaction spec, state matrix, prototype review, Ant Design v6 high-fidelity HTML prototype, requirement freeze | contract and architecture review |
-| 5. System / data architecture, engineering contract, and Design Review | 接口、DTO、错误结构、后端新服务、新模块、DDD 分层、服务边界、部署、集成、状态机、权限、NFR、持久化、元模型、版本、血缘 | calibrated requirements, design inputs, API impact decision, engineering impact decision | API impact record; contract sketch or reviewable OpenAPI Draft marked draft-for-review; OpenAPI Draft Review; engineering baseline review; system overview; data architecture when required; ADR candidates; Design Review result | contract freeze and Issue formalization |
-| 6. Contract freeze and Issue formalization | OpenAPI Freeze、无 API 影响记录、正式拆分垂直切片 | Design Review approval, contract draft / OpenAPI Draft, PRD/design/architecture artifacts | OpenAPI Freeze or no API impact record; GitHub/GitLab/local vertical slice Issues | vertical slices and TDD implementation |
-| 7. Vertical slices and TDD implementation | issue、切片、实现、review、清理简化 | frozen contract / no API impact, approved slice, implementation repo/location | implementation routing, YSS skill routing, tests, review, verification evidence | verification, release, and retrospective |
+| 2. Opportunity and Discovery | 模糊想法、竞品/市场输入、用户痛点尚不清楚 | discovery docs, market/user facts, stakeholder notes | user, pain, why now, MVP, non-goals, success criteria, downstream impact | `competitive-intelligence` when market / competitor facts are needed, then `grill-with-docs` / spec |
+| 3. Business / spec / functional architecture | 需要明确用户故事、验收标准、功能边界、模块依赖 | discovery, `CONTEXT.md`, ADRs, existing Spec | Spec, business architecture, functional architecture, Spec review notes | product design or contract design |
+| 4. Product design and requirement freeze | 有 UI、页面、交互、状态矩阵、权限状态、空/错/加载态、高保真体验 | spec, design system, existing UI, component docs | product overview design, interaction spec, state matrix, prototype review, Ant Design v6 high-fidelity HTML prototype, requirement freeze | contract and architecture review |
+| 5. System / data architecture, engineering contract, and Design Review | 接口、DTO、错误结构、后端新服务、新模块、DDD 分层、服务边界、部署、集成、状态机、权限、NFR、持久化、元模型、版本、血缘 | calibrated requirements, design inputs, API impact decision, engineering impact decision | API impact record; contract sketch or reviewable OpenAPI Draft marked draft-for-review; OpenAPI Draft Review; engineering baseline review; system overview; data architecture when required; ADR candidates; Design Review result | contract freeze and ticket formalization |
+| 6. Contract freeze and ticket formalization | OpenAPI Freeze、无 API 影响记录、正式拆分垂直切片 | Design Review approval, contract draft / OpenAPI Draft, spec/design/architecture artifacts | OpenAPI Freeze or no API impact record; GitHub/GitLab/local vertical slice tickets | vertical slices and TDD implementation |
+| 7. Vertical slices and TDD implementation | ticket、切片、实现、review、清理简化 | frozen contract / no API impact, approved slice, implementation repo/location | implementation routing, YSS skill routing, tests, review, verification evidence | verification, release, and retrospective |
 | 8. Verification, release, and retrospective | 准备合并、发布、归档、复盘、用户手册 | diff, tests, CI, review notes, release notes | fresh verification, release / rollback notes, retrospective, doc updates | next intake |
 
 ## Routing Principles
 
-- Treat lifecycle opportunity exploration as product/MVP boundary work. Discovery may produce competitive analysis via `competitive-intelligence`, an opportunity statement, product capability guidance, and downstream impact signals, but it must not freeze PRD, final functional architecture, OpenAPI, data architecture, or technical system design.
-- Small iterations only expand from the earliest affected artifact. Do not rerun Discovery or PRD if a copy/style/config change has no API, state, permission, data, module boundary, or security impact.
+- Treat lifecycle opportunity exploration as product/MVP boundary work. Discovery may produce competitive analysis via `competitive-intelligence`, an opportunity statement, product capability guidance, and downstream impact signals, but it must not freeze spec, final functional architecture, OpenAPI, data architecture, or technical system design.
+- Small iterations only expand from the earliest affected artifact. Do not rerun Discovery or spec if a copy/style/config change has no API, state, permission, data, module boundary, or security impact.
 - If a small iteration only changes copy, local style, an existing option value, or documentation without touching API, state, permission, data, module boundary, or security red lines, route to direct minimal change plus verification.
-- API changes route through OpenAPI Draft Review and Freeze, then `to-issues`.
+- API changes route through OpenAPI Draft Review and Freeze, then `to-tickets`.
 - For implementation spanning frontend and backend, first check whether the impacted frontend/backend runtime projects already exist and can be reused; if not, route to scaffold initialization before `yss-router`.
-- If multiple PRDs or issues look relevant, ask the user which one to continue before planning work.
+- If multiple specs or tickets look relevant, ask the user which one to continue before planning work.
 
 ## Required Inspection Before Implementation
 
-1. Inspect the relevant PRD, issue, OpenAPI Freeze or no-API-impact record, and architecture/design review when applicable.
+1. Inspect the relevant spec, ticket, OpenAPI Freeze or no-API-impact record, and architecture/design review when applicable.
 2. Confirm the implementation repo/location.
 3. Confirm whether each impacted frontend/backend runtime project already exists and is reusable; if not, route to `yss-ddd-scaffold-generator` or `yss-frontend-scaffold-generator`.
 4. Confirm `yss-router` output when frontend/backend/YSS areas are involved.
@@ -40,7 +40,7 @@ Use this reference after reading current repo context. It maps request shape to
 
 ```text
 使用 yss-product-lifecycle，判断 <feature> 当前生命周期阶段。
-请先检查现有 Discovery、PRD、设计、OpenAPI、架构和 Issue 资产，
+请先检查现有 Discovery、spec、设计、OpenAPI、架构和 ticket 资产，
 然后输出缺失资产、是否阻塞、下一步推荐 skill 和可直接使用的提示词。
 ```
 
@@ -49,14 +49,14 @@ Use this reference after reading current repo context. It maps request shape to
 ```text
 使用 yss-product-lifecycle，判断 <topic> 是否需要先进入竞品分析。
 如果需要，请路由到 competitive-intelligence，输出研究问题、竞品范围、证据来源计划、
-竞品矩阵落点、PRD 输入和下一步 grill-with-docs / to-prd 衔接方式。
+竞品矩阵落点、spec 输入和下一步 grill-with-docs / to-spec 衔接方式。
 ```
 
 ### API change
 
 ```text
 使用 yss-product-lifecycle，评估 <feature> 的 API 影响。
-请判断是否需要 OpenAPI Draft、Draft Review、Freeze、to-issues，
+请判断是否需要 OpenAPI Draft、Draft Review、Freeze、to-tickets，
 并列出进入实现前必须补齐的 YSS skill routing、测试命令和审查点。
 ```
 
@@ -64,7 +64,7 @@ Use this reference after reading current repo context. It maps request shape to
 
 ```text
 使用 yss-product-lifecycle，检查 <issue-or-feature> 的实现准备度。
-若 PRD、OpenAPI Freeze 或架构清单缺失，请路由回对应阶段；
+若 spec、OpenAPI Freeze 或架构清单缺失，请路由回对应阶段；
 若已就绪，请先判断受影响的 frontend/backend 工程是否已存在且可复用；
 若缺失则路由到对应脚手架 skill，否则输出最小 YSS skill 集合、TDD 策略、review 策略和验证命令。
 ```

package/template/.codex/skills/yss-product-lifecycle/references/yss-skill-routing.md

@@ -16,9 +16,11 @@ Use this reference after lifecycle stage and slice scope are clear. Pick the min
 | Backend service from scratch | `yss-ddd-scaffold-generator` | After implementation location decision; then baseline check |
 | Backend scaffold baseline | `yss-backend-scaffold-parent` | Required after generated backend skeleton and before business implementation |
 | Domain modeling / aggregate / state behavior | `yss-domain-modeling`, `yss-domain`, `yss-backend-scaffold-domain` | Use before repository/controller code when domain concepts are unstable |
-| Repository / PO / Convertor / GatewayImpl | `yss-repository` | Add `yss-mybatis` / `yss-backend-scaffold-infrastructure` for mapper/persistence details |
-| Web controller / DTO / VO / Web Convertor | `yss-web-controller`, `yss-dto`, `yss-backend-scaffold-web` | Requires OpenAPI Freeze or no-API-impact record |
-| Java coding style and review | `alibaba-java-code-style` | Treat blockers as review blockers |
+| Application use case orchestration / transaction boundary | `yss-backend-scaffold-application` | Use when implementing AppService, command/query handling, cross-aggregate coordination, or transaction boundaries |
+| Repository / PO / Convertor / GatewayImpl | `yss-repository` | Add `mapstruct` and `lombok` for POJO / Convertor work; add `yss-mybatis` / `yss-backend-scaffold-infrastructure` for mapper/persistence details |
+| Web controller / DTO / VO / Web Convertor | `yss-web-controller`, `yss-dto`, `yss-backend-scaffold-web` | Requires OpenAPI Freeze or no-API-impact record; add `mapstruct` and `lombok` when DTO / VO / WebConvertor objects are created or converted |
+| POJO boilerplate and object conversion | `lombok`, `mapstruct` | Required for Java POJO getter/setter/constructor/builder/logging and DTO / VO / PO / Domain Model conversion work |
+| Java coding style and review | `alibaba-java-code-style` | Treat blockers as review blockers; include MapStruct / Lombok processor and anti-pattern checks |
 | SQL condition/template/query utilities | `yss-sql-condition`, `yss-sql-tpl` | SQL red line still requires human review for native SQL |
 | Audit log | `yss-audit-log` | Security and traceability impacts must be recorded |
 | Cache | `yss-cache` | Include invalidation and consistency strategy |
@@ -29,9 +31,11 @@ Use this reference after lifecycle stage and slice scope are clear. Pick the min
 ## Routing Rules
 
 - Do not route directly to frontend/backend implementation skills before `yss-router` when the task crosses multiple YSS areas.
-- Do not use backend implementation skills before required PRD, OpenAPI Freeze/no-impact record, architecture/data design, and Build Architecture Checklist are ready for the slice.
+- Do not use backend implementation skills before required spec, OpenAPI Freeze/no-impact record, architecture/data design, and Build Architecture Checklist are ready for the slice.
 - Do not use Repository / MyBatis skills before data architecture and domain metadata are stable enough to review.
 - Do not use Controller / DTO skills before OpenAPI contract is frozen or explicitly marked as no API impact.
+- Do not implement DTO / VO / PO / Domain Model conversions with `BeanUtils.copyProperties`, reflection copy, or repeated manual field assignment unless the implementation contract records a controlled exception, tests, and review evidence.
+- Do not handwrite batches of getter/setter/constructor/builder/logger code for Java POJO classes when Lombok is available; use `lombok` or record a controlled exception.
 - Do not use UI implementation skills before `yss-design-system` and product design/prototype review when user-facing workflow is affected.
 - For bugs, start with `diagnosing-bugs`; route to YSS skills only after the failing feedback command points to the impacted area.
 
@@ -41,7 +45,7 @@ Use this reference after lifecycle stage and slice scope are clear. Pick the min
 请使用 yss-router 为 <slice> 选择最小 YSS skill 集合。
 
 已知资产：
-- PRD / Issue: <path-or-link>
+- Spec / ticket: <path-or-link>
 - OpenAPI Freeze / no API impact: <path-or-link>
 - Architecture / data design: <path-or-link>
 - Build Architecture Checklist: <path-or-link>
@@ -50,7 +54,8 @@ Use this reference after lifecycle stage and slice scope are clear. Pick the min
 请输出：
 1. 必须加载的 YSS skills
 2. 可选 skills 与触发条件
-3. TDD / 验证命令
-4. 人审点和 TODO-HUMAN-REVIEW
-5. 不应触碰的范围
+3. 是否必须加载 `mapstruct` / `lombok`，以及对象转换和 POJO 样板代码证据
+4. TDD / 验证命令
+5. 人审点和 TODO-HUMAN-REVIEW
+6. 不应触碰的范围
 ```

package/template/.codex/skills/yss-repository/SKILL.md

@@ -23,8 +23,10 @@ description: 用于生成或重构 YSS Repository 持久层与 Domain Gateway
 
 1. 先确认输入来源：领域模型、metadata、数据库表、DDL。
 2. 如果 metadata 不完整，优先转到 `yss-db2mybatis` 提取。
-3. 生成代码时严格保持 Domain 与 Infrastructure 分层边界。
-4. 默认先生成基础 CRUD 骨架，把复杂查询留给手工实现。
+3. 涉及 POJO 字段、getter/setter、constructor、builder 或日志时，必须加载并遵守 `lombok`。
+4. 涉及 `PO <-> Domain Model`、集合转换、更新映射或枚举转换时，必须加载并遵守 `mapstruct`。
+5. 生成代码时严格保持 Domain 与 Infrastructure 分层边界。
+6. 默认先生成基础 CRUD 骨架，把复杂查询留给手工实现。
 
 ## 产物范围
 
@@ -38,17 +40,23 @@ description: 用于生成或重构 YSS Repository 持久层与 Domain Gateway
 
 - Domain 不依赖 Infrastructure。
 - Gateway 定义在 Domain，实现放在 Infrastructure。
-- Convertor 优先使用 MapStruct。
+- PO / Domain Model 等 POJO 样板代码优先使用 Lombok；不要成片手写 getter/setter、constructor、builder 或 logger。
+- Convertor 必须优先使用 MapStruct；禁止 `BeanUtils.copyProperties`、反射式通用拷贝和重复手写字段赋值，除非实现合同记录受控例外、测试和 review 证据。
+- MapStruct 与 Lombok 同时使用时，必须确认注解处理器顺序和 `lombok-mapstruct-binding` 配置；构建命令使用项目根目录 `./mvnw ...`。
 - 逻辑删除、审计字段、主键策略要显式处理，不要隐式略过。
 
 ## 质量门禁
 
 - 生成代码必须可编译。
 - 命名、包路径、注解要与工程现有规范一致。
+- Convertor 必须有 MapStruct 接口 / 抽象类、生成实现可编译，必要时补 mapper 单测或覆盖核心字段转换的行为测试。
+- POJO 使用 Lombok 时不得引入 `@Data` 造成实体 equals / toString 风险；有关系字段、敏感字段或懒加载字段时按 `lombok` skill 排除。
 - 遇到无法自动判断的字段或规则时，写 TODO 或向用户说明，不要假装已确认。
 
 ## 协同顺序
 
 - metadata 提取：`yss-db2mybatis`
 - 领域建模：`yss-domain`
+- POJO 样板代码：`lombok`
+- 对象转换：`mapstruct`
 - Web 补齐：`yss-web-controller`

package/template/.codex/skills/yss-router/SKILL.md

@@ -19,7 +19,7 @@ When the request is already narrowly scoped, use the matching specialist directl
 
 ## Lifecycle Boundaries
 
-- If the task introduces or changes a frontend/backend API contract, route back to `yss-product-lifecycle` until PRD, OpenAPI Draft, engineering baseline/design review, and OpenAPI Freeze are clear.
+- If the task introduces or changes a frontend/backend API contract, route back to `yss-product-lifecycle` until Spec, OpenAPI Draft, engineering baseline/design review, and OpenAPI Freeze are clear.
 - `api-integration` consumes generated clients and wires page behavior; it must not invent missing API paths, DTOs, or response shapes.
 - `yss-openapi` is for generating or refreshing contracts/Orval clients after OpenAPI Freeze, or for regenerating from an already implemented backend source of truth.
 
@@ -61,7 +61,6 @@ When the request is already narrowly scoped, use the matching specialist directl
 | Work with current user info propagation or user info starter | `yss-userinfo` |
 | Work with variable component APIs | `yss-variable` |
 | Work with quality starter behavior | `yss-quality` |
-| Work with DolphinScheduler anti-corrosion/anti-scheduler integration | `yss-anti-scheduler` |
 | Work with exception component or unified exception handling | `yss-exception` |
 | Work with mail starter or email sending | `yss-mail` |
 | Work with file runner component | `yss-filerunner` |
@@ -98,7 +97,7 @@ Backend component skills have generated source indexes under `references/source-
 中文说明：当问题涉及真实类名、配置项、注解、拦截器、自动配置或排障时，先读对应 `source-index.md`，它会指向后端组件源码库里的真实入口。
 
 - Core framework/component examples: `yss-cache`, `yss-mybatis`, `yss-dto`, `yss-audit-log`, `yss-excel-mvc`, `yss-distributed-id`, `yss-jdbc`.
-- Extended component examples: `yss-dictionary`, `yss-dir`, `yss-file`, `yss-log`, `yss-liquibase`, `yss-resilience4j`, `yss-sql-condition`, `yss-sql-tpl`, `yss-taskflow`, `yss-validation`, `yss-security-algorithm`, `yss-userinfo`, `yss-variable`, `yss-quality`, `yss-anti-scheduler`, `yss-exception`, `yss-mail`, `yss-filerunner`, `yss-valuation`, `yss-duckdb`, `yss-mapper-dynamic`.
+- Extended component examples: `yss-dictionary`, `yss-dir`, `yss-file`, `yss-log`, `yss-liquibase`, `yss-resilience4j`, `yss-sql-condition`, `yss-sql-tpl`, `yss-taskflow`, `yss-validation`, `yss-security-algorithm`, `yss-userinfo`, `yss-variable`, `yss-quality`, `yss-exception`, `yss-mail`, `yss-filerunner`, `yss-valuation`, `yss-duckdb`, `yss-mapper-dynamic`.
 
 Regenerate these indexes with `yss-source-index/scripts/refresh-yss-skill-index.py` after `yss-cloud-microservice` changes. Read `yss-source-index/references/source-map-config.md` when you need the full skill-to-source mapping.
 

package/template/.codex/skills/yss-router/references/boundaries.md

@@ -54,7 +54,6 @@ Default for backend CRUD: use `yss-domain`, `yss-dto`, `yss-repository`, and `ys
 - `yss-userinfo`: Current-user info propagation and starter integration.
 - `yss-variable`: Variable component APIs and variable resolution.
 - `yss-quality`: Quality starter behavior.
-- `yss-anti-scheduler`: DolphinScheduler anti-corrosion/anti-scheduler integration.
 - `yss-exception`: Exception component and unified exception handling.
 - `yss-mail`: Mail starter and email sending.
 - `yss-filerunner`: File runner component behavior.

package/template/.codex/skills/yss-source-index/references/source-map-config.md

@@ -27,7 +27,6 @@ The refresh script maps component source path hints to skill references. These p
 | `yss-userinfo` | `yss-microservice-components/yss-component-userinfo-starter` |
 | `yss-variable` | `yss-microservice-components/yss-component-variable` |
 | `yss-quality` | `yss-microservice-components/yss-component-quality-starter` |
-| `yss-anti-scheduler` | `yss-microservice-components/yss-component-anti-corrosion/yss-component-anti-scheduler` |
 | `yss-exception` | `yss-microservice-components/yss-component-exception` |
 | `yss-mail` | `yss-microservice-components/yss-component-mail-starter` |
 | `yss-filerunner` | `yss-microservice-components/yss-component-filerunner-parent` |

package/template/.codex/skills/yss-source-index/scripts/refresh-yss-skill-index.py

@@ -76,9 +76,6 @@ BACKEND_SKILLS = {
     "yss-quality": [
         "yss-microservice-components/yss-component-quality-starter",
     ],
-    "yss-anti-scheduler": [
-        "yss-microservice-components/yss-component-anti-corrosion/yss-component-anti-scheduler",
-    ],
     "yss-exception": [
         "yss-microservice-components/yss-component-exception",
     ],

package/template/.codex/skills/yss-web-controller/SKILL.md

@@ -21,9 +21,11 @@ description: 用于根据 YSS 规范生成或重构 Web Adapter Controller 层
 ## 优先流程
 
 1. 先确认 metadata、基础包、模块名、领域 segment、domain/web 落盘目录。
-2. 运行 `scripts/generate_controller.py`。
-3. 生成后检查路径、命名、返回值包装和 Gateway 引用是否对齐项目。
-4. 对复杂接口做少量手工修正，不在 skill 中承诺自动覆盖全部业务逻辑。
+2. 涉及 DTO / VO / CMD / Query POJO 样板代码时，加载并遵守 `lombok`。
+3. 涉及 Domain / Application Result 到 VO / DTO 或 CMD / Query 到输入模型的转换时，加载并遵守 `mapstruct`。
+4. 运行 `scripts/generate_controller.py`。
+5. 生成后检查路径、命名、返回值包装、Gateway 引用、Lombok 注解和 MapStruct WebConvertor 是否对齐项目。
+6. 对复杂接口做少量手工修正，不在 skill 中承诺自动覆盖全部业务逻辑。
 
 ## 推荐命令
 
@@ -51,6 +53,8 @@ python3 scripts/generate_controller.py \
 
 - 生成代码默认依赖既有 Domain Gateway，不直接穿透 Repository。
 - 返回结构保持项目既有 `SingleResult`、`PageResult`、`MultiResult` 体系。
+- DTO / VO / CMD / Query 默认用 Lombok 处理 getter/setter、constructor、builder 和日志样板；不要在 Controller 内部类或非约定包临时定义主要 DTO / VO。
+- `WebConvertor` 默认使用 MapStruct；禁止在 Controller / Application 中大段手写字段赋值、使用 `BeanUtils.copyProperties` 或反射式通用拷贝，除非有受控例外和测试证据。
 - 先跑脚本，再按项目规范做少量手调。
 - 若用户只是要改单个 Controller，先看现有代码，不要盲覆盖整个目录。
 
@@ -59,3 +63,5 @@ python3 scripts/generate_controller.py \
 - 生成脚本：`scripts/generate_controller.py`
 - Controller 模板：`assets/templates/Controller.java.template`
 - Convertor 模板：`assets/templates/WebConvertor.java.template`
+- POJO 样板代码：`lombok`
+- 对象转换：`mapstruct`