MCP Attribution Worktree

Operating rules

• Only update attribution issues through the local report API.
• Treat owner as fixed: always set it to codex when you patch an attribution.
• Before any new iteration, always inspect the latest attribution notes, externalUrl, linked GitHub issue or PR status, and any available PR comments or review decisions.
• Before moving any issue to resolved, always perform a fresh closure sweep on the linked issue or PR after the latest push or evaluation has completed. Do not rely on an earlier preflight.
• Do not change resolutionStatus until you have read at least one related run's result and trace.
• Do not mark an issue resolved without clear closure evidence such as an existing GitHub issue, PR, merged fix, or a verified duplicate that already has external tracking.
• Do not mark an issue resolved if there are unread or unaddressed PR comments, review comments, review decisions, or issue comments that arrived after the last time you inspected the linked artifact.
• Keep notes short but auditable. Include the representative run, the main failing signal, and the code or tool signal that supports the conclusion.
• If the evidence is incomplete, keep the issue todo or move it to in_progress and explicitly state what is still missing.
• For a real and repairable issue in mcp/src or config/source/skills, the default expectation is full follow-through: attribution triage, GitHub issue linkage, isolated worktree repair, validation, and PR creation.
• When the likely root cause is model misunderstanding rather than backend behavior, first try to repair the model-facing contract: clearer tool descriptions, safer parameter wording, skill guidance, canonical examples, and explicit warning about dangerous defaults.
• When the fix belongs to CloudBase skill content, edit config/source/skills/ as the source of truth. Do not treat the root skills/ directory as the source for those external skills.
• Only stop at status-only attribution updates when the issue is non-actionable, blocked by missing evidence, blocked by missing Worktrunk, or clearly outside MCP repo control.
• Do not use broad uncategorized backlog queries as the default source of work. Only use them in explicit fallback mode when category labels are incomplete or the user asks for a full backlog sweep.
• Items discovered through fallback broad queries must not enter the repair queue until run evidence clearly shows they belong to mcp/src or config/source/skills.
• Prefer one sub-agent per issue when sub-agent support exists. Give each sub-agent ownership of exactly one issue. If sub-agents are unavailable, process issues serially and keep a strict one-issue-at-a-time context.
• If a repair is needed, use Worktrunk's wt workflow for the isolated worktree. If wt is unavailable, stop and report that Worktrunk is missing instead of silently falling back to a shared checkout.
• Never reuse the same worktree for multiple attribution issues.
• Do not open or update GitHub issues until you have enough run evidence to explain the problem clearly.
• If an issue already has a GitHub issue or PR, read its current state before starting a new branch or changing direction: open or closed status, latest comments, review decisions, and whether the linked work is already stale or superseded.
• Review comments and post-PR evaluation failures are part of the same repair loop. Use them to drive another iteration instead of prematurely closing the attribution.
• If a real evaluation interface is available, prefer leaving the attribution in_progress until the repaired branch or PR passes a fresh evaluation round.
• Do not claim validation success from reasoning alone. Use the evaluation API and the final run result whenever that interface is available.

Required preflight

Before starting a fresh diagnosis or code iteration for an attribution issue, complete this checklist in order:

1. Read the attribution detail plus the latest notes.
2. Read externalUrl if present.
3. If externalUrl points to a GitHub issue, check whether it is open or closed and whether later comments changed the fix direction.
4. If externalUrl points to a PR, check whether it is open, merged, closed, or superseded.
5. Read PR comments, review comments, and review decisions before deciding whether to continue the same branch or start a new iteration.
6. Only after that, pick the representative run and continue into result, trace, and evaluation-trace.

Required closure preflight

Before changing an attribution to resolved, complete this checklist in order even if you already did the normal preflight earlier:

1. Reopen the linked GitHub issue or PR.
2. Re-read the latest top-level comments, review comments, and review decisions.
3. Confirm whether any comment arrived after the latest code push, PR update, or evaluation result.
4. If new feedback exists, keep the attribution in_progress and continue the loop.
5. Only if there is no newer unresolved feedback, evaluate whether closure evidence is now strong enough.

Quick commands

curl -s 'http://127.0.0.1:5174/api/attributions?category=tool&resolutionStatus=todo&limit=50'
curl -s 'http://127.0.0.1:5174/api/attributions?category=skill&resolutionStatus=todo&limit=50'
curl -s "http://127.0.0.1:5174/api/attributions/<issueId>"
curl -s "http://127.0.0.1:5174/api/runs/<caseId>/<runId>/result"
curl -s "http://127.0.0.1:5174/api/runs/<caseId>/<runId>/trace"
curl -s "http://127.0.0.1:5174/api/runs/<caseId>/<runId>/evaluation-trace"
wt switch --create feature/attribution-<slug>
gh issue create --repo TencentCloudBase/CloudBase-MCP
gh pr view <number> --comments --repo TencentCloudBase/CloudBase-MCP
gh pr create --repo TencentCloudBase/CloudBase-MCP
curl -s -X POST http://127.0.0.1:5174/api/evaluations

Minimum self-check

• Did I complete the existing-artifact preflight before starting a new diagnosis or code iteration?
• Did I inspect at least one related run's result and trace before changing status?
• Did I keep this issue isolated from every other issue?
• Is the issue actually actionable in mcp/src, config/source/skills, or is it environment / grader noise?
• If the issue was actionable, did I continue into GitHub issue / worktree / PR work instead of stopping at triage?
• If there was already a PR or review thread, did I continue from that feedback instead of ignoring it?
• If a real evaluation interface was available, did I run a fresh evaluation before treating the issue as closed?
• Did I base the validation conclusion on the final evaluation result instead of my own guess?
• If I patched the attribution, did I keep the change limited to resolutionStatus, owner, notes, and externalUrl when relevant?
• If I started a fix, does it live in its own Worktrunk worktree and branch?
• If the issue was caused by model misunderstanding, did I reduce model-facing complexity by mapping repo-specific behavior to familiar concepts and by explicitly naming dangerous defaults?
• If I marked something resolved, is there explicit closure evidence?
• If I marked something resolved, did I re-read the latest PR comments, review comments, review decisions, and issue comments immediately before closing it?