orbitmap 0.4.2 → 0.4.3

package/dist/agent-instructions.d.ts

@@ -3,13 +3,13 @@ export declare const MARKER_END = "<!-- ORBITMAP_END -->";
 /** The core skill name (entry point). Kept for backwards compatibility. */
 export declare const SKILL_NAME = "orbitmap";
 export declare const SKILL_ORBITMAP_FRONTMATTER = "---\nname: orbitmap\ndescription: >\n  OrbitMap project management via the orbitmap CLI. Use when the user mentions OrbitMap,\n  orbit, tasks, backlog, missions, intents, ideas, issues, vibes, or asks to track,\n  plan, or log work. Entry point: object model, context resolution, command reference.\n---";
-export declare const SKILL_ORBITMAP_BODY = "# OrbitMap CLI \u2014 core\n\nOrbitMap is an agentic project management platform. You interact with it exclusively\nthrough the `orbitmap` CLI (run with `npx orbitmap \u2026` if not on PATH). The CLI works\nidentically in cloud mode and local-files mode \u2014 never assume which one is active, and\nnever read or write the workspace's data files directly. The CLI is the only interface.\n\n## General behaviour\n- Always prioritise the user's direct request. If the user asks you to do something\n  (read a file, write code, answer a question), handle that first.\n- Only interact with OrbitMap when the user explicitly asks you to (e.g. \"check my\n  tasks\", \"start a task\", \"what's on my backlog\", \"log this idea\").\n- When the user mentions OrbitMap, orbit, task, backlog, or project-management concepts\n  in the context of tracking work, use `orbitmap` commands to handle the request.\n\n## Object model\n- Workspace = team level. Area = repo-level scope (formerly Project) \u2014 tasks, vibes and\n  most issues live in an area. Mission (MS-) = time-boxed workspace focus; at most one\n  active. Intent (IN-) = workspace-level goal grouping tasks/issues. Idea (ID-) = future\n  possibility, not a problem. Issue (IS-) = problem/bug. Vibe (VB-) = ad-hoc work log\n  outside a task. Task (TS-) = unit of work.\n- Entity numbers (TS-xxxxxx etc.) are accepted by every command that takes an id.\n\n## Context\n- Area resolves automatically (config/env). Override per call with `--area <slug>`.\n- If a command fails asking for area context, run `orbitmap areas` to list areas, then\n  retry with `--area`.\n- `orbitmap context` shows who you are, the workspace, and the active area. Run it when\n  unsure.\n\n## Task statuses\nbacklog, todo, in_progress, in_review, review_changes, done, blocked.\n`orbitmap tasks` defaults to todo,in_progress. Ask for others explicitly, e.g.\n`orbitmap tasks --status backlog` when the user asks about the backlog.\n\n## Command reference (all commands accept --json)\n- Context: `orbitmap context`, `orbitmap areas`, `orbitmap overview`\n- Tasks: `orbitmap tasks [--status s1,s2]`, `orbitmap task TS-x`, `orbitmap get <ID>`,\n  `orbitmap start [TS-x]`, `orbitmap status TS-x <status> [--delivery <d>]`,\n  `orbitmap create \"title\" [--intent IN-x|--mission MS-x] [--priority p]`,\n  `orbitmap subtask TS-parent \"title\"`, `orbitmap assign TS-x [agent]`,\n  `orbitmap dep add|remove TS-a TS-b`, `orbitmap log TS-x \"msg\" --type <t>`\n- Issues: `orbitmap issue register|list|show|status|resolve`\n- Ideas: `orbitmap idea add|list|show|status`\n- Vibes: `orbitmap vibe log|list|show`\n- Missions: `orbitmap mission list|show|create|update|status|link|unlink`\n- Intents: `orbitmap intent list|show|create|update|link|unlink`\n- Documents: `orbitmap docs`, `orbitmap doc <slug> [--section \"## H\"|--full]`,\n  `orbitmap doc-import`, `orbitmap doc-update`\n\n## Error handling\n- If OrbitMap is unreachable (network down / workspace directory unavailable), inform\n  the user and continue the primary work without logging. Do NOT retry failed orbitmap\n  calls in a loop \u2014 report the issue and proceed with the task.";
+export declare const SKILL_ORBITMAP_BODY = "# OrbitMap CLI \u2014 core\n\nOrbitMap is an agentic project management platform. You interact with it exclusively\nthrough the `orbitmap` CLI (run with `npx orbitmap \u2026` if not on PATH). The CLI works\nidentically in cloud mode and local-files mode \u2014 never assume which one is active, and\nnever read or write the workspace's data files directly. The CLI is the only interface.\n\n## General behaviour\n- Always prioritise the user's direct request. If the user asks you to do something\n  (read a file, write code, answer a question), handle that first.\n- Only interact with OrbitMap when the user explicitly asks you to (e.g. \"check my\n  tasks\", \"start a task\", \"what's on my backlog\", \"log this idea\").\n- When the user mentions OrbitMap, orbit, task, backlog, or project-management concepts\n  in the context of tracking work, use `orbitmap` commands to handle the request.\n\n## Object model\n- Workspace = team level. Area = repo-level scope (formerly Project) \u2014 tasks, vibes and\n  most issues live in an area. Mission (MS-) = time-boxed workspace focus; at most one\n  active. Intent (IN-) = workspace-level goal grouping tasks/issues. Idea (ID-) = future\n  possibility, not a problem. Issue (IS-) = problem/bug. Vibe (VB-) = ad-hoc work log\n  outside a task. Task (TS-) = unit of work.\n- Entity numbers (TS-xxxxxx etc.) are accepted by every command that takes an id.\n\n## Context\n- START HERE, always: `orbitmap context`. `orbitmap context` is authoritative and returns\n  in ONE call everything a session needs \u2014 the agent, the workspace, the areas you work in,\n  the active mission, open intents, your tasks and the documents. Never list areas and never\n  ask the user \"which area?\" before you have read it.\n- You work in a WORKSPACE, not inside a single area. Missions, intents\n  and documents are workspace-level and take no area \u2014 a document is exactly ONE copy,\n  global to the workspace, never per-area. Tasks, vibes, issues and ideas are\n  AREA-scoped.\n- Missions and intents outrank individual tasks. Asked to work on \"what matters\", take the\n  active mission and open intents from context and pick work that serves them.\n- The area follows from the directory, never from a question to the user:\n  `.orbitmap/config.json` maps directories \u2192 area slugs at the workspace root, and each\n  area directory carries its own `.orbitmap/config.json` marker naming its area. That\n  config is the only source of truth \u2014 never hard-code area names anywhere.\n  So: do area-scoped work from the directory it belongs to and let the CLI resolve it.\n- `--area <slug>` is an OVERRIDE for a single call, not part of normal usage \u2014 reach for it\n  only to read or write outside the area the current directory resolves to.\n- If a command fails with `AREA_CONTEXT_REQUIRED`, its details list the mapped\n  directories: cd into the right one, or retry with `--area <slug>`.\n- WRITES: the resolved area is a default for *reading*, never a statement of where the\n  work belongs. Before creating anything area-scoped (task, subtask, issue, vibe),\n  derive the target area from the work itself (which repo/package it lives in) and pass\n  `--area <slug>` if that differs from the area the CLI echoes. If the work itself is\n  genuinely ambiguous, ASK THE USER; do not guess. There is no\n  `move` command: a write in the wrong area has to be recreated.\n- Every write echoes its scope on stderr: `creates in area <slug> (source: \u2026)` when it\n  creates an object, `scoped to area <slug> (source: \u2026)` when it changes one by id. A\n  `source` of `global ~/.orbitmap/config.json` is a machine-wide leftover that nothing\n  here chose \u2014 treat it as unconfirmed and pass `--area` explicitly.\n\n## Task statuses\nbacklog, todo, in_progress, in_review, review_changes, done, blocked.\n`orbitmap tasks` defaults to todo,in_progress. Ask for others explicitly, e.g.\n`orbitmap tasks --status backlog` when the user asks about the backlog.\n\n## Command reference (all commands accept --json)\n- Context: `orbitmap context` (start here), `orbitmap overview`, `orbitmap areas`\n  (rarely needed \u2014 context already lists the areas you work in)\n- Tasks: `orbitmap tasks [--status s1,s2]`, `orbitmap task TS-x`, `orbitmap get <ID>`,\n  `orbitmap start [TS-x]`, `orbitmap status TS-x <status> [--delivery <d>]`,\n  `orbitmap create \"title\" [--intent IN-x|--mission MS-x] [--priority p]`,\n  `orbitmap subtask TS-parent \"title\"`, `orbitmap assign TS-x [agent]`,\n  `orbitmap dep add|remove TS-a TS-b`, `orbitmap log TS-x \"msg\" --type <t>`\n- Issues: `orbitmap issue register|list|show|status|resolve`\n- Ideas: `orbitmap idea add|list|show|status`\n- Vibes: `orbitmap vibe log|list|show`\n- Missions: `orbitmap mission list|show|create|update|status|link|unlink`\n- Intents: `orbitmap intent list|show|create|update|link|unlink`\n- Documents: `orbitmap docs`, `orbitmap doc <slug> [--section \"## H\"|--full]`,\n  `orbitmap doc-import`, `orbitmap doc-update`\n\n## Error handling\n- If OrbitMap is unreachable (network down / workspace directory unavailable), inform\n  the user and continue the primary work without logging. Do NOT retry failed orbitmap\n  calls in a loop \u2014 report the issue and proceed with the task.";
 export declare const SKILL_WORKING_FRONTMATTER = "---\nname: orbitmap-working\ndescription: >\n  Working on OrbitMap tasks: starting/resuming, logging work, decisions and blockers,\n  finishing with the correct status, git branches and delivery status. Use whenever\n  implementing, resuming, or finishing a tracked task.\n---";
