feat(plugins): add queryable coding session profiles

plugins/claude-code/README.md

@@ -20,9 +20,9 @@ the session back to it before the context window compacts.
   queries Basic Memory for your active tasks and recent work and puts a short
   brief in front of Claude — so you start where you left off instead of cold.
 - **Compaction checkpoint (PreCompact hook).** Right before Claude Code compacts
-  the context window, the plugin writes a `type: session` checkpoint note to the
-  graph, so the texture of the session survives and the next one can resume from
-  it.
+  the context window, the plugin writes a general `session` or schema-backed
+  `coding_session` checkpoint note to the graph, so the texture of the session
+  survives and the next one can resume from it.
 - **Deliberate checkpoints (`bm-checkpoint` skill).** On request — "checkpoint
   this", "wrap up", "hand off" — Claude writes a durable handoff note: the story,
   verification actually run, decisions, blockers, and the next action. In a
@@ -138,19 +138,19 @@ settings (or select it via `/config`).
 | `recallTimeframe` | `3d` | Recency window for the session brief |
 | `recallPrompt` | _(built-in)_ | The instruction appended to the brief |
 | `preCompactCapture` | `extractive` | How checkpoints are produced |
-| `sessionProfile` | `general` | `coding` makes deliberate checkpoints schema-backed `coding_session` notes with required Git identity |
+| `sessionProfile` | `general` | `coding` makes checkpoints schema-backed `coding_session` notes with required Git identity |
 | `repository` | _(none)_ | User-confirmed stable repository identifier (`owner/name`); required for the `coding` profile |
 | `captureEvents` | `false` | Opt-in: record redacted lifecycle-event envelopes to the local inbox (see `basic-memory hook status` / `flush`). Only the JSON boolean `true` enables it. |
 | `redactKeys` | `[]` | Additional payload keys to redact before an event enters the local inbox |
 | `redactPaths` | `[]` | Additional paths to redact from working-directory and path-bearing capture content |
 
 The plugin seeds schemas for notes the Claude integration writes directly:
-`session`, `decision`, and `task`. A **coding setup** (the interview's focus
-answer is code/dev, persisted as `sessionProfile: "coding"` with a
-user-confirmed `repository`) also seeds `coding_session`, whose required
-repository, repo-root, working-directory, branch, and Git SHA frontmatter make
-checkpoints queryable by structured filters; typed pull-request fields are
-added when a PR exists. Optional flush projection also writes
+`decision`, `task`, and the session type relevant to the selected profile. A
+general setup seeds `session`; a **coding setup** (persisted as
+`sessionProfile: "coding"` with a user-confirmed `repository`) seeds
+`coding_session`, whose required repository, repo-root, working-directory,
+branch, and Git SHA frontmatter make checkpoints queryable by structured
+filters; typed pull-request fields are added when a PR exists. Optional flush projection also writes
 normalized `session` and `tool_ledger` artifacts. Those projection contracts are
 owned and tested by Basic Memory core rather than copied into separate
 host-plugin schemas.

plugins/claude-code/schemas/coding-session.md

@@ -23,7 +23,7 @@ settings:
     git_sha: string, exact Git commit at checkpoint time
     ended?: string, when the session was checkpointed
     status?(enum, lifecycle of the checkpoint): [open, resumed, closed]
-    pull_request_number?: integer, current pull request number
+    pull_request_number?: string, current pull request number as a queryable identifier
     pull_request_title?: string, current pull request title
     pull_request_url?: string, canonical pull request URL
     pull_request_state?(enum, pull request state at checkpoint time): [open, closed, merged]
@@ -32,6 +32,8 @@ settings:
     username?: string, operating-system user that created the checkpoint
     hostname?: string, host that created the checkpoint
     claude_session_id?: string, Claude Code session identifier
+    codex_session_id?: string, Codex session identifier
+    codex_turn_id?: string, Codex turn identifier
     trigger?: string, compaction trigger or deliberate checkpoint source
     model?: string, active model slug when known
     capture?(enum, how this checkpoint was produced): [extractive, deliberate, summarized]
@@ -47,7 +49,7 @@ Examples:
 
 `search_notes(note_types=["coding_session"], metadata_filters={"repository": "owner/repo"})`
 
-`search_notes(note_types=["coding_session"], metadata_filters={"pull_request_number": 123})`
+`search_notes(note_types=["coding_session"], metadata_filters={"pull_request_number": "123"})`
 
 Pull-request fields are optional because valid coding work can precede a pull
 request. When a pull request exists, checkpoint writers populate the complete

plugins/claude-code/schemas/session.md

