skillwiki 0.10.21 → 0.10.23

package/skills/skills/wiki-archive/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wiki-archive
-description: Archive a superseded typed-knowledge page. Moves page to _archive/, removes from index.md, logs the action.
+description: Archive a superseded typed page or preserve-move an exact raw source through the attended lifecycle workflow.
 ---
 
 # wiki-archive
@@ -8,7 +8,8 @@ description: Archive a superseded typed-knowledge page. Moves page to _archive/,
 ## When This Skill Activates
 
 - User wants to retire, supersede, or remove a typed-knowledge page from active use.
-- A page has been replaced by a newer version and should be kept for reference but excluded from lint and queries.
+- A page has been replaced by a newer version and should be kept for reference but excluded from active use.
+- The user explicitly requests a structural archive of one exact raw source while preserving its bytes under `raw/`.
 
 ## Output language
 
@@ -20,29 +21,32 @@ Standard four reads (SCHEMA, index, log, project context if applicable).
 
 ## Probe
 
-Same matrix as `using-skillwiki` → **CLI probe and failsafe**: PRIMARY (`skillwiki archive`), FAILSAFE-GIT (hand tombstone + `git mv` to `_archive/` + push), or FAIL CLOSED.
+Same matrix as `using-skillwiki` → **CLI probe and failsafe**. FAILSAFE-GIT is permitted for typed pages only. Raw archive requires the SkillWiki attended approval flow; if it is unavailable, fail closed.
 
 ## Steps (PRIMARY)
 
 0. Resolve vault: `skillwiki path` and `skillwiki lang`.
-1. Identify the target page. Confirm with the user which page to archive (show full relPath).
-2. Run `skillwiki archive <page> [vault]`. On a vault-sync leaf host where S3 stale originals must be pruned, use `skillwiki archive <page> [vault] --remote seaweed-wiki:cloud/wiki --remote-delete --max-remote-deletes 1` only when that remote path deletion is explicitly intended. Read the JSON output. Successful archive **always** writes a live-path tombstone under `meta/delete-intents/` so snapshot cannot resurrect the live key.
-3. Verify with `skillwiki index-check [vault]` — confirm no ghost entries remain.
-4. Run `skillwiki lint [vault]` — check for broken wikilinks from other pages that still reference the archived page. If found, update those pages to point to the replacement or remove the stale link.
-5. **Raw file archiving (N9 Reingest Protocol only):** When archiving a `raw/` file due to content drift, update ALL `^[raw/...]` citation markers and `sources:` frontmatter entries that reference the old path. Change `raw/articles/foo.md` to `_archive/raw/articles/foo.md` in every referencing page. Verify with `skillwiki audit` that no broken markers remain.
-6. Append a `log.md` entry: `## [{date}] archive | {relPath} → _archive/{subdir}/`.
-7. Commit/push so tombstone + archive land on private `main`.
+1. Identify the target page and show its full vault-relative path. Raw targets must be exact `raw/...` paths; basename inference is refused.
+2. For a typed page, run `skillwiki archive <page> [vault]` using the normal managed mutation workflow.
+3. For a raw article, paper, or transcript:
+   1. Run `skillwiki archive <exact-raw-path> [vault]` and inspect the dry-run, destination, complete-file hash, citation impact, and state-bound approval token.
+   2. If the user approves that exact live plan, run the identical command with `--apply --approve <token>`.
+   3. The destination is `raw/archived/<category>/...`. The command copies exclusively, verifies complete-file SHA-256, retires the old address, records append-only relocation history, and leaves the raw bytes unchanged.
+   4. Maintained citations may be rewritten to the new address; historical addresses also resolve through relocation history. Legacy `_archive/raw/` is read-compatible only and is never a new-write destination.
+4. On a vault-sync leaf where remote stale-path pruning is explicitly intended, add `--remote ... --remote-delete --max-remote-deletes 1`. This prunes only the retired address; the preserved raw destination remains.
+5. Verify with `skillwiki index-check [vault]`, `skillwiki lint [vault]`, and `skillwiki audit <referencing-page>` where applicable.
+6. Commit/push through the normal vault-sync workflow so the tombstone, preserved destination, and relocation event land together.
 
 ## FAILSAFE-GIT (no skillwiki)
 
-1. Confirm path. Write `meta/delete-intents/<slug>.json` with `action: "archive"`, `source: "failsafe-git"`, schema `vault-delete-intent/v1`.
-2. `git mv` live path → `_archive/<same relPath>` (create dirs as needed); update `index.md` if typed.
-3. Commit with `Delete-Intent` / `Delete-Source: failsafe-git` trailers; push to private `main`.
-4. Optional single-path `rclone deletefile` for the **live** path if remote configured.
+1. Confirm the target is not under `raw/`. Raw preserve-moves fail closed without the CLI transaction.
+2. Write `meta/delete-intents/<slug>.json` with `action: "archive"`, `source: "failsafe-git"`, schema `vault-delete-intent/v1`.
+3. `git mv` the typed page to `_archive/<same relPath>`; update `index.md`.
+4. Commit with `Delete-Intent` / `Delete-Source: failsafe-git` trailers; push to private `main`.
 
 ## Reversibility
 
