| name | fantasia-final-cleanup |
| description | End-of-batch ship workflow for Fantasia Archive: run yarn testbatch:verify and fix failures, sync README/AGENTS/rules/skills from Git changes, update in-app changelog, split conventional commits, and git push. Use when the user says final cleanup, doing final cleanup, run final cleanup, wrap up and ship, or similar end-of-session handoff language. |
Final cleanup — ship the current batch
Execute these steps in this exact order. Do not skip, merge, or reorder unless the user interrupts with a narrower instruction.
Final cleanup is an explicit handoff: you may commit and push without asking for per-commit approval (unlike the default in git-conventional-commits). Still use conventional type: subject messages and logical splits.
Step 1 — Verify quality gate
In one terminal:
yarn testbatch:verify
- Stop on the first failure; report what failed and where.
- While debugging, run individual steps from testing-terminal-isolation.mdc only for the failing slice, then re-run the full
yarn testbatch:verify chain.
- Do not append Playwright, Electron production build, or Storybook to this chain unless the user separately asked for
yarn testbatch:ensure:nochange or yarn testbatch:ensure:change.
Step 2 — Fix issues
- If step 1 failed: fix root causes, re-run
yarn testbatch:verify until it passes.
- If step 1 passed: continue to step 3.
- Do not edit changelog or commit until the verify gate is green (except rare changelog-only repair after a prior green verify — see testing-terminal-isolation.mdc).
Step 3 — Sync maintainer docs from Git
Inspect the working tree and recent diff (git status, git diff, git diff --staged):
| Area | When to update |
|---|
README.md | New scripts, test commands, architecture, or contributor workflows touched by the batch |
AGENTS.md | New subsystems, rules, skills, testing expectations, or repo layout changes |
.cursor/rules/*.mdc | New enforced policies or corrections to existing rule text |
.cursor/skills/**/SKILL.md | New playbooks or materially changed workflows |
- Match existing tone and structure; avoid drive-by rewrites unrelated to the diff.
- Omit doc edits when the batch is trivial and already covered elsewhere.
docs: commits may group README + AGENTS + rules + skills when they describe the same batch.
Step 4 — Changelog
Before any product commit:
- Re-read package.json for the live
version (never auto-bump).
- Follow fantasia-changelog-en-us and changelog-en-us.mdc.
- For user-visible
src/components/** changes, confirm Storybook stories/mocks are aligned (storybook-stories.mdc) before changelog text.
- Prefer same commit as substantive work; user-facing bullets only — no QA gate noise, no Git meta.
Mirror i18n/*/documents/changeLog.md under other locales when you maintain them.
Step 5 — Commit in logical batches
git status and full diff review.
- Propose an ordered commit plan (type, subject, paths per commit). Briefly show the plan to the user, then execute unless they object.
- Split by concern:
feat / fix / test / chore / refactor / docs per git-conventional-commits.
- Typical order when multiple apply:
chore / refactor (tooling, harness) before feat / fix
- product + tests + changelog together when one feature
docs: for README/AGENTS/rules/skills-only deltas
- Storybook VRT snapshot PNGs with the UI change they belong to
- Never commit secrets; never use
--no-verify unless the user explicitly requests it.
- After each commit,
git status until the tree is clean (or only intentionally untracked files remain).
Step 6 — Push
When all commits are done and the tree is clean:
git push
Use -u origin <branch> when the branch has no upstream. If push fails (auth, non-fast-forward), report the error and stop — do not force-push main / master unless the user explicitly asks.
Reporting
Summarize in execution order:
- Verify gate (pass/fail)
- Fixes applied (if any)
- Docs/changelog files touched
- Each commit (
type: subject + short scope)
- Push result (remote, branch)
Related
TypeScript interfaces and types (types/)
- Put shared
interface / type declarations in repository-root types/ (import with app/types/...). Prefer one domain-oriented module per feature area with brief JSDoc on exports (see types/I_appMenusDataList.ts). Do not add colocated <filename>.types.ts under src/, src-electron/, or .storybook-workspace/. Ambient augmentations for third-party modules also live under types/ and are loaded with a side-effect import from the owning boot file or src/stores/index.ts (see types/piniaModuleAugmentation.ts).
- For JavaScript (
.js), TypeScript (.ts), Vue (.vue), and JSON (.json, .jsonc, .json5) files, enforce expanded multi-line object literals via ESLint (object-curly-newline + object-property-newline) and keep files auto-fixable with eslint --fix.