rigjs 4.0.7 → 4.0.8

package/.claude/skills/rig-wiki/SKILL.md

@@ -15,6 +15,8 @@ metadata:
 
 **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.
 
+**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.
+
 ## Vault model — one fixed dir per project
 
 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.
@@ -73,6 +75,7 @@ Note: page directories (`sources/`, `entities/`, `concepts/`, `synthesis/`, `que
 - **raw filename** = `YYYY-MM-DD-<slug>.md`. Pick today's local date; if filename collides, append `-2`, `-3`.
 - **URL → slug**: last path segment, drop extension, lowercase, replace non-`[a-z0-9-]` with `-`, max 64 chars.
 - **`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.
+- **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.
 
 ## Hard rules — refuse and explain if violated
 
@@ -89,7 +92,23 @@ The scanner skips these automatically — do not waste user time adding them to
 - Any path segment starting with `.` (`.git/`, `.obsidian/`, `.vscode/`, `.DS_Store`, …).
 - Any path matched by the project's `.gitignore`.
 
-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.
+Defaults in `.rig/config.yml` from `init`:
+- `include: ['**']` — everything that survives the auto-skips
+- `exclude:` — binary archives (`*.zip`, `*.tar`, `*.tar.gz`, `*.tgz`, `*.7z`, `*.rar`). Their contents can't be ingested without unpacking.
+
+What you DO need to put in `exclude` is additional content-type filtering the user explicitly asks for.
+
+## Multimodal ingest (what Claude Read can decode)
+
+`rig wiki ingest <source>` invokes Claude (`claude -p`) and tells it to Read the source. By type:
+
+| Type | Behaviour |
+|---|---|
+| `.md`, `.txt`, `.json`, `.csv`, `.yml`, `.py`, `.ts`, code etc. | Read directly as text. |
+| `.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. |
+| `.pdf` | Claude Read decodes natively. >10 pages: the prompt instructs chunked reads with the `pages` parameter. |
+| `.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. |
+| `.zip` and other archives | Default-excluded; do not ingest. Unpack first, then ingest the unpacked tree. |
 
 ## Common error → recovery
 

package/RIG_CREW_SKILL.md

@@ -41,10 +41,13 @@ Project Owner management:
 rig crew project add rig --path /path/to/projects/rig --executor claude --test-command "yarn build"
 rig crew project add dsh-service --path /path/to/projects/dsh-service --executor codex --test-command "yarn test"
 rig crew project add demo-web --path /path/to/ObsidianVault/tmp/demo-web --executor codex
+rig crew project sync
 rig crew project list
 rig crew project status rig
 ```
 
+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/`.
+
 ## State Model
 
 `rig crew` is file-backed. Do not assume a long-running multi-agent runtime exists.
@@ -57,8 +60,10 @@ rig crew project status rig
 - Shared context: `<crew-root>/Shared/**`
 - Role registry for Lead: `<crew-root>/Shared/Roles.md`
 - Project owner memory: `<crew-root>/Projects/<project>/**`
+- Project-scoped agent tasks: `<crew-root>/Projects/<project>/Agents/<role>/Tasks.md`
+- Large active task batches: `<crew-root>/Projects/<project>/Tasklists/active/*.md` and `<crew-root>/Projects/<project>/Agents/<role>/Tasklists/active/*.md`
+- Reusable role descriptions: `<crew-root>/<role>/Role.md` and `<crew-root>/Roles/<custom-role>/Role.md`
 - Researcher memory and index: `<crew-root>/Researcher/**`
-- Custom role workspaces: `<crew-root>/Roles/<role>/**`
 - Vault agent instructions: `CLAUDE.md` and `AGENTS.md`
 - Local cache: `~/.rig/crew-state.json`
 - Config: `~/.rig/crew.config.json`
@@ -68,7 +73,24 @@ All multi-agent collaboration materials should live inside the Vault. Temporary
 
 `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.
 
-`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.
+`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.
+
+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:
+
+```text
+<crew-root>/Projects/<project>/Tasks.md
+<crew-root>/Projects/<project>/Agents/Coder/Tasks.md
+<crew-root>/Projects/<project>/Agents/Tester/Tasks.md
+```
+
+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:
+
+```text
+<crew-root>/Projects/<project>/Tasklists/active/<feature-or-iteration>.md
+<crew-root>/Projects/<project>/Agents/<role>/Tasklists/active/<feature-or-iteration>.md
+```
+
+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.
 
 ## Lead Orchestration
 
@@ -81,19 +103,20 @@ After handoff, read:
 - `<crew-root>/Team-Dashboard.md`
 - `<crew-root>/Inbox.md`
 - `<crew-root>/Shared/Roles.md`
-- role task files such as `<crew-root>/Tester/Tasks.md`
 - relevant `<crew-root>/Projects/<project>/Tasks.md`
+- relevant `<crew-root>/Projects/<project>/Agents/<role>/Tasks.md`
+- relevant active tasklists under `<crew-root>/Projects/<project>/**/Tasklists/active/`
 
 If the CLI is unavailable, use the file protocol:
 
 1. Append the request to `<crew-root>/Current-Goal.md`.
-2. Create or update a Lead task in `<crew-root>/Lead/Tasks.md`.
+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`.
 3. Route worker tasks with inline fields such as `[role:: tester]`, `[owner:: maintainer:rig]`, `[project:: rig]`, `[executor:: codex]`, `[status:: pending]`.
 4. Put user-facing questions or approvals in `<crew-root>/Inbox.md`.
 
 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.
 
-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.
+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.
 
 ## Mixed Executors
 
@@ -145,13 +168,13 @@ When a role is materialized in a Vault, use:
 
 ```text
 <crew-root>/Roles/<role>/
-├── Tasks.md
-├── Notes.md
 ├── Role.md
 └── Reports/
 ```
 
-`<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.
+Built-in roles use `<crew-root>/<Role>/Role.md`. These role files are short editable descriptions. Do not use them as normal task queues.
+
+`<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.
 
 ## Researcher
 

package/RIG_WIKI_SKILL.md

@@ -15,6 +15,8 @@ metadata:
 
 **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.
 
+**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.
+
 ## Vault model — one fixed dir per project
 
 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.
@@ -73,6 +75,7 @@ Note: page directories (`sources/`, `entities/`, `concepts/`, `synthesis/`, `que
 - **raw filename** = `YYYY-MM-DD-<slug>.md`. Pick today's local date; if filename collides, append `-2`, `-3`.
 - **URL → slug**: last path segment, drop extension, lowercase, replace non-`[a-z0-9-]` with `-`, max 64 chars.
 - **`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.
+- **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.
 
 ## Hard rules — refuse and explain if violated
 
@@ -89,7 +92,23 @@ The scanner skips these automatically — do not waste user time adding them to
 - Any path segment starting with `.` (`.git/`, `.obsidian/`, `.vscode/`, `.DS_Store`, …).
 - Any path matched by the project's `.gitignore`.
 
-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.
+Defaults in `.rig/config.yml` from `init`:
+- `include: ['**']` — everything that survives the auto-skips
+- `exclude:` — binary archives (`*.zip`, `*.tar`, `*.tar.gz`, `*.tgz`, `*.7z`, `*.rar`). Their contents can't be ingested without unpacking.
+
+What you DO need to put in `exclude` is additional content-type filtering the user explicitly asks for.
+
+## Multimodal ingest (what Claude Read can decode)
+
+`rig wiki ingest <source>` invokes Claude (`claude -p`) and tells it to Read the source. By type:
+
+| Type | Behaviour |
+|---|---|
+| `.md`, `.txt`, `.json`, `.csv`, `.yml`, `.py`, `.ts`, code etc. | Read directly as text. |
+| `.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. |
+| `.pdf` | Claude Read decodes natively. >10 pages: the prompt instructs chunked reads with the `pages` parameter. |
+| `.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. |
+| `.zip` and other archives | Default-excluded; do not ingest. Unpack first, then ingest the unpacked tree. |
 
 ## Common error → recovery