rigjs 4.0.6 → 4.0.8

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (15) hide show
  1. package/.claude/skills/rig-wiki/SKILL.md +53 -27
  2. package/RIG_CREW_SKILL.md +31 -8
  3. package/RIG_WIKI_SKILL.md +53 -27
  4. package/built/index.js +176 -182
  5. package/lib/crew/board.ts +8 -3
  6. package/lib/crew/doctor.ts +7 -3
  7. package/lib/crew/index.ts +11 -1
  8. package/lib/crew/project.ts +88 -2
  9. package/lib/crew/role.ts +6 -6
  10. package/lib/crew/task.ts +59 -10
  11. package/lib/crew/vault.ts +67 -17
  12. package/lib/wiki/index.ts +2 -2
  13. package/lib/wiki/ingest.ts +37 -6
  14. package/lib/wiki/init.ts +116 -50
  15. package/package.json +2 -2
package/.claude/skills/rig-wiki/SKILL.md CHANGED
@@ -15,15 +15,19 @@ metadata:
15
15
 
16
16
  **Positioning.** rig wiki is an **agent-facing tool**. Humans don't memorise the CLI; they tell their agent (you) what they want, and you orchestrate `rig wiki *`. Treat any direct user-typed `rig wiki ...` invocation as a fallback — your job is to make raw CLI use unnecessary. Never just hand the user a command and walk away; run it, observe, report.
17
17
 
18
- ## Vault discovery (no registry)
18
+ **Substrate.** rig wiki runs **on top of an Obsidian vault**. The project root IS the Obsidian vault (e.g. `overmind/`); `rig-wiki/` is the metadata subdirectory rig manages inside it. Sibling dirs (`personal/`, `research/`, …) are user-authored data — sources for ingest. All cross-references generated by ingest use `obsidian://open?vault=<name>&file=<vault-rel-path>` URLs, not filesystem paths, so links work the same from inside Obsidian and from terminal-launched tools.
19
19
 
20
- There is **no global registry**. The active vault is resolved by walking up from the current working directory looking for a `.rig/config.yml`. The directory that contains that file IS the vault.
20
+ ## Vault model — one fixed dir per project
21
+
22
+ A vault is **a single `rig-wiki/` dir at the project root** holding metadata (purpose.md, schema.md, page tree, `.rig/config.yml`). The project root itself is the conceptual "vault" — `rig-wiki/` is just the metadata subdir living inside it, named `rig-wiki/` by convention. User-authored data (`personal/`, `research/`, etc.) lives in sibling dirs and is NEVER touched.
23
+
24
+ - **The scope** — which sibling data dir(s) the wiki actually ingests — is recorded in `<rig-wiki>/.rig/config.yml` (`name`, `root`, `include`).
25
+ - **Discovery is automatic.** Any `rig wiki *` command walks up from CWD; at each level it checks both `<dir>/.rig/config.yml` (you're inside the vault) and `<dir>/rig-wiki/.rig/config.yml` (you're at the project root). So `cd` anywhere inside the project works.
21
26
 
22
27
  This means:
23
- - **Always `cd` into the project first.** If the user is in some other CWD, change directory before running any `rig wiki *` command.
24
28
  - **No `--wiki <name>` flag exists.** Don't try to pass one.
25
29
  - **No `rig wiki list`, `register`, or `unregister` commands.** They've been removed.
26
- - If the user is in a project that has no vault, the next step is `rig wiki init <subdir>` (see "Setup" below).
30
+ - If the user is in a project that has no vault, the next step is `rig wiki init <scope>` (see "Setup" below).
27
31
 
28
32
  ## Intent → command map
29
33
 
@@ -42,31 +46,36 @@ This means:
42
46
  ## Vault layout (flat — no inner `wiki/` subdir)
43
47
 