-Archiving is locally reversible: move the file back from `_archive/` to its original directory, re-add the wikilink entry to `index.md`, and **delete the matching tombstone** under `meta/delete-intents/`. If `--remote-delete` was used, the stale active-path object is pruned from the remote after the archive move, but the archived copy remains and a restore will republish the active path on the next push once the tombstone is cleared.
+Typed archiving is locally reversible from `_archive/`. Raw archive is reversible only through another attended preserve-move that keeps exact bytes under `raw/`; do not hand-edit or recreate the source at its old address.
 
 ## Stop conditions
 
@@ -52,8 +56,9 @@ Archiving is locally reversible: move the file back from `_archive/` to its orig
 
 ## Forbidden
 
-- Archiving `raw/` files outside the N9 Reingest Protocol (raw is immutable except during content-drift reingestion).
-- Archiving raw files without updating all `^[raw/...]` citation markers that reference them.
-- Archiving without user confirmation.
+- Rewriting raw content or frontmatter during archive.
+- Moving raw evidence outside `raw/`, including new writes to `_archive/raw/`.
+- Moving `raw/assets/**` as a side effect of source archive; referenced asset paths stay frozen.
+- Applying a raw archive without a fresh state-bound token and attended explicit invocation.
 - Deleting local vault files with bare `rm` / bare `git rm` without a delete-intent tombstone (causes snapshot resurrection).
 - Remote stale-path pruning only via explicit `skillwiki archive --remote ... --remote-delete` (PRIMARY) or bounded single-path rclone in FAILSAFE-GIT.

package/skills/skills/wiki-audit/SKILL.md

@@ -21,7 +21,8 @@ Standard four reads.
 0. **Resolve vault and language.** Run `skillwiki path` (fail if NO_VAULT_CONFIGURED) and `skillwiki lang`.
 1. `skillwiki audit <page>`. Read the JSON report.
 2. Reason over the report:
-   - For each unresolved marker: suggest ingesting the missing source or correcting the path.
+   - Resolve citations against active `raw/`, `raw/archived/`, `raw/duplicates/`, and append-only relocation history. Legacy `_archive/raw/` is read-compatible only, not a valid new destination.
+   - For each unresolved marker: distinguish a genuinely missing target from a stale historical path, then suggest ingesting the missing source or correcting maintained-page metadata.
    - For each `unused_sources` entry: suggest adding a body marker or removing from `sources:`.
    - For each `missing_from_sources` entry: suggest adding to `sources:`.
 3. Append one `log.md` entry summarizing the audit and any suggested follow-ups.
@@ -31,3 +32,4 @@ None — audit always completes.
 
 ## Forbidden
 - Auto-applying suggested fixes (audit is observation-only).
+- Rewriting raw evidence while repairing an audit finding.

package/skills/skills/wiki-init/SKILL.md

@@ -22,7 +22,18 @@ None for the first run.
 3. Propose a 10–15 tag taxonomy tailored to the domain. Confirm or accept the user's revision.
 4. Ask the language question: "What language should generated page prose use? Default is `en`. Aliases like `chinese-traditional` or `zh-Hant` are accepted."
 5. Run `skillwiki init --target <dir> --domain "<answer>" --taxonomy "<comma list>" --lang "<lang>"`.
-6. **Suggest first sources.** Propose 3–5 initial sources (URLs, papers, articles) appropriate to the domain. Prompt the user to provide the first one to ingest, then hand off to wiki-ingest.
+6. Report the installed Web Clipper assets at
+   `_Templates/web-clipper/llm-wiki-clippings.json` and
+   `_Templates/web-clipper/readme.txt`. Tell the user to open Obsidian Web
+   Clipper Settings, import the JSON, and repeat the import for every browser
+   profile that should capture into the vault. Re-init preserves existing
+   customized copies, including short files.
+7. Explain that the generic template preserves `{{content}}`; remote HTTP(S)
+   images remain external dependencies. An attended local-asset capture may
+   choose any URL-friendly path under `raw/assets/`, but it must write the asset,
+   emit an explicit vault-qualified `![[raw/assets/...]]` embed, verify
+   resolution/preview, and only then finalize the immutable raw note.
+8. **Suggest first sources.** Propose 3–5 initial sources (URLs, papers, articles) appropriate to the domain. Prompt the user to provide the first one to ingest, then hand off to wiki-ingest.
 
 ## Stop conditions
 

package/skills/skills/wiki-lint/SKILL.md

@@ -15,7 +15,7 @@ Standard four reads.
 2. For lint-only maintenance, run `skillwiki lint <vault> --summary`. This returns bounded bucket counts, capped examples, and `details_command` hints without full item arrays.
 3. Drill into important buckets with `skillwiki lint <vault> --only <bucket>` when examples are insufficient for remediation.
 4. Reason over findings; present grouped by severity with concrete suggested actions per kind. If the CLI was recently updated with new lint checks, re-running lint on the full vault may flag pre-existing pages that predate the new rule — treat these as legitimate findings, not false positives.
-5. Treat `sensitive_content` as a security error. Drill down with `skillwiki lint <vault> --only sensitive_content --human`. Redaction is allowed as a security exception to raw immutability only through `skillwiki lint <vault> --fix --only sensitive_content`; never print the secret value in the report.
+5. Treat `sensitive_content` as a security error. Drill down with `skillwiki lint <vault> --only sensitive_content --human`; never print the secret value. Raw findings are report/quarantine-only: `--fix` must not redact, rewrite, or recompute existing raw evidence. Maintained-page repairs may proceed only through their approved write workflow.
 6. If `log_rotate_needed` is present and the user consents, run `skillwiki log-rotate <vault> --apply`. Otherwise leave alone.
 7. **Post-migration verification**: If the user recently migrated content (e.g., moved entity/concept pages to another vault), re-run `skillwiki lint <vault> --summary` and verify that broken_wikilinks count decreased. Remaining broken links for migrated content indicate pages still referencing the moved files — these should be cleaned up (remove citations or migrate the referencing pages too).
 8. Append a `log.md` entry summarizing lint counts only when the user asked to record the maintenance result. Do not log routine `health` reports by default.
