docs(agents): sync commit/push policy, MemPalace tunnels rewrite

.agent-instructions/AGENTS.md

@@ -30,20 +30,24 @@ Common types: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`.
 Scope: the phase number, feature area, or affected layer (e.g. `feat(17-03): …`,
 `fix(ingest): …`, `docs(planning): …`).
 
+**Commit and push are standing, default behavior in every `solid-stats` repo** — no per-message
+authorization needed. Session Hygiene above already expects every completed session to end
+committed; treat commit + push as part of finishing the work, not a separate ask. This does
+**not** extend to anything destructive:
+
 **Absolute rules:**
 
-- Never run `git commit`, `git push`, or any destructive git operation (reset --hard, force
-  push, branch -D, rebase) without an explicit instruction from the user in the current message.
-  Authorization from a previous message does not carry forward.
+- `git reset --hard`, force push, `branch -D`, and `rebase` still require an explicit
+  instruction from the user in the current message every time — authorization from a previous
+  message does not carry forward, and the standing commit/push permission above does not imply
+  it.
 - Never skip hooks with `--no-verify` or `--no-gpg-sign` unless explicitly asked to. If a
   pre-commit hook fails, fix the underlying issue — the hook is the signal, not the obstacle.
 - When a pre-commit hook fails, the commit did not happen. Create a new commit after fixing;
   do not amend the previous one (amending could silently modify work that already shipped).
 
-**Auto commit + push policy.** Once the user has explicitly asked for the work to be committed
-(this instruction does not itself grant that authorization — see the absolute rules above), the
-default flow across every `solid-stats` repo is a **direct push to `master`** — no feature branch,
-no PR, unless the repo says otherwise below:
+**Push routing.** The default flow across every `solid-stats` repo is a **direct push to
+`master`** — no feature branch, no PR, unless the repo says otherwise below:
 
 - **`server-2`** has a protected `master` — always go through a branch + pull request there,
   never a direct push.
@@ -107,8 +111,15 @@ Every SolidStats repo has its own MemPalace **wing, named after the repo itself*
 (`web`, `server-2`, `replays-fetcher`, `replay-parser-2`, `infrastructure`, `skills`) — use the
 generic `mcp__mempalace__*` tools, scoped to that wing; there is no isolated per-project MCP
 server here (unlike VocalClub's `vocalclub_memory`). Never file a durable fact into the wrong
-repo's wing, and never invent a new wing name — if a fact spans repos, use a cross-wing tunnel
-(`mempalace_create_tunnel`) instead of duplicating the drawer.
+repo's wing, and never invent a new wing name.
+
+**Inside a GSD workflow, most of this is already automatic.** The `mempalace` GSD capability
+injects recall into `discuss:pre` (gated by `mempalace.recall_on_discuss`) and capture into
+`execute:wave:post` (gated by `mempalace.capture_artifacts`), plus a ship-time curator
+(`gsd-mempalace-curator`) — see `gsd/common-config.json` for the shared defaults and each
+repo's `.planning/config.json` for the rest. Don't re-implement that cycle by hand inside a GSD
+phase; the sections below are for everything GSD's own injection doesn't cover — ad-hoc
+diagnosis, a non-GSD session, or manual recall/capture outside a phase boundary.
 
 - **Recall before diagnosing or building**, not just when a hook happens to inject a snippet.
   Run an explicit `mempalace_search` seeded from the task's real identifiers (symptom, service
@@ -119,10 +130,38 @@ repo's wing, and never invent a new wing name — if a fact spans repos, use a c
   resolved gotcha — not raw session transcripts, planning artifacts, or GSD's own
   `CONTEXT.md`/`PLAN.md`/`SUMMARY.md` files. Dedup with `mempalace_check_duplicate` before
   filing.
-- **GSD's `mempalace` config block** (`.planning/config.json`) governs whether/when a GSD
-  workflow recalls and captures automatically for that repo; the common defaults live in
-  `agent-instructions`' `gsd/common-config.json` (`mempalace.enabled`), while the richer
-  per-repo flags (`capture_artifacts`, `mirror_kg`, `cross_project_tunnels`,
+- **`memory_mode` stays `augment`** (GSD's own default): the palace is an additional layer,
+  never a replacement for `.planning/graphs/` or `STATE.md`. **Never enable
+  `mempalace.recall_on_plan`** — the planner doesn't automatically consume that separate
+  recall artifact, so it just produces an orphaned memory read; the top-level coordinator's one
+  scoped recall (at `discuss:pre`, or manually for entry points with no native recall hook —
+  `gsd-quick`, `gsd-fast`, `gsd-debug`) is the single recall point per task. Specialists and
+  subagents don't independently recall or capture — they get a filtered context handoff from
+  whichever level already recalled.
+
+### Cross-repo tunnels — use them, don't just avoid duplicating
+
+SolidStats is a genuinely multi-repo platform (§D/§E) — a decision at a cross-app boundary or
+contract change routinely concerns two wings at once, unlike VC's setup, which leaves
+`cross_project_tunnels` off. Here it should be **on and actually used**, not just a
+de-duplication fallback:
+
+- **Create a tunnel** (`mempalace_create_tunnel`) whenever a captured fact genuinely concerns
+  two repos — an API/data-model/queue/S3-layout/parser-contract decision (§E's high-risk list)
+  almost always does. File the fact once, in the wing of the repo that owns the decision, then
+  tunnel it to the other wing(s) it affects instead of duplicating the drawer.
+- **Query tunnels during recall, not just search.** A wing-scoped `mempalace_search` alone can
+  miss a relevant fact filed under an adjacent repo's wing. Before or alongside recall on a
+  cross-app task, run `mempalace_find_tunnels` (between the two wings in play) or
+  `mempalace_follow_tunnels` (from the current wing) to surface what's already linked.
+- **`mempalace.mirror_kg`** (per-repo, stays local — see below) governs whether decision facts
+  also mirror into the temporal knowledge graph; tunnels connect *drawers*, `mempalace_kg_add`
+  connects *typed facts* — use whichever fits what's actually being captured, and both where a
+  cross-repo decision has both a narrative and a queryable shape (e.g. a validity window).
+- **`mempalace.enabled` and `mempalace.cross_project_tunnels`** are common defaults in
+  `agent-instructions`' `gsd/common-config.json` — the latter is a deliberate override of
+  gsd-core's own default (`false`), because a single-service default doesn't fit a genuinely
+  multi-repo platform. The richer per-repo flags (`capture_artifacts`, `mirror_kg`,
   `auto_capture_hooks`) are tuned per repo and stay local — a backend service and a frontend
   repo do not need identical capture behavior.
 

.planning/config.json

@@ -211,7 +211,8 @@
     "enabled": true
   },
   "mempalace": {
-    "enabled": true
+    "enabled": true,
+    "cross_project_tunnels": true
   },
   "code_quality": {
     "fallow": {