mattmireles Deploy (kokoro-coreml)
Purpose
This repository is a PyTorch → Core ML conversion and model-artifact tree for
Kokoro TTS. It is not the Roast Cloudflare monorepo: there are no
pnpm deploy:* scripts or Workers/Pages pipelines here.
“Deploy” in this context means release engineering appropriate to this repo:
- Git: push branches, tags, or PRs (often via
git-push). - Artifacts:
.mlpackagebundles undercoreml/, checkpoints, and export scripts consumed by a separate macOS app (e.g. TalkToMe). - Verification: run
pytest(or targeted export smoke scripts) before declaring a revision ready for downstream integration.
Default interpretation
- “Ship it” / “deploy” → confirm what the user means: push to GitHub, cut a tag, or hand models to the app—not a cloud deploy unless they name another system.
Pre-ship gate (recommended)
From the repository root, when a change touches Python export, Core ML, or tests:
pytest(full test pass when tests are present).- If the change is export-only, at minimum run the relevant
examples/ortest_*.pyscripts the guides mention.
There is no single CI workflow in .github/workflows/ for this repo yet; treat
local green tests as the main gate before pushing risky changes.
Procedure (agent)
- Read
README.md,CLAUDE.md(agent operating rules),README/Wiki/plus relevantREADME/Guides/(PyTorch → Core ML playbooks), and the relevantREADME/*.mdguide for the subsystem (conversion, runtime, export). - Do not run Cloudflare/Roast deploy commands—they do not apply.
- Run Pre-ship gate before advising “ready to ship.”
- For git remote operations, follow
git-pushwhen the user wants push- CI (if added later).
Anti-patterns
- Copying Roast
pnpm deploy:staging/ Workers steps into this repo. - Pushing large binary or regenerated
.mlpackagechanges without noting what was regenerated and how to verify.
Related skills
git-push: commit, merge, push, chase CI when CI exists.git-commit: post-commitpytestawareness (non-blocking heads-up).audit: full review when the user saysaudit.