73 lines
3.3 KiB
Markdown
73 lines
3.3 KiB
Markdown
---
|
|
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.
|