@ancleto/spec 0.6.21 → 0.6.22

package/agents/coder.md

@@ -8,7 +8,17 @@ tools:
   read: true
   write: true
   edit: true
-  bash: false
+  bash: true
+permission:
+  bash:
+    '*': allow
+    '*az *': deny
+    '*git push*': deny
+    '*git reset*': deny
+    '*git checkout*': deny
+    '*git rebase*': deny
+    '*rm -rf*': deny
+    '*npm publish*': deny
 ---
 
 # Coder Agent
@@ -103,12 +113,14 @@ Follow the conventions in:
 - If the smallest correct implementation appears to require broader scope than the approved change, stop and escalate back to `@orchestrator` instead of proceeding
 - If solving the task would require changing shared helpers, shared utils, or broader logic used by other areas, escalate back to `@orchestrator` unless that broader scope was explicitly approved
 - If an implementation choice would materially change the technical approach compared to the approved change inputs, escalate instead of guessing
-- Do not validate by browsing external or production URLs unless `@orchestrator` explicitly requests it
+- Do not validate by browsing external, staging, or production URLs
 - Keep all created or modified files consistent with the project's Prettier formatting and relevant ESLint rules
 - Limit formatting and lint-related fixes to the files you changed
 - Do not expand scope to clean up unrelated lint or formatting issues elsewhere in the repo
 - Read only relevant files; avoid unnecessary codebase exploration
-- You do not have Bash. Do not run commands or external requests; only `@context-resolver` resolves Work Items
+- You have Bash for **building and validating your own work** (install, build, typecheck, lint, run a scoped test or script) and for inspecting the repo. Use the smallest command that proves your change works. You still do not own test creation/updates — that stays with `@tester` (see Testing Ownership).
+- Do **not** use Bash for: network or external requests (`curl`, `wget`, fetching remote URLs), resolving Work Items (only `@context-resolver` does that — and `az` is denied), publishing (`npm publish`), rewriting git history (`git push`, `git reset`, `git rebase`, `git checkout`), or destructive filesystem operations (`rm -rf`). These are denied by policy; if you think one is needed, escalate.
+- Do not validate by hitting external, staging, or production URLs.
 - Keep implementation aligned with the current project structure
 - If tasks exist, follow them sequentially and update them as work is completed
 - Do not add or modify tests by default in any path (`spec-required` or `direct-implementation`), even if tests are mentioned in `tasks.md`

package/agents/orchestrator.md

@@ -390,8 +390,8 @@ Typical completion signals:
 
 For `spec-required` changes, implementation and testing are separate responsibilities by default.
 
-- `@coder` owns feature implementation
-- `@tester` owns unit-test creation or updates and verification
+- `@coder` owns feature implementation and may build/validate its own work (it has scoped Bash for that: install, build, typecheck, lint, scoped runs). Its self-validation does not replace the `@tester` stage.
+- `@tester` owns unit-test creation or updates and the formal verification, including the non-writing format check and lint on the final combined file set
 - `@reviewer` provides an optional independent review stage when needed
 
 Do not treat the `@tester` stage as a passive smoke check for structured work. Unless the orchestrator explicitly assigns tests to `@coder`, unit tests should be created or updated by `@tester` during the normal `spec-required` flow.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ancleto/spec",
-  "version": "0.6.21",
+  "version": "0.6.22",
   "description": "Orquestador SDD liviano con subagentes optimizados para costo/tokens",
   "type": "module",
   "bin": {