@maestria/codex 0.4.0 → 0.4.2

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "maestria",
-  "version": "0.4.0",
+  "version": "0.4.2",
   "description": "Maestria methodology for Codex CLI: specialist workflow skills, orchestration, and review contracts",
   "author": {
     "name": "agustinusnathaniel"

package/CHANGELOG.md

@@ -1,5 +1,19 @@
 # @maestria/codex
 
+## 0.4.2
+
+### Patch Changes
+
+- [#275](https://github.com/agustinusnathaniel/maestria/pull/275) [`56351de`](https://github.com/agustinusnathaniel/maestria/commit/56351debf73a97c24eb10826517e0d9aabeaca6b) Thanks [@agustinusnathaniel](https://github.com/agustinusnathaniel)! - Refine specialist engineering judgment around trust-boundary normalization, feature-local seams, shared-interface compatibility, executable sources of truth, staged migrations, durable diagnostic knowledge, and operational documentation.
+
+## 0.4.1
+
+### Patch Changes
+
+- [#269](https://github.com/agustinusnathaniel/maestria/pull/269) [`ef07bf7`](https://github.com/agustinusnathaniel/maestria/commit/ef07bf78a8e5f676c76b55680301bc7c839b68a9) Thanks [@agustinusnathaniel](https://github.com/agustinusnathaniel)! - Add conditional visual-evidence guidance for PR delivery: confirm the project targets GitHub with authenticated gh --attach support and an available capture tool before attaching a screenshot or short video for visual or behavioral changes. Vision is optional verification only, not a precondition.
+
+- [#269](https://github.com/agustinusnathaniel/maestria/pull/269) [`ef07bf7`](https://github.com/agustinusnathaniel/maestria/commit/ef07bf78a8e5f676c76b55680301bc7c839b68a9) Thanks [@agustinusnathaniel](https://github.com/agustinusnathaniel)! - Add a global testing-judgment rule (test artifacts are opt-in, behavior over implementation shape, mocks only at external seams) and align reviewer and diagnose guidance with it.
+
 ## 0.4.0
 
 ### Minor Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@maestria/codex",
-  "version": "0.4.0",
+  "version": "0.4.2",
   "private": false,
   "description": "Maestria skills and native agent integration for Codex CLI",
   "keywords": [
@@ -40,7 +40,7 @@
   "devDependencies": {
     "@types/node": "^26.2.0",
     "typescript": "^7.0.2",
-    "vite-plus": "0.2.9",
+    "vite-plus": "0.3.0",
     "vitest": "4.1.11"
   },
   "engines": {

package/skills/adventurer/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: adventurer
 description: Codebase reconnaissance workflow for mapping unfamiliar code, tracing call chains, and reporting verified context without implementing changes.
+name: adventurer
 ---
 
 <!-- Auto-generated from @maestria/core. Do not edit directly.

package/skills/architect/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: architect
 description: Architecture decision workflow for comparing implementation approaches, boundaries, threat models, and ADR decisions.
+name: architect
 ---
 
 <!-- Auto-generated from @maestria/core. Do not edit directly.

package/skills/blitz/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: blitz
 description: Fast capability-aware Maestria route that skips optional ceremony without waiving safety or review.
+name: blitz
 ---
 
 <!-- Auto-generated from @maestria/core. Do not edit directly.

package/skills/builder/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: builder
 description: Focused implementation workflow for one atomic, verifiable feature, fix, test, or refactor.
+name: builder
 ---
 
 <!-- Auto-generated from @maestria/core. Do not edit directly.
@@ -31,6 +31,18 @@ If the task is not atomic - if it spans multiple unrelated concerns - document t
 
 Start with the smallest change that satisfies acceptance. Reuse existing code and dependencies first; before custom infrastructure, check framework capabilities and mature ecosystem solutions. Add a dependency only when its fit, maintenance, compatibility, security, and total burden beat a small local implementation. Add layers only when the product requires them.
 
+At trust boundaries, validate and normalize inputs once into a stable internal shape; client or convenience checks never replace authoritative security enforcement. Keep seams local to the feature by default; broaden them only when visible repetition, shared change pressure, or coupled data/contracts justify it, and only when callers become simpler.
+
+When changing a shared interface, trace every caller and supported usage mode; preserve or deliberately migrate them, then verify through the highest practical consumer. When several consumers must agree on one contract or convention, keep one executable source of truth or automated drift check, and record intentional exceptions instead of duplicating policy.
+
+Keep mechanical chores separate from behavior changes, and prefer many small reviewable increments over one large change.
+
+Prefer deny by default, keep secrets in the trusted runtime, and fail closed on missing or invalid configuration.
+
+When superseding code, mark the old path as do-not-extend, keep it until migration completes, then remove it in an isolated change.
+
+Never hand-edit generated outputs; change the single source and regenerate.
+
 ## Skills
 
 Load on trigger: `agent-browser` (UI verification), `tdd` (explicit TDD requests), `pnpm` (package/lockfile changes), `mcp-builder` (MCP servers), `webapp-testing` (browser-level testing), `frontend-design` (UI build tasks), `commit-work` (staging and commit messages). Skip skill loads for mechanical one-line fixes.

package/skills/diagnose/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: diagnose
 description: Systematic regression-tracing workflow from symptom and error evidence to root cause, fix, and prevention.
+name: diagnose
 ---
 
 <!-- Auto-generated from @maestria/core. Do not edit directly.
@@ -63,9 +63,9 @@ Fix the root cause with minimal changes:
 
 Prevent similar bugs:
 
-- Add/update regression tests
+- Consider regression tests where a durable contract or plausible recurrence justifies them (per Global Rules testing judgment)
 - Consider linting rules to catch the pattern
-- Document the lesson in a knowledge artifact for future reference
+- **!!! Preserve durable diagnostic lessons** - update an existing knowledge artifact when one fits; create one only when the findings have durable future value or the user/project requires a record.
 
 ## Step 6: Verify Fix
 
@@ -78,7 +78,6 @@ Confirm it works:
 
 ## Rules
 
-- **!!! Document diagnostic work as persistent knowledge artifacts** - save what you investigated, ruled out, root cause, and fix via `$maestria:writer` or markdown file.
 - **!!! Edit and system-change permissions follow the host policy** - explain the rationale before any change and use the platform's approval controls.
 - **!!! Exhaust environment data** (lockfile, env vars, version mismatch, CWD) before asking; document assumptions with supporting evidence and proceed.
 - **Parallelization:** different bugs in parallel; same bug = consolidate.

package/skills/fein/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: fein
 description: "Full Maestria pipeline: reconnaissance, design, implementation, and independent review."
+name: fein
 ---
 
 <!-- Auto-generated from @maestria/core. Do not edit directly.

package/skills/global-rules/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: global-rules
 description: Universal Maestria rules for evidence, safety, authorization, delegation, review, bounded repair, and branch discipline.
+name: global-rules
 ---
 
 <!-- Auto-generated from @maestria/core. Do not edit directly.
@@ -18,6 +18,7 @@ Cross-platform behavior contract for outcomes, evidence, safety, delegation, rev
 - **!!! Match effort to stakes.** Use the smallest route, investigation, test set, and review depth that establishes acceptance; escalate only when uncertainty, impact, or complexity warrants it.
 - **!!! Prefer reuse over reinvention.** Check existing project code, dependencies, framework capabilities, and mature ecosystem solutions before custom infrastructure; weigh fit, maintenance, compatibility, security, and total cost when material.
 - **!!! Exhaust available evidence before asking.** Make material assumptions explicit, tag uncertain ones `[inferred]`, and proceed on ordinary ambiguity. Ship affected documentation and changesets with code when project policy requires them.
+- **!!! Exercise testing judgment, not coverage.** New test files, fixtures, mocks, and test-only helpers are opt-in, never automatic: reuse existing suites first and prefer the cheapest verification that establishes acceptance (typecheck, lint, runtime or browser checks). Add tests only for durable contracts and plausible regressions; assert observable behavior, not implementation shape; mock only genuinely external seams (network, clock, randomness).
 - **!!! Keep output self-contained and professional.** Understand existing systems before adapting or deleting them, and never claim isolation, enforcement, or lifecycle control the runtime does not provide.
 - **!!! Human-facing output.** In all agent-authored text (responses, status updates, briefs, comments/docstrings, commit messages, PR titles/descriptions, and documentation), never emit Unicode U+2014 EM DASH. Prefer commas, colons, parentheses, or ASCII hyphen-minus (`-`). Preserve code syntax, intentional literals, quoted source text, and user-provided text. Scan authored output before handoff or delivery.
 
@@ -49,7 +50,7 @@ Default to one independent review and, only when blockers exist, one repair/re-r
 
 Safety and authorization override user intent, methodology, and brevity. Security, authentication, and permission boundaries are mandatory stops. Stop and obtain applicable authorization before changes that alter them, involve data migration or possible loss, impact production, are irreversible, create external side effects outside delegated scope, or involve consequential ambiguity after evidence is exhausted. Ordinary in-scope security defects may be repaired autonomously.
 
-The orchestrator owns continuation for implementation and delivery work until the outcome reaches its terminal artifact; incomplete todos, pending handoffs, or specialist messages saying "continue if needed" are not a user checkpoint. Routine delivery is autonomous. For implementation work, continue through validation, review, and delivery: when repository, branch, remote, ownership, and host capabilities support it, create or use a non-protected feature branch and continue through commit, push, and PR without asking whether to perform those steps - these are delivery mechanics, not approval checkpoints. Where supported, create a reviewable PR without ceremonial approval rather than stopping at a verified working tree; a delegated implementation outcome is complete only at its delivered state - reviewed changes on a pushed feature branch with an open PR. Never commit or push protected branches; inspect status, stage only intended files, and use logical conventional commits. Merge, release, and production operations remain separate authorization boundaries. Track task-owned background processes and stop and verify them before completion unless intentionally part of the requested result; never broadly kill unrelated or user-owned processes outside platform lifecycle controls. An explicitly authorized checkpoint may preserve unreviewed work but never authorizes shipping.
+The orchestrator owns continuation for implementation and delivery work until the outcome reaches its terminal artifact; incomplete todos, pending handoffs, or specialist messages saying "continue if needed" are not a user checkpoint. Routine delivery is autonomous. For implementation work, continue through validation, review, and delivery: when repository, branch, remote, ownership, and host capabilities support it, create or use a non-protected feature branch and continue through commit, push, and PR without asking whether to perform those steps - these are delivery mechanics, not approval checkpoints. Where supported, create a reviewable PR without ceremonial approval rather than stopping at a verified working tree; a delegated implementation outcome is complete only at its delivered state - reviewed changes on a pushed feature branch with an open PR. Never commit or push protected branches; inspect status, stage only intended files, and use logical conventional commits. Before attaching visual PR evidence, confirm both preconditions: the project targets GitHub (GitHub remote with authenticated gh that supports media attachments, for example gh v2.99.0+ repeatable --attach on pr create, edit, and comment) and a capture tool is available (screenshot, screen-capture, or browser tool). When both hold and the change is visual or behavioral, capture a screenshot or short video at reasonable cost and attach it, preferring referenced paths with alt text (for example, --attach './after.png#Short alt text') within host size limits; skip when either check fails, when no display is available, or when review value is low. Vision is not required: when present, use it to verify the capture shows the intended state, otherwise describe the capture from the action taken and leave visual verification to the reviewer. Merge, release, and production operations remain separate authorization boundaries. Track task-owned background processes and stop and verify them before completion unless intentionally part of the requested result; never broadly kill unrelated or user-owned processes outside platform lifecycle controls. An explicitly authorized checkpoint may preserve unreviewed work but never authorizes shipping.
 
 ## Canonical Source Invariant
 

package/skills/handoff/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: handoff
 description: Concise handoff contract for passing outcome, constraints, evidence, blockers, and next steps between workflow stages.
+name: handoff
 ---
 
 <!-- Auto-generated from @maestria/core. Do not edit directly.

package/skills/iteration-limits/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: iteration-limits
 description: Verifiable termination and bounded repair guidance for loops, reviews, and repeated implementation attempts.
+name: iteration-limits
 ---
 
 <!-- Auto-generated from @maestria/core. Do not edit directly.

package/skills/orchestrator/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: orchestrator
 description: "Maestria workflow dispatcher for Codex CLI: route work, use specialist skills, preserve handoffs, and keep independent review explicit."
+name: orchestrator
 ---
 
 <!-- Auto-generated from @maestria/core. Do not edit directly.
@@ -72,7 +72,7 @@ Modes are case-insensitive and per-turn.
 
 For implementation work, own the delivery path: inspect -> plan -> implement -> validate -> one independent review -> repair material blockers only when required -> targeted validation of repaired scope -> final verification -> commit -> push -> PR.
 
-**Routine delivery is autonomous.** When repository, branch, remote, ownership, and host capabilities support PR delivery, do not ask whether to create or use a feature branch, commit, push, or create a PR; complete the lifecycle without ceremonial approval. A delegated implementation outcome reaches its terminal artifact only when delivered: reviewed changes on a pushed feature branch with an open PR. Do not stop at a local diff, commit, pushed branch, or `PR pending`, and never treat "not requested" as a reason to withhold routine delivery. Merge, release, and production actions remain separate authorization boundaries.
+**Routine delivery is autonomous.** When repository, branch, remote, ownership, and host capabilities support PR delivery, do not ask whether to create or use a feature branch, commit, push, or create a PR; complete the lifecycle without ceremonial approval. A delegated implementation outcome reaches its terminal artifact only when delivered: reviewed changes on a pushed feature branch with an open PR. Do not stop at a local diff, commit, pushed branch, or `PR pending`, and never treat "not requested" as a reason to withhold routine delivery. When the change is visual or behavioral, attach a screenshot or short video only after confirming both preconditions: the project targets GitHub (GitHub remote with authenticated gh that supports --attach) and a capture tool is available (screenshot, screen-capture, or browser tool); skip when either check fails, when no display is available, or when cost outweighs review value. Vision is not required: use it to verify the capture when present, otherwise describe the capture from the action taken. Merge, release, and production actions remain separate authorization boundaries.
 
 The parent session owns continuation until the selected implementation outcome reaches its terminal artifact. Incomplete todos or specialist handoffs are not user checkpoints: take or delegate the next bounded action. A failed or cancelled delegation is transport trouble, not a verdict - retry once with an adjusted brief before reporting a structured blocker; user-initiated or intentional platform cancellation is terminal. Research-only, planning-only, explicitly read-only, `sonar`, and host-blocked routes terminate at their requested artifact or exact blocker. Safety, authorization, ambiguity, and host-capability boundaries always take precedence.
 

package/skills/planner/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: planner
 description: Phased implementation planning workflow with dependencies, verification criteria, timelines, and rollback points.
+name: planner
 ---
 
 <!-- Auto-generated from @maestria/core. Do not edit directly.
@@ -22,6 +22,8 @@ You create implementation plans.
 4. **Verification** - Criteria to confirm phase completion
 5. **Rollback Points** - Safe stopping points between phases
 
+Deliver each increment as a runnable slice including its wiring, not as a single layer.
+
 ## Rules
 
 Planning briefs state the outcome, phases, dependencies, acceptance evidence, assumptions, rollback points, and next step.
@@ -31,7 +33,9 @@ Planning briefs state the outcome, phases, dependencies, acceptance evidence, as
 - **!!! Verifiable completion criteria** - success criteria and rollback points are mandatory for every phase.
 - **!!! No open questions in plans** - convert every open question into an assumption with supporting evidence.
 
-**Guard rails:** follow existing conventions; don't change architecture unasked, don't add dependencies without approval, don't refactor while adding features, don't skip verification.
+**Guard rails:** follow existing conventions; don't change architecture unasked; don't add dependencies without approval; don't bundle unrelated cleanup. When a feature needs an enabling refactor, plan it as an explicit, separately verifiable phase with its own acceptance evidence and rollback point. Don't skip verification.
+
+For migrations spanning many call sites or modules, name the current and target states, prove the target on a representative slice, and migrate in separately verifiable batches. Every compatibility shim needs a removal condition or an explicit reason to retain it.
 
 ## Handoff
 

package/skills/reviewer/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: reviewer
 description: Independent code review workflow covering correctness, security, performance, maintainability, and quality gates.
+name: reviewer
 ---
 
 <!-- Auto-generated from @maestria/core. Do not edit directly.
@@ -63,9 +63,9 @@ The initial general reviewer must give a verdict for every category. A specializ
 
 ### 7. Test Coverage
 
-- Are tests present for new functionality?
-- Do tests cover edge cases and error paths?
-- Are tests meaningful (not just checking implementation details)?
+- Is meaningful regression risk covered proportionate to stakes (per Global Rules testing judgment)?
+- Do tests cover edge cases and error paths where the contract demands it?
+- Are tests meaningful (observable behavior, not implementation details)?
 
 ### 8. Assumption Validation
 

package/skills/sonar/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: sonar
 description: Research-only Maestria route using read-only specialist skills, then stop before implementation.
+name: sonar
 ---
 
 <!-- Auto-generated from @maestria/core. Do not edit directly.

package/skills/writer/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: writer
 description: Structured documentation workflow for READMEs, API docs, architecture documents, changelogs, and decision records.
+name: writer
 ---
 
 <!-- Auto-generated from @maestria/core. Do not edit directly.
@@ -26,6 +26,7 @@ You write documentation.
 - Follow the project's existing doc style
 - One concept per section
 - Document guard rails and constraints explicitly
+- Verify factual claims against current code/config; for operator-critical instructions, link to the authoritative source and include a runnable check with the expected success or failure signal
 - Don't invent isolation, lifecycle, or enforcement guarantees the adapter does not provide.
 
 ## Format
@@ -59,8 +60,8 @@ You write documentation.
 
 ## Check
 
-- **Termination condition:** links checked, examples runnable, tone matches docs, proofread once.
-- **!!! Mandatory Proofread** - verify links, examples runnable, tone matches style.
+- **Termination condition:** factual claims match current code/config; links work; examples and operator checks run with the expected signals; tone matches surrounding docs.
+- **!!! Mandatory Proofread** - verify the termination condition once before handoff.
 - **!!! Scope Ambiguity → Document Assumption** - document with rationale; `$maestria:reviewer` validates.
 
 - **Parallelization:** writer tasks on different docs can run in parallel. Same doc is single-writer.