@jkwd/inbase 0.1.21 → 0.1.22

package/skill/commands/lime.md

@@ -0,0 +1,23 @@
+---
+description: Attach this chat to the Lime Inbase session
+---
+
+The user invoked `/lime`. Attach this chat to the **Lime** Inbase session, not the next empty slot.
+
+Do **not** ask for a session id. Do **not** run `inbase start-session`.
+
+1. Attach to the Lime session:
+
+```bash
+npx inbase attach --color lime
+```
+
+If attach fails with `VISUAL_CODER_NOT_RUNNING`, `VISUAL_CODER_CHAT_LIMIT`, `VISUAL_CODER_COLOR_BUSY`, or `VISUAL_CODER_COLOR_UNKNOWN`, reply with that message and stop.
+
+2. Read `VISUAL_CODER_SESSION` from the output. That id is the session to use for every later `inbase` command.
+
+3. Continue the Inbase visual edits skill from `wait-for-blueprint` onward with that `--session` id. Attach already started the session. `wait-for-blueprint` only reads the optional blueprint, instruction, and attached files; it does not wait.
+
+The user's request is:
+
+$ARGUMENTS

package/skill/commands/orange.md

@@ -0,0 +1,23 @@
+---
+description: Attach this chat to the Orange Inbase session
+---
+
+The user invoked `/orange`. Attach this chat to the **Orange** Inbase session, not the next empty slot.
+
+Do **not** ask for a session id. Do **not** run `inbase start-session`.
+
+1. Attach to the Orange session:
+
+```bash
+npx inbase attach --color orange
+```
+
+If attach fails with `VISUAL_CODER_NOT_RUNNING`, `VISUAL_CODER_CHAT_LIMIT`, `VISUAL_CODER_COLOR_BUSY`, or `VISUAL_CODER_COLOR_UNKNOWN`, reply with that message and stop.
+
+2. Read `VISUAL_CODER_SESSION` from the output. That id is the session to use for every later `inbase` command.
+
+3. Continue the Inbase visual edits skill from `wait-for-blueprint` onward with that `--session` id. Attach already started the session. `wait-for-blueprint` only reads the optional blueprint, instruction, and attached files; it does not wait.
+
+The user's request is:
+
+$ARGUMENTS

package/skill/commands/purple.md

@@ -0,0 +1,23 @@
+---
+description: Attach this chat to the Violet (purple) Inbase session
+---
+
+The user invoked `/purple`. Attach this chat to the **Violet** Inbase session, not the next empty slot.
+
+Do **not** ask for a session id. Do **not** run `inbase start-session`.
+
+1. Attach to the Violet session:
+
+```bash
+npx inbase attach --color purple
+```
+
+If attach fails with `VISUAL_CODER_NOT_RUNNING`, `VISUAL_CODER_CHAT_LIMIT`, `VISUAL_CODER_COLOR_BUSY`, or `VISUAL_CODER_COLOR_UNKNOWN`, reply with that message and stop.
+
+2. Read `VISUAL_CODER_SESSION` from the output. That id is the session to use for every later `inbase` command.
+
+3. Continue the Inbase visual edits skill from `wait-for-blueprint` onward with that `--session` id. Attach already started the session. `wait-for-blueprint` only reads the optional blueprint, instruction, and attached files; it does not wait.
+
+The user's request is:
+
+$ARGUMENTS

package/skill/commands/red.md

@@ -0,0 +1,23 @@
+---
+description: Attach this chat to the Coral (red) Inbase session
+---
+
+The user invoked `/red`. Attach this chat to the **Coral** Inbase session, not the next empty slot.
+
+Do **not** ask for a session id. Do **not** run `inbase start-session`.
+
+1. Attach to the Coral session:
+
+```bash
+npx inbase attach --color red
+```
+
+If attach fails with `VISUAL_CODER_NOT_RUNNING`, `VISUAL_CODER_CHAT_LIMIT`, `VISUAL_CODER_COLOR_BUSY`, or `VISUAL_CODER_COLOR_UNKNOWN`, reply with that message and stop.
+
+2. Read `VISUAL_CODER_SESSION` from the output. That id is the session to use for every later `inbase` command.
+
+3. Continue the Inbase visual edits skill from `wait-for-blueprint` onward with that `--session` id. Attach already started the session. `wait-for-blueprint` only reads the optional blueprint, instruction, and attached files; it does not wait.
+
+The user's request is:
+
+$ARGUMENTS

