oh-my-codex 0.18.8 → 0.18.10

package/templates/AGENTS.md

@@ -14,15 +14,6 @@ When OMX is installed, load the installed prompt/skill/agent surfaces from `~/.c
 
 <guidance_schema_contract>
 Canonical guidance schema for this template is defined in `docs/guidance-schema.md`.
-
-Required schema sections and this template's mapping:
-- **Role & Intent**: title + opening paragraphs.
-- **Operating Principles**: `<operating_principles>`.
-- **Execution Protocol**: delegation/model routing/agent catalog/skills/team pipeline sections.
-- **Constraints & Safety**: keyword detection, cancellation, and state-management rules.
-- **Verification & Completion**: `<verification>` + continuation checks in `<execution_protocols>`.
-- **Recovery & Lifecycle Overlays**: runtime/team overlays are appended by marker-bounded runtime hooks.
-
 Keep runtime marker contracts stable and non-destructive when overlays are applied:
 - `<!-- OMX:RUNTIME:START --> ... <!-- OMX:RUNTIME:END -->`
 - `<!-- OMX:TEAM:WORKER:START --> ... <!-- OMX:TEAM:WORKER:END -->`
@@ -33,9 +24,8 @@ Keep runtime marker contracts stable and non-destructive when overlays are appli
 - Delegate only when it materially improves quality, speed, or correctness.
 - Keep progress short, concrete, and useful.
 - Prefer evidence over assumption; verify before claiming completion.
-- Use the lightest path that preserves quality: direct action, MCP, then delegation.
 - Check official documentation before implementing with unfamiliar SDKs, frameworks, or APIs.
-- Within a single Codex session or team pane, use Codex native subagents for independent, bounded parallel subtasks when that improves throughput.
+- Within one Codex session or team pane, use Codex native subagents for independent, bounded subtasks when that improves throughput.
 <!-- OMX:GUIDANCE:OPERATING:START -->
 - Default to outcome-first, quality-focused responses: identify the user's target result, success criteria, constraints, available evidence, expected output, and stop condition before adding process detail.
 - Keep collaboration style short and direct. Make progress from context and reasonable assumptions; ask only when missing information would materially change the result or create meaningful risk.
@@ -62,91 +52,40 @@ Keep runtime marker contracts stable and non-destructive when overlays are appli
 - Keep diffs small, reviewable, and reversible.
 - Verify with lint, typecheck, tests, and static analysis after changes; final reports include changed files, simplifications, and remaining risks.
 
-<lore_commit_protocol>
-## Lore Commit Protocol
-
-Every commit message must follow the Lore protocol: a concise decision record using git-native trailers.
-
-### Format
-
-```
-<intent line: why the change was made, not what changed>
-
-<optional concise body: constraints and approach rationale>
-
-Constraint: <external constraint that shaped the decision>
-Rejected: <alternative considered> | <reason for rejection>
-Confidence: <low|medium|high>
-Scope-risk: <narrow|moderate|broad>
-Directive: <forward-looking warning for future modifiers>
-Tested: <what was verified>
-Not-tested: <known gaps in verification>
-```
-
-### Rules
-
-- Intent line first; describe why, not what.
-- Use trailers only when they add decision context.
-- Use `Rejected:` for alternatives future agents should not re-explore.
-- Use `Directive:` for warnings, `Constraint:` for external forces, and `Not-tested:` for known verification gaps.
-- Teams may introduce domain-specific trailers without breaking compatibility.
-</lore_commit_protocol>
-
----
 
 <delegation_rules>
 Default posture: work directly.
 
 Choose the lane before acting:
-- `$deep-interview` for unclear intent, missing boundaries, or explicit "don't assume" requests. This mode clarifies and hands off; it does not implement.
-- `$ralplan` when requirements are clear enough but plan, tradeoff, or test-shape review is still needed.
-- `$team` when the approved plan needs coordinated parallel execution across multiple lanes.
-- `$ralph` when the approved plan needs a persistent single-owner completion / verification loop.
-- **Solo execute** when the task is already scoped and one agent can finish + verify it directly.
-
-Delegate only when it materially improves quality, speed, or safety. Do not delegate trivial work or use delegation as a substitute for reading the code.
-For substantive code changes, `executor` is the default implementation role.
-Outside active `team`/`swarm` mode, use `executor` (or another standard role prompt) for implementation work; do not invoke `worker` or spawn Worker-labeled helpers in non-team mode.
-Reserve `worker` strictly for active `team`/`swarm` sessions and team-runtime bootstrap flows.
-Switch modes only for a concrete reason: unresolved ambiguity, coordination load, or a blocked current lane.
+- `$deep-interview` for unclear intent, missing boundaries, or explicit "don't assume" requests. It clarifies and hands off; it does not implement.
+- `$ralplan` when requirements are clear enough but plan, tradeoff, architecture, or test-shape review is still needed.
+- `$team` when an approved plan needs coordinated parallel execution across multiple lanes.
+- `$ralph` when an approved plan needs a persistent single-owner completion and verification loop.
+- Solo execute when the task is already scoped and one agent can finish and verify it directly.
+- Outside active `team`/`swarm` mode, use `executor` for bounded implementation or review slices; do not invoke `worker` as a general-purpose role.
+- Reserve `worker` strictly for active `team`/`swarm` sessions where the team runtime assigns a worker lane.
+- `worker` is a team-runtime surface, not a general-purpose child role.
+
+
+Use Codex native subagents for bounded implementation, research, review, or verification slices when they materially improve quality, speed, or safety. Do not delegate trivial work or use delegation as a substitute for reading the code.
 </delegation_rules>
 
 <child_agent_protocol>
-Leader responsibilities:
-1. Pick the mode and keep the user-facing brief current.
-2. Delegate only bounded, verifiable subtasks with clear ownership.
-3. Integrate results, decide follow-up, and own final verification.
-
-Worker responsibilities:
-1. Execute the assigned slice; do not rewrite the global plan or switch modes on your own.
-2. Stay inside the assigned write scope; report blockers, shared-file conflicts, and recommended handoffs upward.
-3. Ask the leader to widen scope or resolve ambiguity instead of silently freelancing.
-
-Rules:
-- Max 6 concurrent child agents.
-- Child prompts stay under AGENTS.md authority.
-- `worker` is a team-runtime surface, not a general-purpose child role.
-- Child agents should report recommended handoffs upward.
-- Child agents should finish their assigned role, not recursively orchestrate unless explicitly told to do so.
-- Prefer inheriting the leader model by omitting `spawn_agent.model` unless a task truly requires a different model.
-- Do not hardcode stale frontier-model overrides for Codex native child agents. If an explicit frontier override is necessary, use the current frontier default from `OMX_DEFAULT_FRONTIER_MODEL` / the repo model contract (currently `gpt-5.5`), not older values such as `gpt-5.2`.
-- Prefer role-appropriate `reasoning_effort` over explicit `model` overrides when the only goal is to make a child think harder or lighter.
+Leader responsibilities: choose the mode, delegate bounded verifiable subtasks, integrate results, and own final verification.
+Worker responsibilities: execute the assigned slice, stay inside scope, and report blockers, shared-file conflicts, scope expansion, or recommended handoffs upward; child prompts should report recommended handoffs upward rather than recursively orchestrating.
+Leader vs worker: leaders own mode selection, integration, verification, and stop/escalate calls; workers execute assigned slices and escalate from worker to leader for blockers, shared-file conflicts, scope expansion, missing authority, or mode mismatch.
+Rules: max 6 concurrent child agents; child prompts remain under AGENTS.md authority; prefer inherited model defaults unless a task has a concrete model reason; `worker` is a team-runtime surface, not a general-purpose child role.
 </child_agent_protocol>
 
+
 <invocation_conventions>
-- `$name` — invoke a workflow skill
-- `/skills` — browse available skills
-- Prefer skill invocation and keyword routing as the primary user-facing workflow surface
+- `$name` — invoke a workflow skill.
+- `/skills` — browse available skills.
+- Prefer explicit skill invocation for deterministic workflow routing.
 </invocation_conventions>
 
 <model_routing>
-Match role to task shape:
-- Low complexity: `explore`, `style-reviewer`, `writer`
-- Research/discovery: `explore` for repo lookup, `researcher` for official docs/reference gathering, `dependency-expert` for SDK/API/package evaluation
-- Standard: `executor`, `debugger`, `test-engineer`
-- High complexity: `architect`, `executor`, `critic`
-
-For Codex native child agents, model routing defaults to inheritance/current repo defaults unless the caller has a concrete reason to override it.
+Match role to task shape: `explore` for repo lookup, `researcher` for official docs/reference gathering, `dependency-expert` for SDK/package decisions, `executor` for implementation, `debugger` for root cause, `architect`/`critic` for high-complexity review. Codex native child agents inherit current repo/model defaults unless the caller has a concrete reason to override them.
 </model_routing>
 
 <specialist_routing>
@@ -161,105 +100,45 @@ Leader/workflow routing contract:
 <!-- OMX:GUIDANCE:SPECIALIST-ROUTING:END -->
 </specialist_routing>
 
----
-
 <agent_catalog>
-Key roles: `explore` (repo search/mapping), `planner` (plans/sequencing), `architect` (read-only design/diagnosis), `debugger` (root cause), `executor` (implementation/refactoring), and `verifier` (completion evidence).
-
-Research/discovery specialists:
-- `explore` — first-stop repository lookup and symbol/file mapping
-- `researcher` — official docs, references, and external fact gathering
-- `dependency-expert` — SDK/API/package evaluation before adopting or changing dependencies
-
-Specialists remain available through the role catalog and native child-agent surfaces when the task clearly benefits from them.
+Key roles: `explore`, `researcher`, `dependency-expert`, `planner`, `architect`, `debugger`, `executor`, `test-engineer`, `verifier`, and `critic`. Use the installed role catalog for full descriptions.
 </agent_catalog>
 
----
-
 <keyword_detection>
 Keyword routing is implemented primarily by native `UserPromptSubmit` hooks and the generated keyword registry. Treat hook-injected routing context as authoritative for the current turn, then load the named `SKILL.md` or prompt file as instructed.
 
 Fallback behavior when hook context is unavailable:
 - Explicit `$name` invocations run left-to-right and override implicit keywords.
-- Bare skill names do not activate skills by themselves; skill-name activation requires explicit `$skill` invocation. Natural-language routing phrases may still map to a workflow when they are not just the bare skill name. Examples: `analyze` / `investigate` → `$analyze` for read-only deep analysis with ranked synthesis, explicit confidence, and concrete file references; `deep interview`, `interview`, `don't assume`, or `ouroboros` → `$deep-interview` for Socratic deep interview requirements clarification; `ralplan` / `consensus plan` → `$ralplan`; `cancel`, `stop`, or `abort` → `$cancel`.
-- Keep the detailed keyword list in `src/hooks/keyword-registry.ts`; do not duplicate that table here.
-
-Runtime availability gate:
-- Treat `autopilot`, `ralph`, `ultrawork`, `ultraqa`, `team`/`swarm`, and `ecomode` as **OMX runtime workflows**, not generic prompt aliases.
-- Auto-activate runtime workflows only when the current session is actually running under OMX CLI/runtime (for example, launched via `omx`, with OMX session overlay/runtime state available, or when the user explicitly asks to run `omx ...` in the shell).
-- In Codex App or plain Codex sessions without OMX runtime, do **not** treat those keywords alone as activation. Explain that they require OMX CLI runtime support and are not directly available there, and continue with the nearest App-safe surface (`deep-interview`, `ralplan`, `plan`, or native subagents) unless the user explicitly wants you to launch OMX CLI from shell first.
-- When deep-interview is active in attached-tmux OMX CLI/runtime, ask each interview round via `omx question` as a temporary popup-style renderer over the leader pane; after launching `omx question` in a background terminal, wait for that terminal to finish and read the JSON answer before continuing; preserve the leader pane with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` (or an explicit `%pane` value) when invoking it through Bash/tool paths, prefer `answers[0].answer` / `answers[]` from the response and use legacy `answer` only as fallback, and respect Stop-hook blocking while a deep-interview question obligation is pending. Deep-interview remains one question per round; do not batch multiple interview rounds into one `questions[]` form. Outside tmux or native surfaces that cannot render `omx question` should use the native structured question path when available, otherwise ask exactly one concise plain-text question and wait for the answer.
-
-<triage_routing>
-## Triage: advisory prompt-routing context
+- Bare skill names do not activate skills by themselves; skill-name activation requires explicit `$skill` invocation. Natural-language routing phrases may still map to a workflow. Examples: `analyze` / `investigate` → `$analyze` for read-only deep analysis with ranked synthesis, explicit confidence, and concrete file references; `deep interview`, `interview`, `don't assume`, or `ouroboros` → `$deep-interview` for Socratic deep interview requirements clarification.
+- Keep the detailed keyword list in `src/hooks/keyword-registry.ts`; do not duplicate it here.
 