@@ -24,5 +24,6 @@ None — lint reports all findings even on per-page errors.
 ## Forbidden
 - Auto-rotating logs.
 - Auto-updating sha256 fields.
+- Rewriting or redacting existing raw content/frontmatter, even for a sensitive-content finding.
 - Modifying any page beyond a user-approved lint summary entry in `log.md`.
 - Printing live credentials, access keys, tokens, passwords, cookies, bearer headers, private keys, or other authenticating secrets in findings or summaries.

package/skills/skills/wiki-query/SKILL.md

@@ -13,6 +13,8 @@ Standard four reads (SCHEMA, index, log, project context if applicable).
 ## Steps
 0. **Resolve vault and language.** Run `skillwiki path` (fail if NO_VAULT_CONFIGURED) and `skillwiki lang`.
 1. **Determine scope.** Ask the user once if ambiguous: vault | current project | project+concepts.
+   - Ordinary questions are typed-knowledge-first. Run `skillwiki query "<text>" [vault]` without widening into raw captures.
+   - Explicit freshness language — `new`, `recent`, `fresh`, `clipped`, `raw`, `pending`, `undigested`, `unprocessed`, `not yet ingested`, or `not yet integrated` — requests the pending evidence channel. Run `skillwiki sources pending [vault]` for inventory and `skillwiki query "<text>" [vault] --include-pending` for synthesis support.
 2. **Refresh graph.** If `.skillwiki/graph.json` is missing or older than 24h: `skillwiki graph build <vault>`.
 3. **Compute overlap.** `skillwiki overlap <vault>`.
 4. **Score candidates** in prompt using the 4 signals:
@@ -22,6 +24,9 @@ Standard four reads (SCHEMA, index, log, project context if applicable).
 - Type affinity: 1.0×
 5. **Read top candidates** in full (frontmatter + body).
 6. **Synthesize answer** with explicit citations to the candidate pages.
+   - When pending evidence was requested, keep the CLI's `pending_sources` separate from ranked typed `results`. Pending captures never change typed scores or ordering.
+   - Label raw captures as **pending evidence**, not established vault knowledge. Explain that they have not yet been distilled into a maintained page.
+   - Weak typed results may justify suggesting a pending lookup, but never silently broaden the query.
 7. **Sensitive content guard.** Before filing any query or comparison page, scan the generated body for live credentials, access keys, tokens, passwords, cookies, bearer headers, or private keys. Redact before writing. If the answer depends on preserving a live secret, STOP and ask for a redacted source or explicit rotation/remediation direction.
 8. **Optional file.** If the user accepts, first run `skillwiki page publish --help`. If it is unavailable, fail closed and leave the result unpublished. Otherwise:
    1. Resolve the vault and create a temporary directory outside the vault.
@@ -52,4 +57,6 @@ When a wiki page (especially a work item `tasks.md`) claims that fixes were appl
 - Filing without the `skillwiki page publish` dry-run passing.
 - Directly creating a final typed page or separately editing `index.md` or `log.md` for its publication.
 - Skipping the orientation reads even for "quick" queries.
+- Treating a pending raw capture as integrated typed knowledge, or mixing it into typed ranking.
+- Silently searching pending sources when the user did not request fresh/raw/unprocessed material.
 - Writing live credentials, access keys, tokens, passwords, cookies, bearer headers, private keys, or other authenticating secrets to the vault.

package/skills/skills/wiki-reingest/SKILL.md

@@ -8,7 +8,7 @@ description: Detect and act on source drift. Runs skillwiki drift, reviews chang
 ## When This Skill Activates
 
 - User wants to check if any vault sources have changed since ingestion.
-- Periodic drift check during lint or maintenance cycles.
+- Periodic drift check during lint or maintenance cycles; scheduled/headless runs report only.
 - User explicitly asks to re-ingest a specific source.
 
 ## Output language
@@ -28,17 +28,19 @@ Standard four reads (SCHEMA, index, log, project context if applicable).
    - **identity_conflicts:** The fetched source no longer matches the raw filename/source identity. STOP and surface the conflict. Do not archive or reingest until a human chooses the correct source/filename pair.
    - **fetch_failed:** Could not re-fetch. Show error details.
    - **unchanged:** No action needed.
-3. For each drifted source, ask the user: archive old + ingest new, or skip?
-4. If the user approves re-ingest for a source:
-   a. Run `skillwiki archive <raw-path>` to archive the old raw file.
-   b. Follow the `wiki-ingest` skill to ingest the updated content as a new raw file.
-   c. Update any concept/entity pages that cite the old source to reference the new one.
-5. Append a `log.md` entry summarizing: scanned, drifted, re-ingested, skipped.
+3. Report-only is the default. `skillwiki drift --apply` must not rewrite raw hashes or content; it reports the need for a new capture.
+4. For each drifted source, ask the user whether to create a new capture and preserve-archive the old address, or skip.
+5. If the user explicitly approves one source:
+   a. Follow `wiki-ingest` to create the updated content as a **new** raw capture. Verify it before changing the old address.
+   b. Preview `skillwiki archive <exact-old-raw-path>`.
+   c. Apply only with the live `--apply --approve <token>` flow. The old complete bytes move to `raw/archived/<category>/...`; they are never rewritten.
+   d. Update maintained concept/entity pages to cite the new capture where the editorial meaning requires it. Relocation history continues to resolve the old archived evidence.
+6. Append a log event/entry summarizing: scanned, drifted, newly captured, archived, skipped.
 
 ## N9 Compliance
 
 Raw files are immutable (N9). Re-ingest never modifies an existing raw file. Instead:
-- Archive the old raw file (moves to `_archive/raw/`).
+- Preserve the old raw file under `raw/archived/<category>/` through the attended structural transaction.
 - Create a new raw file with updated content and new sha256.
 - This preserves full provenance history.
 
@@ -51,6 +53,8 @@ Raw files are immutable (N9). Re-ingest never modifies an existing raw file. Ins
 ## Forbidden
 
 - Modifying files in `raw/` directly (N9).
+- Writing new archives to legacy `_archive/raw/`.
+- Running raw structural apply from scheduled or headless maintenance.
 - Re-ingesting without user approval for each drifted source.
 - Re-ingesting a source listed under `identity_conflicts` without explicit user approval and a corrected target filename/source URL.
 - Skipping the drift check and assuming sources have changed.

package/skills/skills/wiki-remove/SKILL.md

@@ -1,13 +1,14 @@
 ---
 name: wiki-remove
-description: Hard-delete a vault path with a durable delete-intent tombstone so S3+snapshot cannot resurrect it. Prefer skillwiki remove; if CLI missing, failsafe-git via private GitHub.
+description: Remove maintained vault paths with durable delete intent; raw evidence requires the separate attended exact-target sources dispose workflow.
 ---
 
 # wiki-remove
 
 ## When This Skill Activates
 
-- User wants to permanently remove a vault path (not archive-for-reference).
+- User wants to permanently remove a maintained vault path (not archive-for-reference).
+- User explicitly requests permanent disposal of one exact raw object.
 - Cleanup of stale pages that should not return via snapshot resurrection.
 - User says hard delete, remove for real, stop resurrecting.
 
@@ -17,7 +18,7 @@ If `skillwiki` is available: run `skillwiki lang` at the start. Otherwise defaul
 
 ## Pre-orientation
 
-Read SCHEMA/index only as needed. Confirm full vault-relative path with the user before delete.
+Read SCHEMA/index only as needed. Confirm the full vault-relative path. First classify the target as maintained content or `raw/**` evidence.
 
 ## Probe (required)
 
@@ -33,7 +34,7 @@ Read SCHEMA/index only as needed. Confirm full vault-relative path with the user
 
 Do not auto `npm install -g skillwiki` in headless/goal/satellite sessions.
 
-## PRIMARY steps
+## PRIMARY — maintained pages
 
 1. Resolve vault: `skillwiki path`.
 2. Confirm path with user.
@@ -44,9 +45,22 @@ Do not auto `npm install -g skillwiki` in headless/goal/satellite sessions.
 5. Commit + push via normal wiki-sync / git (tombstone + deletion must reach private `main` for durability).
 6. Report MODE=primary, paths, and whether remote-delete ran.
 
+`skillwiki remove` must refuse every `raw/**` target. Do not bypass that refusal.
+
+## PRIMARY — exact raw disposal
+
+Permanent raw disposal is exceptional and never inferred from cleanup, dedup, stale, archive, or reingest intent.
+
+1. Require an explicit user request naming one exact raw file and a reason. Refuse basenames, globs, directories, symlinks, batches, and inferred targets.
+2. Run `skillwiki sources dispose <exact-raw-path> [vault] --reason "<text>"`.
+3. Present the preview: complete-file SHA-256, byte size, typed/other/asset inbound references, delete-intent path, recoverability statement, operation ID, and approval token.
+4. Only in the same attended session, after the user approves that exact preview, run the identical command with `--write --approve <token>`.
+5. The command revalidates bytes and inbound references under the managed lock, writes append-only approval/completion events plus durable delete intent, then removes the exact object.
+6. Scheduled/headless disposal is always refused. A stale token never authorizes changed state.
+
 ## FAILSAFE-GIT steps (no skillwiki CLI)
 
-Agent **must** have git (and preferably gh) access to private vault remote.
+Agent **must** have git (and preferably gh) access to private vault remote. This fallback is for maintained pages only. If the target is under `raw/`, fail closed until `skillwiki sources dispose` is available; never reproduce raw disposal by hand.
 
 1. Confirm path with user. Set `PATH_REL` (vault-relative, no `..`).
 2. Write tombstone `meta/delete-intents/<slug>.json` where slug is path with `/` → `__`, e.g. `summaries/foo.md` → `summaries__foo.md.json`:
@@ -83,6 +97,7 @@ Delete-Source: failsafe-git
 - FAIL CLOSED (no CLI and no private git access).
 - Push to private wiki fails.
 - Path invalid or under `_archive/` without explicit restore/remove policy.
+- Raw target cannot be processed by the attended exact-target CLI flow.
 
 ## Forbidden
 
@@ -90,6 +105,8 @@ Delete-Source: failsafe-git
 - Force-push.
 - Unbounded `rclone sync` / mass remote delete.
 - Claiming fleet delete complete without tombstone on `origin/main` (and push success).