package/skill/commands/skipinbase.md

@@ -2,7 +2,7 @@
 description: Bypass Inbase and do the request directly in this chat
 ---
 
-The user invoked `/skipinbase`. Do **not** start or attach an Inbase visual session. Do **not** print the "direct chat interaction not allowed" message.
+The user invoked `/skipinbase`. Do **not** start or attach an Inbase visual session.
 
 Fulfill this request directly, without the Inbase plan/patch loop:
 

package/skill/commands/violet.md

@@ -0,0 +1,23 @@
+---
+description: Attach this chat to the Violet Inbase session
+---
+
+The user invoked `/violet`. Attach this chat to the **Violet** Inbase session, not the next empty slot.
+
+Do **not** ask for a session id. Do **not** run `inbase start-session`.
+
+1. Attach to the Violet session:
+
+```bash
+npx inbase attach --color violet
+```
+
+If attach fails with `VISUAL_CODER_NOT_RUNNING`, `VISUAL_CODER_CHAT_LIMIT`, `VISUAL_CODER_COLOR_BUSY`, or `VISUAL_CODER_COLOR_UNKNOWN`, reply with that message and stop.
+
+2. Read `VISUAL_CODER_SESSION` from the output. That id is the session to use for every later `inbase` command.
+
+3. Continue the Inbase visual edits skill from `wait-for-blueprint` onward with that `--session` id. Attach already started the session. `wait-for-blueprint` only reads the optional blueprint, instruction, and attached files; it does not wait.
+
+The user's request is:
+
+$ARGUMENTS

package/skill/commands/yellow.md

@@ -0,0 +1,23 @@
+---
+description: Attach this chat to the Amber (yellow) Inbase session
+---
+
+The user invoked `/yellow`. Attach this chat to the **Amber** Inbase session, not the next empty slot.
+
+Do **not** ask for a session id. Do **not** run `inbase start-session`.
+
+1. Attach to the Amber session:
+
+```bash
+npx inbase attach --color yellow
+```
+
+If attach fails with `VISUAL_CODER_NOT_RUNNING`, `VISUAL_CODER_CHAT_LIMIT`, `VISUAL_CODER_COLOR_BUSY`, or `VISUAL_CODER_COLOR_UNKNOWN`, reply with that message and stop.
+
+2. Read `VISUAL_CODER_SESSION` from the output. That id is the session to use for every later `inbase` command.
+
+3. Continue the Inbase visual edits skill from `wait-for-blueprint` onward with that `--session` id. Attach already started the session. `wait-for-blueprint` only reads the optional blueprint, instruction, and attached files; it does not wait.
+
+The user's request is:
+
+$ARGUMENTS

package/skill/inbase/SKILL.md

@@ -3,11 +3,11 @@ name: inbase
 description: >-
   Grounds source-file changes in the Inbase visual map. Use when creating,
   editing, or deleting application source files in this repository, including
-  when the user chats a change request without /inbase. Direct chat is blocked
-  unless they invoked /inbase or /skipinbase. Lists every feature step, then
-  edits live files after invocation and records each step with inbase
-  propose-patch (no patch file). Do not use for git, docs-only, lockfiles, or
-  questions.
+  when the user chats a change request without /inbase. Connects this chat to
+  the next empty Inbase session, or to a color with /coral /red /amber and
+  the other session colors. Lists every feature step, then edits live
+  files after invocation and records each step with inbase propose-patch (no
+  patch file). Do not use for git, docs-only, lockfiles, or questions.
 ---
 
 # Inbase visual edits
@@ -16,19 +16,18 @@ Apply this skill **whenever the work is file changes in this repository**.
 Skip it for git, lockfiles, `.inbase`, `.cursor`, or questions with no code
 changes.
 
-Sessions start only from the visualizer (**Setup LLM session**). This chat
-cannot open a session.
+`npx inbase run` creates 5 empty chat slots. A regular Cursor chat connects to
+the next unconnected slot. You do not need `/inbase`.
 
