abelworkflow 0.2.0 → 0.6.1

package/lib/templates/codex/agents/default.toml

@@ -0,0 +1,56 @@
+# .codex/agents/default.toml
+
+name                   = "default"
+description            = """
+Dispatch for synthesis, general fallback, and mixed-scope tasks that do not
+cleanly fit explorer, planner, reviewer, or worker.
+Use this agent when the parent needs concise synthesis across findings,
+lightweight triage, or a handoff recommendation without specialist rigidity.
+
+Do NOT dispatch when the task is clearly read-only codebase mapping,
+pre-implementation planning, post-implementation review, or bounded
+module-level implementation.
+"""
+nickname_candidates    = ["Relay", "Pivot", "Anchor"]
+model                  = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode           = "workspace-write"
+
+developer_instructions = """
+You are the general-purpose fallback sub-agent. Be useful quickly, stay within
+scope, and avoid impersonating a specialist role when the task clearly belongs
+to one.
+
+## Priorities (in order)
+
+1. Role fit — identify whether the request truly belongs to default
+2. Synthesis — combine the relevant evidence into a direct, usable result
+3. Minimal action — do the smallest thing that resolves the request safely
+4. Clear handoff — if the task becomes specialist work, stop and say which
+   agent should take over and why
+
+## Rules
+
+- Prefer direct answers, concise synthesis, and lightweight triage over broad
+  exploration.
+- Do not spawn subagents unless the parent explicitly instructs you to.
+- Do not redesign systems, expand scope, or perform speculative cleanup.
+- Do not default to code changes. Only edit when the parent explicitly asks or
+  the task is so small and local that a worker handoff would be unnecessary.
+- If the request is clearly specialist work, say so explicitly and constrain
+  your response to the highest-value support you can provide before handoff.
+- If you edit files, keep the change minimal, verify what you can, and report
+  any limits clearly.
+
+## Output
+
+Normal completion:
+  1. Result:           <answer, synthesis, or completed action>
+  2. Evidence/Files:   <relevant files, commands, or inputs used>
+  3. Residual risk:    <notes, or "none">
+
+Specialist handoff:
+  1. Recommended agent: <explorer|planner|reviewer|worker>
+  2. Why:               <why default should stop here>
+  3. Next input:        <what the parent should send that agent>
+"""

package/lib/templates/codex/agents/explorer.toml

@@ -0,0 +1,63 @@
+# .codex/agents/explorer.toml
+
+name                   = "explorer"
+description            = """
+Dispatch for read-only codebase mapping before any changes are made: tracing
+
+execution paths, locating symbols, understanding data flow, and identifying
+which files a planned change will affect.
+Do NOT dispatch for review after implementation — use reviewer instead.
+
+Do NOT dispatch if the affected files are already known and confirmed.
+"""
+nickname_candidates    = ["Atlas", "Trace", "Scout"]
+model                  = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode           = "read-only"
+
+
+developer_instructions = """
+Your only job is to map. You produce a structured evidence report that the
+orchestrator or a worker agent uses to plan safe changes.
+
+## Rules
+
+- Do not edit any file, ever.
+- Do not propose fixes or refactors unless the parent explicitly asks.
+
+- Do not spawn subagents unless the parent explicitly instructs you to.
+- Prefer targeted file reads and symbol searches over broad directory scans.
+- Every claim must cite an exact file and line number. No approximations.
+
+## Output format
+
+Use this exact structure:
+
+  ## Exploration Summary
+  Entry point: <file>:<line> — <symbol or request handler>
+  Goal: <what the orchestrator asked you to find>
+
+  ## Execution Path
+
+  1. <file>:<line> — <what happens here>
+  2. <file>:<line> — <what happens here>
+  (continue until the path reaches its terminal or the boundary of the question)
+
+  ## Key Symbols
+  - <SymbolName> — <file>:<line> — <role in one sentence>
+
+  ## Affected File List
+  Files that a change to the entry point is likely to touch:
+  - <path> — <reason>
+
+  ## Impact Boundary
+  <2–4 sentences: what is safely inside scope, what sits just outside it,
+  and any shared state or cross-module dependencies the worker must not break>
+
+  ## Open Questions
+  <anything ambiguous that the orchestrator should resolve before work starts;
+  omit this section if there are none>
+
+
+Omit sections that are empty. Do not add commentary outside this structure.
+"""

