create-egregore 0.19.21 → 0.19.23

package/runtime/pi/.codex/skills/task/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: task
-description: 'Create, import, inspect, approve, answer, or cancel work in the hosted Egregore Agent Desk. Use for `/task`, `$task`, “send this work to the agents,” “start these tasks,” Markdown development batches, or checking hosted task progress. This skill submits work to the hosted pipeline; it does not implement the task in the current local session.'
+description: 'Create, import, inspect, approve, answer, retry, complete, or cancel work in the hosted Egregore Agent Desk. Use for `/task`, `$task`, “send this work to the agents,” “start these tasks,” Markdown development batches, or checking hosted task progress. This skill submits work to the hosted pipeline; it does not implement the task in the current local session.'
 ---
 
 <!-- generated-by: bin/codex-sync-skills.sh -->
@@ -17,9 +17,13 @@ when it is available; otherwise render compact numbered choices with an
 
 1. Read `.claude/skills/task/SKILL.md` for the workflow details.
 2. Run the referenced `bin/` scripts directly from Codex.
-3. Treat graph, publish, and notify steps as best-effort unless that workflow
-   explicitly says they are required.
-4. Keep local-mode behavior filesystem-first and avoid graph or notification
+3. Treat graph and publish steps as best-effort unless that workflow explicitly
+   says they are required.
+4. For every external notification, follow
+   `.claude/context/notification-consent.md`: plan without sending, then show
+   a separate exact Send / Edit / Cancel checkpoint. Never infer notification
+   consent from the workflow request or a batch approval.
+5. Keep local-mode behavior filesystem-first and avoid graph or notification
    calls when `egregore.json` declares `"mode": "local"`.
-5. Never call the deprecated `egregore-handoff` CLI for Egregore project
+6. Never call the deprecated `egregore-handoff` CLI for Egregore project
    handoffs.

package/runtime/pi/.codex/skills/teams-connect/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: teams-connect
+description: 'Fallback Codex adapter for the Egregore teams-connect workflow.'
+---
+
+<!-- generated-by: bin/codex-sync-skills.sh -->
+
+# Egregore teams-connect Adapter
+
+This is fallback coverage for a long-tail Egregore workflow that has not been
+ported to a hand-written Codex-native skill yet.
+
+Use the project shell and filesystem directly. Do not invoke Claude Code
+commands. Translate interactive choices to structured Codex question tooling
+when it is available; otherwise render compact numbered choices with an
+`Other:` option and wait for the user.
+
+1. Read `.claude/skills/teams-connect/SKILL.md` for the workflow details.
+2. Run the referenced `bin/` scripts directly from Codex.
+3. Treat graph and publish steps as best-effort unless that workflow explicitly
+   says they are required.
+4. For every external notification, follow
+   `.claude/context/notification-consent.md`: plan without sending, then show
+   a separate exact Send / Edit / Cancel checkpoint. Never infer notification
+   consent from the workflow request or a batch approval.
+5. Keep local-mode behavior filesystem-first and avoid graph or notification
+   calls when `egregore.json` declares `"mode": "local"`.
+6. Never call the deprecated `egregore-handoff` CLI for Egregore project
+   handoffs.

package/runtime/pi/.codex/skills/telegram-connect/SKILL.md

@@ -17,9 +17,13 @@ when it is available; otherwise render compact numbered choices with an
 
 1. Read `.claude/skills/telegram-connect/SKILL.md` for the workflow details.
 2. Run the referenced `bin/` scripts directly from Codex.
-3. Treat graph, publish, and notify steps as best-effort unless that workflow
-   explicitly says they are required.
-4. Keep local-mode behavior filesystem-first and avoid graph or notification
+3. Treat graph and publish steps as best-effort unless that workflow explicitly
+   says they are required.
+4. For every external notification, follow
+   `.claude/context/notification-consent.md`: plan without sending, then show
+   a separate exact Send / Edit / Cancel checkpoint. Never infer notification
+   consent from the workflow request or a batch approval.
+5. Keep local-mode behavior filesystem-first and avoid graph or notification
    calls when `egregore.json` declares `"mode": "local"`.