+- **`/coral` `/amber` `/lime` `/orange` `/violet`**: attach this chat to that
+  color's empty slot. Aliases: `/red` (Coral), `/yellow` (Amber), `/green`
+  (Lime), `/purple` (Violet). The text after the command is the user's request.
+- **`/blue`**: Blue is the global blueprint, not a chat. Do not attach.
 - **`/skipinbase`**: do the user's request without Inbase. Do not attach, wait,
   or record patches.
-- **`/inbase`**, or this conversation already has a `VISUAL_CODER_SESSION` from
-  `/inbase`: connect if needed, then follow Required sequence. Do not refuse.
-- **Any other file-change request**: do not edit files and do not run Inbase
-  commands. Reply with exactly this line, then **stop**:
-
-```
-direct chat interaction not allowed use /skipinbase [request] to bypass inbase.
-```
+- **Any other file-change request**, or this conversation already has a
+  `VISUAL_CODER_SESSION`: connect if needed, then follow Required sequence.
+  Do not refuse.
 
 The LLM uses a plan-first loop. It reports the complete plan before editing
 files. When **Step by step** is on, it waits for the user to click **Create
@@ -51,18 +50,46 @@ The visualizer stores immutable diffs under
 (`inbase run` or `npx inbase run`). Prefer `npx inbase` so the local package
 is used.
 
-If this chat is not yet attached, run:
+If this chat is not yet attached:
+
+- If the user invoked `/coral`, `/red`, `/amber`, `/yellow`, `/lime`,
+  `/green`, `/orange`, `/violet`, or `/purple`, run
+  `npx inbase attach --color <that command name>` (for example `/red` →
+  `--color red`).
+- Otherwise run:
 
 ```bash
 npx inbase attach
 ```
 
-That attaches this chat to the next waiting visualizer session (oldest first).
-Already-attached sessions are skipped. Window focus does not matter. No id is
-passed in; read `VISUAL_CODER_SESSION` from the output and use that
-`--session` value for every later command. Then continue from
-`wait-for-blueprint` below. Do **not** run `start-session`. Do **not** wait
-for a blueprint handshake.
+That attaches this chat to the matching color's empty slot, or to the next
+unconnected visualizer session (oldest first). Already-connected sessions are
+skipped unless you asked for that color — then attach fails with
+`VISUAL_CODER_COLOR_BUSY`. Window focus does not matter.
+No id is passed in; read `VISUAL_CODER_SESSION` from the output and use that
+`--session` value for every later command. Read `VISUAL_CODER_COLOR` and **reply
+in this chat first** with one short sentence that names that color, for example:
+`Connecting to the Coral session.` Then continue from `wait-for-blueprint` below.
+
+If attach fails:
+
+- `VISUAL_CODER_NOT_RUNNING`: reply with exactly this line, then **stop**:
+
+```
+Inbase isn't running. Start it with `npx inbase run`, then send this request again.
+```
+
+- `VISUAL_CODER_CHAT_LIMIT`: reply with exactly this line, then **stop**:
+
+```
+Only 5 Inbase chats can be connected at once. Finish or stop one in the map, then start a new chat.
+```
+
+- `VISUAL_CODER_COLOR_BUSY` or `VISUAL_CODER_COLOR_UNKNOWN`: reply with the rest
+  of that line (it names the color), then **stop**.
+
+Then continue from `wait-for-blueprint` below. Do **not** run `start-session`.
+Do **not** wait for a blueprint handshake.
 
 ## Direct response
 
@@ -71,8 +98,9 @@ Visualizer signals arrive as `VISUAL_CODER_ACK` from `attach`,
 you cannot chat; that process is the listen loop.
 
 The moment a command prints `VISUAL_CODER_ACK`, **reply in this chat first**
-with one short sentence that acknowledges the signal. Echo the ack, for
-example: `Got it — running step 2: Show ColorGenerator on Home.` Then continue
+with one short sentence that acknowledges the signal. After `attach`, name the
+color from `VISUAL_CODER_COLOR`, for example: `Connecting to the Coral session.`
+For later acks, echo the signal, for example: `Got it — running step 2: Show ColorGenerator on Home.` Then continue
 the required tools in the same turn. Do not wait for the user after the ack.
 Do not start with a long analysis. Do not call tools before that sentence.
 