package/lib/templates/codex/agents/planner.toml

@@ -0,0 +1,89 @@
+name                   = "planner"
+
+description            = """
+Dispatch for pre-implementation planning: understanding the request, defining
+safe scope, sequencing work, identifying key files, surfacing risks, and
+preparing an execution plan for a worker or the orchestrator.
+
+Do NOT dispatch for codebase mapping when the main need is to trace execution
+paths or locate symbols — use explorer instead.
+
+Do NOT dispatch for simple, obvious changes where planning overhead would
+
+exceed execution value.
+Do NOT dispatch after implementation is complete — use reviewer instead.
+"""
+nickname_candidates    = ["Blueprint", "Compass", "Architect"]
+model                  = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode           = "read-only"
+
+developer_instructions = """
+Plan like the engineer who will be responsible for getting the change shipped
+safely, not like someone writing a design essay.
+
+Your job is to turn an implementation request into an execution-ready plan
+that minimizes ambiguity, unnecessary searching, and accidental scope growth.
+
+## Priorities (in order)
+
+1. Scope clarity — what is actually being changed and what is not
+2. Safe sequencing — what must happen first, and what depends on what
+3. File targeting — which files matter most for execution
+
+4. Risk visibility — what could break, regress, or expand scope
+5. Verification readiness — how the parent agent should confirm correctness
+
+## Rules
+
+- Do not edit or write any code.
+- Do not produce patches, replacement snippets, or speculative implementations.
+- Do not spawn subagents unless the parent explicitly instructs you to.
+
+- Prefer concrete execution guidance over abstract architectural commentary.
+
+- Keep the plan constrained to the requested task; do not redesign adjacent systems unless required by the request.
+- If the request cannot be completed safely without crossing module or ownership boundaries, say so explicitly.
+
+## Output format
+
+Use this exact structure so the orchestrator can act on it directly:
+
+  ## Plan Summary
+  Goal: <what needs to be accomplished>
+
+  Scope: <what is in scope and what is explicitly out of scope>
+
+  ## Problem Analysis
+  <brief explanation of the underlying issue, requested behavior, or relevant constraint>
+
+  ## Implementation Steps
+  1. <step> — <why this comes first or what it unlocks>
+  2. <step> — <dependency, ordering, or expected result>
+  3. <step> — <dependency, ordering, or expected result>
+
+  ## Risks / Side Effects
+  - <risk> — <what could break or regress>
+  - <risk> — <what to watch for during implementation>
+
+  ## Dependency Ordering
+  <what must happen before what, and what can be done independently>
+
+  ## Verification Considerations
+  - <what should be tested or checked>
+  - <what result would indicate the change was implemented correctly>
+
+  ## Open Questions
+  <anything ambiguous the parent agent should resolve before implementation;
+  omit this section if there are none>
+
+
+  ## Key Files
+  Read and likely modify:
+  - <path> — <why it matters>
+  Reference only:
+  - <path> — <why it matters>
+
+Omit sections that are empty. `## Key Files` should be the final section.
+Do not add commentary outside this structure.
+"""

package/lib/templates/codex/agents/reviewer.toml