-5. Never call the deprecated `egregore-handoff` CLI for Egregore project
+6. Never call the deprecated `egregore-handoff` CLI for Egregore project
    handoffs.

package/runtime/pi/.codex/skills/telemetry/SKILL.md

@@ -17,9 +17,13 @@ when it is available; otherwise render compact numbered choices with an
 
 1. Read `.claude/skills/telemetry/SKILL.md` for the workflow details.
 2. Run the referenced `bin/` scripts directly from Codex.
-3. Treat graph, publish, and notify steps as best-effort unless that workflow
-   explicitly says they are required.
-4. Keep local-mode behavior filesystem-first and avoid graph or notification
+3. Treat graph and publish steps as best-effort unless that workflow explicitly
+   says they are required.
+4. For every external notification, follow
+   `.claude/context/notification-consent.md`: plan without sending, then show
+   a separate exact Send / Edit / Cancel checkpoint. Never infer notification
+   consent from the workflow request or a batch approval.
+5. Keep local-mode behavior filesystem-first and avoid graph or notification
    calls when `egregore.json` declares `"mode": "local"`.
-5. Never call the deprecated `egregore-handoff` CLI for Egregore project
+6. Never call the deprecated `egregore-handoff` CLI for Egregore project
    handoffs.

package/runtime/pi/.codex/skills/test/SKILL.md

@@ -33,9 +33,13 @@ reading `.claude/skills/test/SKILL.md`, reproduce the same visible UX in Codex:
 
 1. Read `.claude/skills/test/SKILL.md` for the workflow details.
 2. Run the referenced `bin/` scripts directly from Codex.
-3. Treat graph, publish, and notify steps as best-effort unless that workflow
-   explicitly says they are required.
-4. Keep local-mode behavior filesystem-first and avoid graph or notification
+3. Treat graph and publish steps as best-effort unless that workflow explicitly
+   says they are required.
+4. For every external notification, follow
+   `.claude/context/notification-consent.md`: plan without sending, then show
+   a separate exact Send / Edit / Cancel checkpoint. Never infer notification
+   consent from the workflow request or a batch approval.
+5. Keep local-mode behavior filesystem-first and avoid graph or notification
    calls when `egregore.json` declares `"mode": "local"`.
-5. Never call the deprecated `egregore-handoff` CLI for Egregore project
+6. Never call the deprecated `egregore-handoff` CLI for Egregore project
    handoffs.

package/runtime/pi/.codex/skills/thread/SKILL.md

@@ -17,9 +17,13 @@ when it is available; otherwise render compact numbered choices with an
 
 1. Read `.claude/skills/thread/SKILL.md` for the workflow details.
 2. Run the referenced `bin/` scripts directly from Codex.
-3. Treat graph, publish, and notify steps as best-effort unless that workflow
-   explicitly says they are required.
-4. Keep local-mode behavior filesystem-first and avoid graph or notification
+3. Treat graph and publish steps as best-effort unless that workflow explicitly
+   says they are required.
+4. For every external notification, follow
+   `.claude/context/notification-consent.md`: plan without sending, then show
+   a separate exact Send / Edit / Cancel checkpoint. Never infer notification
+   consent from the workflow request or a batch approval.
+5. Keep local-mode behavior filesystem-first and avoid graph or notification
    calls when `egregore.json` declares `"mode": "local"`.
-5. Never call the deprecated `egregore-handoff` CLI for Egregore project
+6. Never call the deprecated `egregore-handoff` CLI for Egregore project
    handoffs.

package/runtime/pi/.codex/skills/todo/SKILL.md

@@ -33,9 +33,13 @@ reading `.claude/skills/todo/SKILL.md`, reproduce the same visible UX in Codex:
 
 1. Read `.claude/skills/todo/SKILL.md` for the workflow details.
 2. Run the referenced `bin/` scripts directly from Codex.
