skillwiki 0.10.21 → 0.10.22

package/dist/{index-projection-HAXDEM2F.js → index-projection-Q6WL76SO.js}

@@ -4,8 +4,8 @@ import {
   UNMANAGED_START,
   renderRootIndex,
   writeRootIndexProjection
-} from "./chunk-I5JD3BQZ.js";
-import "./chunk-Y6KRDGI2.js";
+} from "./chunk-54JVBNWK.js";
+import "./chunk-C2DKFJFA.js";
 export {
   UNMANAGED_END,
   UNMANAGED_START,

package/dist/{managed-write-preflight-CTXX2MHQ.js → managed-write-preflight-4LPVMP42.js}

@@ -2,9 +2,9 @@
 import {
   runManagedWritePreflight,
   runManagedWriteTransaction
-} from "./chunk-65Q5UGND.js";
-import "./chunk-GNS2ZV5P.js";
-import "./chunk-Y6KRDGI2.js";
+} from "./chunk-BASWDOQB.js";
+import "./chunk-PQG26AGJ.js";
+import "./chunk-C2DKFJFA.js";
 export {
   runManagedWritePreflight,
   runManagedWriteTransaction

package/dist/skillwiki-mcp.js

@@ -1,11 +1,11 @@
 #!/usr/bin/env node
 import {
   runSkillwikiMcpStdio
-} from "./chunk-UNPZDCWN.js";
+} from "./chunk-7YDWC6D3.js";
 import "./chunk-7I2TPIV5.js";