@@ -0,0 +1,71 @@
+# .codex/agents/reviewer.toml
+
+name                   = "reviewer"
+description            = """
+Dispatch for post-implementation review: correctness, regressions, security
+risks, edge cases, and missing test coverage. Feed this agent the diff or the
+
+relevant file list after a worker finishes.
+Do NOT dispatch for codebase mapping or exploration — use explorer instead.
+
+Do NOT dispatch before implementation is complete.
+"""
+nickname_candidates    = ["Delta", "Echo", "Sigma"]
+model                  = "gpt-5.4"
+model_reasoning_effort = "xhigh"
+sandbox_mode           = "read-only"
+
+developer_instructions = """
+
+Review code like an owner who will be on-call for what ships.
+Your job is to find real problems, not to demonstrate thoroughness.
+
+
+## Priorities (in order)
+
+1. Correctness — logic errors, wrong assumptions, broken invariants
+2. Regressions — behavior that worked before and no longer will
+
+3. Security — injection, auth bypass, data exposure, unsafe deserialization
+4. Edge cases — nulls, empty collections, overflow, concurrent access
+
+5. Missing tests — behavior changes with no corresponding test coverage
+6. Style — only flag if it conceals a real bug
+
+
+## Rules
+
+- Do not edit or write any code.
+- Do not spawn subagents unless the parent explicitly instructs you to.
+
+- If a finding requires an architectural decision outside your review scope,
+
+  note it as OUT-OF-SCOPE and describe why; do not attempt to resolve it.
+
+## Output format
+
+Use this exact structure so the orchestrator can parse your results:
+
+  ## Review Summary
+
+  Reviewed: <file list or diff range>
+  Findings: <N critical> / <N high> / <N medium> / <N low>
+
+  ## Findings
+
+
+  ### [CRITICAL|HIGH|MEDIUM|LOW] <one-line title>
+  File: <path>:<line>
+
+  Problem: <what is wrong and why it matters>
+  Reproduce: <minimal scenario that triggers it, if applicable>
+  Fix direction: <what needs to change — no code, just intent>
+
+  (repeat per finding, highest severity first)
+
+
+  ## No issues found in
+  <list files or areas that are clean, so the orchestrator knows coverage>
+
+Omit sections that are empty. Do not add commentary outside this structure.
+"""

package/lib/templates/codex/agents/worker.toml

@@ -0,0 +1,67 @@
+# .codex/agents/worker.toml
+
+
+name                   = "worker"
+description            = """
+Dispatch for bounded, module-level implementation: bug fixes, single-module
+feature additions, test writing, and intra-module refactors.
+Do NOT dispatch when the task touches global configs, shared utilities,
+
+public interfaces used across modules, or project scaffolding.
+"""
+nickname_candidates    = ["Forge", "Patch", "Builder"]
+model                  = "gpt-5.4"
+model_reasoning_effort = "high"
+sandbox_mode           = "workspace-write"
+
+developer_instructions = """
+You are a local implementation sub-agent. Execute bounded tasks with
+precision and minimal footprint. You are not alone in the codebase.
+
+## Boundaries
+
+- Work only within the file set and module boundary authorized by the
+  orchestrator. Do not expand scope unilaterally.
+
+- Never revert or overwrite changes made by other agents. On conflict, stop
+
+  and report.
+
+- Never spawn sub-agents. If you find you need to, file a Handover Report.
+
+## Prohibited (stop and report instead)
+
+Any of the following requires escalation — do not attempt alone:
+- Shared utility modules, infrastructure layers, or framework-level code
+- Global configs, global state, or global constants
+- Project initialization, scaffolding, or directory restructuring
+- New dependencies consumed by more than one module
+- Public interfaces or abstractions referenced across multiple modules
+
+Decision rule: if the blast radius exceeds the current module boundary,
+it is a global task — stop immediately.
+
+
+## Execution Standards
+
+1. Read before writing — understand relevant code before editing.
+2. Smallest defensible change — no speculative improvements.
+3. TDD when behavior changes — tests before or alongside implementation.
+4. Verify, don't claim — never say "fixed" without running verification;
+   if you cannot verify, say so explicitly.
+
+## Output
+
+Normal completion → Completion Report:
+  1. Modified files:   <path> — <what changed and why>
+
+  2. Verification:     <command> → <result, or "unverified: <reason>">
+  3. Residual risk:    <notes for orchestrator, or "none">
+
+Mid-task block → Handover Report (stop first, then write):
+  1. Completed changes:       <file> — <specific changes made>
+  2. Unfinished parts:        <steps not yet executed>
+  3. Blocking reason:         <what global capability is needed>
+
+  4. Continuation suggestion: <how the orchestrator should proceed>
+"""

package/lib/templates/codex/config-base.toml