+- Passing raw paths to ordinary `skillwiki remove`, or using FAILSAFE-GIT/bare filesystem deletion for raw evidence.
+- Scheduled, headless, batch, glob, directory, basename-inferred, or stale-token raw disposal.
 
 ## Reversibility
 

package/skills/skills/wiki-sync/SKILL.md

@@ -162,7 +162,7 @@ git -C "$VAULT" rebase --continue
 
 **Prevention**:
 - Sync more frequently — don't let local fall >5 commits behind origin/main
-- Bundle archive commits — `skillwiki archive --batch` groups 5-10 transcript archives into one commit, reducing rebase surface
+- Prefer smaller, attended exact-target archive operations and sync promptly; there is no batch raw-archive apply mode.
 - For vaults with snapshot cron, prefer smaller, more frequent syncs over large batch rebases
 
 See `concepts/wiki-sync-rebase-conflict-storm-pattern.md` for detailed analysis.
@@ -174,72 +174,58 @@ When the user mentions editing from Obsidian desktop and Claude Code on a server
 - If both devices edit the same page between syncs, conflicts are inevitable — the Conflict Resolution section handles this.
 - Suggest enabling auto-commit in Obsidian (Community Plugins: `obsidian-git`) to reduce dirty-state drift.
 
-## Rclone-backed vault with git snapshotting (cron pattern)
-Some deployments use a cloud-backed vault (`rclone mount`) with a separate git repository for versioned snapshots. This pattern separates "live working vault" from "versioned backup".
-### Architecture
-```
-~/wiki           → rclone mount to cloud storage (S3/IDrive/etc) — live vault
-~/wiki-git       → git repository cloned from GitHub — snapshot target
-cron hourly      → rsync ~/wiki/ → ~/wiki-git/ → git commit → git push
-```
-On snapshotter hosts, `~/wiki` remains the active SkillWiki vault for path resolution unless the operator explicitly configures otherwise. `~/wiki-git` is snapshot infrastructure, not the default authoring or dev-loop vault. Agents may author the live vault path when the host policy allows it, but should not point project work or `fleet context` at `~/wiki-git` unless `skillwiki path` intentionally resolves there.
+## Host-aware write and promotion authority
 
-### Implementation (wiki-snapshot.sh)
-```bash
-#!/bin/bash
-WIKI_DIR="/root/wiki"
-GIT_DIR="/root/wiki-git"
-DATE=$(date +%Y%m%d_%H%M%S)
-# Sync from rclone mount to git repo (quiet mode for slow mounts)
-rsync -a --delete -q \
---exclude='.snapshots' --exclude='.git' --exclude='.obsidian' --exclude='.skillwiki' \
-"$WIKI_DIR/" "$GIT_DIR/"
-cd "$GIT_DIR" || exit 1
-git config user.email "cron@hermes.local"
-git config user.name "Hermes Snapshot"
-# Check for changes
-if [ -z "$(git status --porcelain)" ]; then
-exit 0  # Nothing to commit
-fi
-git add -A
-git commit -m "Snapshot $DATE"
-# Pull with rebase to handle remote changes (e.g., README edits on GitHub)
-if ! git pull --rebase origin main 2>/dev/null; then
-git pull origin main 2>/dev/null || true
-fi
-git push origin main || echo "Push failed"
-```
-### Pitfalls specific to this pattern
-1. **Divergent branches from external pushes**: If something else pushes to the same GitHub repo (manual edits from macOS desktop, GitHub web UI edits, another server), the local `~/wiki-git` will diverge. The `--rebase` flag handles most cases, but if commits conflict:
-```bash
-cd ~/wiki-git
-git rebase --abort 2>/dev/null || true
-git fetch origin main
-git reset --hard origin/main
-bash ~/.hermes/scripts/wiki-snapshot.sh  # Re-sync fresh
-```
-**Prevention**: Avoid editing the GitHub repo directly via web interface or uncoordinated clones. The canonical flow is **single-writer-git** (see `concepts/vault-write-authority-model.md`):
-- Server (sg01): agents may author the live vault at `~/wiki`; the snapshot job promotes cloud-backed live-vault state into `~/wiki-git`, then commits and pushes — **sole git writer to `main`**
-- macOS/desktop: edit → `wiki-push` rclone copy to S3 (NO git push) → consume sg01 snapshots via `wiki-fetch-notify` (opt-in `WIKI_FETCH_PULL_ON_DELTA=1`) or manual `skillwiki sync`
-- `wiki-sync` skill push is for **explicit** agent/human edit commits only, not automated background pushes
-2. **Slow rsync on rclone mounts**: The rclone FUSE mount can be slow for large directory listings. Use `rsync -q` (quiet) to reduce output overhead, and consider `--delete-delay` instead of `--delete` if file churn is high. The rclone mount latency can cause `du` and `find` operations to timeout — this is normal, not an error.
-3. **Golden Rule violation**: Never mix sync methods on the same vault. If using rclone mount + git snapshotting, do NOT also enable Obsidian Sync, Syncthing, or iCloud on `~/wiki`. The rclone mount IS the sync mechanism.
-4. **Credential exposure**: The rclone mount and git remote use different credentials. Ensure git credentials are cached or use HTTPS with token, but never commit rclone config to git.
+Resolve the live vault with `skillwiki path` first. Then choose the host role:
+
+| Host role | Live vault | Authoring surface | Promotion to GitHub |
+| --- | --- | --- | --- |
+| Authorized Git-backed leaf (e.g. macOS) | Git vault from `skillwiki path` | Managed SkillWiki publishers against that vault | `skillwiki sync push "$VAULT"` after lint-delta |
+| Protected snapshotter (sg01) | `/root/wiki` (rclone FUSE; not a Git repo) | Managed SkillWiki publishers against `/root/wiki` | S3 → `wiki-snapshot.timer` (default) → protected `/root/wiki-git` pipeline → GitHub |
+
+High-signal safety rule:
+
+> Do not author, copy, edit, stage, commit, pull, reset, or push agent changes
+> in `/root/wiki-git`.
+
+### Protected snapshotter rules (sg01)
+
+- Author only via managed commands against the live vault (`skillwiki path` → usually `/root/wiki`).
+- Do **not** run `skillwiki sync push /root/wiki` (not a Git repo) or `skillwiki sync push /root/wiki-git` (blocked as protected snapshot worktree).
+- Do **not** `cd` into `/root/wiki-git` or `~/wiki-git` for ordinary authoring.
+- Do **not** rsync, copy, or edit files into the snapshot worktree as an agent/operator workflow.
+- Do **not** run `git reset --hard`, direct commits, or manual snapshot scripts to "fix" divergence.
+- Promotion is owned by `wiki-snapshot.timer` by default. Publishers never start systemd units.
+- `skillwiki work-complete` may finish with `committed=false` on sg01; later snapshot promotion owns the Git commit/push.
+
+### Authorized Git leaf rules
+
+- Use managed publication (`skillwiki page publish`, `skillwiki project-page publish`, etc.) against the resolved Git vault.
+- Then use this skill's push workflow (`skillwiki sync status` → lint-delta → commit → `skillwiki sync push` / `git push` as documented above).
+- Never treat a snapshot worktree mirror as a substitute for the live vault.
+
+### Historical rationale (not executable)
+
+Some older deployments separated a cloud-backed live vault from a Git snapshot worktree. That architecture still exists on protected snapshotters, but the snapshot worktree is **pipeline-internal**. Historical recipes that rsync into the worktree, reset it hard to origin/main, or run snapshot shell scripts by hand are obsolete and must not be copied.
 
 ## Stop conditions
