@organizaone/o1-code 0.2.2 → 0.3.0

package/bundled/commit/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: commit
-description: Turn the uncommitted changes in the current git repository into one commit per logical change, with messages in the repository's own style, asking for confirmation before each commit. Use when the user asks to commit their work, split changes into commits, or write commit messages. Usage - /commit, or /commit <what changed> to give the intent behind the changes. It only commits; it never pushes.
+description: "Use when the user asks to commit work or write commit messages: one commit per logical change, in the repository's style, confirmed one by one (/commit, /commit <what changed>). It never pushes."
 argument-hint: '[what changed, optional]'
 allowedTools:
   - run_shell_command

package/bundled/debugging/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: debugging
+description: Use when a test fails, an error appears, or behaviour differs from what is expected, before proposing or making a fix.
+---
+
+# Debugging
+
+Find the cause before changing code. A fix made without knowing the cause usually moves the symptom,
+and each guessed fix makes the next one harder to reason about.
+
+## 1. Reproduce and read
+
+- Read the whole error: message, stack trace, exit code, and the lines of output before it.
+- Reproduce it with one command you can run again. If it does not reproduce reliably, collect more
+  data (inputs, environment, timing) before going further; do not guess.
+- Check what changed recently: the diff, new dependencies, configuration, environment.
+
+## 2. Trace to the origin
+
+- Follow the bad value backwards from where it shows up to where it was first wrong. Fix it there, not
+  where it surfaced.
+- When the path crosses components (a CLI calling a library calling a database), check the data at each
+  boundary and find the first one where it is wrong.
+- `references/root-cause-tracing.md` has techniques for traces that are not obvious: temporary
+  logging with call stacks, finding which test pollutes shared state, waiting for conditions instead of
+  timing.
+
+## 3. Compare with something that works
+
+- Find similar code in the same project that behaves correctly, or the reference the code is meant to
+  follow, and read it completely.
+- List every difference between the working and the broken case, however small.
+
+## 4. One hypothesis at a time
+
+- State it before acting: "X causes Y because Z."
+- Test it with the smallest change or observation that could prove it wrong, one variable at a time.
+- If it is wrong, form a new hypothesis from what you learned. Do not stack another change on top of the
+  first.
+
+## 5. Fix at the cause
+
+- Write a test that reproduces the bug and fails (the `tdd` skill), then make one change at the cause.
+- Run the reproduction and the project's tests in the reach of the change.
+- Remove any temporary logging you added.
+
+## When fixes keep failing
+
+Follow the core rule for repeated failures: after the same fix fails twice, stop and re-read the
+relevant code top-down, saying where your understanding was wrong. When each fix reveals a new problem
+in a different place, the design is the likely cause: stop and bring the evidence to the user before
+another attempt, or, when no one can be asked, report it as the blocker.
+
+## Reporting
+
+Say what the cause was, the evidence that shows it (command and output), what you changed, and how you
+verified it. If you could not find the cause, say what you ruled out and what you would check next;
+do not present a workaround as a fix.

package/bundled/debugging/references/root-cause-tracing.md

@@ -0,0 +1,37 @@
+# Root-cause tracing
+
+## Trace backwards
+
+1. Note where the wrong value or behaviour is observed.
+2. Find the code that produced it and the input it received.
+3. Ask where that input came from, and repeat until you reach the first place the value is wrong.
+4. That place is the cause. Everything after it only carried the value along.
+
+When reading is not enough, add temporary instrumentation at each step: log the value together with a
+call stack (in JavaScript `new Error().stack`, in Python `traceback.format_stack()`), write it to
+stderr, and run the reproduction. Remove the instrumentation before finishing.
+
+## Check every boundary
+
+In a chain of components, log what enters and leaves each one in a single run. The first boundary where
+the data is wrong narrows the search to one component. This beats reading all the code when the chain
+is long or partly outside the project.
+
+## A test that fails only with others
+
+When a test passes alone and fails in the suite, another test is leaving state behind (a file, a
+database row, a global, an environment variable). Run the failing test together with halves of the
+suite that ran before it, keep the half that still fails, and repeat until one test remains. Then fix
+the cleanup in that test, not the victim.
+
+## Timing and flakiness
+
+A test or script that sleeps a fixed time and then checks a result fails on slow machines and wastes
+time on fast ones. Wait for the condition instead: poll it at a short interval, with an overall
+timeout and a message that says what was being waited for. Keep a fixed delay only when the behaviour
+itself is time-based (a debounce, a retry interval), and say so next to the delay.
+
+## Make it impossible, not just fixed
+
+After fixing the cause, check whether the same bad value can enter through another path. Validate where
+data enters the system, so that the next caller cannot reintroduce the bug.