-export declare const SKILL_WORKING_BODY = "# Working on OrbitMap tasks\n\n## Task workflow (on user request)\nWhen the user asks you to work on tasks:\n1. `orbitmap tasks --status in_progress` \u2014 check for unfinished work.\n2. If found \u2192 `orbitmap task TS-x` \u2192 read the work log \u2192 resume from the resume point.\n3. If not \u2192 `orbitmap start` \u2014 auto-picks the first todo task, sets it in_progress and\n   prints full context (description, agent_instructions, logs).\n4. If no tasks \u2192 inform the user.\nUse `orbitmap start TS-x` to begin a specific task; `orbitmap task TS-x` only inspects.\n\n## Rules\n- Work on ONE task at a time.\n- Always read agent_instructions from the task before implementing. Task-level\n  agent_instructions take precedence over area-level instructions.\n- Only work on subtasks assigned to you; do not pick up other agents' subtasks.\n- Do NOT mark a parent task done while it has unfinished subtasks, unless the user\n  explicitly asks.\n\n## Logging\n- `orbitmap log TS-x \"\u2026\" --type note|code_change|decision|blocker` \u2014 work WITHIN a task.\n- `orbitmap vibe log \"\u2026\" --type discovery|exploration|fix` \u2014 ad-hoc work outside a task.\n- Use `--type decision` when you pick between approaches, reject an alternative, or lock\n  in a non-obvious assumption \u2014 record the choice AND the why, not just the outcome.\n- `orbitmap idea add` \u2014 future possibilities, NOT problems (problems \u2192\n  `orbitmap issue register`).\n- Keep log content concrete, concise, and useful for someone resuming work later.\n\n## End of session or task \u2014 MANDATORY\n- Task finished \u2192 default to **in_review** so a human verifies before closing:\n  `orbitmap log TS-x \"Ready for review: \u2026\" --type note` then\n  `orbitmap status TS-x in_review`.\n- Task finished AND the user's prompt or the task's agent_instructions explicitly say to\n  close without review \u2192 `orbitmap log TS-x \"Summary: \u2026\" --type note` then\n  `orbitmap status TS-x done`.\n- Blocked by an external dependency you cannot resolve (waiting on another task, missing\n  access/credentials, unclear requirements, failing external service) \u2192\n  `orbitmap log TS-x \"Blocked: <reason>\" --type blocker` then\n  `orbitmap status TS-x blocked`.\n- Session ending, task not done but NOT blocked \u2192 `orbitmap log TS-x \"Resume point: \u2026\"\n  --type note` \u2014 leave status in_progress.\n- NEVER leave a task without a final log entry.\n\n### Status decision guide\n- **in_review**: work is finished. THE DEFAULT for completed work. The requester should\n  verify before closing.\n- **done**: only when the prompt or task agent_instructions explicitly allow closing\n  without review (\"auto-close\", \"mark as done\", \"no review needed\"). A user saying \"do\n  this task\" is NOT permission to auto-close.\n- **blocked**: an external factor outside your control stops you. Always log the\n  specific blocker.\n- **in_progress** (keep): session ends but you can resume autonomously next time.\n\n## Git workflow\n- When the task context contains a branch_name, create or switch to it:\n  `git checkout -b <branch_name>` (or `git checkout <branch_name>` if it exists).\n- If the task has NO branch_name, work on the current branch \u2014 do not create one.\n- Do NOT work directly on main/master/develop unless the task has no branch_name and you\n  are already on a feature branch.\n\n## Delivery flow\n- Commit messages: prefix the entity number with its type tag \u2014\n  `[TS-r5d8zf] Add delivery status field` (also `[IS-\u2026]`, `[ID-\u2026]`, `[VB-\u2026]`).\n- When you committed/pushed code during the task, finish with\n  `orbitmap status TS-x <status> --delivery on_branch`.\n- When the user asks what's in a branch/PR: `git log target..source --oneline`, parse\n  `[TS-\u2026]`/`[IS-\u2026]` tags, report the matched entities.\n- When the user reports a merge or release: update the relevant tasks with\n  `--delivery merged` or `--delivery released`.\n\n## Planning mode (agents with a plan mode)\nWhen you create an implementation plan for a tracked task, you MUST include OrbitMap\nlifecycle steps as explicit plan items:\n- First step: reference the OrbitMap task number and title.\n- Last steps, always: (1) `orbitmap log` with a summary of all changes; (2)\n  `orbitmap status` set per the status decision guide (or a resume-point log if\n  incomplete).\n\n## Example: completing a task (default \u2192 in_review)\n1. `orbitmap tasks --status in_progress` \u2192 empty\n2. `orbitmap start` \u2192 task context\n3. read agent_instructions; implement; run tests; commit with `[TS-x]` prefix\n4. `orbitmap log TS-x \"Implemented X by doing Y\" --type code_change`\n5. `orbitmap log TS-x \"Ready for review: all tests pass.\" --type note`\n6. `orbitmap status TS-x in_review --delivery on_branch`";
+export declare const SKILL_WORKING_BODY = "# Working on OrbitMap tasks\n\n## Task workflow (on user request)\nWhen the user asks you to work on tasks \u2014 including a vague \"work on what's important\":\n1. `orbitmap context` \u2014 the workspace, your areas, the active mission, open intents and\n   your tasks in one call. Do not ask which area and do not list areas first.\n2. Unfinished work in context (or `orbitmap tasks --status in_progress`) \u2192\n   `orbitmap task TS-x` \u2192 read the work log \u2192 resume from the resume point.\n3. Otherwise pick work that serves the active mission / open intents, or `orbitmap start`\n   \u2014 auto-picks the first todo task, sets it in_progress and prints full context\n   (description, agent_instructions, logs).\n4. If there is nothing to pick up \u2192 inform the user.\nUse `orbitmap start TS-x` to begin a specific task; `orbitmap task TS-x` only inspects.\n\n## Rules\n- Work on ONE task at a time.\n- Always read agent_instructions from the task before implementing. Task-level\n  agent_instructions take precedence over area-level instructions.\n- Subtasks never show up in a task list (`orbitmap context`, `orbitmap tasks`,\n  `orbitmap start`) \u2014 only inside the parent task you opened with `orbitmap task TS-x`.\n- Only work on subtasks assigned to you; do not pick up other agents' subtasks.\n- Do NOT mark a parent task done while it has unfinished subtasks, unless the user\n  explicitly asks.\n\n## Logging\n- `orbitmap log TS-x \"\u2026\" --type note|code_change|decision|blocker` \u2014 work WITHIN a task.\n- `orbitmap vibe log \"\u2026\" --type discovery|exploration|fix` \u2014 ad-hoc work outside a task.\n- Use `--type decision` when you pick between approaches, reject an alternative, or lock\n  in a non-obvious assumption \u2014 record the choice AND the why, not just the outcome.\n- `orbitmap idea add` \u2014 future possibilities, NOT problems (problems \u2192\n  `orbitmap issue register`).\n- Keep log content concrete, concise, and useful for someone resuming work later.\n\n## End of session or task \u2014 MANDATORY\n- Task finished \u2192 default to **in_review** so a human verifies before closing:\n  `orbitmap log TS-x \"Ready for review: \u2026\" --type note` then\n  `orbitmap status TS-x in_review`.\n- Task finished AND the user's prompt or the task's agent_instructions explicitly say to\n  close without review \u2192 `orbitmap log TS-x \"Summary: \u2026\" --type note` then\n  `orbitmap status TS-x done`.\n- Blocked by an external dependency you cannot resolve (waiting on another task, missing\n  access/credentials, unclear requirements, failing external service) \u2192\n  `orbitmap log TS-x \"Blocked: <reason>\" --type blocker` then\n  `orbitmap status TS-x blocked`.\n- Session ending, task not done but NOT blocked \u2192 `orbitmap log TS-x \"Resume point: \u2026\"\n  --type note` \u2014 leave status in_progress.\n- NEVER leave a task without a final log entry.\n\n### Status decision guide\n- **in_review**: work is finished. THE DEFAULT for completed work. The requester should\n  verify before closing.\n- **done**: only when the prompt or task agent_instructions explicitly allow closing\n  without review (\"auto-close\", \"mark as done\", \"no review needed\"). A user saying \"do\n  this task\" is NOT permission to auto-close.\n- **blocked**: an external factor outside your control stops you. Always log the\n  specific blocker.\n- **in_progress** (keep): session ends but you can resume autonomously next time.\n\n## Git workflow\n- When the task context contains a branch_name, create or switch to it:\n  `git checkout -b <branch_name>` (or `git checkout <branch_name>` if it exists).\n- If the task has NO branch_name, work on the current branch \u2014 do not create one.\n- Do NOT work directly on main/master/develop unless the task has no branch_name and you\n  are already on a feature branch.\n\n## Delivery flow\n- Commit messages: prefix the entity number with its type tag \u2014\n  `[TS-r5d8zf] Add delivery status field` (also `[IS-\u2026]`, `[ID-\u2026]`, `[VB-\u2026]`).\n- When you committed/pushed code during the task, finish with\n  `orbitmap status TS-x <status> --delivery on_branch`.\n- When the user asks what's in a branch/PR: `git log target..source --oneline`, parse\n  `[TS-\u2026]`/`[IS-\u2026]` tags, report the matched entities.\n- When the user reports a merge or release: update the relevant tasks with\n  `--delivery merged` or `--delivery released`.\n\n## Planning mode (agents with a plan mode)\nWhen you create an implementation plan for a tracked task, you MUST include OrbitMap\nlifecycle steps as explicit plan items:\n- First step: reference the OrbitMap task number and title.\n- Last steps, always: (1) `orbitmap log` with a summary of all changes; (2)\n  `orbitmap status` set per the status decision guide (or a resume-point log if\n  incomplete).\n\n## Example: completing a task (default \u2192 in_review)\n1. `orbitmap context` \u2192 workspace, mission, intents, tasks; nothing in_progress\n2. `orbitmap start` \u2192 task context\n3. read agent_instructions; implement; run tests; commit with `[TS-x]` prefix\n4. `orbitmap log TS-x \"Implemented X by doing Y\" --type code_change`\n5. `orbitmap log TS-x \"Ready for review: all tests pass.\" --type note`\n6. `orbitmap status TS-x in_review --delivery on_branch`";
 export declare const SKILL_PLANNING_FRONTMATTER = "---\nname: orbitmap-planning\ndescription: >\n  Planning with OrbitMap: missions (time-boxed focus), intents (goals grouping work),\n  promoting ideas to tasks, triaging issues, decomposing work into tasks and subtasks.\n  Use for \"plan\", \"roadmap\", \"mission\", \"intent\", \"break this down\", idea or issue\n  triage requests.\n---";
