First read ../comet-github/references/maintainer-contract.md. Treat the Issue or review as an input contract; do not treat it as authorization to modify GitHub or release code.
Confirm the work boundary
- Read the live Issue/PR and verify that the reported problem actually exists. Do not implement unconfirmed review bot speculation.
- Confirm the target branch, repository state, existing dirty files, and associated worktree.
- Protect the user's current checkout. When the target branch or workspace is dirty, use an isolated worktree/branch.
- Before editing, define the minimal behavior, files, tests, generated assets, documentation, and out-of-scope boundaries.
Implement through the owning Comet process
- Use the Native workflow for Native work and the Classic workflow for Classic work.
- When scope expands during implementation, first return to the owning Build/scope confirmation step, then add files or behavior.
- Manage Runtime state and generated assets through supported commands; do not manually edit machine state or treat generated bundles as source files.
- Use the minimal production change that satisfies the confirmed Issue; add a focused regression test when the defect is reproducible.
Verification and handoff
Run the minimal relevant tests first. When the change crosses the corresponding boundary, add build, generated asset, lint, or full checks. Report local results, unrelated failures, and remote CI separately.
Explicitly determine whether the final behavior is user-visible and whether a Changelog is needed. Do not write internal problems discovered during new feature development as Changelog entries.
Unless the user requests it, do not commit, push, comment, or create a PR. After authorization is obtained, hand off the exact file scope to comet-safe-delivery。