package/bundled/design/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: design
+description: Use when about to build a feature, component or project, or change behaviour, and what to build and how is not settled yet.
+---
+
+# Design before building
+
+Settle what to build, and how, before writing product code. The amount of design scales with the
+task: a question gets a probe, a change to an existing flow gets a short design in the conversation, a
+new system gets a full design that becomes the plan.
+
+## 1. Classify the request, and say it
+
+Read the relevant code first. Then pick one path and tell the user which one, in one line:
+
+- **Spike**: the question is whether something is feasible or how something behaves.
+- **Bounded**: a well-scoped change to a flow that already exists in this project.
+- **Architectural**: a new project, subsystem, interface or data model, or a request that spans
+  several independent parts.
+
+When two paths could fit, take the heavier one. If the work turns out bigger than it looked, move up a
+path and say so; never move down in the middle of a task. A request that spans several independent
+parts is split: each part gets its own design, plan and implementation, one at a time.
+
+## 2. Understand the intent
+
+- Ask about the purpose before proposing features: what the user wants to achieve and for whom.
+- One question per message, with choices when the answers are predictable. Never ask what the code can
+  tell you.
+- Write back your understanding, separating what the user said from what you assume.
+- When the session cannot ask questions, state the assumptions you made and continue on them.
+
+## 3. Follow the path
+
+**Spike.** Describe the probe in two or three sentences, run it, and report a recommendation with the
+evidence. Anything you built for it is throwaway: say so, and do not present it as the implementation.
+
+**Bounded.** Present a short design in the conversation: what changes, where, what stays untouched, and
+how it will be tested. Wait for the user's approval, then implement it (with the `tdd` skill when the
+code has tests). No design document and no separate plan.
+
+**Architectural.**
+
+1. Propose two or three approaches with their trade-offs and say which one you recommend and why.
+2. Present the design in sections, each a few sentences to a short page depending on its weight:
+   components and their single responsibilities, interfaces between them, data flow, error handling,
+   and testing. Ask for approval after each section.
+3. Check the whole design once before the last approval: no placeholders, no contradictions between
+   sections, nothing in scope that was not asked for.
+4. Hand it to the `write-plan` skill. The approved design is the plan's source; when plan mode is active, the
+   plan is submitted there and the harness keeps it.
+
+## Approval covers only what was shown
+
+Approving an idea does not approve a design that has not been presented yet, and approving a design
+does not approve the plan. Each stage waits for its own yes. Read-only exploration needs no approval.
+
+A session that cannot ask questions (headless, or no one to answer) cannot wait for a yes: at each
+stage take the option you recommend, state it and the assumptions behind it in your report, and
+continue.
+
+## Keep it small
+
+Design only what the request needs. Leave out options, abstractions and features nobody asked for, and
+prefer units with one clear purpose that can be understood and tested on their own.

package/bundled/execute-plan/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: execute-plan
+description: Use when carrying out an approved implementation plan in this session, task by task.
+---
+
+# Executing a plan
+
+The plan already made the decisions. Carry them out in order, prove each task with its tests, and keep
+a record that survives your own forgetting.
+
+## Before the first task
+
+1. Read the whole plan once and note its global constraints.
+2. Workspace: if the user wants the work isolated from the current branch, create a worktree with the
+   worktree tool; ask once if the plan is large and they have not said. Do not create one on your own.
+3. Run the project's tests in the reach of the plan and note the result, so a later failure can be told
+   apart from one that was already there.
+4. Put one todo item per task in the todo list when the tool is available.
+
+## Each task
+
+1. Read the task again from the plan: what you remember is a summary.
+2. Follow its steps with the `tdd` skill: the test fails first for the stated reason, then passes.
+3. Compare every `Expected:` in the task with what you actually saw.
+4. Commit the task on its own, staging only its files (through `/commit`).
+5. Mark the todo item done.
+
+When the code does not behave as the plan says, use the `debugging` skill. When the plan itself is
+wrong or silent, decide, and record the decision as `Ruling: <what> — <why> — <cost if wrong>` in the
+todo item and in your final report. The requirements win over the plan; your judgement settles what
+neither answers.
+
+## When to stop
+
+Continue between tasks without asking. Stop and ask only for:
+
+- an irreversible or destructive action;
+- a security-sensitive action;
+- a side effect outside the workspace that is normally confirmed first (merge, push, publish);
+- a plan so broken that every way forward is a guess.
+
+## After the last task
+
+1. Run the project's build, lint and the tests in the reach of all tasks.
+2. Ask one fresh reviewer, with the agent tool, to review the whole change: give it the plan's location
+   or text, the global constraints, the review focus and the commit range, and ask for findings graded
+   critical, important or minor, with file and line.
+3. Fix critical and important findings in one pass, each with a test, and run the checks again. List
+   the minor ones.
+4. Report: what was built, the evidence that it works, every ruling you made, and the deferred minor
+   findings.