-export declare const SKILL_PLANNING_BODY = "# Planning in OrbitMap\n\n## Hierarchy\nMission (MS-) \u2192 Intent (IN-) \u2192 Task (TS-) / Issue (IS-). Missions and intents are\nworkspace-level; tasks live in areas. An intent groups the tasks/issues that realise one\ngoal; a mission time-boxes a set of intents (and directly-attached items) toward an\noutcome. At most ONE mission is active at a time.\n\n## Missions\n- `orbitmap mission list` / `orbitmap mission show MS-x`\n- `orbitmap mission create \"name\" [--outcome \"\u2026\"] [--start d] [--end d]`\n- `orbitmap mission status MS-x active|completed|cancelled` \u2014 activating fails while\n  another mission is active; complete or cancel it first.\n- `orbitmap mission link MS-x IN-y|TS-y|IS-y|ID-y` / `mission unlink` \u2014 attach items.\n\n## Intents\n- `orbitmap intent create \"name\" [--mission MS-x]`, statuses:\n  new \u2192 design \u2192 plan \u2192 build \u2192 done (or cancelled); update with\n  `orbitmap intent update IN-x --status build`.\n- `orbitmap intent link IN-x TS-y|IS-y` attaches work items to the intent.\n- RULE (intent-exclusive): an item linked to an intent gets its mission THROUGH the\n  intent \u2014 never set a direct mission on a task/issue that has an intent. The CLI\n  enforces this; do not fight it.\n\n## Planning workflow (recommended when the user asks to plan a body of work)\n1. Clarify the outcome \u2192 `orbitmap mission create` (or pick the active mission).\n2. Split into goals \u2192 `orbitmap intent create` per goal, `mission link` them.\n3. Decompose each intent into concrete tasks \u2192\n   `orbitmap create \"title\" --intent IN-x [--priority p]`, subtasks via\n   `orbitmap subtask`.\n4. Wire ordering constraints \u2192 `orbitmap dep add TS-a TS-b` (a depends on b).\n5. Review: `orbitmap mission show MS-x` and `orbitmap overview`.\n\n## Ideas (opportunities, not problems)\n- Capture: `orbitmap idea add \"\u2026\" [--priority p]`.\n- Review: `orbitmap idea list` (default pending).\n- Promote to work: analyse the codebase first, then `orbitmap create \"task title\"\n  --intent \u2026` referencing the idea in the description, then\n  `orbitmap idea status ID-x used`. Reject with `\u2026 rejected`.\n\n## Issues (problems)\n- Report: `orbitmap issue register \"title\" --severity critical|high|medium|low\n  [--description \"\u2026\"]`.\n- Start investigating: `orbitmap issue status IS-x investigating`.\n- Convert to work: `orbitmap create` a fix task, link it, and resolve with\n  `orbitmap issue resolve IS-x --task TS-y --resolution \"\u2026\"` (or status wont_fix /\n  duplicate with a reason).";
+export declare const SKILL_PLANNING_BODY = "# Planning in OrbitMap\n\n## Hierarchy\nMission (MS-) \u2192 Intent (IN-) \u2192 Task (TS-) / Issue (IS-). Missions and intents are\nworkspace-level and never take an area \u2014 plan from anywhere in the workspace, and never\nask which area to plan in. Tasks and issues are area-scoped. An intent groups the\ntasks/issues that realise one goal; a mission time-boxes a set of intents (and\ndirectly-attached items) toward an outcome. At most ONE mission is active at a time.\n`orbitmap context` already gives you the active mission and the open intents \u2014 read it\nbefore planning instead of listing anything.\n\n## Missions\n- `orbitmap mission list` / `orbitmap mission show MS-x`\n- `orbitmap mission create \"name\" [--outcome \"\u2026\"] [--start d] [--end d]`\n- `orbitmap mission status MS-x active|completed|cancelled` \u2014 activating fails while\n  another mission is active; complete or cancel it first.\n- `orbitmap mission link MS-x IN-y|TS-y|IS-y|ID-y` / `mission unlink` \u2014 attach items.\n\n## Intents\n- `orbitmap intent create \"name\" [--mission MS-x]`, statuses:\n  new \u2192 design \u2192 plan \u2192 build \u2192 done (or cancelled); update with\n  `orbitmap intent update IN-x --status build`.\n- `orbitmap intent link IN-x TS-y|IS-y` attaches work items to the intent.\n- RULE (intent-exclusive): an item linked to an intent gets its mission THROUGH the\n  intent \u2014 never set a direct mission on a task/issue that has an intent. The CLI\n  enforces this; do not fight it.\n\n## Planning workflow (recommended when the user asks to plan a body of work)\n1. Clarify the outcome \u2192 `orbitmap mission create` (or pick the active mission).\n2. Split into goals \u2192 `orbitmap intent create` per goal, `mission link` them.\n3. Decompose each intent into concrete tasks \u2192\n   `orbitmap create \"title\" --intent IN-x [--priority p]`, subtasks via\n   `orbitmap subtask`.\n4. Wire ordering constraints \u2192 `orbitmap dep add TS-a TS-b` (a depends on b).\n5. Review: `orbitmap mission show MS-x` and `orbitmap overview`.\n\n## Ideas (opportunities, not problems)\n- Capture: `orbitmap idea add \"\u2026\" [--priority p]`.\n- Review: `orbitmap idea list` (default pending).\n- Promote to work: analyse the codebase first, then `orbitmap create \"task title\"\n  --intent \u2026` referencing the idea in the description, then\n  `orbitmap idea status ID-x used`. Reject with `\u2026 rejected`.\n\n## Issues (problems)\n- Report: `orbitmap issue register \"title\" --severity critical|high|medium|low\n  [--description \"\u2026\"]`.\n- Start investigating: `orbitmap issue status IS-x investigating`.\n- Convert to work: `orbitmap create` a fix task, link it, and resolve with\n  `orbitmap issue resolve IS-x --task TS-y --resolution \"\u2026\"` (or status wont_fix /\n  duplicate with a reason).";
 export declare const SKILL_DOCS_FRONTMATTER = "---\nname: orbitmap-docs\ndescription: >\n  Reading and updating OrbitMap documents (specs, architecture, guides, decisions).\n  Use when the user asks to read, import, or update project documentation tracked in\n  OrbitMap.\n---";