-3. Treat graph, publish, and notify steps as best-effort unless that workflow
-   explicitly says they are required.
-4. Keep local-mode behavior filesystem-first and avoid graph or notification
+3. Treat graph and publish steps as best-effort unless that workflow explicitly
+   says they are required.
+4. For every external notification, follow
+   `.claude/context/notification-consent.md`: plan without sending, then show
+   a separate exact Send / Edit / Cancel checkpoint. Never infer notification
+   consent from the workflow request or a batch approval.
+5. Keep local-mode behavior filesystem-first and avoid graph or notification
    calls when `egregore.json` declares `"mode": "local"`.
-5. Never call the deprecated `egregore-handoff` CLI for Egregore project
+6. Never call the deprecated `egregore-handoff` CLI for Egregore project
    handoffs.

package/runtime/pi/.codex/skills/tui-design/SKILL.md

@@ -33,9 +33,13 @@ reading `.claude/skills/tui-design/SKILL.md`, reproduce the same visible UX in C
 
 1. Read `.claude/skills/tui-design/SKILL.md` for the workflow details.
 2. Run the referenced `bin/` scripts directly from Codex.
-3. Treat graph, publish, and notify steps as best-effort unless that workflow
-   explicitly says they are required.
-4. Keep local-mode behavior filesystem-first and avoid graph or notification
+3. Treat graph and publish steps as best-effort unless that workflow explicitly
+   says they are required.
+4. For every external notification, follow
+   `.claude/context/notification-consent.md`: plan without sending, then show
+   a separate exact Send / Edit / Cancel checkpoint. Never infer notification
+   consent from the workflow request or a batch approval.
+5. Keep local-mode behavior filesystem-first and avoid graph or notification
    calls when `egregore.json` declares `"mode": "local"`.
-5. Never call the deprecated `egregore-handoff` CLI for Egregore project
+6. Never call the deprecated `egregore-handoff` CLI for Egregore project
    handoffs.

package/runtime/pi/.codex/skills/tutorial/SKILL.md

@@ -33,9 +33,13 @@ reading `.claude/skills/tutorial/SKILL.md`, reproduce the same visible UX in Cod
 
 1. Read `.claude/skills/tutorial/SKILL.md` for the workflow details.
 2. Run the referenced `bin/` scripts directly from Codex.
-3. Treat graph, publish, and notify steps as best-effort unless that workflow
-   explicitly says they are required.
-4. Keep local-mode behavior filesystem-first and avoid graph or notification
+3. Treat graph and publish steps as best-effort unless that workflow explicitly
+   says they are required.
+4. For every external notification, follow
+   `.claude/context/notification-consent.md`: plan without sending, then show
+   a separate exact Send / Edit / Cancel checkpoint. Never infer notification
+   consent from the workflow request or a batch approval.
+5. Keep local-mode behavior filesystem-first and avoid graph or notification
    calls when `egregore.json` declares `"mode": "local"`.
-5. Never call the deprecated `egregore-handoff` CLI for Egregore project
+6. Never call the deprecated `egregore-handoff` CLI for Egregore project
    handoffs.

package/runtime/pi/.codex/skills/update/SKILL.md

@@ -17,9 +17,13 @@ when it is available; otherwise render compact numbered choices with an
 
 1. Read `.claude/skills/update/SKILL.md` for the workflow details.
 2. Run the referenced `bin/` scripts directly from Codex.
-3. Treat graph, publish, and notify steps as best-effort unless that workflow
-   explicitly says they are required.
-4. Keep local-mode behavior filesystem-first and avoid graph or notification
+3. Treat graph and publish steps as best-effort unless that workflow explicitly
+   says they are required.
+4. For every external notification, follow
+   `.claude/context/notification-consent.md`: plan without sending, then show
+   a separate exact Send / Edit / Cancel checkpoint. Never infer notification
+   consent from the workflow request or a batch approval.
+5. Keep local-mode behavior filesystem-first and avoid graph or notification
    calls when `egregore.json` declares `"mode": "local"`.
-5. Never call the deprecated `egregore-handoff` CLI for Egregore project
+6. Never call the deprecated `egregore-handoff` CLI for Egregore project
    handoffs.

package/runtime/pi/.codex/skills/visual-explain/SKILL.md