@@ -34,8 +34,8 @@ session was doing so the next session can pick up where this one left off.
 Sessions are found by the SessionStart hook via structured recall:
 `search_notes(metadata_filters={"type": "session"}, after_date="3d")`.
 
-In a **coding setup** (`sessionProfile: "coding"`), deliberate checkpoints use
-the Coding Session schema instead — it adds required, queryable Git identity
+In a **coding setup** (`sessionProfile: "coding"`), checkpoints use the Coding
+Session schema instead — it adds required, queryable Git identity
 (`repository`, `branch`, `git_sha`, pull-request fields). This schema stays the
 general-purpose checkpoint.
 

plugins/claude-code/skills/bm-checkpoint/SKILL.md

@@ -83,8 +83,10 @@ When the current branch has a pull request, also add the typed optional fields
 `pull_request_number`, `pull_request_title`, `pull_request_url`, lowercase
 `pull_request_state`, `pull_request_base`, and `pull_request_head`. Resolve the
 pull request with a read-only GitHub query (e.g. `gh pr view --json ...`); omit
-those fields when no PR exists. Never infer or copy repository/PR identity only
-from conversation text. Stop if the required coding fields cannot be proven.
+those fields when no PR exists. Write the number as a quoted string, for example
+`pull_request_number: "123"`, so exact metadata queries behave consistently
+across storage backends. Never infer or copy repository/PR identity only from
+conversation text. Stop if the required coding fields cannot be proven.
 
 Begin the body with `# <exact note title>`.
 

plugins/claude-code/skills/bm-setup/SKILL.md

@@ -107,9 +107,9 @@ Ask only what you can't infer. Cover:
    SessionStart brief surfaces it (alongside `captureFolder`), so this is what makes
    your captures land where the user expects — without it, placement is guesswork.
 
-5. **Schemas.** "I'll add schemas for session checkpoints, decisions, and tasks
-   — plus coding sessions for a coding setup — so I can find them precisely
-   later — okay?" (See "Seed the schemas" below.)
+5. **Schemas.** "I'll add the session schema for this profile, plus decision and
+   task schemas, so I can find them precisely later — okay?" (See "Seed the
+   schemas" below.)
 
 6. **Lifecycle-event capture.** "Should I also keep a local, redacted trail of
    SessionStart and PreCompact events for later projection?" Default to **off**.
@@ -141,7 +141,8 @@ Ask only what you can't infer. Cover:
 ### 1. Seed the schemas
 The plugin ships seed schemas at `<plugin>/schemas/` — that's **two directories up
 from this skill's directory, then `schemas/`** (this skill is at
-`<plugin>/skills/bm-setup/`). Read `session.md`, `decision.md`, and `task.md` there.
+`<plugin>/skills/bm-setup/`). Read `coding-session.md` for a coding profile or
+`session.md` for a general profile, then read `decision.md` and `task.md`.
 
 These schemas cover notes the Claude integration writes directly. The normalized
 `session` and `tool_ledger` artifacts written by `bm hook flush` are core-owned
@@ -168,11 +169,10 @@ For each one:
     round-trips correctly on both local and cloud. After seeding, verify one note
     with `read_note(..., output_format="json", include_frontmatter=true)` —
     `schema`/`settings` must come back as nested objects, not strings.
-- **Coding setup:** when `sessionProfile` is `coding`, also read and seed
-  `coding-session.md` (title `Coding Session`) the same way. Its Git identity
-  fields (`repository`, `repo_root`, `cwd`, `branch`, `git_sha`) are required by
-  design — required-and-proven fields are what make coding checkpoints queryable
-  — so seed the schema unmodified.
+- **Coding setup:** the selected `coding-session.md` schema's Git identity fields
+  (`repository`, `repo_root`, `cwd`, `branch`, `git_sha`) are required by design.
+  Required-and-proven fields are what make coding checkpoints queryable, so seed
+  the schema unmodified instead of also seeding the general Session schema.
 
 ### 2. Install the shared skills (if the user opted in)
 **First, guard against clobbering a source checkout.** If `./skills` already exists,

plugins/codex/README.md

@@ -12,7 +12,8 @@ verification, decision capture, and resumable checkpoints.
 - **Orient from memory.** The `bm-orient` skill reads active tasks, open
   decisions, and recent Codex checkpoints before substantial work.
 - **Checkpoint work.** The `bm-checkpoint` skill and `PreCompact` hook write
-  `type: codex_session` notes with the current work cursor.
+  general `codex_session` notes or schema-backed `coding_session` notes with
+  structured repository and pull-request context.
 - **Capture decisions.** The `bm-decide` skill records durable engineering
   decisions with rationale, alternatives, and consequences.
 - **Remember lightly.** The `bm-remember` skill saves small facts without turning
