First read ../comet-github/references/maintainer-contract.md. Before modifying source code or reinstalling, complete the diagnosis first.
Determine the problem boundary
Classify the report as one or more of the following:
- Local installation is stale or incomplete;
- Project/global configuration or path ownership issue;
- Source/Runtime logic defect;
- Generated asset drift;
- Platform registration, installation, or uninstallation inconsistency;
- Documentation or lifecycle contract inconsistency.
Inspect the current source code, installed files, generated assets, platform metadata, lifecycle JSON/configuration, and related tests. When real execution is involved, static configuration inspection is not sufficient to reach a conclusion.
Execute the real path
- Using the project provided by the host
cwdand the actual platform identifier (if any), invoke the generated/packaged Router or Runtime. - When necessary, inspect the protected and allowed phases, as well as missing or ambiguous project context.
- For cross-platform work, check each affected adapter against the canonical platform registry; do not substitute a short handwritten platform list for the canonical registry.
- When suspecting source code, compare against the source entry point, generated bundle, Manifest, and installed copy.
- Distinguish project-level from global Hook ownership; when trusted host context is missing, remain neutral and do not scan the current process directory on your own.
Report diagnostic results
Return the observed command/path, expected contract, actual result, classification, evidence, and minimal next step. Clarify whether the issue is reproducible, configuration-only, generated-artifact-only, or a production defect.
Unless the user requests it, do not modify source code, generated assets, installation state, or GitHub Issues. When the user authorizes a fix, hand it off to comet-github-issue-fix, and rebuild the generated Runtime from source before verifying again.