package/bundled/extension-creator/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: extension-creator
-description: Create, scaffold, customize, validate, and locally test O1-Code extensions. Use when the user wants a new O1-Code extension, needs help choosing an extension template, wants to add AGENTS.md context, commands, skills, agents, MCP servers, settings, hooks, or LSP servers, or asks how to link and test an extension locally. Invoke with `/extension-creator` followed by an extension path and optional template name.
+description: 'Use when the user wants to create, scaffold, customize, validate or locally test an O1-Code extension (context, commands, skills, agents, MCP servers, settings, hooks, LSP): /extension-creator <path> [template].'
 argument-hint: '<extension-path> [template]'
 allowedTools:
   - run_shell_command

package/bundled/finish/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: finish
-description: Close a unit of change in the current project - build, lint on the whole project, typecheck, the tests in the reach of the change, a documentation check and the version step when the project declares one - then report what ran and what did not. Use when the user says the work is done, asks to finish, wrap up, or verify a change before committing. Usage - /finish to check and report, /finish --fix to also fix what fails and sync the docs, /finish --full to run the full test suite as well. It stops before the commit and offers /commit.
+description: 'Use when the work is done and needs its closing checks (build, lint, typecheck, tests in reach, docs) before a commit: /finish to check and report, /finish --fix to also fix, /finish --full for the whole suite; it then offers /commit.'
 argument-hint: '[--fix] [--full]'
 allowedTools:
   - run_shell_command

package/bundled/goal-draft/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: goal-draft
-description: Turn a fuzzy intention into a /goal objective the Goal verifier can actually judge - one outcome, numbered binary "Done when" checks that leave evidence in the transcript, guardrails, a budget, and a block protocol. Use when the user wants to set or define a goal, asks whether a goal is good enough, or says "keep going until X". Usage - /goal-draft <what you want done>, or /goal-draft <existing goal> to tighten it. This skill only writes the objective; it never starts the work.
+description: 'Use when the user wants to set, define or check a Goal, or says "keep going until X": /goal-draft <intent or existing goal> writes an objective the verifier can judge; it never starts the work.'
 argument-hint: '[intent, or an existing goal to tighten]'
 allowedTools:
   - get_goal

package/bundled/new-app/SKILL.md

@@ -4,6 +4,8 @@ description: Workflow for creating new applications from scratch. Covers require
 when_to_use: When the user asks to create a new application, project, website, game, mobile app, CLI tool, or library from scratch.
 ---
 
+Load the `design` skill first: a new application is an architectural request, and that skill settles the requirements and the approach with the user. This skill adds the technology defaults and the delivery steps below.
+
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype. Utilize all tools at your disposal to implement the application. Some tools you may especially find useful are 'write_file', 'edit' and 'run_shell_command'.
 
 1. **Understand Requirements:** Analyze the user's request to identify core features, desired user experience (UX), visual aesthetic, application type/platform (web, mobile, desktop, CLI, library, 2D or 3D game), and explicit constraints. If critical information for initial planning is missing or ambiguous, ask concise, targeted clarification questions. Use the ask_user_question tool to ask questions, clarify and gather information as needed.

