feat(claude-sessions): narrate the instance's own development

CHANGELOG.md

@@ -14,6 +14,7 @@ this project adheres to [Semantic Versioning](https://semver.org/).
 - **Slack notification refinements** (`phases/connectors/slack.md`) — two rules upstreamed from accumulated instance experience: **lead the briefing wrap-DM with a "Today's Focus" continuity line** (open with the throughline from recent work to today, before the counts — counts say *how much*, not *what to care about first*); and a **Slack-renderable link refinement** to the existing DM-legibility rule (Slack does not auto-linkify custom URL schemes like `obsidian://` / `file://` — wrap them in mrkdwn angle-bracket form `<url|label>`; GFM `[label](url)` also fails for custom schemes — a clickable-link fix only lands when the link renders in the destination's markup dialect).
 - **GitHub PR action-item context** (`phases/connectors/github.md`) — a rule upstreamed from accumulated instance experience: when a PR becomes an action item, the line must state **what the PR does, which project it serves, and what's blocked downstream** — never just the title and merge status. Captures the change in plain English, the project/area resolved against the KB, who's waiting / what ships on merge, and how long it's waited; a bare title + status is not enough context to act on.
 - **Ingested-timestamp conversion rule** (`phases/core/git-setup.md`, Timezone Handling) — upstreamed from accumulated instance experience: connector payloads often carry UTC timestamps (trailing `Z` / `+00:00`); never copy one verbatim into the KB / action items / a DM as if it were already in the display zone. Parse the source zone and convert to `{{TIMEZONE}}` at write time (it can shift hours and cross a calendar-day boundary, and the drift changes with DST). Connector-agnostic; complements the existing "never use bare `date`" generation rule.
+- **Narrate the instance's own development** (`phases/connectors/claude-sessions.md`) — a rule upstreamed from accumulated instance experience: work *on the system itself* (commits/PRs against the engine/plugin or a companion app, sessions spent building the instance) is invisible to the standard connector scans, which target the user's work product. Sweep the instance's own dev repos' git deltas each run and narrate them, surfacing an instance-owned open/stale PR like any work-product PR. The repo set is **parameterized** — read from this instance's configuration; no hardcoded user paths or private-repo names.
 
 ## [0.7.2] - 2026-06-22
 

phases/connectors/claude-sessions.md

@@ -62,6 +62,19 @@ A session may have changed files that were never committed — invisible to `git
 cd <repo> && git status --porcelain && git log --since='<last-run-time>' --oneline
 ```
 
+### Narrate {{INSTANCE_NAME}}'s Own Development
+
+{{INSTANCE_NAME}} maintains its own codebase, and {{USER_NAME}}'s work *on the system itself* is a real signal the standard connector scans miss — those scans target {{USER_NAME}}'s work product (the repos and trackers tied to projects), not the instance's own development. So commits and PRs against the engine/plugin or a companion app, and sessions spent building {{INSTANCE_NAME}}, go invisible unless swept explicitly.
+
+The vault's own git delta is already narrated (see the Git Setup phase). Extend the **same treatment to the instance's other repositories** — an engine/plugin checkout, a desktop or mobile app — each run:
+
+```bash
+# For each instance-owned dev repo (read from this instance's configuration, not hardcoded):
+git -C <repo> log --since='<last-run-time>' --oneline --shortstat
+```
+
+Narrate the deltas in the run summary, and surface an instance-owned PR that's open and waiting on review (or stale ≥48h) in the action items just as a work-product PR would be. **Parameterize the repo set** — read it from this instance's configuration; never hardcode an absolute user path or a specific private-repo name. An instance whose only repo is its vault simply relies on the vault narration.
+
 ### Claim Gate — No "Actively Building X" Without a Cited Signal
 
 Do not assert that {{USER_NAME}} "is actively building / working on X" unless you can cite a concrete signal: a session JSONL with matching prompts, a commit SHA, an open PR, or dirty working-tree files. A session *title* or a single prompt is weak evidence — tie the claim to the tangible artifact, or downgrade it to "{{USER_NAME}} opened a session about X" rather than asserting active work.