44
48
  ```
45
- <vault>/
46
- purpose.md ← human-authored, never write
47
- schema.md ← human-authored, never write
48
- index.md ← LLM-writable
49
- overview.md ← LLM-writable
50
- log.md ← append-only LLM log
51
- reviews.md ← LLM-writable backlog of human-review items
52
- raw/ ← immutable source files (never edit existing)
53
- sources/ ← one .md per ingested source — page tree at vault root
54
- entities/
55
- concepts/
56
- synthesis/
57
- queries/
58
- .rig/config.yml ← per-vault settings (name, root, include, exclude, …)
59
- .gitignore
49
+ <project>/ ← the conceptual vault (e.g. overmind/)
50
+ rig-wiki/ ← fixed metadata-dir name; created by `rig wiki init`
51
+ purpose.md ← human-authored, never write
52
+ schema.md ← human-authored, never write
53
+ index.md ← LLM-writable
54
+ overview.md ← LLM-writable
55
+ log.md ← append-only LLM log
56
+ reviews.md ← LLM-writable backlog of human-review items
57
+ raw/ ← immutable source files (never edit existing)
58
+ sources/ ← one .md per ingested source — page tree at vault root
59
+ entities/
60
+ concepts/
61
+ synthesis/
62
+ queries/
63
+ .rig/config.yml ← per-vault settings (name, root, include, exclude, …)
64
+ .gitignore
65
+ personal/ ← user-authored data — scope target (NEVER touched)
66
+ research/ ← (other sibling data dirs)
67
+ ...
60
68
  ```
61
69
 
62
- Note: there is no `<vault>/wiki/` subdirectory. Page directories (`sources/`, `entities/`, `concepts/`, `synthesis/`, `queries/`) live directly under the vault root.
70
+ Note: page directories (`sources/`, `entities/`, `concepts/`, `synthesis/`, `queries/`) live directly under `rig-wiki/` — no nested `wiki/` subdir.
63
71
 
64
72
  ## Argument inference rules
65
73
 
66
74
  - **slug** = kebab-case, no dates in page filenames; dates only on `raw/YYYY-MM-DD-*` prefix.
67
75
  - **raw filename** = `YYYY-MM-DD-<slug>.md`. Pick today's local date; if filename collides, append `-2`, `-3`.
68
76
  - **URL → slug**: last path segment, drop extension, lowercase, replace non-`[a-z0-9-]` with `-`, max 64 chars.
69
- - **Default vault dir name** when the user says "init a vault / make a wiki here" without specifying: suggest `rig-wiki` at the project root. Never default silently — confirm the name once.
77
+ - **`rig wiki init <scope>` arg** is a data subdir NAME, not a path to create. Examples: `rig wiki init personal` (scopes to `./personal/`), `rig wiki init research`. The vault metadata dir is always `./rig-wiki/`. Never pass a path like `rig-wiki` — that's the metadata dir, not the scope.
78
+ - **Cross-references** in generated wiki pages: file links → `obsidian://open?vault=<name>&file=<vault-rel>` (the ingest prompt provides the vault name and rel-path); page-to-page links → `[[slug]]` wikilinks. Never put raw absolute paths or `../`-style relative paths in generated content.
70
79
 
71
80
  ## Hard rules — refuse and explain if violated
72
81
 
@@ -83,7 +92,23 @@ The scanner skips these automatically — do not waste user time adding them to
83
92
  - Any path segment starting with `.` (`.git/`, `.obsidian/`, `.vscode/`, `.DS_Store`, …).
84
93
  - Any path matched by the project's `.gitignore`.
85
94
 