package/bundled/review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: review
-description: Review changed code for correctness, security, code quality, and performance. Use when the user asks to review code changes, a PR, or specific files. Invoke with `/review`, `/review <pr-number>`, `/review <file-path>`, `/review <pr-number> --comment` to post inline comments on the PR, `/review --fix` to apply the findings to your working tree, or `/review <pr-number> --resume` to continue an interrupted review of that PR instead of starting over. Add `--effort low|medium|high` to trade depth for speed (defaults to high for PRs, medium for local changes). Add `--topology minimal` to run the single-pass A/B comparison arm instead of the pipeline.
+description: Use when the user asks to review code changes, a pull request or specific files for correctness, security, quality and performance; --comment posts the findings to the PR and --fix applies them.
 argument-hint: '[pr-number|file-path] [--effort low|medium|high] [--severity-floor critical|suggestion] [--topology minimal] [--comment] [--fix] [--resume]'
 allowedTools:
   - task

package/bundled/tdd/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: tdd
+description: Use when implementing a feature or fixing a bug in code that has, or can have, automated tests, before writing the implementation.
+---
+
+# Test-driven development
+
+Write the test first, watch it fail for the reason you expect, then write the smallest code that makes
+it pass. A test you never saw fail may be testing nothing: it can pass because of a typo, a wrong
+import, or behaviour that already existed.
+
+## The cycle
+
+Repeat for each behaviour, one at a time:
+
+1. **Red.** Write one test for the next behaviour, named after what it proves. Run it and read the
+   output. It must fail, and fail on the assertion you wrote, not on an import error or a typo. If it
+   passes, either the behaviour already exists or the test is wrong: find out which before going on.
+2. **Green.** Write the least code that makes that test pass. No extra options, branches or cleanup
+   the test does not ask for.
+3. **Check.** Run the project's tests in the reach of the change (the file you touched and the tests
+   of its callers), not only the new test. Everything must pass, with no new warnings in the output.
+4. **Refactor.** Improve names and structure with the tests green, and run them again.
+
+For a bug fix, the first test reproduces the bug: it fails today with the symptom the user reported.
+It then stays as the regression test.
+
+## When the code came first
+
+If implementation code already exists without a test (yours from earlier in this task, or the user's),
+do not delete it. Write the test now, then prove it can fail: temporarily undo only your own change
+(or break the branch the test covers), run the test, see it fail, restore, and run it again green. A
+test that stays green with the behaviour removed proves nothing.
+
+## When this does not apply
+
+Say so in one line and continue without the cycle when:
+
+- the user asked for a throwaway prototype or a spike;
+- the change is configuration, generated code, or documentation only;
+- the project has no test setup and the user does not want one added.
+
+In every other case, missing tooling is part of the task: find the project's test command (README,
+package or build configuration, existing tests) before writing code. Never assume a standard command.
+
+## Good tests
+
+Read `references/good-tests.md` before writing the first test of the task. In short: each test names
+the break it catches, exercises the real code rather than a mock of it, and derives its expected value
+independently of the implementation.
+
+## Reporting
+
+In the final message, for each behaviour or at least for the task, give the evidence of the cycle:
+the command you ran, that it failed first and why, and the passing run after the change. If you
+skipped the cycle, say which exception applied.

package/bundled/tdd/references/good-tests.md

@@ -0,0 +1,37 @@
+# Good tests
+
+Two questions decide whether a test is worth keeping: what break does it catch, and would it notice if
+the real code stopped working?
+
+## Each test names the break it catches
+
+- Name the test after the behaviour and the condition: `rejects a blank title`, `lists done tasks
+last`, not `test_add_2`.
+- One behaviour per test. When it fails, the name alone should tell the reader what broke.
+- Before writing the body, say which wrong implementation would make it fail: a wrong constant, a
+  missing branch, a missing side effect, an empty return, a skipped validation. If none would, the test
+  is not needed.
+
+## Each test exercises the real thing
+
+- Drive the code the way its users do: call the public function, run the command, send the request.
+- Mock only what you do not own or cannot run in a test (a network service, the clock, randomness),
+  and at the boundary where your code meets it. A mock earns no assertions of its own: asserting that
+  a mock was called with what you just configured it to return tests the mock.
+- Use real data shapes. A fixture missing fields the real data has hides the bugs those fields cause.
+
+## Expected values come from outside the code
+
+- Work the expected value out from the requirement, not by running the code and pasting what it
+  printed.
+- Do not assert on implementation constants (`MAX_RETRIES == 5`) or on the exact text of a source file:
+  that proves the source is the source.
+
+## Keep the suite honest
+
+- A test must be able to fail. After writing it, break the code once (or check it against the code
+  without your change) and watch it go red.
+- Clean up what the test creates (files, databases, environment variables) inside the test or its
+  fixture, so tests pass in any order.
+- A flaky test is a defect: wait for the condition the test depends on, with a timeout, instead of
+  sleeping a fixed time.

