- Read
docs/task-definition.mdbefore editing code. - Treat
docs/spec.mdanddocs/appendix.mdas normative requirements, not suggestions. - The first public release is the feature set formerly discussed as
v1.1; ship tag remainsv1.0.0. - This repository is a single package implementation target. Do not convert it into a monorepo.
- Prefer
pnpmfor all package operations. - Keep the implementation ESM-only TypeScript on Node.js 22+.
- Do not add production dependencies unless required by the specs or documented in
docs/architecture-decisions.md.
- Before making broad architectural changes, re-read
docs/architecture-decisions.md. - After each meaningful change, run
bash scripts/verify.sh. - Do not mark any requirement complete unless verification evidence exists in tests, fixtures, or a documented manual validation note.
- When a behavior changes, update docs, fixtures, and snapshots in the same change.
- Prefer small validated diffs over speculative large rewrites.
- failing verification script outputs
- missing required public surface from the specs
- fixture coverage gaps
- docs drift
- convenience improvements
- Never expose raw low-level
xctracepassthrough tools in the public MCP surface unless the specs explicitly require them. - Never implement signpost rewriting with regex. Use the SwiftSyntax helper path described in
docs/appendix.md. - Never claim metric precision that is unsupported by the exported evidence.
- Keep outputs bounded by default.
- Preserve privacy-first local behavior.
- Do not turn sparse or low-signal traces into broad performance narratives.
- Lead with the strongest defensible conclusion, not a tour of every instrument result.
- Separate app-owned evidence from SDK, wrapper, analytics, and framework noise.
- If the trace is weak, say so explicitly:
no actionable app bottleneck isolatedis better than generic advice. - Prefer one concrete suspect path, symbol, or subsystem over a long generic hotspot list.
- State confidence and limits in plain language when the capture window is too quiet, too broad, or dominated by vendor code.
- End with the next targeted recording step needed to answer the unresolved human question.
- When summarizing for humans, answer these four questions directly:
- What is the most likely real issue?
- How confident is that conclusion?
- What specific code or subsystem should be inspected next?
- What capture should be rerun if the evidence is still weak?
A task is only done when all of the following are true:
- relevant acceptance IDs are green in
docs/acceptance-matrix.json bash scripts/verify.shpassesbash scripts/release_readiness.shpasses for release-blocking work- public docs and examples match the implementation