-- `skillwiki sync status` reports `not_a_repo` — the vault is not a git repository. Advise the user to initialize one.
+- `skillwiki sync status` reports `not_a_repo` — the vault is not a git repository. On protected snapshotters this is expected for the FUSE live path; do not switch to `/root/wiki-git` to force a push.
 - Lint errors are found before a push — do not push until resolved.
 - `git push` or `git pull` fails with a network error — report and stop.
 - Peer lock is held or peer stashes exist — abort and ask the user to wait or pass `--force`.
 - Untracked file collision detected on pull — surface to user for manual resolution.
+- Host is a protected snapshotter and the requested operation would author or push via `/root/wiki-git` — refuse and use managed live-vault publication + timer promotion instead.
 
 ## Forbidden
 - Pushing when lint errors exist.
 - Auto-resolving body conflicts without user review.
 - Force-pushing (`git push --force`).
-- Modifying files in `raw/` to resolve conflicts (N9 — archive and re-ingest instead).
+- Rewriting raw content/frontmatter to resolve conflicts. Preserve-moves must stay under `raw/` (normally `raw/archived/` or `raw/duplicates/`) and require an attended approved structural command; scheduled/headless sync remains report-only.
 - Stashing without the `wiki-sync:...` name format (breaks peer detection).
 - Force-deleting a peer's lockfile (use `--force` only if peer is confirmed dead).
+- Authoring, copying, editing, staging, committing, pulling, resetting, or pushing agent changes in `/root/wiki-git` (or any configured snapshot worktree).
+- Running `skillwiki sync push` against a protected snapshot worktree or against a non-Git FUSE live vault.
+- Invoking snapshot services/scripts or `git reset --hard` in the snapshot worktree as a recovery shortcut.
 
 ## Convergence safeguards (2026-07-11)
 
@@ -256,4 +242,3 @@ Drop a local commit from rebase only when every path is proven present on the ta
 - CLI: `skillwiki sync lint-delta <vault> --base-ref origin/main`
 - Block publication only when `new_errors > 0`; inherited full debt remains visible.
 - Missing/malformed delta evidence blocks (never silent lint skip).
-

package/skills/using-skillwiki/SKILL.md

@@ -37,14 +37,17 @@ Invoke a skillwiki skill when the user:
 
 ## Vault Structure
 A skillwiki vault has three layers. The canonical architecture lives in `SCHEMA.md` at the vault root — read it before creating any new directories.
-**Layer 1 — Raw (`raw/`):** Immutable source material. Never modify after ingest. `raw/transcripts/` doubles as the ad-hoc capture point for meeting notes and unprocessed ideas.
+**Layer 1 — Raw (`raw/`):** Immutable evidence. Existing content/frontmatter is never autonomously rewritten or removed. Attended structural workflows may rename, relocate, archive, or deduplicate only when exact bytes remain somewhere under `raw/`. Permanent disposal requires explicit exact-target user intent. `raw/transcripts/` is the ad-hoc capture point for meeting notes and unprocessed ideas.
 ```
 raw/
-├── articles/    # Web articles, clippings
-├── papers/      # PDFs, arxiv papers
-├── transcripts/ # Meeting notes, interviews, ad-hoc captures
-└── assets/      # Images, diagrams referenced by sources
+├── articles/             # Active Web articles and clippings
+├── papers/               # Active PDFs and papers
+├── transcripts/          # Active meeting notes and ad-hoc captures
+├── assets/               # Stable flexible asset pool; no fixed internal taxonomy
+├── archived/{articles,papers,transcripts}/
+└── duplicates/{articles,papers,transcripts}/
 ```