@@ -87,13 +88,15 @@ Run the setup skill, or create `.codex/basic-memory.json` in a repo:
     "secondaryProjects": [],
     "teamProjects": {},
     "focus": "code/dev",
-    "captureFolder": "codex-sessions",
+    "sessionProfile": "coding",
+    "repository": "owner/repo",
+    "captureFolder": "codex",
     "rememberFolder": "codex-remember",
     "recallTimeframe": "7d",
     "captureEvents": false,
     "redactKeys": [],
     "redactPaths": [],
-    "placementConventions": "Put decisions in decisions/ and work checkpoints in codex-sessions/."
+    "placementConventions": "Put decisions in decisions/ and work checkpoints in codex/."
   }
 }
 ```
@@ -105,10 +108,13 @@ Add `redactKeys` and `redactPaths` arrays to extend the built-in redaction floor
 for repository-specific payload fields and paths.
 
 The plugin's seed schemas cover notes Codex writes directly: `codex_session`,
-`decision`, and `task`. Optional flush projection also writes normalized
-`session` and `tool_ledger` artifacts. Those are core-owned contracts implemented
-and tested with the projector, not duplicate schema files maintained by each host
-plugin. `bm-orient` and `bm-status` still recall normalized `session` notes
+`coding_session`, `decision`, and `task`. Coding sessions require structured
+repository, repository-root, working-directory, branch, and Git SHA frontmatter;
+current pull-request fields are added when a PR exists. Optional flush projection
+also writes normalized `session` and `tool_ledger` artifacts. Those are
+core-owned contracts implemented and tested with the projector, not duplicate
+schema files maintained by each host plugin. `bm-orient` and `bm-status` still
+recall normalized `session` notes
 alongside Codex checkpoints.
 
 Codex plugin hooks must be reviewed and trusted before they run. Open `/hooks` in

plugins/codex/schemas/codex-session.md

@@ -30,7 +30,7 @@ settings:
 
 # Codex Session
 
-A **CodexSession** note is a resumable engineering checkpoint. It captures the
+A **CodexSession** note is a resumable general checkpoint. It captures the
 thread cursor: what changed, what was verified, what decisions matter, and what
 the next Codex thread should do first.
 

plugins/codex/schemas/coding-session.md

@@ -0,0 +1,56 @@
+---
+title: Coding Session
+type: schema
+entity: CodingSession
+version: 1
+schema:
+  summary?: string, one-paragraph what happened in this coding session
+  changed_file?(array): string, files created, edited, deleted, or inspected
+  verification?(array): string, checks run and their result
+  decision?(array): string, decisions surfaced or created during the session
+  blocker?(array): string, unresolved blockers or failed approaches
+  next_step?(array): string, explicit cursor for the next coding session
+  produced?(array): Entity, notes or artifacts created or updated
+settings:
+  validation: warn
+  frontmatter:
+    project: string, the Basic Memory project this session belongs to
+    started: string, when the session began or checkpoint was created
+    repository: string, stable repository identifier such as owner/name
+    repo_root: string, Git repository root for this checkout
+    cwd: string, working directory for the session
+    branch: string, checked-out Git branch or HEAD when detached
+    git_sha: string, exact Git commit at checkpoint time
+    ended?: string, when the session was checkpointed
+    status?(enum, lifecycle of the checkpoint): [open, resumed, closed]
+    pull_request_number?: string, current pull request number as a queryable identifier
+    pull_request_title?: string, current pull request title
+    pull_request_url?: string, canonical pull request URL
+    pull_request_state?(enum, pull request state at checkpoint time): [open, closed, merged]
+    pull_request_base?: string, pull request base branch
+    pull_request_head?: string, pull request head branch
+    username?: string, operating-system user that created the checkpoint
+    hostname?: string, host that created the checkpoint
+    claude_session_id?: string, Claude Code session identifier
+    codex_session_id?: string, Codex session identifier
+    codex_turn_id?: string, Codex turn identifier
+    trigger?: string, compaction trigger or deliberate checkpoint source
+    model?: string, active model slug when known
+    capture?(enum, how this checkpoint was produced): [extractive, deliberate, summarized]
+---
+
+# Coding Session
+
+A **CodingSession** is a resumable engineering checkpoint whose repository
+identity is structured and queryable. Required Git fields make it possible to
+find the exact work cursor without parsing prose.
+
+Examples:
+
+`search_notes(note_types=["coding_session"], metadata_filters={"repository": "owner/repo"})`
+
+`search_notes(note_types=["coding_session"], metadata_filters={"pull_request_number": "123"})`
+
+Pull-request fields are optional because valid coding work can precede a pull
+request. When a pull request exists, checkpoint writers populate the complete
+pull-request field set.

plugins/codex/skills/bm-checkpoint/SKILL.md

@@ -14,8 +14,10 @@ context transition.
 Read `.codex/basic-memory.json` if present:
 
 - `primaryProject`, default omitted
-- `captureFolder`, default `codex-sessions`
+- `captureFolder`, default `codex`
 - `placementConventions`, optional
+- `sessionProfile`, default `general`
+- `repository`, required when `sessionProfile` is `coding`
 
 Apply the `bm-writing` skill before drafting the note.
 
@@ -27,6 +29,9 @@ Gather repo evidence:
 - tradeoffs, sharp edges, useful simplifications, and intentionally parked work
 - `git status --short`
 - current branch
+- repository root and current working directory
+- current Git SHA
+- current pull request number, title, URL, state, base, and head when one exists
 - changed files you touched
 - tests or checks actually run
 - failures or skipped checks
@@ -42,7 +47,7 @@ Do not claim a test passed unless you ran it or the user supplied the result.
 A checkpoint is a durable handoff, not a status dump or commit-by-commit
 changelog. Tell the story for a human or agent returning later.
 
-Write a note to Basic Memory:
+Write a note to Basic Memory. For the `general` profile:
 
 - `title`: `Codex checkpoint - <short topic>`
 - `directory`: configured `captureFolder`
@@ -57,6 +62,24 @@ Write a note to Basic Memory:
   - `hostname: <current hostname>`
   - `capture: deliberate`
 
+For the `coding` profile, write `type: coding_session` and use the same common
+frontmatter plus these schema-required fields:
+
+- `repository: <confirmed stable repository identifier>`
+- `repo_root: <git rev-parse --show-toplevel>`
+- `cwd: <current cwd>`
+- `branch: <git rev-parse --abbrev-ref HEAD>`
+- `git_sha: <git rev-parse HEAD>`
+
+When the current branch has a pull request, also add the typed optional fields
+`pull_request_number`, `pull_request_title`, `pull_request_url`,
+`pull_request_state`, `pull_request_base`, and `pull_request_head`. Resolve the
+pull request with a read-only GitHub query; omit those fields when no PR exists.
+Write the number as a quoted string, for example `pull_request_number: "123"`,
+so exact metadata queries behave consistently across storage backends.
+Never infer or copy repository/PR identity only from conversation text. Stop if
+the required coding fields cannot be proven.
+
 Begin the body with `# <exact note title>`.
 
 Use these sections, omitting optional ones that add no value:

plugins/codex/skills/bm-orient/SKILL.md

@@ -11,25 +11,34 @@ the user asks where things stand.
 ## Steps
 
 1. Read `.codex/basic-memory.json` if present. Use `primaryProject`, `secondaryProjects`,
-   `recallTimeframe`, and `placementConventions`. If the file is missing, continue
+   `recallTimeframe`, `sessionProfile`, `repository`, and `placementConventions`.
+   If the file is missing, continue
    against the default Basic Memory project and mention that setup has not been run.
 
 2. Query the primary project:
    - active tasks: `type=task`, `status=active`
    - open decisions: `type=decision`, `status=open`
    - recent Codex sessions: `type=codex_session`, after `recallTimeframe`
+   - recent coding sessions: `type=coding_session`,
+     `repository=<configured repository>`, after `recallTimeframe`, when
+     `sessionProfile=coding`
    - recent core-projected sessions: `type=session`, after `recallTimeframe`
 
-   Always query both session types. Merge and deduplicate the results, sort them
+   Always query `codex_session` and `session`; include `coding_session` for a
+   coding profile only with the configured `repository` metadata filter. Never
+   run an unscoped coding-session query; if the repository is missing, report
+   that setup is incomplete. Merge and deduplicate the results, sort them
    newest first, and prefer the highest-signal checkpoint regardless of which
-   producer wrote it. `codex_session` preserves deliberate and legacy Codex
-   checkpoints; `session` carries normalized artifacts from `bm hook flush`.
+   producer wrote it. `coding_session` carries schema-required, queryable Git
+   context; `codex_session` preserves general and legacy Codex checkpoints;
+   `session` carries normalized artifacts from `bm hook flush`.
 
 3. Query configured `secondaryProjects` read-only for open decisions. Do not write
    to shared projects during orientation.
 
 4. Read the highest-signal hits before summarizing. Prefer notes that match the
-   current repo, named route, issue, branch, or file path.
+   current repository, branch, Git SHA, pull request, named route, issue, or file
+   path. For coding sessions, use structured metadata filters before text search.
 
 5. Present a compact orientation:
    - active work