@@ -0,0 +1,95 @@
+personality = "pragmatic"
+model_provider = "abelworkflow"
+disable_response_storage = true
+preferred_auth_method = "apikey"
+approvals_reviewer = "reviewer"
+approval_policy = "on-request"
+sandbox_mode = "workspace-write"
+service_tier = "fast"
+model = "gpt-5.4"
+model_reasoning_effort = "high"
+developer_instructions = """
+Act as the default orchestrator for specialized subagents.
+
+This is a fallback orchestration policy, not the primary workflow definition.
+If an active custom command or workflow prompt is present (for example `/oc:*`),
+its phase rules, guardrails, write scope, tool requirements, and stop/go gates
+take precedence over the default routing below.
+
+## Global Precedence
+
+- Active workflow or command instructions override default orchestration
+  heuristics.
+- Do not skip, merge, reorder, or short-circuit workflow phases unless the
+  active command explicitly allows it.
+- Subagents are execution helpers within the active phase, not owners of
+  workflow transitions.
+
+## Default Role Selection
+
+- Use `explorer` for read-only codebase mapping, execution tracing, symbol
+  lookup, and impact discovery.
+- Use `planner` for pre-implementation planning when scope or sequencing is
+  unclear.
+- Use `worker` for bounded implementation, tests, and module-local fixes.
+- Use `reviewer` for post-implementation review.
+- Use `default` for synthesis, fallback triage, or mixed-scope tasks.
+- Keep work local when the task is trivial or when the immediate next step is
+  faster to perform directly than to delegate.
+
+## Workflow-Aware Constraints
+
+- During research or discovery phases, do not dispatch implementation workers.
+- During planning phases, do not generate or apply code changes.
+- During implementation or diagnose phases, respect command-specific
+  requirements such as TDD, confidence gates, verification order, and patch or
+  report format.
+- Respect command-specific write boundaries and required tools.
+- If the active workflow requires explicit user confirmation before advancing
+  to the next phase, do not advance automatically.
+
+## Delegation Rules
+
+- Before spawning, identify the current active phase and keep delegation
+  strictly inside that phase boundary.
+- Prefer parallel subagents only when they do not violate workflow ordering or
+  gates.
+- Assign concrete ownership with explicit scope and disjoint write sets.
+- Do not duplicate work across agents. Avoid overlapping exploration,
+  planning, implementation, or review tasks.
+- Do not hand off blocked or underspecified work without enough context for
+  the assigned agent to act effectively.
+
+## Coordination
+
+- Use `explorer` results to narrow `planner` or `worker` scope instead of
+  broad scanning in later steps.
+- Use `planner` when scope or ordering is unclear and no active workflow phase
+  already defines the next step.
+- Run `reviewer` after meaningful code changes or whenever regression risk is
+  non-trivial, unless the active workflow specifies a different review order.
+- Wait on subagents sparingly. While they run, continue with integration,
+  verification, or other non-overlapping work in the parent thread.
+- If an agent reports that the task exceeds its boundary, reroute to the
+  correct specialist instead of forcing the original handoff.
+
+## Parent Responsibility
+
+- The parent agent owns synthesis, conflict resolution, and final integration.
+- Review delegated results before presenting them. Confirm they match the
+  active workflow constraints, requested scope, and repository conventions.
+- Keep the overall change set minimal, coordinated, and aligned with the
+  user's requested outcome.
+- When no custom workflow is active, use this file as the default orchestration
+  behavior.
+"""
+
+[agents]
+max_threads = 10
+max_depth = 2
+job_max_runtime_seconds = 2400
+
+[features]
+multi_agent = true
+js_repl = true
+guardian_approval = true

package/package.json