+Use explicit vault-root asset embeds such as `![[raw/assets/example/diagram.png]]`. Agents may choose flat or URL-friendly nested paths. Once an immutable capture references an asset, that path freezes; routine source archive/dedup never moves the asset. Remote images remain external dependencies unless separately captured.
 Raw frontmatter:
 ```yaml
 ---
@@ -94,6 +97,9 @@ Also mirror these pointers in vault-presync / vault-sync-status skills when oper
 
 - typed pages: `skillwiki page publish <draft> <vault> --target <path>` then the same command with `--write`
 - archive: `skillwiki archive <path> <vault>`
+- pending source inventory: `skillwiki sources pending <vault>`
+- editorial disposition: `skillwiki sources disposition <exact-raw-path> <vault> ...`
+- exceptional raw disposal: `skillwiki sources dispose <exact-raw-path> <vault> --reason ...` then attended `--write --approve <token>`
 - ad-hoc structural log: `skillwiki log-append <vault> --content '<entry>'` (Release A dual-write) or event materialization (Release B)
 - project/root index: `skillwiki project-index <slug> <vault> --apply` and `skillwiki index rebuild <vault> --write` only through managed commands
 - log projection: `skillwiki log materialize <vault> [--write]`
@@ -125,20 +131,20 @@ The vault is shared across hosts, so host-local absolute paths are not durable s
 | Entry | When | What happens |
 |-------|------|-------------|
 | `/wiki-add-task <text>` | You're in a Claude session | Creates `raw/transcripts/YYYY-MM-DD-{type}-{slug}.md` with ad-hoc capture frontmatter |
-| Filesystem drop | You're NOT in a Claude session (Obsidian, editor, sync) | Create/edit any `.md` file in `raw/transcripts/` — dev-loop discovers it on next cycle |
+| Filesystem drop | You're NOT in a Claude session (Obsidian, editor, sync) | Create a new `.md` file in `raw/transcripts/` — dev-loop discovers it on next cycle; do not edit it after capture |
 | Dev-loop discovery | Automatic, next cycle | Scans `raw/transcripts/` for new files since last cycle, surfaces as claimable work |
 
 ## Skill Map
 | Skill | When to Invoke |
 |-------|----------------|
-| `wiki-init` | Bootstrap a new vault — SCHEMA.md, index.md, log.md, ~/.skillwiki/.env |
+| `wiki-init` | Bootstrap a vault and install `_Templates/web-clipper/llm-wiki-clippings.json` plus import guidance |
 | `wiki-ingest` | Convert URLs, files, or pasted text into typed-knowledge pages |
-| `wiki-query` | Search the vault and synthesize an answer with ranked results |
+| `wiki-query` | Search typed knowledge by default; explicitly requested fresh/raw evidence uses the separate pending channel |
 | `wiki-lint` | Vault health and lint checks; use `health` for whole-system reports and `lint --summary` for bounded lint buckets |
 | `wiki-crystallize` | Distill the current working session into a typed-knowledge page |
 | `wiki-audit` | Verify raw provenance references and source frontmatter integrity |
-| `wiki-archive` | Archive a typed-knowledge page — move to `_archive/`, remove from index (writes delete-intent) |
-| `wiki-remove` | Hard-delete a path with delete-intent tombstone; failsafe-git if CLI missing |
+| `wiki-archive` | Archive typed pages, or attended preserve-move exact raw sources under `raw/archived/` |
+| `wiki-remove` | Remove maintained pages; exact raw disposal uses the separate attended `sources dispose` flow |
 | `wiki-reingest` | Detect drift in raw sources (sha256 comparison) and re-ingest updated content |
 | `wiki-add-task` | Quick-capture ideas, bugs, tasks, notes into `raw/transcripts/` without leaving the current workflow |
 | `wiki-adapter-prd` | Map foreign PRD formats (CodeStable, RFC, AIDE, Hermes) into vault pages |
@@ -174,8 +180,8 @@ Use `prd_layer` + `prd_pipeline` from `.claude/dev-loop.config.md` as source of
 
 ## CLI Backbone
 All skills are backed by the `skillwiki` CLI — a deterministic tool with no LLM calls. It handles path resolution, config management, validation, health reporting, and linting. Skills invoke it via Bash for the mechanical parts and use Claude for the creative parts.
-Key CLI subcommands: `init`, `health`, `lint`, `config`, `doctor`, `path`, `lang`, `install`, `fleet context`, `fleet validate`, `graph build`, `archive`, `remove`, `drift`, `compound`, `tag-sync`, `tag reconcile`, `page publish`, `sync status`, `seed`, `stale`, `observe`, `canvas generate`.
-Run `skillwiki health <vault> --out /tmp/skillwiki-health.json --no-fail` for a bounded whole-system report that includes doctor, lint, vault-sync, query-readiness, source-freshness, risk flags, and self-check coverage. Run `skillwiki lint <vault> --summary` for lint-only bucket counts with capped examples and details commands. Run `skillwiki doctor` to diagnose setup/runtime issues only. Run `skillwiki config list` to see current configuration.
+Key CLI subcommands: `init`, `health`, `lint`, `config`, `doctor`, `path`, `lang`, `install`, `fleet context`, `fleet validate`, `graph build`, `query`, `sources pending`, `sources disposition`, `sources dispose`, `archive`, `remove`, `drift`, `dedup`, `compound`, `tag-sync`, `tag reconcile`, `page publish`, `sync status`, `seed`, `stale`, `observe`, `canvas generate`.
+Run `skillwiki health <vault> --out /tmp/skillwiki-health.json --no-fail` for a bounded whole-system report that includes the nonblocking source-lifecycle backlog. Pending captures are informational and do not make health fail. Run `skillwiki lint <vault> --summary` for lint-only bucket counts with capped examples and details commands. Run `skillwiki doctor` to diagnose setup/runtime issues only. Run `skillwiki config list` to see current configuration.
 
 ## Runtime Host Context and Fleet Freshness
 Resolve the active project vault with `skillwiki path` first. Then pass that exact path to `skillwiki --human fleet context <vault>` for host identity and safety guidance. `fleet context` is authoritative for host identity. It overrides stale injected SessionStart context, remembered workspace context, and prior conversation summaries. `fleet context` is local and network-free; it reports `identity_status`, resolver trace, warnings, and the fact that remote freshness was not checked.
@@ -214,7 +220,7 @@ Before asking questions or running scheduled maintenance, resolve the session ki
 ## Typical Workflow
 1. **Init** (`wiki-init`) — create vault, set domain and taxonomy
 2. **Ingest** (`wiki-ingest`) — add sources, build pages
-3. **Query** (`wiki-query`) — search and synthesize answers
+3. **Query** (`wiki-query`) — search typed knowledge; explicitly include pending captures for fresh/raw intent
 4. **Lint** (`wiki-lint`) — periodic health checks
 5. **Crystallize** (`wiki-crystallize`) — save session insights as pages
 6. **Audit** (`wiki-audit`) — verify source integrity

package/skills/wiki-add-task/SKILL.md

@@ -8,7 +8,7 @@ Capture ad-hoc ideas, bugs, tasks, and notes into the vault. Three entry points
 |-------|------|-------------|
 | `/wiki-add-task <text>` | You're in a Claude Code session (NOT Hermes compact) | Creates `raw/transcripts/YYYY-MM-DD-{type}-{slug}.md` with ad-hoc capture frontmatter |
 | Filesystem drop | Hermes Agent compact mode (no slash commands available) | Same as above — create `.md` in `raw/transcripts/`, dev-loop discovers it |
-| Filesystem drop | You're NOT in a Claude session (Obsidian, editor, sync) | Create any `.md` file in `raw/transcripts/` using the vault template — dev-loop discovers it on next cycle |
+| Filesystem drop | You're NOT in a Claude session (Obsidian, editor, sync) | Create a new `.md` file in `raw/transcripts/` using the vault template — dev-loop discovers it on next cycle |
 | Dev-loop discovery | Automatic, next cycle | Scans `raw/transcripts/` for new files since last cycle, surfaces as claimable work |
 **Path Rule:** Captures ALWAYS go to `$(skillwiki path)/raw/transcripts/` (Layer 1). Never under `projects/{slug}/raw/` — that violates SCHEMA.md Layer 1 immutability.
 ### Exception: Explicit project task requests
@@ -47,7 +47,7 @@ project: "[[{slug}]]"
 - If a `project` slug was provided, set `project: "[[slug]]"`.
 - If no project, omit the `project` field entirely.
 - `source_url` is null (these are locally originated captures).
-- No `sha256` — ad-hoc captures are mutable working notes, not immutable sources.
+- `sha256` may be omitted for locally originated captures, but the completed capture is still immutable evidence. Corrections create a new capture or a maintained work-item note; never rewrite the existing transcript.
 5. **Write body.** Below the frontmatter, write:
 ```markdown
 # {type}: {text}