-The keyword detector is the first and deterministic routing surface. Triage runs only when no keyword matches.
+Runtime workflows such as `autopilot`, `ralph`, `ultrawork`, `ultraqa`, `team`/`swarm`, and `ecomode` require OMX CLI runtime support. In Codex App, outside-tmux, or plain Codex sessions without OMX tmux runtime, explain that those workflows are not directly available there and continue with the nearest App-safe surface unless the user explicitly wants to launch OMX CLI from shell first.
+- When deep-interview is active in attached-tmux OMX CLI/runtime, ask each interview round via `omx question`; after launching `omx question` in a background terminal, wait for that terminal to finish and read the JSON answer before continuing; preserve the leader pane with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` when invoking it through Bash/tool paths. Outside tmux or native surfaces that cannot render `omx question` should use the native structured question path when available; otherwise ask exactly one concise plain-text question and wait for the answer.
 
-When active, triage emits **advisory prompt-routing context** — a developer-context string that the model may follow. It does not activate a skill or workflow by itself. It is a best-effort hint, not a guarantee.
-
-Note: `explore`, `executor`, `designer`, and `researcher` are agent role-prompt files under `prompts/`, not workflow skills. `researcher` is used for official-doc/reference/source-backed external lookup prompts only; local anchors and implementation-shaped prompts stay with `explore`/`executor`/HEAVY routing.
-
-Explicit keywords remain the deterministic control surface when you want explicit, guaranteed routing — use them whenever exact behavior matters.
-
-To opt out per prompt with phrases such as `no workflow`, `just chat`, or `plain answer` — the triage layer will suppress context injection for that prompt.
-</triage_routing>
-
-Ralph / Ralplan execution gate:
-- Enforce **ralplan-first** when ralph is active and planning is not complete.
-- Planning is complete only after both `.omx/plans/prd-*.md` and `.omx/plans/test-spec-*.md` exist.
-- Until complete, do not begin implementation or execute implementation-focused tools.
 </keyword_detection>
 
----
-
 <skills>
-Skills are workflow commands. Core workflows include `autopilot`, `ralph`, `ultrawork`, `visual-verdict`, `visual-ralph`, `ecomode`, `team`, `swarm`, `ultraqa`, `plan`, `deep-interview`, and `ralplan`; utilities include `cancel`, `note`, `doctor`, `help`, and `trace`.
+Skills are workflow commands. Always load the relevant installed `SKILL.md` before following a skill-specific process. Remove or ignore deprecated skill descriptions unless the installed catalog still marks that skill active.
 </skills>
 
----
-
 <team_compositions>
 Use explicit team orchestration for feature development, bug investigation, code review, UX audit, and similar multi-lane work when coordination value outweighs overhead.
 </team_compositions>
 
----
-
 <team_pipeline>
-Team mode is the structured multi-agent surface.
-Canonical pipeline:
-`team-plan -> team-prd -> team-exec -> team-verify -> team-fix (loop)`
-
-Use it when durable staged coordination is worth the overhead. Otherwise, stay direct.
-Terminal states: `complete`, `failed`, `cancelled`.
+Team mode is the structured multi-agent surface. Use it when durable staged coordination is worth the overhead; otherwise stay direct. Terminal states: `complete`, `failed`, `cancelled`.
 </team_pipeline>
 
----
-
 <team_model_resolution>
-Team/Swarm workers currently share one `agentType` and one launch-arg set.
-Model precedence:
-1. Explicit model in `OMX_TEAM_WORKER_LAUNCH_ARGS`
-2. Inherited leader `--model`
-3. Low-complexity default model from `OMX_DEFAULT_SPARK_MODEL` (legacy alias: `OMX_SPARK_MODEL`)
-
-Normalize model flags to one canonical `--model <value>` entry.
-Do not guess frontier/spark defaults from model-family recency; use `OMX_DEFAULT_FRONTIER_MODEL` and `OMX_DEFAULT_SPARK_MODEL`.
+Team/Swarm worker model precedence: explicit `OMX_TEAM_WORKER_LAUNCH_ARGS`, inherited leader `--model`, then low-complexity default from `OMX_DEFAULT_SPARK_MODEL` (legacy alias: `OMX_SPARK_MODEL`). Normalize model flags to one canonical `--model <value>` entry and use `OMX_DEFAULT_FRONTIER_MODEL` / `OMX_DEFAULT_SPARK_MODEL` rather than guessing defaults.
 </team_model_resolution>
 
 <!-- OMX:MODELS:START -->
 <!-- Auto-generated by omx setup -->
 <!-- OMX:MODELS:END -->
 
----
-
 <verification>
 Verify before claiming completion.
-
-Sizing guidance:
-- Small changes: lightweight verification
-- Standard changes: standard verification
-- Large or security/architectural changes: thorough verification
-
 <!-- OMX:GUIDANCE:VERIFYSEQ:START -->
 Verification loop: define the claim and success criteria, run the smallest validation that can prove it, read the output, then report with evidence. If validation fails, iterate; if validation cannot run, explain why and use the next-best check. Keep evidence summaries concise but sufficient.
 
@@ -273,29 +152,17 @@ Verification loop: define the claim and success criteria, run the smallest valid
 <execution_protocols>
 Mode selection: use `$deep-interview` for unclear intent/boundaries; `$ralplan` for consensus on architecture, tradeoffs, or tests; `$team` for approved multi-lane work; `$ralph` for persistent single-owner completion/verification loops; otherwise execute directly in solo mode. Switch modes only when evidence shows the current lane is mismatched or blocked.
 
-Command routing:
-- `omx explore` is deprecated and MUST NOT be recommended as the default surface for simple read-only repository lookup tasks. Use normal Codex repository inspection tools/subagents for file, symbol, pattern, relationship, and implementation discovery.
-- `USE_OMX_EXPLORE_CMD` is compatibility-only for legacy callers; it does not make `omx explore` preferred for new work.
-
-Use `omx sparkshell` for explicit shell-native read-only commands, bounded verification, repo-wide listing/search, or explicit `omx sparkshell --tmux-pane` summaries. Treat sparkshell as explicit opt-in. When to use what: keep ambiguous, implementation-heavy, edit-heavy, diagnostics, tests, MCP/web, and complex shell work on the normal path; if `omx sparkshell` is incomplete, retry narrower or gracefully fall back to the normal path.
-
-Leader vs worker:
-- The leader chooses the mode, keeps the brief current, delegates bounded work, and owns verification plus stop/escalate calls.
-- Workers execute their assigned slice, do not re-plan the whole task or switch modes on their own, and report blockers or recommended handoffs upward.
-- Workers escalate shared-file conflicts, scope expansion, or missing authority to the leader instead of freelancing.
+Command routing: `omx explore` is deprecated and MUST NOT be recommended as the default surface for simple read-only repository lookup tasks. Use normal Codex repository inspection tools/subagents; use `omx sparkshell` only for explicit shell-native read-only evidence or bounded verification.
+When to use what:
+- Use normal Codex repository inspection tools/subagents for repository lookup and implementation context.
+- Use `omx sparkshell --tmux-pane` only as an explicit opt-in operator aid for shell-native tmux evidence or bounded verification; it does not replace raw evidence capture.
+- `USE_OMX_EXPLORE_CMD` is a compatibility-only override for deprecated `omx explore` routing and does not make `omx explore` preferred.
 
-Stop / escalate:
-- Stop when the task is verified complete, the user says stop/cancel, or no meaningful recovery path remains.
-- Escalate to the user only for irreversible, destructive, or materially branching decisions, or when required authority is missing.
-- Escalate from worker to leader for blockers, scope expansion, shared ownership conflicts, or mode mismatch.
-- `deep-interview` and `ralplan` stop at a clarified artifact or approved-plan handoff; they do not implement unless execution mode is explicitly switched.
+Leader vs worker: leaders choose mode, delegate bounded work, integrate, and own verification; workers execute their slice and escalate blockers, scope expansion, shared-file conflicts, or mode mismatch upward. Escalate from worker to leader for blockers, scope expansion, shared ownership conflicts, or mode mismatch.
 
-Output contract:
-- Default update/final shape: current mode; action/result; evidence or blocker/next step.
-- Keep rationale once; do not restate the full plan every turn.
-- Expand only for risk, handoff, or explicit user request.
+Stop / escalate: stop when the task is verified complete, the user says stop/cancel, or no meaningful recovery path remains. Escalate to the user only for irreversible, destructive, materially branching decisions, or missing authority.
 
-Parallelization: run independent tasks in parallel, dependent tasks sequentially, and long builds/tests in the background when helpful. Prefer Team mode only when coordination value outweighs overhead. If correctness depends on retrieval, diagnostics, tests, or other tools, continue until the task is grounded and verified.
+Output contract: Default update/final shape: state current mode, action/result, and evidence or blocker/next step. Keep rationale once; do not restate the full plan every turn; expand only for risk, handoff, or explicit request.
 
 Anti-slop workflow:
 - Cleanup/refactor/deslop work still follows the same `$deep-interview` -> `$ralplan` -> `$team`/`$ralph` path; use `$ai-slop-cleaner` as a bounded helper inside the chosen execution lane, not as a competing top-level workflow.
@@ -305,43 +172,17 @@ Anti-slop workflow:
 - Run lint, typecheck, tests, and static analysis before claiming completion.
 - Keep writer/reviewer pass separation for cleanup plans and approvals; preserve writer/reviewer pass separation explicitly.
 
-Visual iteration gate:
-- For visual tasks, run `$visual-verdict` every iteration before the next edit.
-- Persist verdict JSON in `.omx/state/{scope}/ralph-progress.json`.
-
-Continuation:
-Before concluding, confirm: no pending work, features working, tests passing, zero known errors, verification evidence collected. If not, continue.
-
-Ralph planning gate:
-If ralph is active, verify PRD + test spec artifacts exist before implementation work.
+Continuation: before concluding, confirm no pending work remains, features work, tests pass or gaps are explicit, and verification evidence is collected. If not, continue.
 </execution_protocols>
 
 <cancellation>
-Use the `cancel` skill to end execution modes.
-Cancel when work is done and verified, when the user says stop, or when a hard blocker prevents meaningful progress.
-Do not cancel while recoverable work remains.
+Use the `cancel` skill to end active execution modes when work is done and verified, when the user says stop, or when a hard blocker prevents meaningful progress. Do not cancel while recoverable work remains.
 </cancellation>
 
----
-
 <state_management>
-Hooks own normal skill-active and workflow-state persistence under `.omx/state/`.
-
-OMX persists runtime state under `.omx/`:
-- `.omx/state/` — mode state
-- `.omx/notepad.md` — session notes
-- `.omx/project-memory.json` — cross-session memory
-- `.omx/plans/` — plans
-- `.omx/logs/` — logs
-
-Available MCP groups include state/memory tools, code-intel tools, and trace tools.
-
-Agents may use OMX state/MCP tools for explicit lifecycle transitions, recovery, checkpointing, cancellation cleanup, or compaction resilience.
-Do not manually duplicate hook-owned activation state unless recovering from missing or stale state.
+Hooks own normal skill-active and workflow-state persistence under `.omx/state/`. OMX runtime state lives under `.omx/`; do not manually duplicate hook-owned activation state unless recovering from missing or stale state.
 </state_management>
 
----
-
 ## Setup
 
 Execute `omx setup` to install all components. Execute `omx doctor` to verify installation.

package/src/scripts/postinstall-bootstrap.js

@@ -1,23 +0,0 @@
-import { existsSync } from "node:fs";
-import { dirname, join } from "node:path";
-import { fileURLToPath, pathToFileURL } from "node:url";
-
-const __filename = fileURLToPath(import.meta.url);
-const __dirname = dirname(__filename);
-const distScriptPath = join(__dirname, "..", "..", "dist", "scripts", "postinstall.js");
-
-if (!existsSync(distScriptPath)) {
-  process.exit(0);
-}
-
-const moduleUrl = pathToFileURL(distScriptPath).href;
-try {
-  const postinstallModule = await import(moduleUrl);
-  if (typeof postinstallModule.main === "function") {
-    await postinstallModule.main();
-  }
-} catch (error) {
-  console.warn(
-    `[omx] Postinstall bootstrap skipped after a non-fatal error: ${error instanceof Error ? error.message : String(error)}`,
-  );
-}