diff --git a/.agent-instructions/AGENTS.md b/.agent-instructions/AGENTS.md index 615e219..fae0f23 100644 --- a/.agent-instructions/AGENTS.md +++ b/.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. diff --git a/.planning/config.json b/.planning/config.json index fc051c5..dc6f4fb 100644 --- a/.planning/config.json +++ b/.planning/config.json @@ -211,7 +211,8 @@ "enabled": true }, "mempalace": { - "enabled": true + "enabled": true, + "cross_project_tunnels": true }, "code_quality": { "fallow": {