coordinate-project-work

name	coordinate-project-work
description	Use when service rules, contracts, DBML, dbdiagram, external UI, ownership, repositories, submodules, or integration order cross implementation boundaries.

Coordinate Project Work

Coordinate shared meaning before parallel implementation. Run stackcord status --json, re-read the selected task provider, and choose only the relevant path below.

• Service and technical contracts: Treat purpose, guarantees, non-goals, business rules, authorization, failure, retry, idempotency, compensation, support, API behavior, events, and data obligations as contracts. Keep human-readable policy meaning separate from machine-readable interfaces, but bind both to stable IDs. Run stackcord contract impact --json and stackcord contract check; prefer additive or side-by-side compatibility.
• Product authority: Before changing service purpose, policy, business rules, contracts, or governance, run stackcord governance check --json. A contributor outside the configured product authorities may prepare the proposal, tests, implementation, issue, and PR, but may not present it as approved. Use only the selected Git review provider's normalized live account and exact commit evidence; Git display name and email, assignment, comments, and cached review state never authorize the change. Request reviewer or merge actions only when the user selected that provider and asked for the external write.
• Semantic conflict: Run stackcord work conflict --json even when files differ. Check policy, scenario, contract, DB entity, migration, UI flow, dependency, workspace, and root-pointer meaning. Resolve shared contracts first; then assign path and semantic ownership plus merge order.
• Database: Keep Git DBML canonical. Use stackcord db diagram --json to create an isolated dbdiagram proposal and stackcord db diff for semantic entity, column, relation, index, and note changes. Treat direct dbdiagram edits as proposals, explain the difference, and ask why meaning changed before canonical apply. Require contract, migration, rollback, and test references for canonical changes.
• External and editable UI: Use stackcord ui import --json for an internal safety check of archives, provenance, license, secrets, executables, and paths. Do not make the user manage quarantine. Decide reference, seed, or canonical from actual authority. For material the team will edit, review stackcord ui promote --json with whole or exact selected paths; accepted files become ordinary editable files in the declared UI workspace. Preserve existing UI rather than overwriting it. Complete missing loading, empty, error, permission, destructive, responsive, and accessibility states. Optional UI creation tools, including MengTo/Skills-like packages, may produce inputs but never become canonical. Commit and publish the UI workspace normally, then run stackcord ui baseline bind to record the exact commit, source fingerprints, flows, and consumers. Frontend work must reference that exact baseline before TDD implementation. Keep stackcord ui integrate only for the earlier source-acknowledgement compatibility path.
• External lifecycle and ownership: Verify local evidence before asking the selected connector to change status or owner. After the external write, re-read the exact item and run stackcord work provider reconcile --apply. Then use stackcord work transition --apply or stackcord work handoff --apply to synchronize the Git semantic reservation. A provider assignment is advisory until the Git compare-and-swap reservation agrees. Do not silently stash, commit, push, or discard.
• Integration: Use stackcord integrate plan --json, review the exact order, apply, then run stackcord integrate verify. The plan binds both the selected-provider revision and Git semantic-reservation revision. Integrate compatible contracts, provider workspaces, consumer workspaces, UI, migrations, and finally the reviewed root submodule pointer. Never move a pointer merely because a child branch finished.

Require TDD and integration evidence for behavior, bugs, contracts, migrations, and UI interactions. Explain user impact and required coordination in ordinary language. Say “작업 선점” or “work reservation,” never claim. Translate internal clear, coordinate, block, and unknown outcomes into the concrete user action; keep internal IDs and storage paths hidden unless troubleshooting needs them.

Read workflow, safety, context recovery, and tool selection. Rerun combined status after each canonical integration boundary.