@@ -33,9 +33,13 @@ reading `.claude/skills/visual-explain/SKILL.md`, reproduce the same visible UX
 
 1. Read `.claude/skills/visual-explain/SKILL.md` for the workflow details.
 2. Run the referenced `bin/` scripts directly from Codex.
-3. Treat graph, publish, and notify steps as best-effort unless that workflow
-   explicitly says they are required.
-4. Keep local-mode behavior filesystem-first and avoid graph or notification
+3. Treat graph and publish steps as best-effort unless that workflow explicitly
+   says they are required.
+4. For every external notification, follow
+   `.claude/context/notification-consent.md`: plan without sending, then show
+   a separate exact Send / Edit / Cancel checkpoint. Never infer notification
+   consent from the workflow request or a batch approval.
+5. Keep local-mode behavior filesystem-first and avoid graph or notification
    calls when `egregore.json` declares `"mode": "local"`.
-5. Never call the deprecated `egregore-handoff` CLI for Egregore project
+6. Never call the deprecated `egregore-handoff` CLI for Egregore project
    handoffs.

package/runtime/pi/.codex/spec-manifest.json

@@ -35,7 +35,7 @@
     {
       "section": "After Greeting — BRANCH ON FIRST RESPONSE",
       "action": "replace",
-      "sourceHash": "bce266fb848b",
+      "sourceHash": "f3bce52b9ade",
       "note": "EnterWorktree -> bin/agent.sh branch with git checkout fallback; AskUserQuestion -> numbered options in plain text; branch-guard mapped to .codex/hooks/branch-guard.js with instruction fallback; plan-mode note dropped (no plan mode on Codex); /branch + /onboarding -> skill tokens. Handoff claiming and repoState auto-checkout kept verbatim (pure git)."
     },
     {
@@ -59,7 +59,7 @@
     {
       "section": "Notifications",
       "action": "keep",
-      "sourceHash": "e155d669f5bd",
+      "sourceHash": "1649d6eebb96",
       "note": "Kept verbatim — bin/notify.sh is runtime-neutral."
     },
     {
@@ -89,7 +89,7 @@
     {
       "section": "Git Workflow",
       "action": "keep",
-      "sourceHash": "49fd4625fa1e",
+      "sourceHash": "fe3d9dabd03d",
       "note": "Kept; slash tokens rendered as $skill tokens. Branch diagram unchanged (code fence)."
     },
     {
@@ -101,7 +101,7 @@
     {
       "section": "Command Awareness",
       "action": "keep",
-      "sourceHash": "a020fc5d9b98",
+      "sourceHash": "d6fe47a75c00",
       "note": "Prepended the Codex command surface (skill tokens, native vs adapter split, $save abstraction); disambiguation map kept with /x -> $x token rendering. Tokens with no Codex skill (e.g. /loop, a Claude Code harness feature) are left as-is."
     },
     {

package/runtime/pi/.pi/APPEND_SYSTEM.md

@@ -51,11 +51,18 @@ The project-local Pi extension renders the Egregore startup card (identity, hand
 
 **Mandatory behavioral rule.** When the user describes work, your **first action** — before reading files, exploring code, or anything else — is to get onto a working branch:
 
+The integration branch is `develop` by default. When top-level
+`egregore.json.base_branch` is set, that configured branch replaces
+`develop` as the branch point, rebase target, PR base, and protected
+integration branch.
+
 1. Derive a topic slug from what the user said (kebab-case, 2–4 words)
-2. Run `bin/agent.sh branch --topic "<topic>"` — it creates a work branch from `origin/develop` in a task worktree (`dev/{author}/{slug}`, or `feature/{slug}` / `bugfix/{slug}` when the topic reads as a feature or fix) and prints the worktree path. Continue all file work from that printed path.
+2. Run `bin/agent.sh branch --topic "<topic>"` — it resolves the configured base and creates a work branch from `origin/{base}` in a task worktree (`dev/{author}/{slug}`, or `feature/{slug}` / `bugfix/{slug}` when the topic reads as a feature or fix). Continue all file work from the printed path.
 3. Confirm: `On {branch} (worktree).`
 
-**Fallback:** If `bin/agent.sh branch` fails, use `git checkout -b dev/{author}/{slug} origin/develop`.
+**Fallback:** If `bin/agent.sh branch` fails, resolve `{base}` with
+`_get_base_branch`, then use
+`git checkout -b dev/{author}/{slug} origin/{base}`.
 
 4. Update graph (fire-and-forget): `bash bin/graph-op.sh set-topic "$(cat .egregore-session-id 2>/dev/null)" "topic from slug" "dev/author/slug" 2>/dev/null &`
 
@@ -87,11 +94,11 @@ Report results: `✓ Checked out {branch} in {repo1}, {repo2}`. If a branch no l
 
 **Topic pivot while on a working branch:** If the user describes work **unrelated** to the current branch's topic, treat it as a new topic and create a new branch (`bin/agent.sh branch --topic "<new topic>"`). Do NOT mix unrelated work on one branch.
 
-If on develop after two messages, create a branch immediately from whatever context you have.
+If still on the configured base branch after two messages, create a branch immediately from whatever context you have.
 
 ### Branch-guard protocol
 
-The `.pi/extensions/egregore.ts` `tool_call` gate (loaded after Pi project trust) protects project writes on `develop`/`main`/`master`. Its block message is operational guidance, not a reason to interrupt the user with routine Git choices:
+The `.pi/extensions/egregore.ts` `tool_call` gate (loaded after Pi project trust) protects project writes on the configured base branch as well as `develop`/`main`/`master`. Its block message is operational guidance, not a reason to interrupt the user with routine Git choices:
 
 - **Topic is clear** (the user said "fix X", "add Y feature") → run `bin/agent.sh branch --topic "<topic>"` automatically, continue in the printed worktree, and say one short sentence so the branch change is visible. Do not ask the user to approve routine branching.
 - **Topic is genuinely ambiguous** → ask only for the topic, using compact numbered options:
@@ -108,7 +115,7 @@ The `.pi/extensions/egregore.ts` `tool_call` gate (loaded after Pi project trust
 
 Memory, managed-repo, and runtime-state writes should bypass the project guard. If one triggers it, correct the operation target/context instead of asking for protected-branch consent.
 
-If Pi project resources are disabled, follow the same discipline as a standing instruction: never write or commit on develop/main/master.
+If Pi project resources are disabled, follow the same discipline as a standing instruction: never write or commit on the configured base, develop, main, or master.
 
 ### Onboarding exception
 
@@ -195,7 +202,19 @@ Never name `Egregore Connect` unless a graph read will actually run.
 
 ## Notifications
 
-**Connected mode only.** Always use `bin/notify.sh` for Telegram notifications — never construct API calls directly. See DEVELOPMENT.md §1 for usage examples. In local mode there are no live notifications.
+**Connected mode only.** Every external notification requires a separate,
+explicit human approval for one exact delivery. Before dispatch, show the
+organization, final recipient or group, every receiving channel, and the exact
+final message (including links) in a dedicated Send / Edit / Cancel checkpoint.
+A workflow request, batch approval, prior approval, broad permission mode, or
+approval of another action is not notification consent. There is no standing
+approval, no unattended dispatch, no silent direct-message-to-group fallback,
+and no retry from an old approval.
+
+Always use the plan → approve → dispatch protocol in
+`.claude/context/notification-consent.md` and `bin/notify.sh`; never call
+notification API endpoints directly. Background jobs and automation may only
+create notification proposals for later human approval.
 
 ---
 
@@ -238,7 +257,10 @@ Loom routes commands across model tiers on the Claude Code runtime (`loom/routes
 
 ## Git Workflow
 
-`develop` branch model with deferred, topic-based branching. Users never interact with git directly.
+`develop` is the default integration branch. A top-level
+`egregore.json.base_branch` replaces it for instances using another integration
+branch; `base_branch: "main"` is single-branch mode. Users never interact with
+git directly.
 
 ```
 main ← stable (/release)
@@ -246,13 +268,13 @@ main ← stable (/release)
     dev/{author}/{topic-slug} | feature/{slug} | bugfix/{slug}
 ```
 
-- **On launch**: syncs develop + memory. Does NOT create a branch.
+- **On launch**: syncs the configured base branch + memory. Does NOT create a branch.
 - **Branch creation**: MANDATORY on first work-related message (see above).
-- **Resuming**: rebase onto develop and continue.
-- **If on develop after two messages**: create branch immediately.
-- **`/save`**: pushes working branch, PR to develop. Auto-merges markdown-only PRs.
+- **Resuming**: rebase onto the configured base branch and continue.
+- **If on the configured base after two messages**: create branch immediately.
+- **`/save`**: pushes the working branch and opens a PR to the configured base. Auto-merges markdown-only PRs.
 - **Memory repo**: stays on main (separate repo, auto-merge).
-- **Never push directly to main or develop.** All changes flow through PRs.
+- **Never push directly to the configured base, main, or develop.** All changes flow through PRs.
 
 ### Pull request format (all harnesses)
 

package/runtime/pi/.pi/extensions/egregore.ts

@@ -385,7 +385,14 @@ export default function egregore(pi) {
     const gitDir = operation?.top || hub?.top || ctx.cwd;
     const result = await pi.exec("git", ["-C", gitDir, "branch", "--show-current"], { timeout: 5000 });
     const branch = String(result.stdout || "").trim();
-    if (!PROTECTED_BRANCHES.has(branch)) return;
+    let configuredBase = "develop";
+    try {
+      const config = JSON.parse(readFileSync(join(gitDir, "egregore.json"), "utf8"));
+      if (typeof config.base_branch === "string" && config.base_branch.trim()) {
+        configuredBase = config.base_branch.trim();
+      }
+    } catch {}
+    if (!PROTECTED_BRANCHES.has(branch) && branch !== configuredBase) return;
 
     // The documented escape hatch must itself be runnable: recording consent
     // (echo 'develop' into .egregore-branch-consent) contains a redirect and

package/runtime/pi/.pi/spec-manifest.json

@@ -1,8 +1,8 @@
 {
   "generatedBy": "bin/pi-render-spec.mjs",
   "source": "AGENTS.md generated Codex spec",
-  "sourceHash": "34a5f678b6e3",
-  "outputHash": "43cd068d78fd",
+  "sourceHash": "dc445470f616",
+  "outputHash": "147fd1b54289",
   "adaptations": [
     "Pi project trust and APPEND_SYSTEM delivery",
     "Pi tool_call branch gate",

package/runtime/pi/AGENTS.md

@@ -125,11 +125,18 @@ The `egregore` launcher renders the Egregore startup card (identity, team moment
 
 **Mandatory behavioral rule.** When the user describes work, your **first action** — before reading files, exploring code, or anything else — is to get onto a working branch:
 
+The integration branch is `develop` by default. When top-level
+`egregore.json.base_branch` is set, that configured branch replaces
+`develop` as the branch point, rebase target, PR base, and protected
+integration branch.
+
 1. Derive a topic slug from what the user said (kebab-case, 2–4 words)
-2. Run `bin/agent.sh branch --topic "<topic>"` — it creates a work branch from `origin/develop` in a task worktree (`dev/{author}/{slug}`, or `feature/{slug}` / `bugfix/{slug}` when the topic reads as a feature or fix) and prints the worktree path. Continue all file work from that printed path.
+2. Run `bin/agent.sh branch --topic "<topic>"` — it resolves the configured base and creates a work branch from `origin/{base}` in a task worktree (`dev/{author}/{slug}`, or `feature/{slug}` / `bugfix/{slug}` when the topic reads as a feature or fix). Continue all file work from the printed path.
 3. Confirm: `On {branch} (worktree).`
 
-**Fallback:** If `bin/agent.sh branch` fails, use `git checkout -b dev/{author}/{slug} origin/develop`.
+**Fallback:** If `bin/agent.sh branch` fails, resolve `{base}` with
+`_get_base_branch`, then use
+`git checkout -b dev/{author}/{slug} origin/{base}`.
 
 4. Update graph (fire-and-forget): `bash bin/graph-op.sh set-topic "$(cat .egregore-session-id 2>/dev/null)" "topic from slug" "dev/author/slug" 2>/dev/null &`
 
@@ -161,11 +168,11 @@ Report results: `✓ Checked out {branch} in {repo1}, {repo2}`. If a branch no l
 
 **Topic pivot while on a working branch:** If the user describes work **unrelated** to the current branch's topic, treat it as a new topic and create a new branch (`bin/agent.sh branch --topic "<new topic>"`). Do NOT mix unrelated work on one branch.
 
-If on develop after two messages, create a branch immediately from whatever context you have.
+If still on the configured base branch after two messages, create a branch immediately from whatever context you have.
 
 ### Branch-guard protocol
 
-The `.codex/hooks/branch-guard.js` PreToolUse hook (enabled by the launcher via `--enable hooks`) protects project writes on `develop`/`main`/`master`. Its block message is operational guidance, not a reason to interrupt the user with routine Git choices:
+The `.codex/hooks/branch-guard.js` PreToolUse hook (enabled by the launcher via `--enable hooks`) protects project writes on the configured base branch as well as `develop`/`main`/`master`. Its block message is operational guidance, not a reason to interrupt the user with routine Git choices:
 
 - **Topic is clear** (the user said "fix X", "add Y feature") → run `bin/agent.sh branch --topic "<topic>"` automatically, continue in the printed worktree, and say one short sentence so the branch change is visible. Do not ask the user to approve routine branching.
 - **Topic is genuinely ambiguous** → ask only for the topic, using compact numbered options:
@@ -182,7 +189,7 @@ The `.codex/hooks/branch-guard.js` PreToolUse hook (enabled by the launcher via
 
 Memory, managed-repo, and runtime-state writes should bypass the project guard. If one triggers it, correct the operation target/context instead of asking for protected-branch consent.
 
-If this Codex build does not support hooks, follow the same discipline as a standing instruction: never write or commit on develop/main/master.
+If this Codex build does not support hooks, follow the same discipline as a standing instruction: never write or commit on the configured base, develop, main, or master.
 
 ### Onboarding exception
 
@@ -269,7 +276,19 @@ Never name `Egregore Connect` unless a graph read will actually run.
 
 ## Notifications
 
-**Connected mode only.** Always use `bin/notify.sh` for Telegram notifications — never construct API calls directly. See DEVELOPMENT.md §1 for usage examples. In local mode there are no live notifications.
+**Connected mode only.** Every external notification requires a separate,
+explicit human approval for one exact delivery. Before dispatch, show the
+organization, final recipient or group, every receiving channel, and the exact
+final message (including links) in a dedicated Send / Edit / Cancel checkpoint.
+A workflow request, batch approval, prior approval, broad permission mode, or
+approval of another action is not notification consent. There is no standing
+approval, no unattended dispatch, no silent direct-message-to-group fallback,
+and no retry from an old approval.
+
+Always use the plan → approve → dispatch protocol in
+`.claude/context/notification-consent.md` and `bin/notify.sh`; never call
+notification API endpoints directly. Background jobs and automation may only
+create notification proposals for later human approval.
 
 ---
 
@@ -312,7 +331,10 @@ Loom routes commands across model tiers on the Claude Code runtime (`loom/routes
 
 ## Git Workflow
 
-`develop` branch model with deferred, topic-based branching. Users never interact with git directly.
+`develop` is the default integration branch. A top-level
+`egregore.json.base_branch` replaces it for instances using another integration
+branch; `base_branch: "main"` is single-branch mode. Users never interact with
+git directly.
 
 ```
 main ← stable (/release)
@@ -320,13 +342,13 @@ main ← stable (/release)
     dev/{author}/{topic-slug} | feature/{slug} | bugfix/{slug}
 ```
 
-- **On launch**: syncs develop + memory. Does NOT create a branch.
+- **On launch**: syncs the configured base branch + memory. Does NOT create a branch.
 - **Branch creation**: MANDATORY on first work-related message (see above).
-- **Resuming**: rebase onto develop and continue.
-- **If on develop after two messages**: create branch immediately.
-- **`$save`**: pushes working branch, PR to develop. Auto-merges markdown-only PRs.
+- **Resuming**: rebase onto the configured base branch and continue.
+- **If on the configured base after two messages**: create branch immediately.
+- **`$save`**: pushes the working branch and opens a PR to the configured base. Auto-merges markdown-only PRs.
 - **Memory repo**: stays on main (separate repo, auto-merge).
-- **Never push directly to main or develop.** All changes flow through PRs.
+- **Never push directly to the configured base, main, or develop.** All changes flow through PRs.
 
 ### Pull request format (all harnesses)
 
@@ -353,7 +375,7 @@ Codex reserves leading `/` for built-ins, so Egregore workflows are **skills**,
 Invoke commands from user intent — don't wait for the slash. Each command file has a `## When to invoke` section. Load it for the full spec.
 
 **Core loop** — `$activity` `$dashboard` `$handoff` `$wrap` `$save` `$reflect` `$todo`
-**Knowledge** — `$search` `$deep-reflect` `$archive` `$note` `$add` `$meeting` `$ingest` `$scroll` `$mock`
+**Knowledge** — `$search` `$deep-reflect` `$archive` `$note` `$add` `$meeting` `$ingest` `$scroll` `$mock` `$audit`
 **Identity** — `$me` (view profile or set display name)
 **Coordination** — `$ask` `$quest` `$issue` `$invite` `$delete-user` `$announce`
 **Connectors** — `$telegram-connect` (Telegram group setup) `$teams-connect` (Microsoft Teams channel setup)
@@ -362,7 +384,7 @@ Invoke commands from user intent — don't wait for the slash. Each command file
 **Infra** — `$setup` `$update` `$pull` `$env` `$infra` `$sync-repos` `$release` `$checkup`
 
 **Disambiguation:**
-- Knowledge: `$reflect` (share-ready) · `$note` (half-baked) · `$deep-reflect` (deep research over memory — questions AND cross-referencing) · `$archive` (AI patterns)
+- Knowledge: `$reflect` (share-ready) · `$note` (half-baked) · `$deep-reflect` (deep research over memory — questions AND cross-referencing) · `$archive` (AI patterns) · `$audit` (evidence-mined forensic sweep of the org's own record — any target)
 - Finding things — **organizational recall starts with `bash bin/search.sh query`** (ranked filesystem retrieval in OSS; automatic relationship/status enrichment in Connect). Use `bin/graph.sh` named reads first only for a pure relationship/status traversal. Use Grep/Glob first for repository code, filenames, and exact error strings—not shared-memory recall. Do not `cd` into the sibling memory repository.
 - Finding **something you generated** (a scroll, handoff, emissary, decision, any hosted egregore.xyz link): `bash bin/artifacts.sh find <query>`. Every generative surface already records into memory — hosted artifacts self-register into `memory/artifacts/` at publish (and the record is committed+pushed, so it's findable from *any* session, not just the one that made it); handoffs land in `memory/handoffs/`, emissaries in `memory/handoffs/outbound/`, decisions/findings/patterns in `memory/knowledge/`. The finder searches **all** of them, ranks title/topic matches above passing body mentions, tags each hit by type (`[document]`/`[handoff]`/`[emissary]`/`[decision]`), and surfaces the shareable URL. Findable by **content, not just name**, across all three layers — grep-first for OSS, folding in search + graph when available. *"bring me the artifact where I laid out our GTM plan"* → this.
 - Artifacts with questions: `$scroll` (living paper + embedded harvest, updates in place) · `$view` (static render) · `$harvest` (elicitation, no published face) · `$mock` (pre-build walkthrough of decided design — gauge per stop, verdict copy-back)

package/runtime/pi/bin/activity-data.sh

@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/usr/bin/env bash
 # Fetches all activity dashboard data: single API call + parallel git/disk ops.
 # Usage: bash bin/activity-data.sh [username]
 # Returns a single JSON object with all query results.