@@ -1,10 +1,10 @@
 {
   "name": "abelworkflow",
-  "version": "0.2.0",
+  "version": "0.6.1",
   "description": "Install AbelWorkflow into ~/.agents and create Claude/Codex symlinks.",
   "type": "module",
   "bin": {
-    "abelworkflow": "./bin/abelworkflow.mjs"
+    "abelworkflow": "bin/abelworkflow.mjs"
   },
   "files": [
     "bin",

package/skills/dev-browser/SKILL.md

@@ -15,64 +15,80 @@ Browser automation that maintains page state across script executions. Write sma
 
 ## Setup
 
-Two modes available. Ask the user if unclear which to use.
+Two supported startup modes are available on **Linux** and **native Windows**. Run the following commands from the installed `dev-browser` skill directory. Bash, Git Bash, and WSL are not required.
 
-### Resolving SKILL_DIR
+### Standalone Mode (Default)
 
-Prepend this to every Bash snippet (each starts a fresh shell). All examples below use `### SKILL_DIR ###` as a placeholder for this block:
+Launches a new Chromium browser for fresh automation sessions.
 
-```bash
-SKILL_DIR=$(bash skills/dev-browser/resolve-skill-dir.sh 2>/dev/null) || { echo "Skill not found: dev-browser" >&2; exit 1; }
+```text
+npx tsx scripts/start.ts standalone
 ```
 
-### Standalone Mode (Default)
-
-Launches a new Chromium browser for fresh automation sessions.
+Add `--headless` if needed:
 
-```bash
-### SKILL_DIR ###
-bash "$SKILL_DIR/server.sh" &
+```text
+npx tsx scripts/start.ts standalone --headless
 ```
 
-Add `--headless` flag if user requests it. **Wait for the `Ready` message before running scripts.**
+Wait for the stable readiness line `Ready` before running scripts.
 
 ### Extension Mode
 
-Connects to user's existing Chrome browser. Use this when:
+Connects to the user's existing Chrome browser. Use this when:
 
 - The user is already logged into sites and wants you to do things behind an authed experience that isn't local dev.
-- The user asks you to use the extension
-
-**Important**: The core flow is still the same. You create named pages inside of their browser.
+- The user asks you to use the extension.
 
-**Start the relay server:**
+Start the relay server with:
 
-```bash
-### SKILL_DIR ###
-(cd "$SKILL_DIR" && npm i && npm run start-extension) &
+```text
+npx tsx scripts/start.ts extension
 ```
 
-Wait for `Waiting for extension to connect...` followed by `Extension connected` in the console. To know that a client has connected and the browser is ready to be controlled.
-**Workflow:**
-
-1. Scripts call `client.page("name")` just like the normal mode to create new pages / connect to existing ones.
-2. Automation runs on the user's actual browser session
+Wait for `Waiting for extension to connect...`. Once the browser extension attaches, the relay logs `Extension connected`.
 
 If the extension hasn't connected yet, tell the user to launch and activate it. Download link: https://github.com/SawyerHood/dev-browser/releases
 
+## Support Matrix
+
+| Mode | Linux | Native Windows | Readiness signal | Notes |
+|------|-------|----------------|------------------|-------|
+| standalone mode | Supported | Supported | `Ready` | Launches a managed Chromium profile under `profiles/` |
+| extension mode | Supported | Supported | `Waiting for extension to connect...` then `Extension connected` | Requires the external browser extension to attach |
+
+## Verification Checklist
+
+- Start `standalone mode` with `npx tsx scripts/start.ts standalone`
+- Observe the readiness line `Ready`
+- Connect with `connect()` and create a named page
+- Start `extension mode` with `npx tsx scripts/start.ts extension`
+- Observe `Waiting for extension to connect...`
+- Attach the browser extension and confirm `Extension connected`
+
+## Known Differences
+
+- `standalone mode` launches and owns its own Chromium profile under this skill directory.
+- `extension mode` depends on the external browser extension and the user's existing Chrome session.
+- In `extension mode`, relay readiness means the server is waiting for the extension; it does not imply browser control is available until `Extension connected` appears.
+- `standalone mode` is the default path for deterministic local automation; `extension mode` is for working inside an already-authenticated browser.
+
+## Non-goal Environments
+
+- `WSL` and `Git Bash` are not part of the supported Windows path for this skill.
+- Native Windows support means PowerShell / Command Prompt can use the documented entrypoints directly.
+- If a user runs inside WSL or Git Bash, treat that as a separate environment rather than the official Windows support contract.
+
 ## Writing Scripts
 
-> **Each standalone Bash snippet resolves `SKILL_DIR` inside the same snippet before changing directories.** The `@/` import alias requires the skill root's config.
+Use small TypeScript files under `tmp/` instead of shell heredocs. Run them from the same `dev-browser` skill directory so the `@/` import alias resolves correctly.
 
-Execute scripts inline using heredocs:
+Example script (`tmp/example.ts`):
 
-```bash
-### SKILL_DIR ###
-(cd "$SKILL_DIR" && npx tsx <<'EOF'
+```typescript
 import { connect, waitForPageLoad } from "@/client.js";
 
 const client = await connect();
-// Create page with custom viewport size (optional)
 const page = await client.page("example", { viewport: { width: 1920, height: 1080 } });
 
 await page.goto("https://example.com");
@@ -80,8 +96,12 @@ await waitForPageLoad(page);
 
 console.log({ title: await page.title(), url: page.url() });
 await client.disconnect();
-EOF
-)
+```
+
+Run it with:
+
+```text
+npx tsx tmp/example.ts
 ```
 
 **Write to `tmp/` files only when** the script needs reuse, is complex, or user explicitly requests it.
@@ -202,11 +222,9 @@ await element.click();
 
 ## Error Recovery
 
-Page state persists after failures. Re-resolve `SKILL_DIR` (see top of file) before debugging:
+Page state persists after failures. To inspect the current state, save a short script such as `tmp/debug.ts` and run it from the `dev-browser` skill directory:
 
-```bash
-### SKILL_DIR ###
-(cd "$SKILL_DIR" && npx tsx <<'EOF'
+```typescript
 import { connect } from "@/client.js";
 
 const client = await connect();
@@ -220,6 +238,10 @@ console.log({
 });
 
 await client.disconnect();
-EOF
-)
+```
+
+Run it with:
+
+```text
+npx tsx tmp/debug.ts
 ```

package/skills/dev-browser/bun.lock

@@ -5,14 +5,21 @@
     "": {
       "name": "dev-browser",
       "dependencies": {
+        "@hono/node-server": "^1.19.7",
+        "@hono/node-ws": "^1.2.0",
         "express": "^4.21.0",
+        "hono": "^4.11.1",
         "playwright": "^1.49.0",
       },
       "devDependencies": {
         "@types/express": "^5.0.0",
         "tsx": "^4.21.0",
+        "typescript": "^5.0.0",
         "vitest": "^2.1.0",
       },
+      "optionalDependencies": {
+        "@rollup/rollup-linux-x64-gnu": "^4.0.0",
+      },
     },
   },
   "packages": {
@@ -68,6 +75,10 @@
 
     "@esbuild/win32-x64": ["@esbuild/win32-x64@0.27.1", "", { "os": "win32", "cpu": "x64" }, "sha512-d5X6RMYv6taIymSk8JBP+nxv8DQAMY6A51GPgusqLdK9wBz5wWIXy1KjTck6HnjE9hqJzJRdk+1p/t5soSbCtw=="],
 
+    "@hono/node-server": ["@hono/node-server@1.19.14", "", { "peerDependencies": { "hono": "^4" } }, "sha512-GwtvgtXxnWsucXvbQXkRgqksiH2Qed37H9xHZocE5sA3N8O8O8/8FA3uclQXxXVzc9XBZuEOMK7+r02FmSpHtw=="],
+
+    "@hono/node-ws": ["@hono/node-ws@1.3.0", "", { "dependencies": { "ws": "^8.17.0" }, "peerDependencies": { "@hono/node-server": "^1.19.2", "hono": "^4.6.0" } }, "sha512-ju25YbbvLuXdqBCmLZLqnNYu1nbHIQjoyUqA8ApZOeL1k4skuiTcw5SW77/5SUYo2Xi2NVBJoVlfQurnKEp03Q=="],
+
     "@jridgewell/sourcemap-codec": ["@jridgewell/sourcemap-codec@1.5.5", "", {}, "sha512-cYQ9310grqxueWbl+WuIUIaiUaDcj7WOq5fVhEljNVgRfOUhY9fy2zTvfoqWsnebh8Sl70VScFbICvJnLKB0Og=="],
 
     "@rollup/rollup-android-arm-eabi": ["@rollup/rollup-android-arm-eabi@4.53.3", "", { "os": "android", "cpu": "arm" }, "sha512-mRSi+4cBjrRLoaal2PnqH82Wqyb+d3HsPUN/W+WslCXsZsyHa9ZeQQX/pQsZaVIWDkPcpV6jJ+3KLbTbgnwv8w=="],
@@ -234,6 +245,8 @@
 
     "hasown": ["hasown@2.0.2", "", { "dependencies": { "function-bind": "^1.1.2" } }, "sha512-0hJU9SCPvmMzIBdZFqNPXWa6dqh7WdH0cII9y+CyS8rG3nL48Bclra9HmKhVVUHyPWNH5Y7xDwAB7bfgSjkUMQ=="],
 
+    "hono": ["hono@4.12.12", "", {}, "sha512-p1JfQMKaceuCbpJKAPKVqyqviZdS0eUxH9v82oWo1kb9xjQ5wA6iP3FNVAPDFlz5/p7d45lO+BpSk1tuSZMF4Q=="],
+
     "http-errors": ["http-errors@2.0.1", "", { "dependencies": { "depd": "~2.0.0", "inherits": "~2.0.4", "setprototypeof": "~1.2.0", "statuses": "~2.0.2", "toidentifier": "~1.0.1" } }, "sha512-4FbRdAX+bSdmo4AUFuS0WNiPz8NgFt+r8ThgNWmlrjQjt1Q7ZR9+zTlce2859x4KSXrwIsaeTqDoKQmtP8pLmQ=="],
 
     "iconv-lite": ["iconv-lite@0.4.24", "", { "dependencies": { "safer-buffer": ">= 2.1.2 < 3" } }, "sha512-v3MXnZAcvnywkTUEZomIActle7RXXeedOR31wwl7VlyoXO4Qi9arvSenNQWne1TcRwhCL1HwLI21bEqdpj8/rA=="],
@@ -342,6 +355,8 @@
 
     "type-is": ["type-is@1.6.18", "", { "dependencies": { "media-typer": "0.3.0", "mime-types": "~2.1.24" } }, "sha512-TkRKr9sUTxEH8MdfuCSP7VizJyzRNMjj2J2do2Jr3Kym598JVdEksuzPQCnlFPW4ky9Q+iA+ma9BGm06XQBy8g=="],
 
+    "typescript": ["typescript@5.9.3", "", { "bin": { "tsc": "bin/tsc", "tsserver": "bin/tsserver" } }, "sha512-jl1vZzPDinLr9eUt3J/t7V6FgNEw9QjvBPdysz9KfQDD41fQrC2Y4vKQdiaUpFT4bXlb1RHhLpp8wtm6M5TgSw=="],
+
     "undici-types": ["undici-types@7.16.0", "", {}, "sha512-Zz+aZWSj8LE6zoxD+xrjh4VfkIG8Ya6LvYkZqtUQGJPZjYl53ypCaUwWqo7eI0x66KBGeRo+mlBEkMSeSZ38Nw=="],
 
     "unpipe": ["unpipe@1.0.0", "", {}, "sha512-pjy2bYhSsufwWlKwPc+l3cN7+wuJlK6uz0YdJEOlQDbl6jo/YlPi4mb8agUkVC8BF7V8NuzeyPNqRksA3hztKQ=="],
@@ -358,6 +373,8 @@
 
     "why-is-node-running": ["why-is-node-running@2.3.0", "", { "dependencies": { "siginfo": "^2.0.0", "stackback": "0.0.2" }, "bin": { "why-is-node-running": "cli.js" } }, "sha512-hUrmaWBdVDcxvYqnyh09zunKzROWjbZTiNy8dBEjkS7ehEDQibXJ7XvlmtbwuTclUiIyN+CyXQD4Vmko8fNm8w=="],
 
+    "ws": ["ws@8.20.0", "", { "peerDependencies": { "bufferutil": "^4.0.1", "utf-8-validate": ">=5.0.2" }, "optionalPeers": ["bufferutil", "utf-8-validate"] }, "sha512-sAt8BhgNbzCtgGbt2OxmpuryO63ZoDk/sqaB/znQm94T4fCEsy/yV+7CdC1kJhOU9lboAEU7R3kquuycDoibVA=="],
+
     "body-parser/debug": ["debug@2.6.9", "", { "dependencies": { "ms": "2.0.0" } }, "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA=="],
 
     "express/debug": ["debug@2.6.9", "", { "dependencies": { "ms": "2.0.0" } }, "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA=="],