-export declare const SKILL_DOCS_BODY = "# OrbitMap documents\n\n## Choosing what to read\n`orbitmap docs` lists documents with their `context` (when the doc is relevant) and\n`sections_count`. Use context to pick the right document; use sections_count to decide\nwhether to fetch the TOC first (many sections) or go straight to full.\n\n## Token-efficient reading flow\n1. `orbitmap doc <slug>` \u2192 context + table of contents (cheap).\n2. `orbitmap doc <slug> --section \"## Auth\"` \u2192 just that section.\n3. `orbitmap doc <slug> --full` \u2192 full content (expensive \u2014 last resort).\nUse the lightest mode that answers your question. When the CLI reports a local file path\nfor the full content, read that file instead of printing the content into the\nconversation.\n\n## Editing\n- Import a new document: `orbitmap doc-import <file.md> --title \"\u2026\" --type\n  spec|architecture|api|guide|decision|changelog|other [--context \"\u2026\"]`.\n- Update: `orbitmap doc-update <slug> --file <file.md>` (replaces content, bumps\n  version).\n- To change an OrbitMap document, ALWAYS go through these commands \u2014 NEVER edit files\n  inside the OrbitMap workspace/cache directories directly.";
+export declare const SKILL_DOCS_BODY = "# OrbitMap documents\n\nDocuments are workspace-level: exactly ONE copy per workspace, never per-area. No document\ncommand takes an area, and `orbitmap context` already lists them.\n\n## Choosing what to read\n`orbitmap docs` lists documents with their `context` (when the doc is relevant) and\n`sections_count`. Use context to pick the right document; use sections_count to decide\nwhether to fetch the TOC first (many sections) or go straight to full.\n\n## Token-efficient reading flow\n1. `orbitmap doc <slug>` \u2192 context + table of contents (cheap).\n2. `orbitmap doc <slug> --section \"## Auth\"` \u2192 just that section.\n3. `orbitmap doc <slug> --full` \u2192 full content (expensive \u2014 last resort).\nUse the lightest mode that answers your question. When the CLI reports a local file path\nfor the full content, read that file instead of printing the content into the\nconversation.\n\n## Editing\n- Import a new document: `orbitmap doc-import <file.md> --title \"\u2026\" --type\n  spec|architecture|api|guide|decision|changelog|other [--context \"\u2026\"]`.\n- Update: `orbitmap doc-update <slug> --file <file.md>` (replaces content, bumps\n  version).\n- To change an OrbitMap document, ALWAYS go through these commands \u2014 NEVER edit files\n  inside the OrbitMap workspace/cache directories directly.";
 export interface SkillDef {
     /** Skill name = directory name under `.claude/skills/`. */
     name: string;
@@ -19,12 +19,25 @@ export interface SkillDef {
     body: string;
 }
 export declare const SKILLS: readonly SkillDef[];
-export declare const THIN_HOOK_CLAUDE = "## OrbitMap\n\nThis project tracks work in OrbitMap via the `orbitmap` CLI (works the same whether data\nis in the cloud or in local files). When the user mentions tasks, backlog, missions,\nintents, ideas, issues, vibes, or asks you to work on / log / plan something, load the\nmatching skill: `orbitmap` (context & commands), `orbitmap-working` (doing tasks),\n`orbitmap-planning` (missions/intents/ideas/issues), `orbitmap-docs` (documents).\nGolden rules: work on ONE task at a time; NEVER finish a task session without a final\n`orbitmap log` entry and an `orbitmap status` update; finished work defaults to\n`in_review`, not `done`. NEVER edit files inside the OrbitMap workspace directory\ndirectly \u2014 always go through `orbitmap` commands.";
-export declare const THIN_HOOK_GENERIC = "## OrbitMap\n\nThis project tracks work in OrbitMap via the `orbitmap` CLI (works the same whether data\nis in the cloud or in local files). When the user mentions tasks, backlog, missions,\nintents, ideas, issues, vibes, or asks you to work on / log / plan something, follow the\nsections below: core (context & commands), working on tasks, planning\n(missions/intents/ideas/issues), and documents.\nGolden rules: work on ONE task at a time; NEVER finish a task session without a final\n`orbitmap log` entry and an `orbitmap status` update; finished work defaults to\n`in_review`, not `done`. NEVER edit files inside the OrbitMap workspace directory\ndirectly \u2014 always go through `orbitmap` commands.";
+export declare const THIN_HOOK_CLAUDE = "## OrbitMap\n\nThis project tracks work in OrbitMap via the `orbitmap` CLI (cloud or local files alike).\nYou work in a WORKSPACE: run `orbitmap context` first \u2014 one call gives the workspace, your\nareas, the active mission, open intents, tasks and documents. Never ask which area \u2014 it\nfollows from the directory (map in `.orbitmap/config.json`); missions, intents and docs\nneed none. When the user mentions tasks, backlog, missions, intents, ideas, issues, vibes,\nor asks you to work on / log / plan something, load the matching skill: `orbitmap`\n(context & commands), `orbitmap-working` (doing tasks), `orbitmap-planning`\n(missions/intents/ideas/issues), `orbitmap-docs` (documents).\nGolden rules: ONE task at a time; NEVER finish a task session without a final\n`orbitmap log` entry and an `orbitmap status` update; finished work defaults to\n`in_review`, not `done`. NEVER edit workspace files directly \u2014 always use `orbitmap`.";
+export declare const THIN_HOOK_GENERIC = "## OrbitMap\n\nThis project tracks work in OrbitMap via the `orbitmap` CLI (cloud or local files alike).\nYou work in a WORKSPACE: run `orbitmap context` first \u2014 one call gives the workspace, your\nareas, the active mission, open intents, tasks and documents. Never ask which area \u2014 it\nfollows from the directory (map in `.orbitmap/config.json`); missions, intents and docs\nneed none. When the user mentions tasks, backlog, missions, intents, ideas, issues, vibes,\nor asks you to work on / log / plan something, follow the sections below: core (context &\ncommands), working on tasks, planning (missions/intents/ideas/issues), and documents.\nGolden rules: ONE task at a time; NEVER finish a task session without a final\n`orbitmap log` entry and an `orbitmap status` update; finished work defaults to\n`in_review`, not `done`. NEVER edit workspace files directly \u2014 always use `orbitmap`.";
 /** Build one SKILL.md file (frontmatter + body) for Claude. */
 export declare function buildSkillFile(skill: SkillDef): string;
-/** Build the thin always-on block for a Claude config file (CLAUDE.md). */
-export declare function buildClaudeHook(): string;
+/**
+ * One extra line appended to the Claude hook when the skills were installed at PROJECT
+ * scope. `CLAUDE.md` is inherited by every sub-directory, but a project-level
+ * `.claude/skills/` directory is not: a session started in a sibling or child repository
+ * reads this hook and cannot load the skills it names. The hook must therefore say where
+ * the skills actually are, and how to make them visible everywhere. At user scope the
+ * skills are visible wherever the hook is, so no caveat is needed.
+ */
+export declare const SKILL_SCOPE_CAVEAT_PROJECT: string;
+/**
+ * Build the thin always-on block for a Claude config file (CLAUDE.md).
+ * `scope` is where the accompanying skill files were installed — see
+ * {@link SKILL_SCOPE_CAVEAT_PROJECT}.
+ */
+export declare function buildClaudeHook(scope?: 'user' | 'project'): string;
 /**
  * Build the markdown fallback block for non-Claude agents: the thin hook plus all four
  * skill bodies inlined (no skill ecosystem to lean on).

package/dist/agent-instructions.js

@@ -57,11 +57,35 @@ never read or write the workspace's data files directly. The CLI is the only int
 - Entity numbers (TS-xxxxxx etc.) are accepted by every command that takes an id.
 
 ## Context
-- Area resolves automatically (config/env). Override per call with \`--area <slug>\`.
-- If a command fails asking for area context, run \`orbitmap areas\` to list areas, then
-  retry with \`--area\`.
-- \`orbitmap context\` shows who you are, the workspace, and the active area. Run it when
-  unsure.
+- START HERE, always: \`orbitmap context\`. \`orbitmap context\` is authoritative and returns
+  in ONE call everything a session needs — the agent, the workspace, the areas you work in,
+  the active mission, open intents, your tasks and the documents. Never list areas and never
+  ask the user "which area?" before you have read it.
+- You work in a WORKSPACE, not inside a single area. Missions, intents
+  and documents are workspace-level and take no area — a document is exactly ONE copy,
+  global to the workspace, never per-area. Tasks, vibes, issues and ideas are
+  AREA-scoped.
+- Missions and intents outrank individual tasks. Asked to work on "what matters", take the
+  active mission and open intents from context and pick work that serves them.
+- The area follows from the directory, never from a question to the user:
+  \`.orbitmap/config.json\` maps directories → area slugs at the workspace root, and each
+  area directory carries its own \`.orbitmap/config.json\` marker naming its area. That
+  config is the only source of truth — never hard-code area names anywhere.
+  So: do area-scoped work from the directory it belongs to and let the CLI resolve it.
+- \`--area <slug>\` is an OVERRIDE for a single call, not part of normal usage — reach for it
+  only to read or write outside the area the current directory resolves to.
+- If a command fails with \`AREA_CONTEXT_REQUIRED\`, its details list the mapped
+  directories: cd into the right one, or retry with \`--area <slug>\`.
+- WRITES: the resolved area is a default for *reading*, never a statement of where the
+  work belongs. Before creating anything area-scoped (task, subtask, issue, vibe),
+  derive the target area from the work itself (which repo/package it lives in) and pass
+  \`--area <slug>\` if that differs from the area the CLI echoes. If the work itself is
+  genuinely ambiguous, ASK THE USER; do not guess. There is no
+  \`move\` command: a write in the wrong area has to be recreated.
+- Every write echoes its scope on stderr: \`creates in area <slug> (source: …)\` when it
+  creates an object, \`scoped to area <slug> (source: …)\` when it changes one by id. A
+  \`source\` of \`global ~/.orbitmap/config.json\` is a machine-wide leftover that nothing
+  here chose — treat it as unconfirmed and pass \`--area\` explicitly.
 
 ## Task statuses
 backlog, todo, in_progress, in_review, review_changes, done, blocked.
@@ -69,7 +93,8 @@ backlog, todo, in_progress, in_review, review_changes, done, blocked.
 \`orbitmap tasks --status backlog\` when the user asks about the backlog.
 
 ## Command reference (all commands accept --json)
-- Context: \`orbitmap context\`, \`orbitmap areas\`, \`orbitmap overview\`
+- Context: \`orbitmap context\` (start here), \`orbitmap overview\`, \`orbitmap areas\`
+  (rarely needed — context already lists the areas you work in)
 - Tasks: \`orbitmap tasks [--status s1,s2]\`, \`orbitmap task TS-x\`, \`orbitmap get <ID>\`,
   \`orbitmap start [TS-x]\`, \`orbitmap status TS-x <status> [--delivery <d>]\`,
   \`orbitmap create "title" [--intent IN-x|--mission MS-x] [--priority p]\`,
@@ -98,18 +123,23 @@ description: >
 export const SKILL_WORKING_BODY = `# Working on OrbitMap tasks
 
 ## Task workflow (on user request)
-When the user asks you to work on tasks:
-1. \`orbitmap tasks --status in_progress\` — check for unfinished work.
-2. If found → \`orbitmap task TS-x\` → read the work log → resume from the resume point.
-3. If not → \`orbitmap start\` — auto-picks the first todo task, sets it in_progress and
-   prints full context (description, agent_instructions, logs).
-4. If no tasks → inform the user.
+When the user asks you to work on tasks — including a vague "work on what's important":
+1. \`orbitmap context\` — the workspace, your areas, the active mission, open intents and
+   your tasks in one call. Do not ask which area and do not list areas first.
+2. Unfinished work in context (or \`orbitmap tasks --status in_progress\`) →
+   \`orbitmap task TS-x\` → read the work log → resume from the resume point.
+3. Otherwise pick work that serves the active mission / open intents, or \`orbitmap start\`
+   — auto-picks the first todo task, sets it in_progress and prints full context
+   (description, agent_instructions, logs).
+4. If there is nothing to pick up → inform the user.
 Use \`orbitmap start TS-x\` to begin a specific task; \`orbitmap task TS-x\` only inspects.
 
 ## Rules
 - Work on ONE task at a time.
 - Always read agent_instructions from the task before implementing. Task-level
   agent_instructions take precedence over area-level instructions.
+- Subtasks never show up in a task list (\`orbitmap context\`, \`orbitmap tasks\`,
+  \`orbitmap start\`) — only inside the parent task you opened with \`orbitmap task TS-x\`.
 - Only work on subtasks assigned to you; do not pick up other agents' subtasks.
 - Do NOT mark a parent task done while it has unfinished subtasks, unless the user
   explicitly asks.
@@ -174,7 +204,7 @@ lifecycle steps as explicit plan items:
   incomplete).
 
 ## Example: completing a task (default → in_review)
-1. \`orbitmap tasks --status in_progress\` → empty
+1. \`orbitmap context\` → workspace, mission, intents, tasks; nothing in_progress
 2. \`orbitmap start\` → task context
 3. read agent_instructions; implement; run tests; commit with \`[TS-x]\` prefix
 4. \`orbitmap log TS-x "Implemented X by doing Y" --type code_change\`
@@ -193,9 +223,12 @@ export const SKILL_PLANNING_BODY = `# Planning in OrbitMap
 
 ## Hierarchy
 Mission (MS-) → Intent (IN-) → Task (TS-) / Issue (IS-). Missions and intents are
-workspace-level; tasks live in areas. An intent groups the tasks/issues that realise one
-goal; a mission time-boxes a set of intents (and directly-attached items) toward an
-outcome. At most ONE mission is active at a time.
+workspace-level and never take an area — plan from anywhere in the workspace, and never
+ask which area to plan in. Tasks and issues are area-scoped. An intent groups the
+tasks/issues that realise one goal; a mission time-boxes a set of intents (and
+directly-attached items) toward an outcome. At most ONE mission is active at a time.
+\`orbitmap context\` already gives you the active mission and the open intents — read it
+before planning instead of listing anything.
 
 ## Missions
 - \`orbitmap mission list\` / \`orbitmap mission show MS-x\`
@@ -246,6 +279,9 @@ description: >
 ---`;
 export const SKILL_DOCS_BODY = `# OrbitMap documents
 
+Documents are workspace-level: exactly ONE copy per workspace, never per-area. No document
+command takes an area, and \`orbitmap context\` already lists them.
+
 ## Choosing what to read
 \`orbitmap docs\` lists documents with their \`context\` (when the doc is relevant) and
 \`sections_count\`. Use context to pick the right document; use sections_count to decide
@@ -292,36 +328,56 @@ export const SKILLS = [
 // Claude variant — §8.2, verbatim (without the markers, which buildClaudeHook adds).
 export const THIN_HOOK_CLAUDE = `## OrbitMap
 
-This project tracks work in OrbitMap via the \`orbitmap\` CLI (works the same whether data
-is in the cloud or in local files). When the user mentions tasks, backlog, missions,
-intents, ideas, issues, vibes, or asks you to work on / log / plan something, load the
-matching skill: \`orbitmap\` (context & commands), \`orbitmap-working\` (doing tasks),
-\`orbitmap-planning\` (missions/intents/ideas/issues), \`orbitmap-docs\` (documents).
-Golden rules: work on ONE task at a time; NEVER finish a task session without a final
+This project tracks work in OrbitMap via the \`orbitmap\` CLI (cloud or local files alike).
+You work in a WORKSPACE: run \`orbitmap context\` first — one call gives the workspace, your
+areas, the active mission, open intents, tasks and documents. Never ask which area — it
+follows from the directory (map in \`.orbitmap/config.json\`); missions, intents and docs
+need none. When the user mentions tasks, backlog, missions, intents, ideas, issues, vibes,
+or asks you to work on / log / plan something, load the matching skill: \`orbitmap\`
+(context & commands), \`orbitmap-working\` (doing tasks), \`orbitmap-planning\`
+(missions/intents/ideas/issues), \`orbitmap-docs\` (documents).
+Golden rules: ONE task at a time; NEVER finish a task session without a final
 \`orbitmap log\` entry and an \`orbitmap status\` update; finished work defaults to
-\`in_review\`, not \`done\`. NEVER edit files inside the OrbitMap workspace directory
-directly — always go through \`orbitmap\` commands.`;
+\`in_review\`, not \`done\`. NEVER edit workspace files directly — always use \`orbitmap\`.`;
 // Non-Claude variant: same rules, but points at the inlined sections below instead of
 // skills that these agents cannot load.
 export const THIN_HOOK_GENERIC = `## OrbitMap
 
-This project tracks work in OrbitMap via the \`orbitmap\` CLI (works the same whether data
-is in the cloud or in local files). When the user mentions tasks, backlog, missions,
-intents, ideas, issues, vibes, or asks you to work on / log / plan something, follow the
-sections below: core (context & commands), working on tasks, planning
-(missions/intents/ideas/issues), and documents.
-Golden rules: work on ONE task at a time; NEVER finish a task session without a final
+This project tracks work in OrbitMap via the \`orbitmap\` CLI (cloud or local files alike).
+You work in a WORKSPACE: run \`orbitmap context\` first — one call gives the workspace, your
+areas, the active mission, open intents, tasks and documents. Never ask which area — it
+follows from the directory (map in \`.orbitmap/config.json\`); missions, intents and docs
+need none. When the user mentions tasks, backlog, missions, intents, ideas, issues, vibes,
+or asks you to work on / log / plan something, follow the sections below: core (context &
+commands), working on tasks, planning (missions/intents/ideas/issues), and documents.
+Golden rules: ONE task at a time; NEVER finish a task session without a final
 \`orbitmap log\` entry and an \`orbitmap status\` update; finished work defaults to
-\`in_review\`, not \`done\`. NEVER edit files inside the OrbitMap workspace directory
-directly — always go through \`orbitmap\` commands.`;
+\`in_review\`, not \`done\`. NEVER edit workspace files directly — always use \`orbitmap\`.`;
 // ── Assembly helpers ───────────────────────────────────────────────────────────
 /** Build one SKILL.md file (frontmatter + body) for Claude. */
 export function buildSkillFile(skill) {
     return `${skill.frontmatter}\n\n${skill.body}\n`;
 }
-/** Build the thin always-on block for a Claude config file (CLAUDE.md). */
-export function buildClaudeHook() {
-    return `${MARKER_START}\n${THIN_HOOK_CLAUDE}\n${MARKER_END}`;
+/**
+ * One extra line appended to the Claude hook when the skills were installed at PROJECT
+ * scope. `CLAUDE.md` is inherited by every sub-directory, but a project-level
+ * `.claude/skills/` directory is not: a session started in a sibling or child repository
+ * reads this hook and cannot load the skills it names. The hook must therefore say where
+ * the skills actually are, and how to make them visible everywhere. At user scope the
+ * skills are visible wherever the hook is, so no caveat is needed.
+ */
+export const SKILL_SCOPE_CAVEAT_PROJECT = 'These skills are installed at PROJECT scope, in this directory\'s `.claude/skills/`. ' +
+    'If you cannot load them (e.g. this session started in a different directory), do not ' +
+    'guess the workflow — ask the user to run `orbitmap setup-agent --scope user`, which ' +
+    'installs them into `~/.claude/skills/` where every session can see them.';
+/**
+ * Build the thin always-on block for a Claude config file (CLAUDE.md).
+ * `scope` is where the accompanying skill files were installed — see
+ * {@link SKILL_SCOPE_CAVEAT_PROJECT}.
+ */
+export function buildClaudeHook(scope = 'user') {
+    const body = scope === 'project' ? `${THIN_HOOK_CLAUDE}\n${SKILL_SCOPE_CAVEAT_PROJECT}` : THIN_HOOK_CLAUDE;
+    return `${MARKER_START}\n${body}\n${MARKER_END}`;
 }
 /**
  * Build the markdown fallback block for non-Claude agents: the thin hook plus all four

package/dist/agent-instructions.js.map

@@ -1 +1 @@
-{"version":3,"file":"agent-instructions.js","sourceRoot":"","sources":["../src/agent-instructions.ts"],"names":[],"mappings":"AAAA,yEAAyE;AACzE,EAAE;AACF,2DAA2D;AAC3D,oFAAoF;AACpF,oFAAoF;AACpF,oFAAoF;AACpF,+EAA+E;AAC/E,+EAA+E;AAC/E,uEAAuE;AACvE,iFAAiF;AACjF,oFAAoF;AACpF,+EAA+E;AAC/E,wDAAwD;AACxD,0CAA0C;AAC1C,wFAAwF;AACxF,uFAAuF;AACvF,oFAAoF;AACpF,qFAAqF;AACrF,EAAE;AACF,+DAA+D;AAC/D,gEAAgE;AAChE,uFAAuF;AACvF,uEAAuE;AAEvE,MAAM,CAAC,MAAM,YAAY,GAAG,yBAAyB,CAAC;AACtD,MAAM,CAAC,MAAM,UAAU,GAAG,uBAAuB,CAAC;AAElD,2EAA2E;AAC3E,MAAM,CAAC,MAAM,UAAU,GAAG,UAAU,CAAC;AAErC,kFAAkF;AAElF,MAAM,CAAC,MAAM,0BAA0B,GAAG;;;;;;IAMtC,CAAC;AAEL,MAAM,CAAC,MAAM,mBAAmB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gEAqD6B,CAAC;AAEjE,kFAAkF;AAElF,MAAM,CAAC,MAAM,yBAAyB,GAAG;;;;;;IAMrC,CAAC;AAEL,MAAM,CAAC,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;2DAoFyB,CAAC;AAE5D,kFAAkF;AAElF,MAAM,CAAC,MAAM,0BAA0B,GAAG;;;;;;;IAOtC,CAAC;AAEL,MAAM,CAAC,MAAM,mBAAmB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;4BA8CP,CAAC;AAE7B,kFAAkF;AAElF,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;IAMlC,CAAC;AAEL,MAAM,CAAC,MAAM,eAAe,GAAG;;;;;;;;;;;;;;;;;;;;;4DAqB6B,CAAC;AAa7D,MAAM,CAAC,MAAM,MAAM,GAAwB;IACzC;QACE,IAAI,EAAE,UAAU;QAChB,WAAW,EAAE,0BAA0B;QACvC,IAAI,EAAE,mBAAmB;KAC1B;IACD;QACE,IAAI,EAAE,kBAAkB;QACxB,WAAW,EAAE,yBAAyB;QACtC,IAAI,EAAE,kBAAkB;KACzB;IACD;QACE,IAAI,EAAE,mBAAmB;QACzB,WAAW,EAAE,0BAA0B;QACvC,IAAI,EAAE,mBAAmB;KAC1B;IACD;QACE,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,sBAAsB;QACnC,IAAI,EAAE,eAAe;KACtB;CACO,CAAC;AAEX,kFAAkF;AAElF,qFAAqF;AACrF,MAAM,CAAC,MAAM,gBAAgB,GAAG;;;;;;;;;;oDAUoB,CAAC;AAErD,sFAAsF;AACtF,wCAAwC;AACxC,MAAM,CAAC,MAAM,iBAAiB,GAAG;;;;;;;;;;oDAUmB,CAAC;AAErD,kFAAkF;AAElF,+DAA+D;AAC/D,MAAM,UAAU,cAAc,CAAC,KAAe;IAC5C,OAAO,GAAG,KAAK,CAAC,WAAW,OAAO,KAAK,CAAC,IAAI,IAAI,CAAC;AACnD,CAAC;AAED,2EAA2E;AAC3E,MAAM,UAAU,eAAe;IAC7B,OAAO,GAAG,YAAY,KAAK,gBAAgB,KAAK,UAAU,EAAE,CAAC;AAC/D,CAAC;AAED;;;GAGG;AACH,MAAM,UAAU,iBAAiB;IAC/B,MAAM,MAAM,GAAG,MAAM,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,aAAa,CAAC,CAAC;IACrE,OAAO,GAAG,YAAY,KAAK,iBAAiB,OAAO,MAAM,KAAK,UAAU,EAAE,CAAC;AAC7E,CAAC"}
+{"version":3,"file":"agent-instructions.js","sourceRoot":"","sources":["../src/agent-instructions.ts"],"names":[],"mappings":"AAAA,yEAAyE;AACzE,EAAE;AACF,2DAA2D;AAC3D,oFAAoF;AACpF,oFAAoF;AACpF,oFAAoF;AACpF,+EAA+E;AAC/E,+EAA+E;AAC/E,uEAAuE;AACvE,iFAAiF;AACjF,oFAAoF;AACpF,+EAA+E;AAC/E,wDAAwD;AACxD,0CAA0C;AAC1C,wFAAwF;AACxF,uFAAuF;AACvF,oFAAoF;AACpF,qFAAqF;AACrF,EAAE;AACF,+DAA+D;AAC/D,gEAAgE;AAChE,uFAAuF;AACvF,uEAAuE;AAEvE,MAAM,CAAC,MAAM,YAAY,GAAG,yBAAyB,CAAC;AACtD,MAAM,CAAC,MAAM,UAAU,GAAG,uBAAuB,CAAC;AAElD,2EAA2E;AAC3E,MAAM,CAAC,MAAM,UAAU,GAAG,UAAU,CAAC;AAErC,kFAAkF;AAElF,MAAM,CAAC,MAAM,0BAA0B,GAAG;;;;;;IAMtC,CAAC;AAEL,MAAM,CAAC,MAAM,mBAAmB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gEA8E6B,CAAC;AAEjE,kFAAkF;AAElF,MAAM,CAAC,MAAM,yBAAyB,GAAG;;;;;;IAMrC,CAAC;AAEL,MAAM,CAAC,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;2DAyFyB,CAAC;AAE5D,kFAAkF;AAElF,MAAM,CAAC,MAAM,0BAA0B,GAAG;;;;;;;IAOtC,CAAC;AAEL,MAAM,CAAC,MAAM,mBAAmB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;4BAiDP,CAAC;AAE7B,kFAAkF;AAElF,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;IAMlC,CAAC;AAEL,MAAM,CAAC,MAAM,eAAe,GAAG;;;;;;;;;;;;;;;;;;;;;;;;4DAwB6B,CAAC;AAa7D,MAAM,CAAC,MAAM,MAAM,GAAwB;IACzC;QACE,IAAI,EAAE,UAAU;QAChB,WAAW,EAAE,0BAA0B;QACvC,IAAI,EAAE,mBAAmB;KAC1B;IACD;QACE,IAAI,EAAE,kBAAkB;QACxB,WAAW,EAAE,yBAAyB;QACtC,IAAI,EAAE,kBAAkB;KACzB;IACD;QACE,IAAI,EAAE,mBAAmB;QACzB,WAAW,EAAE,0BAA0B;QACvC,IAAI,EAAE,mBAAmB;KAC1B;IACD;QACE,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,sBAAsB;QACnC,IAAI,EAAE,eAAe;KACtB;CACO,CAAC;AAEX,kFAAkF;AAElF,qFAAqF;AACrF,MAAM,CAAC,MAAM,gBAAgB,GAAG;;;;;;;;;;;;4FAY4D,CAAC;AAE7F,sFAAsF;AACtF,wCAAwC;AACxC,MAAM,CAAC,MAAM,iBAAiB,GAAG;;;;;;;;;;;4FAW2D,CAAC;AAE7F,kFAAkF;AAElF,+DAA+D;AAC/D,MAAM,UAAU,cAAc,CAAC,KAAe;IAC5C,OAAO,GAAG,KAAK,CAAC,WAAW,OAAO,KAAK,CAAC,IAAI,IAAI,CAAC;AACnD,CAAC;AAED;;;;;;;GAOG;AACH,MAAM,CAAC,MAAM,0BAA0B,GACrC,uFAAuF;IACvF,uFAAuF;IACvF,sFAAsF;IACtF,0EAA0E,CAAC;AAE7E;;;;GAIG;AACH,MAAM,UAAU,eAAe,CAAC,QAA4B,MAAM;IAChE,MAAM,IAAI,GACR,KAAK,KAAK,SAAS,CAAC,CAAC,CAAC,GAAG,gBAAgB,KAAK,0BAA0B,EAAE,CAAC,CAAC,CAAC,gBAAgB,CAAC;IAChG,OAAO,GAAG,YAAY,KAAK,IAAI,KAAK,UAAU,EAAE,CAAC;AACnD,CAAC;AAED;;;GAGG;AACH,MAAM,UAAU,iBAAiB;IAC/B,MAAM,MAAM,GAAG,MAAM,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,aAAa,CAAC,CAAC;IACrE,OAAO,GAAG,YAAY,KAAK,iBAAiB,OAAO,MAAM,KAAK,UAAU,EAAE,CAAC;AAC7E,CAAC"}

package/dist/area-directories.d.ts

@@ -0,0 +1,75 @@
+/**
+ * Which directory holds which area's code — the guessing half of the workspace-first
+ * `orbitmap init` (schema v2).
+ *
+ * A workspace groups several areas, and on this machine each of them is (usually) a
+ * directory: either a subdirectory of an umbrella checkout, or the repository the user is
+ * standing in. Nothing on the server records that mapping — it is per machine — so `init`
+ * has to infer it and then write it down (`config.json` `areas` for in-tree directories,
+ * `link.json` `areas` for the rest).
+ *
+ * Three signals, in decreasing order of confidence, all of them cheap and offline:
+ *
+ * 1. **`name`** — the directory is literally named after the area slug. Unambiguous.
+ * 2. **`git-remote`** — the directory's `origin` remote is the area's `git_url`. The
+ *    strongest signal there is (an area *is* a repository in the data model), and the only
+ *    one that survives a renamed checkout.
+ * 3. **`slugified-name`** — slugifying the directory name yields the slug (`My App` →
+ *    `my-app`), i.e. the same rule the server used to make the slug in the first place.
+ *
+ * The git remote is read from `.git/config` rather than by spawning `git`: the CLI's tests
+ * are offline and process-free by policy, a subprocess per candidate directory is the
+ * slowest thing `init` could possibly do, and the file format has been stable for two
+ * decades. Anything not matched by these three is asked about (or skipped) — never guessed.
+ */
+/** As much of an area as the mapping needs; satisfied by `GET /areas` entries. */
+export interface AreaLike {
+    slug: string;
+    name?: string;
+    /** Repository URL recorded on the area, when the provider returns one. */
+    git_url?: string | null;
+}
+/** Which signal produced a directory ↔ area pairing. */
+export type AreaMatchKind = 'name' | 'git-remote' | 'slugified-name';
+/** One inferred pairing. */
+export interface AreaDirectoryMatch<T extends AreaLike = AreaLike> {
+    area: T;
+    /** Absolute directory. */
+    dir: string;
+    how: AreaMatchKind;
+}
+/**
+ * Immediate subdirectories of `root` that could plausibly be an area checkout — absolute
+ * paths, sorted, dot-directories and the usual build/dependency noise removed.
+ *
+ * Deliberately one level deep: deeper nesting is a real layout but scanning for it turns a
+ * setup command into a filesystem crawl, and the manual answer covers it in one line.
+ */
+export declare function listCandidateDirectories(root: string): string[];
+/**
+ * Comparable form of a git URL: scheme, credentials, the `.git` suffix and the
+ * `git@host:path` / `https://host/path` spelling difference all removed, so the two ways of
+ * writing the same repository compare equal.
+ */
+export declare function normalizeGitUrl(url: string): string;
+/**
+ * The `origin` remote URL recorded in `dir`'s git config, or `undefined` when `dir` is not a
+ * checkout (or has no origin). Handles the `.git`-as-a-file form that worktrees and
+ * submodules use.
+ */
+export declare function readGitRemoteUrl(dir: string): string | undefined;
+/** True when `dir` is the checkout of `area`, by any of the three signals. */
+export declare function matchDirectoryToArea(dir: string, area: AreaLike): AreaMatchKind | undefined;
+/**
+ * Guess a directory under `root` for each area, and report which areas got none.
+ *
+ * One directory is never handed to two areas: the candidates are consumed as they match, in
+ * area order, so a `name` hit for one area cannot be stolen by a `slugified-name` hit for
+ * another.
+ */
+export declare function detectAreaDirectories<T extends AreaLike>(root: string, areas: T[], candidates?: string[]): {
+    matched: Array<AreaDirectoryMatch<T>>;
+    unmatched: T[];
+};
+/** The inverse question: standing in `dir`, which of these areas is it? */
+export declare function detectAreaForDirectory<T extends AreaLike>(dir: string, areas: T[]): AreaDirectoryMatch<T> | undefined;

package/dist/area-directories.js

@@ -0,0 +1,162 @@
+/**
+ * Which directory holds which area's code — the guessing half of the workspace-first
+ * `orbitmap init` (schema v2).
+ *
+ * A workspace groups several areas, and on this machine each of them is (usually) a
+ * directory: either a subdirectory of an umbrella checkout, or the repository the user is
+ * standing in. Nothing on the server records that mapping — it is per machine — so `init`
+ * has to infer it and then write it down (`config.json` `areas` for in-tree directories,
+ * `link.json` `areas` for the rest).
+ *
+ * Three signals, in decreasing order of confidence, all of them cheap and offline:
+ *
+ * 1. **`name`** — the directory is literally named after the area slug. Unambiguous.
+ * 2. **`git-remote`** — the directory's `origin` remote is the area's `git_url`. The
+ *    strongest signal there is (an area *is* a repository in the data model), and the only
+ *    one that survives a renamed checkout.
+ * 3. **`slugified-name`** — slugifying the directory name yields the slug (`My App` →
+ *    `my-app`), i.e. the same rule the server used to make the slug in the first place.
+ *
+ * The git remote is read from `.git/config` rather than by spawning `git`: the CLI's tests
+ * are offline and process-free by policy, a subprocess per candidate directory is the
+ * slowest thing `init` could possibly do, and the file format has been stable for two
+ * decades. Anything not matched by these three is asked about (or skipped) — never guessed.
+ */
+import { existsSync, readFileSync, readdirSync, statSync } from 'node:fs';
+import { basename, isAbsolute, join, resolve } from 'node:path';
+import { slugify } from './adapters/local/store.js';
+/** Directory names never worth scanning as an area checkout. */
+const SKIP_DIRS = new Set([
+    'node_modules',
+    'vendor',
+    'dist',
+    'build',
+    'out',
+    'target',
+    'coverage',
+    'tmp',
+    '__pycache__',
+]);
+/**
+ * Immediate subdirectories of `root` that could plausibly be an area checkout — absolute
+ * paths, sorted, dot-directories and the usual build/dependency noise removed.
+ *
+ * Deliberately one level deep: deeper nesting is a real layout but scanning for it turns a
+ * setup command into a filesystem crawl, and the manual answer covers it in one line.
+ */
+export function listCandidateDirectories(root) {
+    let entries;
+    try {
+        entries = readdirSync(resolve(root), { withFileTypes: true });
+    }
+    catch {
+        return [];
+    }
+    return entries
+        .filter((entry) => entry.isDirectory())
+        .map((entry) => entry.name)
+        .filter((name) => !name.startsWith('.') && !SKIP_DIRS.has(name.toLowerCase()))
+        .sort()
+        .map((name) => join(resolve(root), name));
+}
+/**
+ * Comparable form of a git URL: scheme, credentials, the `.git` suffix and the
+ * `git@host:path` / `https://host/path` spelling difference all removed, so the two ways of
+ * writing the same repository compare equal.
+ */
+export function normalizeGitUrl(url) {
+    let out = url.trim().toLowerCase();
+    if (!out)
+        return '';
+    out = out.replace(/^git\+/, '');
+    out = out.replace(/^[a-z][a-z0-9+.-]*:\/\//, '');
+    out = out.replace(/^[^/@]+@/, '');
+    // scp-style `host:org/repo` → `host/org/repo`; a `:port` (digits) is left alone.
+    out = out.replace(/^([^/:]+):(?!\d)/, '$1/');
+    out = out.replace(/\.git$/, '');
+    return out.replace(/\/+$/, '');
+}
+/**
+ * The `origin` remote URL recorded in `dir`'s git config, or `undefined` when `dir` is not a
+ * checkout (or has no origin). Handles the `.git`-as-a-file form that worktrees and
+ * submodules use.
+ */
+export function readGitRemoteUrl(dir) {
+    const gitPath = join(resolve(dir), '.git');
+    if (!existsSync(gitPath))
+        return undefined;
+    let configFile = join(gitPath, 'config');
+    try {
+        if (statSync(gitPath).isFile()) {
+            const pointer = readFileSync(gitPath, 'utf-8').match(/^gitdir:\s*(.+)$/m)?.[1]?.trim();
+            if (!pointer)
+                return undefined;
+            configFile = join(isAbsolute(pointer) ? pointer : resolve(dir, pointer), 'config');
+        }
+        if (!existsSync(configFile))
+            return undefined;
+        const contents = readFileSync(configFile, 'utf-8');
+        // Only the `[remote "origin"]` section: any other remote (a fork, a mirror) is a
+        // different repository as far as identifying an area goes.
+        const section = contents.split(/^\[/m).find((part) => /^remote\s+"origin"\]/.test(part));
+        return section?.match(/^\s*url\s*=\s*(.+)$/m)?.[1]?.trim() || undefined;
+    }
+    catch {
+        return undefined;
+    }
+}
+/** True when `dir` is the checkout of `area`, by any of the three signals. */
+export function matchDirectoryToArea(dir, area) {
+    const name = basename(resolve(dir));
+    if (name === area.slug)
+        return 'name';
+    if (area.git_url) {
+        const remote = readGitRemoteUrl(dir);
+        if (remote && normalizeGitUrl(remote) === normalizeGitUrl(area.git_url))
+            return 'git-remote';
+    }
+    if (slugify(name) === area.slug)
+        return 'slugified-name';
+    return undefined;
+}
+/**
+ * Guess a directory under `root` for each area, and report which areas got none.
+ *
+ * One directory is never handed to two areas: the candidates are consumed as they match, in
+ * area order, so a `name` hit for one area cannot be stolen by a `slugified-name` hit for
+ * another.
+ */
+export function detectAreaDirectories(root, areas, candidates = listCandidateDirectories(root)) {
+    const remaining = [...candidates];
+    const matched = [];
+    const unmatched = [];
+    for (const area of areas) {
+        // The signals are tried in confidence order across *all* remaining candidates, so a
+        // weak match on an early directory never beats a strong one further down the list.
+        let hit;
+        for (const how of ['name', 'git-remote', 'slugified-name']) {
+            const dir = remaining.find((candidate) => matchDirectoryToArea(candidate, area) === how);
+            if (dir) {
+                hit = { dir, how };
+                break;
+            }
+        }
+        if (!hit) {
+            unmatched.push(area);
+            continue;
+        }
+        remaining.splice(remaining.indexOf(hit.dir), 1);
+        matched.push({ area, dir: hit.dir, how: hit.how });
+    }
+    return { matched, unmatched };
+}
+/** The inverse question: standing in `dir`, which of these areas is it? */
+export function detectAreaForDirectory(dir, areas) {
+    for (const how of ['name', 'git-remote', 'slugified-name']) {
+        const area = areas.find((candidate) => matchDirectoryToArea(dir, candidate) === how);
+        if (area)
+            return { area, dir: resolve(dir), how };
+    }
+    return undefined;
+}
+//# sourceMappingURL=area-directories.js.map

package/dist/area-directories.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"area-directories.js","sourceRoot":"","sources":["../src/area-directories.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AAEH,OAAO,EAAE,UAAU,EAAE,YAAY,EAAE,WAAW,EAAE,QAAQ,EAAE,MAAM,SAAS,CAAC;AAC1E,OAAO,EAAE,QAAQ,EAAE,UAAU,EAAE,IAAI,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAEhE,OAAO,EAAE,OAAO,EAAE,MAAM,2BAA2B,CAAC;AAqBpD,gEAAgE;AAChE,MAAM,SAAS,GAAG,IAAI,GAAG,CAAC;IACxB,cAAc;IACd,QAAQ;IACR,MAAM;IACN,OAAO;IACP,KAAK;IACL,QAAQ;IACR,UAAU;IACV,KAAK;IACL,aAAa;CACd,CAAC,CAAC;AAEH;;;;;;GAMG;AACH,MAAM,UAAU,wBAAwB,CAAC,IAAY;IACnD,IAAI,OAAO,CAAC;IACZ,IAAI,CAAC;QACH,OAAO,GAAG,WAAW,CAAC,OAAO,CAAC,IAAI,CAAC,EAAE,EAAE,aAAa,EAAE,IAAI,EAAE,CAAC,CAAC;IAChE,CAAC;IAAC,MAAM,CAAC;QACP,OAAO,EAAE,CAAC;IACZ,CAAC;IAED,OAAO,OAAO;SACX,MAAM,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,WAAW,EAAE,CAAC;SACtC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC;SAC1B,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC,IAAI,CAAC,UAAU,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,GAAG,CAAC,IAAI,CAAC,WAAW,EAAE,CAAC,CAAC;SAC7E,IAAI,EAAE;SACN,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,EAAE,IAAI,CAAC,CAAC,CAAC;AAC9C,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,eAAe,CAAC,GAAW;IACzC,IAAI,GAAG,GAAG,GAAG,CAAC,IAAI,EAAE,CAAC,WAAW,EAAE,CAAC;IACnC,IAAI,CAAC,GAAG;QAAE,OAAO,EAAE,CAAC;IACpB,GAAG,GAAG,GAAG,CAAC,OAAO,CAAC,QAAQ,EAAE,EAAE,CAAC,CAAC;IAChC,GAAG,GAAG,GAAG,CAAC,OAAO,CAAC,yBAAyB,EAAE,EAAE,CAAC,CAAC;IACjD,GAAG,GAAG,GAAG,CAAC,OAAO,CAAC,UAAU,EAAE,EAAE,CAAC,CAAC;IAClC,iFAAiF;IACjF,GAAG,GAAG,GAAG,CAAC,OAAO,CAAC,kBAAkB,EAAE,KAAK,CAAC,CAAC;IAC7C,GAAG,GAAG,GAAG,CAAC,OAAO,CAAC,QAAQ,EAAE,EAAE,CAAC,CAAC;IAChC,OAAO,GAAG,CAAC,OAAO,CAAC,MAAM,EAAE,EAAE,CAAC,CAAC;AACjC,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,gBAAgB,CAAC,GAAW;IAC1C,MAAM,OAAO,GAAG,IAAI,CAAC,OAAO,CAAC,GAAG,CAAC,EAAE,MAAM,CAAC,CAAC;IAC3C,IAAI,CAAC,UAAU,CAAC,OAAO,CAAC;QAAE,OAAO,SAAS,CAAC;IAE3C,IAAI,UAAU,GAAG,IAAI,CAAC,OAAO,EAAE,QAAQ,CAAC,CAAC;IACzC,IAAI,CAAC;QACH,IAAI,QAAQ,CAAC,OAAO,CAAC,CAAC,MAAM,EAAE,EAAE,CAAC;YAC/B,MAAM,OAAO,GAAG,YAAY,CAAC,OAAO,EAAE,OAAO,CAAC,CAAC,KAAK,CAAC,mBAAmB,CAAC,EAAE,CAAC,CAAC,CAAC,EAAE,IAAI,EAAE,CAAC;YACvF,IAAI,CAAC,OAAO;gBAAE,OAAO,SAAS,CAAC;YAC/B,UAAU,GAAG,IAAI,CAAC,UAAU,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,OAAO,CAAC,GAAG,EAAE,OAAO,CAAC,EAAE,QAAQ,CAAC,CAAC;QACrF,CAAC;QACD,IAAI,CAAC,UAAU,CAAC,UAAU,CAAC;YAAE,OAAO,SAAS,CAAC;QAE9C,MAAM,QAAQ,GAAG,YAAY,CAAC,UAAU,EAAE,OAAO,CAAC,CAAC;QACnD,iFAAiF;QACjF,2DAA2D;QAC3D,MAAM,OAAO,GAAG,QAAQ,CAAC,KAAK,CAAC,MAAM,CAAC,CAAC,IAAI,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,sBAAsB,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC;QACzF,OAAO,OAAO,EAAE,KAAK,CAAC,sBAAsB,CAAC,EAAE,CAAC,CAAC,CAAC,EAAE,IAAI,EAAE,IAAI,SAAS,CAAC;IAC1E,CAAC;IAAC,MAAM,CAAC;QACP,OAAO,SAAS,CAAC;IACnB,CAAC;AACH,CAAC;AAED,8EAA8E;AAC9E,MAAM,UAAU,oBAAoB,CAAC,GAAW,EAAE,IAAc;IAC9D,MAAM,IAAI,GAAG,QAAQ,CAAC,OAAO,CAAC,GAAG,CAAC,CAAC,CAAC;IACpC,IAAI,IAAI,KAAK,IAAI,CAAC,IAAI;QAAE,OAAO,MAAM,CAAC;IAEtC,IAAI,IAAI,CAAC,OAAO,EAAE,CAAC;QACjB,MAAM,MAAM,GAAG,gBAAgB,CAAC,GAAG,CAAC,CAAC;QACrC,IAAI,MAAM,IAAI,eAAe,CAAC,MAAM,CAAC,KAAK,eAAe,CAAC,IAAI,CAAC,OAAO,CAAC;YAAE,OAAO,YAAY,CAAC;IAC/F,CAAC;IAED,IAAI,OAAO,CAAC,IAAI,CAAC,KAAK,IAAI,CAAC,IAAI;QAAE,OAAO,gBAAgB,CAAC;IACzD,OAAO,SAAS,CAAC;AACnB,CAAC;AAED;;;;;;GAMG;AACH,MAAM,UAAU,qBAAqB,CACnC,IAAY,EACZ,KAAU,EACV,aAAuB,wBAAwB,CAAC,IAAI,CAAC;IAErD,MAAM,SAAS,GAAG,CAAC,GAAG,UAAU,CAAC,CAAC;IAClC,MAAM,OAAO,GAAiC,EAAE,CAAC;IACjD,MAAM,SAAS,GAAQ,EAAE,CAAC;IAE1B,KAAK,MAAM,IAAI,IAAI,KAAK,EAAE,CAAC;QACzB,oFAAoF;QACpF,mFAAmF;QACnF,IAAI,GAAoD,CAAC;QACzD,KAAK,MAAM,GAAG,IAAI,CAAC,MAAM,EAAE,YAAY,EAAE,gBAAgB,CAAU,EAAE,CAAC;YACpE,MAAM,GAAG,GAAG,SAAS,CAAC,IAAI,CAAC,CAAC,SAAS,EAAE,EAAE,CAAC,oBAAoB,CAAC,SAAS,EAAE,IAAI,CAAC,KAAK,GAAG,CAAC,CAAC;YACzF,IAAI,GAAG,EAAE,CAAC;gBACR,GAAG,GAAG,EAAE,GAAG,EAAE,GAAG,EAAE,CAAC;gBACnB,MAAM;YACR,CAAC;QACH,CAAC;QAED,IAAI,CAAC,GAAG,EAAE,CAAC;YACT,SAAS,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;YACrB,SAAS;QACX,CAAC;QACD,SAAS,CAAC,MAAM,CAAC,SAAS,CAAC,OAAO,CAAC,GAAG,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC,CAAC;QAChD,OAAO,CAAC,IAAI,CAAC,EAAE,IAAI,EAAE,GAAG,EAAE,GAAG,CAAC,GAAG,EAAE,GAAG,EAAE,GAAG,CAAC,GAAG,EAAE,CAAC,CAAC;IACrD,CAAC;IAED,OAAO,EAAE,OAAO,EAAE,SAAS,EAAE,CAAC;AAChC,CAAC;AAED,2EAA2E;AAC3E,MAAM,UAAU,sBAAsB,CACpC,GAAW,EACX,KAAU;IAEV,KAAK,MAAM,GAAG,IAAI,CAAC,MAAM,EAAE,YAAY,EAAE,gBAAgB,CAAU,EAAE,CAAC;QACpE,MAAM,IAAI,GAAG,KAAK,CAAC,IAAI,CAAC,CAAC,SAAS,EAAE,EAAE,CAAC,oBAAoB,CAAC,GAAG,EAAE,SAAS,CAAC,KAAK,GAAG,CAAC,CAAC;QACrF,IAAI,IAAI;YAAE,OAAO,EAAE,IAAI,EAAE,GAAG,EAAE,OAAO,CAAC,GAAG,CAAC,EAAE,GAAG,EAAE,CAAC;IACpD,CAAC;IACD,OAAO,SAAS,CAAC;AACnB,CAAC"}