@@ -79,7 +79,7 @@ Fix the template mismatch between wiki-add-task and the vault template.
 ```
 The `kind` field uses the capture type and must be one of: `idea`, `bug`, `task`, `note` (plus the existing `postmortem`, `session-log`, `meeting-notes`, `other` for non-capture raw sources).
 The `project` and `kind` fields can be set independently — they do not require `work_item`. The `work_item` field is only used when the raw source is directly tied to a project work item (set by `proj-work`).
-Ad-hoc captures omit `sha256` — they are mutable working notes, not immutable sources. The `sha256` field is reserved for ingested raw sources that require integrity verification.
+Ad-hoc captures may omit `sha256`; omission does not grant mutation authority. Once created, the transcript's content and frontmatter are immutable. The `sha256` field remains required for ingest pipelines that provide integrity verification.
 ## Stop conditions
 - `skillwiki path` returns NO_VAULT_CONFIGURED.
 - No `text` provided (prompt user once, then stop).
@@ -88,6 +88,7 @@ Ad-hoc captures omit `sha256` — they are mutable working notes, not immutable
 ## Forbidden
 - Creating an `inbox/` directory. All captures go to `raw/transcripts/`.
 - Appending to existing capture files — each capture gets its own file.
+- Editing or correcting an existing raw transcript; create a new capture or maintained work-item note instead.
 - Creating a work item — this is capture-only. Use `proj-work` for full work items.
 - Writing to any Layer 2 or Layer 3 location. Captures are Layer 1 (raw).
 - Writing live credentials, access keys, tokens, passwords, cookies, bearer headers, private keys, or other authenticating secrets to the vault.