86
- What you DO need to put in `exclude` are content-type filters the user cares about — e.g. `**/*.zip`, `**/*.pdf` if they don't want those in their text wiki.
95
+ Defaults in `.rig/config.yml` from `init`:
96
+ - `include: ['**']` — everything that survives the auto-skips
97
+ - `exclude:` — binary archives (`*.zip`, `*.tar`, `*.tar.gz`, `*.tgz`, `*.7z`, `*.rar`). Their contents can't be ingested without unpacking.
98
+
99
+ What you DO need to put in `exclude` is additional content-type filtering the user explicitly asks for.
100
+
101
+ ## Multimodal ingest (what Claude Read can decode)
102
+
103
+ `rig wiki ingest <source>` invokes Claude (`claude -p`) and tells it to Read the source. By type:
104
+
105
+ | Type | Behaviour |
106
+ |---|---|
107
+ | `.md`, `.txt`, `.json`, `.csv`, `.yml`, `.py`, `.ts`, code etc. | Read directly as text. |
108
+ | `.png`, `.jpg`, `.jpeg`, `.gif`, `.webp`, `.bmp` | Claude Read returns visual input; the prompt instructs the model to describe contents, transcribe visible text/numbers, capture structure. |
109
+ | `.pdf` | Claude Read decodes natively. >10 pages: the prompt instructs chunked reads with the `pages` parameter. |
110
+ | `.xlsx`, `.xls`, `.ods`, `.numbers` | **Not natively supported by Read in v1.** Ingest writes a stub source page (filename + obsidian:// URL + last-modified date) and appends a `reviews.md` bullet asking the user to export to CSV / JSON for re-ingest. Don't invent contents. |
111
+ | `.zip` and other archives | Default-excluded; do not ingest. Unpack first, then ingest the unpacked tree. |
87
112
 
88
113
  ## Common error → recovery
89
114
 
@@ -113,19 +138,20 @@ What you DO need to put in `exclude` are content-type filters the user cares abo
113
138
 
114
139
  ## Setup — if no vault is found
115
140
 
116
- `rig wiki scan` (or any command) reports `No rig wiki vault found.` → ask the user **once** (don't list multiple defaults; pick one suggestion and confirm):
141
+ `rig wiki scan` (or any command) reports `No rig wiki vault found.` → ask the user **once** which sibling data dir to scope this wiki to (don't guess silently):
117
142
 
118
- > "No vault here. Want me to init one as `rig-wiki/` at the project root? (or pick another path)"
143
+ > "No vault here. Which subdir should this wiki ingest from — `personal/`, `research/`, …?"
119
144
 
120
145
  Then orchestrate without further prompting:
121
146
 
122
147
  ```bash
123
- rig wiki init rig-wiki # creates <project>/rig-wiki/ with templates + .rig/config.yml
148
+ cd <project> # the root that contains the scope dir
149
+ rig wiki init <scope> # e.g. `rig wiki init personal` → creates ./rig-wiki/, scope = ./personal/
124
150
  ```
125
151
 
126
- After init, **pause and ask the user to edit `<vault>/purpose.md`** (one-time human scoping — define what this wiki is for, in/out of scope). Don't write purpose.md yourself; it's the only human-authored anchor for everything downstream.
152
+ After init, **pause and ask the user to edit `<project>/rig-wiki/purpose.md`** (one-time human scoping — define what this wiki is for, in/out of scope). Don't write purpose.md yourself; it's the only human-authored anchor for everything downstream.
127
153
 
128
- If the user describes a scan scope that differs from the defaults (e.g. "include every md file in `personal/` but ignore zip files"), translate that into edits to `<vault>/.rig/config.yml`. Fields: `name`, optional `root` (relative scan base, default `..`), `include[]`, `exclude[]`, `schedule`, `ingestRules`. The vault is self-contained — nothing about its identity or scope lives outside its own directory.
154
+ If the user wants finer scoping than a single subdir (e.g. "ingest `personal/` but ignore zip files"), translate that into edits to `<project>/rig-wiki/.rig/config.yml`. Fields: `name`, `root` (relative scan base, default `../<scope>`), `include[]`, `exclude[]`, `schedule`, `ingestRules`. Everything about the vault lives in that dir — nothing leaks outside.
129
155
 
130
156
  ## Configuration files
131
157
 
package/RIG_CREW_SKILL.md CHANGED
@@ -41,10 +41,13 @@ Project Owner management:
41
41
  rig crew project add rig --path /path/to/projects/rig --executor claude --test-command "yarn build"
42
42
  rig crew project add dsh-service --path /path/to/projects/dsh-service --executor codex --test-command "yarn test"
43
43
  rig crew project add demo-web --path /path/to/ObsidianVault/tmp/demo-web --executor codex
44
+ rig crew project sync
44
45
  rig crew project list
45
46
  rig crew project status rig
46
47
  ```
47
48
 
49
+ Use `rig crew project sync` after directories are added to or removed from the Vault `projects/` folder. It refreshes the active Project Owner registry and project-scoped agent task folders under `<crew-root>/Projects/`.
50
+
48
51
  ## State Model
49
52
 
50
53
  `rig crew` is file-backed. Do not assume a long-running multi-agent runtime exists.
@@ -57,8 +60,10 @@ rig crew project status rig
57
60
  - Shared context: `<crew-root>/Shared/**`
58
61
  - Role registry for Lead: `<crew-root>/Shared/Roles.md`
59
62
  - Project owner memory: `<crew-root>/Projects/<project>/**`
63
+ - Project-scoped agent tasks: `<crew-root>/Projects/<project>/Agents/<role>/Tasks.md`
64
+ - Large active task batches: `<crew-root>/Projects/<project>/Tasklists/active/*.md` and `<crew-root>/Projects/<project>/Agents/<role>/Tasklists/active/*.md`
65
+ - Reusable role descriptions: `<crew-root>/<role>/Role.md` and `<crew-root>/Roles/<custom-role>/Role.md`
60
66
  - Researcher memory and index: `<crew-root>/Researcher/**`
61
- - Custom role workspaces: `<crew-root>/Roles/<role>/**`
62
67
  - Vault agent instructions: `CLAUDE.md` and `AGENTS.md`
63
68
  - Local cache: `~/.rig/crew-state.json`
64
69
  - Config: `~/.rig/crew.config.json`
@@ -68,7 +73,24 @@ All multi-agent collaboration materials should live inside the Vault. Temporary
68
73
 
69
74
  `rig crew` coordinates multiple roles on one device through one Vault. Do not assume a separate multi-agent runtime inside each project repository; project directories are execution workspaces, while tasks, reports, inbox, dashboard, and research indexes return to the Vault.
70
75
 
71
- `rig crew init` is additive and non-destructive. It may create missing folders/files and update managed blocks, but it must not overwrite existing agent work files such as `Tasks.md`, `Notes.md`, `Role.md`, `Index.md`, reports, specs, decisions, or user-authored notes.
76
+ `rig crew init` is additive and non-destructive. It may create missing folders/files and update managed blocks, but it must not overwrite existing agent work files such as project `Tasks.md`, `Role.md`, `Index.md`, reports, specs, decisions, or user-authored notes.
77
+
78
+ Built-in role directories are reusable role cards, not project task queues. Concrete PM/Coder/Tester/etc work should be assigned under a specific project:
79
+
80
+ ```text
81
+ <crew-root>/Projects/<project>/Tasks.md
82
+ <crew-root>/Projects/<project>/Agents/Coder/Tasks.md
83
+ <crew-root>/Projects/<project>/Agents/Tester/Tasks.md
84
+ ```
85
+
86
+ Keep each `Tasks.md` small. Use it as a current queue or index, not an unlimited backlog. When a project or role has many tasks, split the current work into focused files:
87
+
88
+ ```text
89
+ <crew-root>/Projects/<project>/Tasklists/active/<feature-or-iteration>.md
90
+ <crew-root>/Projects/<project>/Agents/<role>/Tasklists/active/<feature-or-iteration>.md
91
+ ```
92
+
93
+ Move completed or stale batches to `Tasklists/archive/YYYY-MM.md`. The active dashboard scans `Tasks.md` and `Tasklists/active/**/*.md`; it does not scan archive files by default.
72
94
 
73
95
  ## Lead Orchestration
74
96
 
@@ -81,19 +103,20 @@ After handoff, read:
81
103
  - `<crew-root>/Team-Dashboard.md`
82
104
  - `<crew-root>/Inbox.md`
83
105
  - `<crew-root>/Shared/Roles.md`
84
- - role task files such as `<crew-root>/Tester/Tasks.md`
85
106
  - relevant `<crew-root>/Projects/<project>/Tasks.md`
107
+ - relevant `<crew-root>/Projects/<project>/Agents/<role>/Tasks.md`
108
+ - relevant active tasklists under `<crew-root>/Projects/<project>/**/Tasklists/active/`
86
109
 
87
110
  If the CLI is unavailable, use the file protocol:
88
111
 
89
112
  1. Append the request to `<crew-root>/Current-Goal.md`.
90
- 2. Create or update a Lead task in `<crew-root>/Lead/Tasks.md`.
113
+ 2. When a project is known, create or update small/current work in `<crew-root>/Projects/<project>/Tasks.md` or `<crew-root>/Projects/<project>/Agents/<role>/Tasks.md`; split larger batches into `Tasklists/active/<feature-or-iteration>.md`.
91
114
  3. Route worker tasks with inline fields such as `[role:: tester]`, `[owner:: maintainer:rig]`, `[project:: rig]`, `[executor:: codex]`, `[status:: pending]`.
92
115
  4. Put user-facing questions or approvals in `<crew-root>/Inbox.md`.
93
116
 
94
117
  Lead communicates with workers through Markdown tasks, delegation packets, and result notes. Do not rely on private subagent chat state as the coordination source of truth. Subagents are optional executors for specific roles when the selected executor supports them; Vault files remain canonical.
95
118
 
96
- Maintain status awareness before and after work: scan dashboard, inbox, role tasks, project tasks, blockers, and todo status. The coding session should be able to answer what each role/project is doing without asking the human to inspect the Vault manually.
119
+ Maintain status awareness before and after work: scan dashboard, inbox, project owner tasks, project-scoped agent tasks, active tasklists, blockers, and todo status. The coding session should be able to answer what each role/project is doing without asking the human to inspect the Vault manually.
97
120
 
98
121
  ## Mixed Executors
99
122
 
@@ -145,13 +168,13 @@ When a role is materialized in a Vault, use:
145
168
 
146
169
  ```text
147
170
  <crew-root>/Roles/<role>/
148
- ├── Tasks.md
149
- ├── Notes.md
150
171
  ├── Role.md
151
172
  └── Reports/
152
173
  ```
153
174
 
154
- `<crew-root>/Shared/Roles.md` is generated so Lead can load available roles. If the user asks Lead to use a specific role, match that role by `name` first, then route the task with `[role:: <name>]`. If the role defines `agent`, use that agent/subagent for role execution when the executor supports it.
175
+ Built-in roles use `<crew-root>/<Role>/Role.md`. These role files are short editable descriptions. Do not use them as normal task queues.
176
+
177
+ `<crew-root>/Shared/Roles.md` is generated so Lead can load available roles. If the user asks Lead to use a specific role, match that role by `name` first, then route the task into `<crew-root>/Projects/<project>/Agents/<role>/Tasks.md` with `[role:: <name>]`. If the role defines `agent`, use that agent/subagent for role execution when the executor supports it.
155
178
 
156
179
  ## Researcher
157
180
 
package/RIG_WIKI_SKILL.md CHANGED
@@ -15,15 +15,19 @@ metadata:
15
15
 
16
16
  **Positioning.** rig wiki is an **agent-facing tool**. Humans don't memorise the CLI; they tell their agent (you) what they want, and you orchestrate `rig wiki *`. Treat any direct user-typed `rig wiki ...` invocation as a fallback — your job is to make raw CLI use unnecessary. Never just hand the user a command and walk away; run it, observe, report.
17
17
 
18
- ## Vault discovery (no registry)
18
+ **Substrate.** rig wiki runs **on top of an Obsidian vault**. The project root IS the Obsidian vault (e.g. `overmind/`); `rig-wiki/` is the metadata subdirectory rig manages inside it. Sibling dirs (`personal/`, `research/`, …) are user-authored data — sources for ingest. All cross-references generated by ingest use `obsidian://open?vault=<name>&file=<vault-rel-path>` URLs, not filesystem paths, so links work the same from inside Obsidian and from terminal-launched tools.
19
19
 
20
- There is **no global registry**. The active vault is resolved by walking up from the current working directory looking for a `.rig/config.yml`. The directory that contains that file IS the vault.
20
+ ## Vault model — one fixed dir per project
21
+
22
+ A vault is **a single `rig-wiki/` dir at the project root** holding metadata (purpose.md, schema.md, page tree, `.rig/config.yml`). The project root itself is the conceptual "vault" — `rig-wiki/` is just the metadata subdir living inside it, named `rig-wiki/` by convention. User-authored data (`personal/`, `research/`, etc.) lives in sibling dirs and is NEVER touched.
23
+
24
+ - **The scope** — which sibling data dir(s) the wiki actually ingests — is recorded in `<rig-wiki>/.rig/config.yml` (`name`, `root`, `include`).
25
+ - **Discovery is automatic.** Any `rig wiki *` command walks up from CWD; at each level it checks both `<dir>/.rig/config.yml` (you're inside the vault) and `<dir>/rig-wiki/.rig/config.yml` (you're at the project root). So `cd` anywhere inside the project works.
21
26
 
22
27
  This means:
23
- - **Always `cd` into the project first.** If the user is in some other CWD, change directory before running any `rig wiki *` command.
24
28
  - **No `--wiki <name>` flag exists.** Don't try to pass one.
25
29
  - **No `rig wiki list`, `register`, or `unregister` commands.** They've been removed.
26
- - If the user is in a project that has no vault, the next step is `rig wiki init <subdir>` (see "Setup" below).
30
+ - If the user is in a project that has no vault, the next step is `rig wiki init <scope>` (see "Setup" below).
27
31
 
28
32
  ## Intent → command map
29
33
 
@@ -42,31 +46,36 @@ This means:
42
46
  ## Vault layout (flat — no inner `wiki/` subdir)
43
47
 
44
48
  ```
45
- <vault>/
46
- purpose.md ← human-authored, never write
47
- schema.md ← human-authored, never write
48
- index.md ← LLM-writable
49
- overview.md ← LLM-writable
50
- log.md ← append-only LLM log
51
- reviews.md ← LLM-writable backlog of human-review items
52
- raw/ ← immutable source files (never edit existing)
53
- sources/ ← one .md per ingested source — page tree at vault root
54
- entities/
55
- concepts/
56
- synthesis/
57
- queries/
58
- .rig/config.yml ← per-vault settings (name, root, include, exclude, …)
59
- .gitignore
49
+ <project>/ ← the conceptual vault (e.g. overmind/)
50
+ rig-wiki/ ← fixed metadata-dir name; created by `rig wiki init`
51
+ purpose.md ← human-authored, never write
52
+ schema.md ← human-authored, never write
53
+ index.md ← LLM-writable
54
+ overview.md ← LLM-writable
55
+ log.md ← append-only LLM log
56
+ reviews.md ← LLM-writable backlog of human-review items
57
+ raw/ ← immutable source files (never edit existing)
58
+ sources/ ← one .md per ingested source — page tree at vault root
59
+ entities/
60
+ concepts/
61
+ synthesis/
62
+ queries/
63
+ .rig/config.yml ← per-vault settings (name, root, include, exclude, …)
64
+ .gitignore
65
+ personal/ ← user-authored data — scope target (NEVER touched)
66
+ research/ ← (other sibling data dirs)
67
+ ...
60
68
  ```
61
69
 
62
- Note: there is no `<vault>/wiki/` subdirectory. Page directories (`sources/`, `entities/`, `concepts/`, `synthesis/`, `queries/`) live directly under the vault root.
70
+ Note: page directories (`sources/`, `entities/`, `concepts/`, `synthesis/`, `queries/`) live directly under `rig-wiki/` — no nested `wiki/` subdir.
63
71
 
64
72
  ## Argument inference rules
65
73
 
66
74
  - **slug** = kebab-case, no dates in page filenames; dates only on `raw/YYYY-MM-DD-*` prefix.
67
75
  - **raw filename** = `YYYY-MM-DD-<slug>.md`. Pick today's local date; if filename collides, append `-2`, `-3`.
68
76
  - **URL → slug**: last path segment, drop extension, lowercase, replace non-`[a-z0-9-]` with `-`, max 64 chars.
69
- - **Default vault dir name** when the user says "init a vault / make a wiki here" without specifying: suggest `rig-wiki` at the project root. Never default silently — confirm the name once.
77
+ - **`rig wiki init <scope>` arg** is a data subdir NAME, not a path to create. Examples: `rig wiki init personal` (scopes to `./personal/`), `rig wiki init research`. The vault metadata dir is always `./rig-wiki/`. Never pass a path like `rig-wiki` — that's the metadata dir, not the scope.
78
+ - **Cross-references** in generated wiki pages: file links → `obsidian://open?vault=<name>&file=<vault-rel>` (the ingest prompt provides the vault name and rel-path); page-to-page links → `[[slug]]` wikilinks. Never put raw absolute paths or `../`-style relative paths in generated content.
70
79
 
71
80
  ## Hard rules — refuse and explain if violated
72
81
 
@@ -83,7 +92,23 @@ The scanner skips these automatically — do not waste user time adding them to
83
92
  - Any path segment starting with `.` (`.git/`, `.obsidian/`, `.vscode/`, `.DS_Store`, …).
84
93
  - Any path matched by the project's `.gitignore`.
85
94
 
86
- What you DO need to put in `exclude` are content-type filters the user cares about — e.g. `**/*.zip`, `**/*.pdf` if they don't want those in their text wiki.
95
+ Defaults in `.rig/config.yml` from `init`:
96
+ - `include: ['**']` — everything that survives the auto-skips
97
+ - `exclude:` — binary archives (`*.zip`, `*.tar`, `*.tar.gz`, `*.tgz`, `*.7z`, `*.rar`). Their contents can't be ingested without unpacking.
98
+
99
+ What you DO need to put in `exclude` is additional content-type filtering the user explicitly asks for.
100
+
101
+ ## Multimodal ingest (what Claude Read can decode)
102
+
103
+ `rig wiki ingest <source>` invokes Claude (`claude -p`) and tells it to Read the source. By type:
104
+
105
+ | Type | Behaviour |
106
+ |---|---|
107
+ | `.md`, `.txt`, `.json`, `.csv`, `.yml`, `.py`, `.ts`, code etc. | Read directly as text. |
108
+ | `.png`, `.jpg`, `.jpeg`, `.gif`, `.webp`, `.bmp` | Claude Read returns visual input; the prompt instructs the model to describe contents, transcribe visible text/numbers, capture structure. |
109
+ | `.pdf` | Claude Read decodes natively. >10 pages: the prompt instructs chunked reads with the `pages` parameter. |
110
+ | `.xlsx`, `.xls`, `.ods`, `.numbers` | **Not natively supported by Read in v1.** Ingest writes a stub source page (filename + obsidian:// URL + last-modified date) and appends a `reviews.md` bullet asking the user to export to CSV / JSON for re-ingest. Don't invent contents. |
111
+ | `.zip` and other archives | Default-excluded; do not ingest. Unpack first, then ingest the unpacked tree. |
87
112
 
88
113
  ## Common error → recovery
89
114
 
@@ -113,19 +138,20 @@ What you DO need to put in `exclude` are content-type filters the user cares abo
113
138
 
114
139
  ## Setup — if no vault is found
115
140
 
116
- `rig wiki scan` (or any command) reports `No rig wiki vault found.` → ask the user **once** (don't list multiple defaults; pick one suggestion and confirm):
141
+ `rig wiki scan` (or any command) reports `No rig wiki vault found.` → ask the user **once** which sibling data dir to scope this wiki to (don't guess silently):
117
142
 
118
- > "No vault here. Want me to init one as `rig-wiki/` at the project root? (or pick another path)"
143
+ > "No vault here. Which subdir should this wiki ingest from — `personal/`, `research/`, …?"
119
144
 
120
145
  Then orchestrate without further prompting:
121
146
 
122
147
  ```bash
123
- rig wiki init rig-wiki # creates <project>/rig-wiki/ with templates + .rig/config.yml
148
+ cd <project> # the root that contains the scope dir
149
+ rig wiki init <scope> # e.g. `rig wiki init personal` → creates ./rig-wiki/, scope = ./personal/
124
150
  ```
125
151
 
126
- After init, **pause and ask the user to edit `<vault>/purpose.md`** (one-time human scoping — define what this wiki is for, in/out of scope). Don't write purpose.md yourself; it's the only human-authored anchor for everything downstream.
152
+ After init, **pause and ask the user to edit `<project>/rig-wiki/purpose.md`** (one-time human scoping — define what this wiki is for, in/out of scope). Don't write purpose.md yourself; it's the only human-authored anchor for everything downstream.
127
153
 
128
- If the user describes a scan scope that differs from the defaults (e.g. "include every md file in `personal/` but ignore zip files"), translate that into edits to `<vault>/.rig/config.yml`. Fields: `name`, optional `root` (relative scan base, default `..`), `include[]`, `exclude[]`, `schedule`, `ingestRules`. The vault is self-contained — nothing about its identity or scope lives outside its own directory.
154
+ If the user wants finer scoping than a single subdir (e.g. "ingest `personal/` but ignore zip files"), translate that into edits to `<project>/rig-wiki/.rig/config.yml`. Fields: `name`, `root` (relative scan base, default `../<scope>`), `include[]`, `exclude[]`, `schedule`, `ingestRules`. Everything about the vault lives in that dir — nothing leaks outside.
129
155
 
130
156
  ## Configuration files
131
157