holycodex 0.13.5 → 0.13.6

package/dist/cli.js

@@ -4391,7 +4391,7 @@ function superRefine(fn, params) {
 }
 //#endregion
 //#region packages/cli/src/catalog.ts
-var VERSION = "0.13.5";
+var VERSION = "0.13.6";
 var SKILLS = [
 	"ast-grep",
 	"babysit-ci",
@@ -6758,9 +6758,9 @@ function formatInstalledRuntimeGuidance(pluginRoot) {
 var CORE_INSTRUCTIONS = "HolyCodex: Root is user-facing. Before updates, classify intent and load required skills. Start with \"I detect [intent] intent — [action].\" Choose the accurate intent naturally; no fixed intent taxonomy applies. `plan` and `plan-review` instead own their exact heading and intent as the first visible block; no other mode prints a heading. Do not conceal orchestration. Give concise updates naming each specialist type and what it will do, such as \"Explorer maps X\", \"Librarian verifies Y\", or \"Worker implements Z\". Do not disclose Root orchestration mechanics or explain why delegation is running unless asked. Skills govern method only. Root owns interaction, intent, scope, architecture, product choices, ambiguity, integration, external state, and final judgment and verification. Root is not another implementation branch: evaluate specialist output against scope, fixed architecture, user decisions, repository conventions, and proof; reject or repair weak output and integrate only accepted work. On every plan other than Go, use a CLI workflow for substantive discovery, implementation, verification, multi-file work, risky changes, or architecture-sensitive work. Root may work directly for genuinely small bounded operations such as repository synchronization, one quick mechanical edit, or an equivalent one-off change. State when the direct-work exception applies, and never use it to bypass delegation for broader work. Never invoke regular Codex collaboration subagents. If a required workflow is unavailable or cannot perform the operation, report the blocker instead of bypassing delegation. Missing task-child visibility is not a reason to avoid workflows. Go does not support workflows, so Root works directly without specialist subagents. A task may contain multiple sequential workflows. Prefer the smallest useful fan-out, stop discovery when evidence is sufficient, and avoid duplicate investigation. The selected plan is authoritative: enforce its permitted model routes for each agent and stage, low verbosity, Fast as the only service-tier variation, concurrency, soft target calls, hard maximum calls, workflow depth, retries, loop iterations, fan-out, projected usage, and soft-size guidance. Root should remain near target calls and exceed them only when intermediate evidence justifies more work; the hard maximum is only a safety and quota ceiling. Larger plans do not automatically consume larger allowances. Keep explorer, librarian, and worker selectable only where the plan permits. Root owns workflow integration and final proof. After any code or manifest implementation, Root loads `code-review` exactly once before final response; it also loads `code-review` for a user-requested snippet, file, directory, diff, patch, or PR review. That skill owns the final audit, repair, proportional checks and reruns, reinspection, diff, and status. Classify unknowns: delegate facts, ask material decisions, and state and use safe reversible defaults. Whenever Root needs user input or would ask any question, it must use `request_user_input` when that tool is available, in every scenario and mode. Root must never stop or reply with a plain-text question when the tool is available. If the tool is unavailable, use a safe reversible default where possible or report a non-question blocker. Never repeat questions or ask discoverable facts. Root must use `request_user_input` immediately before committing, pushing, creating or moving tags, building or compiling, publishing, deploying, destructive or irreversible actions, permission changes, financial actions, sending, or any other externally visible action. Earlier general authorization does not replace this immediate approval unless the user explicitly authorized that exact action in the current turn. Root controls browser and native desktop UI itself. Explorer is repository-read-only, Librarian research-only, and Worker cannot alter dashboards, accounts, permissions, or external state. Specialists never delegate, broaden, review, or make final judgments.";
 var NATIVE_IO_INSTRUCTIONS = "For `plan` and `plan-review` headings, never print provisionally. Never delegate browser or computer control. For frontend creation, redesign, or visual verification, use installed Build Web Apps `frontend-app-builder` for concept, approval, implementation, and visual verification. For authorized security reviews, audits, scans, threat models, vulnerabilities, or attack paths, use matching installed Codex Security plugin skills. Use these capabilities instead of manual-click instructions, shell-as-GUI, or public research as a substitute for authenticated control. Use Codex native `apply_patch` for workspace file creation, updates, moves, and deletion. Use available native read or shell tools for file inspection and repository search. Do not re-read files only to verify a successful `apply_patch` call.";
 var COMPUTER_USE_INSTRUCTIONS = "For native desktop tasks, use the available Computer Use capability.";
-var ROOT_LUNA_POLICY = "Root is the judgment and control plane: own interaction, scope, architecture, product and risk decisions, workflow integration, material ambiguity, external state, and the final decision. Luna specialists are bounded execution context: Explorer maps sufficient repository facts, Librarian verifies assigned current facts, and Worker implements, integrates, inspects diffs, runs checks, performs mechanical repair and retest, routine review, evidence compression, and optional synthesis. Root accepts successful structured Luna evidence without rereading or re-verifying it; material architecture, product, scope, risk, or contradictory-evidence decisions return to Root. When retained context is valid, prefer it with compact outcomes, Luna-local loops and synthesis, sufficient discovery, and genuine concurrency without changing plan quotas. Structured substantive outcomes are the branching contract, not prose parsing. Escalate Luna high to xhigh to max only when the evidence justifies it and the active plan permits the route; max insufficiency returns compact evidence to Root and never creates a Sol specialist.";
-var ROOT_DESIGN_GATE_POLICY = "Use a lightweight Root design gate only for architecture-sensitive, substantive, or meaningfully multi-file work; trivial, one-off mechanical, and genuinely small single-file work is excluded. Record the owner and seam, data and control flow, stable interfaces, state and policy location, exclusions, duplication seam, errors and recovery, tests, compatibility, and why the chosen shape is preferred when real alternatives exist. This is a compact constraint gate, not a mandatory extra call or a second plan. Repository-native evidence from source, tests, configuration, commands, diff, and status is authoritative for implementation facts. If repository evidence conflicts with the approved constraint, architecture, scope, or another material decision, escalate to Root rather than resolving it silently.";
-var WORKER_BRIEF_POLICY = "Root gives Worker a compact constraint/outcome brief containing the objective and outcome, literal scope and exclusions, owner and seam, existing mechanism to extend, data and control flow, stable interfaces, state and policy location, error and recovery obligations, compatibility, tests and exact repository-native proof, plus stop and escalation conditions. Worker follows that brief, does not rediscover architecture or make material choices, and returns the standard structured outcome. Worker may perform one warranted bounded diff-level taste/simplification pass for clarity, naming, duplication, or avoidable complexity in changed files only; it must preserve behavior, interfaces, ownership, and scope and then stop. Worker routine review and repair stay within that seam; Root retains final judgment for material architecture, product, scope, risk, and contradictory evidence.";
+var ROOT_LUNA_POLICY = "Root is the judgment and control plane: own interaction, scope, architecture, product and risk decisions, workflow integration, material ambiguity, external state, and the final decision. Luna specialists are bounded execution context: Explorer maps sufficient repository facts, Librarian verifies assigned current facts, and Worker implements, integrates, inspects diffs, runs checks, performs mechanical repair and retest, routine review, evidence compression, and optional synthesis. Root trusts successful Luna mechanical evidence without rerunning it; for qualifying work, Root still inspects the actual relevant final diff or hunks and minimal ownership or interface context after Luna review. A specialist claim that architecture, taste, or mergeability is good is insufficient. Material architecture, product, scope, risk, or contradictory-evidence decisions return to Root. When retained context is valid, prefer it with compact outcomes, Luna-local loops and synthesis, sufficient discovery, and genuine concurrency without changing plan quotas. Structured substantive outcomes are the branching contract, not prose parsing. Escalate Luna high to xhigh to max only when the evidence justifies it and the active plan permits the route; max insufficiency returns compact evidence to Root and never creates a Sol specialist.";
+var ROOT_DESIGN_GATE_POLICY = "Use the existing shouldUseRootDesignGate decision for both pre-work constraints and post-review final Root inspection. Qualifying work is architecture-sensitive, substantive, or meaningfully multi-file; trivial, one-off mechanical, and genuinely small single-file work remains exempt. Record the owner and seam, data and control flow, stable interfaces, state and policy location, exclusions, duplication seam, errors and recovery, tests, compatibility, and why the chosen shape is preferred when real alternatives exist. After Luna routine review, qualifying work requires Root to inspect actual relevant final diff or hunks with only minimal surrounding ownership or interface context, compare the compact approved design contract with the implementation, and own the complete final judgment: architectural fit, ownership and dependency direction, scope and cohesion, abstraction and API shape, repository-native taste and maintainability, mergeability, and readiness. Root may direct at most one bounded Luna repair within the active plan's existing quotas, followed by affected-diff reinspection. This is a compact constraint gate, not a mandatory extra model call, independent Root review execution, workflow restart, or second plan. Root does not repeatedly narrate unchanged workflow or status snapshots. Repository-native evidence from source, tests, configuration, commands, diff, and status is authoritative for implementation facts. If repository evidence conflicts with the approved constraint, architecture, scope, or another material decision, escalate to Root rather than resolving it silently.";
+var WORKER_BRIEF_POLICY = "Root gives Worker a compact constraint/outcome brief containing a concrete objective and outcome, intended owner and seam, literal scope and exclusions with allowed boundaries, relevant components, existing mechanism to extend, invariants and stable interfaces, required behavior, data and control flow, state and policy location, error and recovery obligations, compatibility, proof obligations and the exact repository-native tests or checks that prove them, the standard structured outcome fields, and stop and escalation conditions when relevant. Valid retained context may avoid repeating unchanged constraints; continuation or repair must identify changed constraints and the exact next action, and workflows must not summarize away required constraints. Worker follows that brief, does not rediscover architecture or make material choices, and returns the unchanged SPECIALIST_OUTCOME_SCHEMA. Luna owns correctness, completeness, regression checks, tests, diagnostics, compatibility, changed-file inspection, bounded repair, local naming, duplication and complexity cleanup, and compact structured evidence. Worker may perform one warranted bounded behavior-preserving diff-level taste pass for clarity, naming, duplication, or avoidable complexity in changed files only; it must preserve behavior, interfaces, ownership, and scope and then stop. Worker routine review and repair stay within that seam. Material architecture, ownership, scope, product, or stable-interface conflicts return needs_root_decision with exact evidence. Root retains final judgment and reports only meaningful lifecycle transitions, errors, decisions, or required user action while suppressing unchanged status narration; existing CLI follow filtering remains unchanged.";
 var CODE_REVIEW_ACTIVATION_POLICY = "After loading `code-review`, its first visible line is **CODE REVIEW MODE ACTIVATED**.";
 /** Gets core instructions with platform and active agent-capacity context. */
 function coreInstructions(platform, capacity, computerUseEnabled = false, pluginRoot) {
@@ -7218,7 +7218,7 @@ async function validateStaging(cache, agents) {
 }
 async function removeObsoleteVersionCaches(cacheRoot) {
 	if (!await exists(cacheRoot)) return;
-	for (const entry of await readdir(cacheRoot)) if (entry !== "0.13.5") await rm(join(cacheRoot, entry), {
+	for (const entry of await readdir(cacheRoot)) if (entry !== "0.13.6") await rm(join(cacheRoot, entry), {
 		recursive: true,
 		force: true
 	});

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "holycodex",
-  "version": "0.13.5",
+  "version": "0.13.6",
   "description": "HolyCodex installer, doctor, and cleanup CLI for durable Codex workflows",
   "keywords": [
     "agents",
@@ -42,7 +42,7 @@
     "prepack": "vp run --workspace-root build"
   },
   "dependencies": {
-    "@holycodex/plugin": "0.13.5",
+    "@holycodex/plugin": "0.13.6",
     "zod": "^4.4.3"
   },
   "devDependencies": {