-import "./chunk-I5JD3BQZ.js";
-import "./chunk-GNS2ZV5P.js";
-import "./chunk-Y6KRDGI2.js";
+import "./chunk-54JVBNWK.js";
+import "./chunk-PQG26AGJ.js";
+import "./chunk-C2DKFJFA.js";
 
 // src/mcp-entry.ts
 runSkillwikiMcpStdio().catch((error) => {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "skillwiki",
-  "version": "0.10.21",
+  "version": "0.10.22",
   "type": "module",
   "bin": {
     "skillwiki": "dist/cli.js",

package/skills/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "skillwiki",
-  "version": "0.10.21",
+  "version": "0.10.22",
   "skills": "./",
   "description": "Project-aware Karpathy-style knowledge base for Claude Code: 19 prompt-only skills (wiki-*, proj-*, using-skillwiki) backed by the deterministic `skillwiki` CLI.",
   "author": {

package/skills/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "skillwiki",
-  "version": "0.10.21",
+  "version": "0.10.22",
   "description": "Project-aware Karpathy-style knowledge base for Codex with 19 prompt-only skills backed by the deterministic skillwiki CLI.",
   "author": {
     "name": "karlorz",

package/skills/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skillwiki/skills",
-  "version": "0.10.21",
+  "version": "0.10.22",
   "private": true,
   "files": [
     "wiki-*",

package/skills/proj-decide/SKILL.md

@@ -12,13 +12,43 @@ description: Write an Architectural Decision Record (ADR). If the decision gener
 Standard four + project context.
 
 ## Steps
-1. Compose the ADR in `projects/{slug}/architecture/YYYY-MM-DD-{adr-slug}.md`. Frontmatter: kind=decision, status=in-progress or completed, project link. If no project context exists, default to `playground`.
-2. `skillwiki validate <adr>`. If non-zero, STOP.
-3. **Generalization check.** If the decision applies beyond this project, create a `concepts/` page with `provenance: project` (or `mixed` if research-informed).
-4. Apply writes: ADR → (optional) concept page → vault `index.md` → vault `log.md` and project `log.md`.
+1. Resolve vault with `skillwiki path`. Draft the ADR **outside** the authoritative target path (temp file or work-item draft). Prefer frontmatter compatible with typed-knowledge architecture pages:
+   - `type: concept`
+   - `tags` include `adr` for newly created architecture pages
+   - `provenance: project` or `mixed`
+   - `provenance_projects` includes `[[{slug}]]`
+   - Target path: `projects/{slug}/architecture/YYYY-MM-DD-{adr-slug}.md`
+   - If no project context exists, default to `playground`.
+2. Dry-run the managed Layer-3 publisher (read-only; emits an approval token):
+   ```bash
+   skillwiki project-page publish <draft> "$VAULT" \
+     --project <slug> \
+     --target projects/<slug>/architecture/YYYY-MM-DD-<adr-slug>.md \
+     --log-note "<one-line note>"
+   ```
+   Review target state, draft SHA, prior target hash, and the returned `approval_token` with the human.
+3. On human approval, publish with the exact token from the dry-run (do not re-author between dry-run and write):
+   ```bash
+   skillwiki project-page publish <draft> "$VAULT" \
+     --project <slug> \
+     --target projects/<slug>/architecture/YYYY-MM-DD-<adr-slug>.md \
+     --log-note "<same one-line note>" \
+     --write --approve <token>
+   ```
+4. Verify the touched page and project knowledge index (`projects/{slug}/knowledge.md`). Do **not** hand-edit root `index.md` for architecture pages — the publisher owns project knowledge projection.
+5. **Generalization check.** If the decision applies beyond this project, draft a `concepts/` page with `provenance: project` (or `mixed` if research-informed) and publish it with `skillwiki page publish` (prefer `--approve` for this workstream).
+6. Host-aware promotion:
+   - Authorized Git leaf: `skillwiki sync` / `skillwiki sync push` after lint-delta.
+   - Protected snapshotter (sg01): leave promotion to `wiki-snapshot.timer`; never author or push via `/root/wiki-git`.
 
 ## Stop conditions
-- `validate` non-zero on either page.
+- `project-page publish` dry-run or approved write exits non-zero.
+- Approval token missing/mismatched — re-run dry-run; do not force a write.
+- Host is a protected snapshotter and the operator asks to edit `/root/wiki-git` — refuse.
 
 ## Forbidden
+- Direct writes into `projects/{slug}/architecture/` without `skillwiki project-page publish`.
+- Hand-editing root `index.md` for architecture ADRs.
 - Filing the concept page without explicit `provenance:`.
+- Do not author, copy, edit, stage, commit, pull, reset, or push agent changes in `/root/wiki-git`.
+- Running snapshot scripts or `git reset --hard` in the snapshot worktree as a publication shortcut.

package/skills/skills/proj-decide/SKILL.md

@@ -12,13 +12,43 @@ description: Write an Architectural Decision Record (ADR). If the decision gener
 Standard four + project context.
 
 ## Steps
-1. Compose the ADR in `projects/{slug}/architecture/YYYY-MM-DD-{adr-slug}.md`. Frontmatter: kind=decision, status=in-progress or completed, project link. If no project context exists, default to `playground`.
-2. `skillwiki validate <adr>`. If non-zero, STOP.
-3. **Generalization check.** If the decision applies beyond this project, create a `concepts/` page with `provenance: project` (or `mixed` if research-informed).
-4. Apply writes: ADR → (optional) concept page → vault `index.md` → vault `log.md` and project `log.md`.
+1. Resolve vault with `skillwiki path`. Draft the ADR **outside** the authoritative target path (temp file or work-item draft). Prefer frontmatter compatible with typed-knowledge architecture pages:
+   - `type: concept`
+   - `tags` include `adr` for newly created architecture pages
+   - `provenance: project` or `mixed`
+   - `provenance_projects` includes `[[{slug}]]`
+   - Target path: `projects/{slug}/architecture/YYYY-MM-DD-{adr-slug}.md`
+   - If no project context exists, default to `playground`.
+2. Dry-run the managed Layer-3 publisher (read-only; emits an approval token):
+   ```bash
+   skillwiki project-page publish <draft> "$VAULT" \
+     --project <slug> \
+     --target projects/<slug>/architecture/YYYY-MM-DD-<adr-slug>.md \
+     --log-note "<one-line note>"
+   ```
+   Review target state, draft SHA, prior target hash, and the returned `approval_token` with the human.
+3. On human approval, publish with the exact token from the dry-run (do not re-author between dry-run and write):
+   ```bash
+   skillwiki project-page publish <draft> "$VAULT" \
+     --project <slug> \
+     --target projects/<slug>/architecture/YYYY-MM-DD-<adr-slug>.md \
+     --log-note "<same one-line note>" \
+     --write --approve <token>
+   ```
+4. Verify the touched page and project knowledge index (`projects/{slug}/knowledge.md`). Do **not** hand-edit root `index.md` for architecture pages — the publisher owns project knowledge projection.
+5. **Generalization check.** If the decision applies beyond this project, draft a `concepts/` page with `provenance: project` (or `mixed` if research-informed) and publish it with `skillwiki page publish` (prefer `--approve` for this workstream).
+6. Host-aware promotion:
+   - Authorized Git leaf: `skillwiki sync` / `skillwiki sync push` after lint-delta.
+   - Protected snapshotter (sg01): leave promotion to `wiki-snapshot.timer`; never author or push via `/root/wiki-git`.
 
 ## Stop conditions
-- `validate` non-zero on either page.
+- `project-page publish` dry-run or approved write exits non-zero.
+- Approval token missing/mismatched — re-run dry-run; do not force a write.
+- Host is a protected snapshotter and the operator asks to edit `/root/wiki-git` — refuse.
 
 ## Forbidden
+- Direct writes into `projects/{slug}/architecture/` without `skillwiki project-page publish`.
+- Hand-editing root `index.md` for architecture ADRs.
 - Filing the concept page without explicit `provenance:`.
+- Do not author, copy, edit, stage, commit, pull, reset, or push agent changes in `/root/wiki-git`.
+- Running snapshot scripts or `git reset --hard` in the snapshot worktree as a publication shortcut.

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

@@ -174,64 +174,47 @@ 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.
@@ -240,6 +223,9 @@ bash ~/.hermes/scripts/wiki-snapshot.sh  # Re-sync fresh
 - Modifying files in `raw/` to resolve conflicts (N9 — archive and re-ingest instead).
 - 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)
 

package/skills/wiki-sync/SKILL.md

@@ -174,64 +174,47 @@ 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.
@@ -240,6 +223,9 @@ bash ~/.hermes/scripts/wiki-snapshot.sh  # Re-sync fresh
 - Modifying files in `raw/` to resolve conflicts (N9 — archive and re-ingest instead).
 - 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)