---
name: miaobao-issue-acceptance-closeout
description: Complete a Miaobao issue or PR acceptance closeout when CI is green, a PR is ready to merge, or bookkeeping remains; includes local verification, Gitea/Drone truth, Feishu Base reconciliation, explicit confirmation, read-back, and cleanup.
---

# Miaobao Issue Acceptance Closeout

Use this when a Miaobao issue fix has reached PR/CI/merge-closeout state and the missing work is bookkeeping, verification, or cleanup.

Do not use this for initial debugging or feature implementation.

## Inputs / Context

1. Confirm the target issue, PR, worktree, and branch.
2. Check whether the task belongs to:
   - requirements pool table `tblvIEDIu5WDWbn9`
   - dev-task table `tblSbtRSb6L6EaPB`
3. Check the current truth surfaces:
   - local verification output
   - Gitea PR state
   - linked issue state
   - Drone build state
   - existing Feishu/Base record or absence of one
4. Verify whether `lark-cli` is callable; on this Mac it may live at `/Users/zfc/.npm-global/bin/lark-cli`.

## Procedure

1. Reconfirm the local result before touching bookkeeping.
   - Prefer exact focused tests plus the repo's normal gate: `typecheck`, `lint`, `format:check`, build/test as appropriate.
2. Reconfirm remote state.
   - Check latest PR head, Drone result, mergeability, and whether the linked issue is already closed.
3. Find the Feishu/Base row before writing anything.
   - Use `+record-search` by issue number, title, or PR number.
4. Prepare the record draft and show it to the user before writing.
   - Keep identifier columns simple:
   - `Gitea工单`: bare digits like `1631`
   - `PR` or `PR编号`: bare digits like `1731`
   - Put links, CI evidence, and notes in narrative fields such as `备注` or `验收标准`.
5. After explicit confirmation, write with `lark-cli`.
6. Read the record back and verify the exact written state.
7. Clean the local acceptance environment only after the record is verified.
   - Worktree removal
   - Local branch cleanup if appropriate
   - Port cleanup
   - Screenshot/temp artifact cleanup if they were acceptance-only

## Efficiency

1. Route by issue/PR number first; avoid broad repo scans.
2. Reuse one authoritative Base/table/view target instead of guessing from older links.
3. Prefer one final reconciliation pass:
   - local evidence
   - PR/issue state
   - Feishu record-search
   - cleanup
4. Stop once all of these agree; do not keep rechecking unrelated browser/UI state.

## Pitfalls

- If the PR is merged but the task still is not actually done, check Feishu/Base update and read-back before closeout.
- If Feishu fields look noisy or sort badly, keep ID fields as bare digits and move narrative evidence elsewhere.
- If browser login looks wrong, do not assume Feishu is inaccessible; test the actual `lark-cli` path and cached identity directly.
- If CI says `Build was killed` or a long test step fails without code evidence, inspect step-level Drone state before changing product code.

## Verification Checklist

- Local verification outputs exist and match the task scope.
- Latest Drone/build state is green or the exact non-code blocker is documented.
- PR state is correct and linked issue state is correct.
- Feishu/Base record exists or was created intentionally.
- Written record was read back and matches the intended status.
- Local acceptance worktree/env cleanup is complete.