@@ -84,18 +112,22 @@ new plan.
 
 ## Required sequence
 
-1. **Read the current layout**. `/inbase` already started the session. Run
+1. **Read the current layout**. Attach already started the session. Run
    this once to load the optional blueprint, instruction, and attached files — it returns
-   immediately. Do not wait for the user to send a blueprint. Then report a
-   plan.
+   immediately. Do not wait for the user to send a blueprint. If that output
+   includes `VISUAL_CODER_ACK explain`, follow exit `7` below. If you cannot
+   report a plan yet (no instruction and no enabled blueprint work), **do not
+   ask in chat**. Immediately run `wait-for-approval` so `?` clicks on the map
+   are heard. Then report a plan when you have one.
 
 ```bash
 npx inbase wait-for-blueprint --session "<session-id>"
 ```
 
-   The user may have placed files (`Space`) and islands (`B`), or left the
-   shared blueprint empty. That blueprint is shared across sessions. They can
-   keep placing at any time.
+   The user may have placed files and islands on the map, or left the
+   blueprints empty. The **global** (blue) blueprint is shared across sessions.
+   This chat also has a **local** blueprint in this session's color; only this
+   chat receives it. They can keep placing at any time.
    If `wait-for-blueprint` prints `VISUAL_CODER_INSTRUCTION_START` /
    `VISUAL_CODER_INSTRUCTION_END`, that text is the user's request for this
    session. If it prints `VISUAL_CODER_CONTEXT_FILES_START` /
@@ -106,32 +138,26 @@ npx inbase wait-for-blueprint --session "<session-id>"
    instruction does not override an enabled blueprint; if they conflict,
    ask the user.
 3. Read the handshake output between `VISUAL_CODER_BLUEPRINT_START` and