package/bundled/write-plan/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: write-plan
+description: Use when requirements or a design are agreed for multi-step work and a written implementation plan is needed before editing code.
+---
+
+# Writing an implementation plan
+
+A plan records the decisions an implementer cannot make alone: which files, which names and
+signatures, which values from the requirements, and which tests prove each task. Write it for an
+engineer who knows the language well but has not seen this codebase or this conversation. A plan
+longer than the code it describes has written the code instead of deciding it.
+
+## Structure
+
+```markdown
+# <Feature> implementation plan
+
+Goal: <one sentence>
+Approach: <two or three sentences>
+
+## Global constraints
+
+<one line each: requirements that hold for every task, with exact values>
+
+## Review focus
+
+<the input classes or failure modes most likely to break this work>
+
+## Files
+
+<each file created or changed, and its one responsibility>
+
+### Task 1: <component>
+
+Files: create/modify <paths>; test <path>
+Interfaces: consumes <names and signatures from earlier tasks>; produces <names and signatures>
+
+- [ ] Write the failing test for <behaviour>. Run `<command>`. Expected: fails with <reason>.
+- [ ] Implement <what>, in <file>, with <signature>.
+- [ ] Run `<command>`. Expected: <passing output>.
+- [ ] Commit.
+```
+
+## Rules for tasks and steps
+
+- A task is the smallest unit with its own test cycle that a reviewer could accept or reject on its
+  own. Fold setup, configuration and documentation into the task that needs them.
+- A step is one action with a result that can be checked. A step is complete when the implementer can
+  do exactly one reasonable thing from it: exact paths, exact commands, exact values from the
+  requirements. Leave the bodies of functions to the implementer.
+- Names and types used across tasks appear in the Interfaces lines, so each task can be read alone.
+- Order tasks so that each one leaves the project building and its tests passing.
+
+## Check the plan before handing it over
+
+1. Every requirement maps to at least one task.
+2. No placeholder is left ("TBD", "handle errors", "add tests").
+3. A name is spelled the same in every task that uses it.
+4. The review focus is filled in, or says you checked and found nothing.
+5. The plan is shorter than the code it describes.
+
+## Hand-off
+
+When plan mode is active, submit the plan through plan mode; the harness keeps the approved plan.
+Otherwise present it in the conversation and wait for approval. Then offer the two ways to run it:
+task by task in this session with the `execute-plan` skill, or unattended as a Goal (`/goal`).

package/chunks/{MaxSizedBox-5SCM5KM2.js → MaxSizedBox-GF25YEIN.js}

@@ -14,36 +14,36 @@ import "./chunk-PJF3WRYZ.js";
 import "./chunk-F5IN4KK7.js";
 import "./chunk-ZCZKKAIG.js";
 import "./chunk-EDRKBK4B.js";
-import "./chunk-7JU2ULBO.js";
+import "./chunk-FWXUI7DZ.js";
 import "./chunk-MYMATZAY.js";
 import "./chunk-6IFQXZTP.js";
 import "./chunk-YO3SEHXM.js";
-import "./chunk-FJAC7QWS.js";
+import "./chunk-QUMGEZV4.js";
 import "./chunk-P7UNPKJM.js";
 import "./chunk-KXN7Q6SB.js";
-import "./chunk-JASYFKBU.js";
+import "./chunk-UXN7KJEI.js";
 import "./chunk-YIEC5SIW.js";
 import "./chunk-4JDEAIW5.js";
 import "./chunk-TIYFDYIF.js";
-import "./chunk-POMHQTHO.js";
-import "./chunk-UVUHDO2Y.js";
+import "./chunk-NNVR5V2I.js";
+import "./chunk-VNMKY2V3.js";
 import "./chunk-NWCDFCWK.js";
 import "./chunk-ZMZRVR62.js";
-import "./chunk-GY77YVM3.js";
+import "./chunk-JBMSEZDI.js";
 import "./chunk-AQVYFR7E.js";