-   `VISUAL_CODER_BLUEPRINT_END`, or read `.inbase/blueprint.json`.
-   If `enabled` is true, **the blueprint is leading**. Treat
+   `VISUAL_CODER_BLUEPRINT_END` (global, shared), and between
+   `VISUAL_CODER_LOCAL_BLUEPRINT_START` and `VISUAL_CODER_LOCAL_BLUEPRINT_END`
+   (this session's color only). You can also read the global
+   `.inbase/blueprint.json`.
+   If either dump has `enabled` true, **that blueprint is leading**. Treat
    `userCreatedBlocks`, `userCreatedIslands`, `addedFunctions`,
    `addedVariables`, and `addedImports` as the source of truth for this chat.
    Create those paths and add those symbols even if they are not on disk.
-   The same blueprint is shared with every session.
+   Honor the global blueprint and this session's local blueprint. Do not use
+   another session's local blueprint.
    Do not omit, rename, relocate, or replace a blueprint file, island, symbol,
    or import. Extra edits to existing files are allowed when needed to finish
-   the feature. Extra new files that are not in the blueprint are a deviation.
-   If the user request, viewpoint, a later instruction, or your own plan would
-   differ from the blueprint, **stop and ask the user in chat** before
+   the feature. Extra new files that are not in either blueprint are a deviation.
+   If the user request, a later instruction, or your own plan would
+   differ from an enabled blueprint, **stop and ask the user in chat** before
    reporting the plan. Do not silently deviate.
-4. Read `.inbase/user-context.json` for viewpoint only.
-5. Use the user's viewpoint only when `followLook` is true:
-   - `island` is where they are standing
-   - `lookingAt` / `lookingAtFiles` are the blocks they are looking at
-   - `selected` is the block they clicked
-   - `filesOnIsland` is the rest of that folder
-   Prefer those files while `followLook` is true, unless the request clearly
-   needs something else. If `followLook` is false or missing, ignore viewpoint
-   and    choose files from the request itself. Viewpoint never overrides the
-   blueprint: still follow the shared blueprint when `enabled` is true.
-6. List **all** steps needed to finish the feature. Keep steps small enough that
+4. List **all** steps needed to finish the feature. Keep steps small enough that
    one recorded step is one landscape change (usually one new file, or a few
    related edits).
-7. Report the plan before editing files:
+5. Report the plan before editing files:
 
 ```bash
 npx inbase report-plan \
@@ -141,20 +167,23 @@ npx inbase report-plan \
   --steps "Show Clock on Home"
 ```
 
-8. **Stop and wait for invocation**:
+6. **Stop and wait for invocation**:
 
 ```bash
 npx inbase wait-for-approval --session "<session-id>"
 ```
 
    Describe this tool call as `inbase wait-for-approval`, not "waiting for the
-   user to invoke". The command keeps running until they invoke; when it
-   returns, they already did. Do not edit project files until this prints
-   `VISUAL_CODER_ACK execute` / `VISUAL_CODER_EXECUTE`. If Step by step is off,
-   this returns immediately for each remaining step. First reply in chat
-   acknowledging the ack, then re-read the shared `blueprint.json`; the
-   user can place files and islands at any time.
-9. Implement only the invoked step by editing the live project files (Write,
+   user to invoke". The command keeps running until they invoke, click
+   **Explain proposal**, or click `?` on a file, folder, or symbol; when it
+   returns, they already did. Do not edit project
+   files until this prints `VISUAL_CODER_ACK execute` / `VISUAL_CODER_EXECUTE`.
+   If it prints `VISUAL_CODER_ACK explain`, follow exit `7` below, then wait
+   again. If Step by step is off, this returns immediately for each remaining
+   step. First reply in chat acknowledging the ack, then re-read the global
+   `blueprint.json` and this session's local blueprint; the user can place
+   files and islands at any time.
+7. Implement only the invoked step by editing the live project files (Write,
    StrReplace, Delete). Paths are the same ids as `codebase.json`. Then record
    the step — Inbase diffs the working tree against the snapshot taken at
    invoke:
@@ -166,10 +195,10 @@ npx inbase propose-patch --session "<session-id>"
    Do not write a unified diff. Do not pass a `.patch` file. Never write or
    replace a patch already stored in the session folder.
 
-10. **Stop editing** until the next `VISUAL_CODER_EXECUTE`. The stored patch is
+8. **Stop editing** until the next `VISUAL_CODER_EXECUTE`. The stored patch is
     the session record; disk already has your edits. Your next tool call is
     `wait-for-approval` — nothing else.
-11. Wait until the user clicks **Accept proposal** on the current step (or, when Step by
+9. Wait until the user clicks **Accept proposal** or **Explain proposal** on the current step (or, when Step by
    step is off, until the next step is auto-invoked), sends an alternative
    instruction, or stops the workflow:
 
@@ -177,7 +206,7 @@ npx inbase propose-patch --session "<session-id>"
 npx inbase wait-for-approval --session "<session-id>"
 ```
 
-12. Read the wait command output. Reply in chat with the `VISUAL_CODER_ACK`
+10. Read the wait command output. Reply in chat with the `VISUAL_CODER_ACK`
     line first, then:
 
    - Exit `0` (`VISUAL_CODER_ACK execute` / `VISUAL_CODER_EXECUTE`): follow
@@ -186,17 +215,20 @@ npx inbase wait-for-approval --session "<session-id>"
      patch file), then wait again for **Accept proposal**. Do not start the
      next step and do not report a new plan. Otherwise the highlighted step
      was invoked: implement that step now — do not explore, re-plan, or run
-     `wait-for-blueprint`. Re-read the shared `blueprint.json` if you need
-     placed files. Edit live files for that step only, record with
+     `wait-for-blueprint`. Re-read the global `blueprint.json` and this
+     session's local blueprint if you need placed files. Edit live files for
+     that step only, record with
      `inbase propose-patch` (no patch file), then wait again.
-   - Exit `6` (`VISUAL_CODER_ACK blueprint` / `VISUAL_CODER_BLUEPRINT`): the
-     shared blueprint changed. Follow the latest files, islands, functions,
-     variables, and imports. Do not omit, rename, relocate, or replace them.
+   - Exit `6` (`VISUAL_CODER_ACK blueprint` / `VISUAL_CODER_BLUEPRINT`): a
+     blueprint this chat can see changed (global, this session's color, or
+     both). Follow the latest files, islands, functions, variables, and
+     imports from those dumps. Do not omit, rename, relocate, or replace them.
+     Ignore other sessions' local blueprints.
      If this would differ from the current plan, ask the user before replacing
      the plan. Then run `wait-for-approval` again.
    - Exit `5` (`VISUAL_CODER_ACK finished` / `VISUAL_CODER_FINISHED`): that was
      the last step. The visualizer already applied the final patch and removed
-     stored session diffs. The shared blueprint remains. Optionally run
+     stored session diffs. The global blueprint remains. Optionally run
      `--clear` if anything remains, tell the user the feature is done, and
      **stop**. Do not propose another patch.
    - Exit `4` (`VISUAL_CODER_ACK replan` / `VISUAL_CODER_REPLAN`): live files
@@ -205,11 +237,27 @@ npx inbase wait-for-approval --session "<session-id>"
      `VISUAL_CODER_INSTRUCTION_END`, edit those live files, then
      `inbase propose-patch`. Wait for **Accept proposal**. Do not start the
      next step.
+   - Exit `7` (`VISUAL_CODER_ACK explain` / `VISUAL_CODER_EXPLAIN`): the user
+     wants something explained on the map — either the current proposal or a
+     file/folder they clicked **?** next to. Do not edit project files and
+     do not invoke the next step. Follow the printed `VISUAL_CODER_EXPLAIN`
+     line: `npx inbase explain start --question "..."`, inspect the named
+     file or folder (or the live files this proposal changed / this plan step
+     will use), then
+     `npx inbase explain report` with `--step` /
+     `--body` / `--files` / `--folders` / `--select` / `--zoom` / `--info` /
+     `--highlight` / `--point`. After
+     reporting, run `npx inbase explain wait`. If that returns
+     `VISUAL_CODER_EXPLAIN_QUESTION`, report sub-steps with `--parent` and wait
+     again. If it returns another `VISUAL_CODER_EXPLAIN` for a file or folder,
+     replace the explanation. When explain wait returns stopped or timeout, run
+     `wait-for-approval` again. The plan is still waiting for
+     **Create proposal** or **Accept proposal**.
    - Exit `2` (`VISUAL_CODER_ACK stopped` / `VISUAL_CODER_STOPPED`) or `3`
      (`VISUAL_CODER_ACK timeout`): make no further project changes.
 
-13. After a finished handshake, the explorer already removed stored session
-    diffs. The shared blueprint remains. Optionally run:
+11. After a finished handshake, the explorer already removed stored session
+    diffs. The global blueprint remains. Optionally run:
 
 ```bash
 npx inbase propose-patch --session "<session-id>" --clear
@@ -217,16 +265,16 @@ npx inbase propose-patch --session "<session-id>" --clear
 
 ## Do not
 
-- Start a visual session from chat with `start-session`; sessions start only
-  from **Setup LLM session** in the map
-- Edit files on a direct chat request; reply with the `/skipinbase` line and stop
-- Invent a session id for `/inbase`; run `npx inbase attach` with no `--session`
+- Start a visual session from chat with `start-session`; `npx inbase run` already opened 5 empty slots
+- Invent a session id; run `npx inbase attach` with no `--session`, or
+  `npx inbase attach --color <name>` when the user invoked a color command
 - Skip `inbase wait-for-blueprint`; it returns immediately and provides the optional blueprint, instruction, and attached files
-- Treat the chat request, viewpoint, or your own plan as overriding an enabled blueprint
-- Skip, rename, relocate, or replace the shared `blueprint.json` files, islands, functions, variables, or imports when `enabled` is true
-- Silently differ from the blueprint; ask the user first
-- Read global `user-context.json` for placed files; those live on the shared blueprint
-- Follow the user's look when `followLook` is false
+- Treat the chat request or your own plan as overriding an enabled blueprint
+- Skip, rename, relocate, or replace files, islands, functions, variables, or imports from the global blueprint or this session's local blueprint when that dump is `enabled`
+- Silently differ from an enabled blueprint; ask the user first
+- Read global `user-context.json` for placed files; those live on the global or this session's local blueprint
+- Follow another session's local blueprint
+- Use the user's camera viewpoint to choose files
 - Edit project files before `VISUAL_CODER_EXECUTE`
 - Keep editing after `inbase propose-patch` until the next `VISUAL_CODER_EXECUTE`
 - Write a unified diff yourself; `inbase propose-patch` with no file records the git diff

package/apps/explorer/src/scene/BlockPlacer.tsx

@@ -1,78 +0,0 @@
-import { useEffect } from 'react'
-import { useThree } from '@react-three/fiber'
-import * as THREE from 'three'
-import { folderAt } from '../layout'
-import { shouldIgnoreShortcut } from '../keyboard'
-import type { WorldLayout } from '../types'
-
-type BlockPlacerProps = {
-  enabled: boolean
-  layout: WorldLayout
-  onPlace: (spot: { x: number; z: number; folder: string }) => void
-}
-
-const ndc = new THREE.Vector2(0, 0)
-const raycaster = new THREE.Raycaster()
-const ground = new THREE.Plane(new THREE.Vector3(0, 1, 0), 0)
-const hit = new THREE.Vector3()
-const forward = new THREE.Vector3()
-
-const PLACE_MIN = 3
-const PLACE_MAX = 22
-
-function lookPoint(camera: THREE.Camera): { x: number; z: number } {
-  raycaster.setFromCamera(ndc, camera)
-  const reached = raycaster.ray.intersectPlane(ground, hit)
-  camera.getWorldDirection(forward)
-  forward.y = 0
-  if (forward.lengthSq() === 0) forward.set(0, 0, 1)
-  else forward.normalize()
-
-  let x: number
-  let z: number
-  if (reached) {
-    x = hit.x
-    z = hit.z
-  } else {
-    x = camera.position.x + forward.x * 8
-    z = camera.position.z + forward.z * 8
-  }
-
-  const dx = x - camera.position.x
-  const dz = z - camera.position.z
-  const distance = Math.hypot(dx, dz)
-  if (distance < 0.001) {
-    return {
-      x: camera.position.x + forward.x * PLACE_MIN,
-      z: camera.position.z + forward.z * PLACE_MIN,
-    }
-  }
-  const clamped = Math.min(PLACE_MAX, Math.max(PLACE_MIN, distance))
-  const scale = clamped / distance
-  return {
-    x: camera.position.x + dx * scale,
-    z: camera.position.z + dz * scale,
-  }
-}
-
-export function BlockPlacer({ enabled, layout, onPlace }: BlockPlacerProps) {
-  const { camera } = useThree()
-
-  useEffect(() => {
-    const onKey = (event: KeyboardEvent) => {
-      if (!enabled || event.repeat || event.code !== 'Space') return
-      if (shouldIgnoreShortcut(event)) return
-      event.preventDefault()
-      const { x, z } = lookPoint(camera)
-      const island =
-        folderAt(x, z, layout) ??
-        folderAt(camera.position.x, camera.position.z, layout)
-      onPlace({ x, z, folder: island?.path ?? '.' })
-    }
-
-    window.addEventListener('keydown', onKey)
-    return () => window.removeEventListener('keydown', onKey)
-  }, [camera, enabled, layout, onPlace])
-
-  return null
-}

package/apps/explorer/src/scene/IslandPlacer.tsx

@@ -1,31 +0,0 @@
-import { useEffect } from 'react'
-import { useThree } from '@react-three/fiber'
-import { folderAt } from '../layout'
-import { shouldIgnoreShortcut } from '../keyboard'
-import type { WorldLayout } from '../types'
-
-type IslandPlacerProps = {
-  enabled: boolean
-  layout: WorldLayout
-  onPlace: (parent: string) => void
-}
-
-export function IslandPlacer({ enabled, layout, onPlace }: IslandPlacerProps) {
-  const { camera } = useThree()
-
-  useEffect(() => {
-    const onKey = (event: KeyboardEvent) => {
-      if (!enabled || event.repeat || event.code !== 'KeyB') return
-      if (shouldIgnoreShortcut(event)) return
-      const island = folderAt(camera.position.x, camera.position.z, layout)
-      if (!island) return
-      event.preventDefault()
-      onPlace(island.path)
-    }
-
-    window.addEventListener('keydown', onKey)
-    return () => window.removeEventListener('keydown', onKey)
-  }, [camera, enabled, layout, onPlace])
-
-  return null
-}