-import "./chunk-V2R5TAQQ.js";
-import "./chunk-5PY64ILO.js";
+import "./chunk-UUNTJ2TR.js";
+import "./chunk-VKFY6KJC.js";
 import "./chunk-F3FKDGHN.js";
-import "./chunk-4OKN67QV.js";
+import "./chunk-C6LFEUFU.js";
 import "./chunk-UBWL27PO.js";
 import "./chunk-BWRP5ZMP.js";
 import "./chunk-DM6W2QYB.js";
 import "./chunk-UAACCQBD.js";
 import "./chunk-GVWQRVLV.js";
 import "./chunk-2QYMJSSC.js";
-import "./chunk-O7LSTDIS.js";
+import "./chunk-SGW7DY4F.js";
 import "./chunk-AVCUVYSA.js";
-import "./chunk-X62LTOGE.js";
+import "./chunk-TNQJ66S4.js";
 import "./chunk-FNALBCC7.js";
 import "./chunk-BZOAEOYF.js";
 import "./chunk-BIDB75DA.js";
@@ -57,13 +57,13 @@ import "./chunk-MZI6FDZT.js";
 import "./chunk-4MSX3ERA.js";
 import "./chunk-YGG52IIN.js";
 import "./chunk-EP7GGUVV.js";
-import "./chunk-Q5D3WECC.js";
+import "./chunk-3YCUO772.js";
 import "./chunk-EXWAECKM.js";
 import "./chunk-S2LBLNBW.js";
 import "./chunk-ZZVIBILR.js";
 import "./chunk-OI7IVUEO.js";
 import "./chunk-DS3COGEF.js";
-import "./chunk-NVKVO57S.js";
+import "./chunk-IFBW6FYH.js";
 import "./chunk-OBPGYMIV.js";
 import "./chunk-RS2LNQEC.js";
 import "./chunk-SYMKXR42.js";
@@ -81,20 +81,20 @@ import "./chunk-GUMLL5KC.js";
 import "./chunk-HPQNI3OQ.js";
 import "./chunk-3XCL57IX.js";
 import "./chunk-YCZXGP63.js";
-import "./chunk-NIYI5272.js";
+import "./chunk-QPGBAI7B.js";
 import "./chunk-CI2ZHR5C.js";
-import "./chunk-46QWU5NF.js";
+import "./chunk-4JQ6AGCG.js";
 import "./chunk-ZFZB6WC5.js";
 import "./chunk-4J6KRUQB.js";
 import "./chunk-QFQQICSQ.js";
 import "./chunk-I7XXUDXZ.js";
 import "./chunk-KQAVEXYD.js";
 import "./chunk-HLWXBJCH.js";
-import "./chunk-T6BNDNKW.js";
+import "./chunk-COABCWBY.js";
 import "./chunk-IO32UWHY.js";
 import "./chunk-OSMXNPJP.js";
 import "./chunk-HX6AICAX.js";
-import "./chunk-X2HM423P.js";
+import "./chunk-G4NGNKM6.js";
 import "./chunk-PPR5SHEF.js";
 import "./chunk-FOZEB37P.js";
 import "./chunk-BQAZCJF7.js";
@@ -102,12 +102,12 @@ import "./chunk-65B6QBMP.js";
 import "./chunk-4OCNSFYL.js";
 import "./chunk-O4IWNFDK.js";
 import "./chunk-NGE3GHMN.js";
-import "./chunk-L7A4D4IY.js";
+import "./chunk-ZNNZZ4BW.js";
 import "./chunk-WMJL2XAM.js";
 import "./chunk-CP63SY5N.js";
-import "./chunk-RQOEQ73K.js";
+import "./chunk-4NV74I76.js";
 import "./chunk-POHJY7RJ.js";
-import "./chunk-3WHURT5H.js";
+import "./chunk-RYKMFNWC.js";
 import "./chunk-242JUBPM.js";
 import "./chunk-E4BNWSC7.js";
 import "./chunk-5P5ZJMW2.js";
@@ -121,7 +121,7 @@ import "./chunk-R7FX7HIR.js";
 import "./chunk-FFUKRRCR.js";
 import "./chunk-23AFREUQ.js";
 import "./chunk-HOPKSSYR.js";
-import "./chunk-J6YVMK2F.js";
+import "./chunk-LVFKSBH3.js";
 import "./chunk-PLWOHBC7.js";
 import "./chunk-LEXKU5FI.js";
 import "./chunk-IQEM74QW.js";