---
name: codepremise-bootstrap
description: Seed the .codepremise/ business-logic map of an EXISTING repository by mining past agent conversations and git history, then interviewing the developer to confirm. Use when a repo adopts codepremise and its .codepremise/nodes/ is empty or sparse.
---

# codepremise bootstrap — fill the map for an existing repo

This repo adopted Logic after it was written, so `.codepremise/nodes/` doesn't yet
describe its existing behavior. Your job: seed it with the claims that matter,
with truthful `why`s. Work through the three evidence tiers IN ORDER — each
tier is more trustworthy than the next, and the interview only covers what the
earlier tiers couldn't source.

Read the capture skill first (`.agents/skills/codepremise/SKILL.md`) — the node
format, hash computation, and restraint rules all apply here.

## Tier 1 — mine past agent conversations (best evidence)

Code written by a coding agent had its reasoning recorded at generation time —
in session transcripts. Distill it.

- **Claude Code** transcripts for this repo live at
  `~/.claude/projects/<encoded-path>/*.jsonl`, where `<encoded-path>` is this
  repo's absolute path with `/` replaced by `-` (e.g.
  `/Users/ana/code/shop` → `-Users-ana-code-shop`).
- **Codex CLI** sessions live under `~/.codex/sessions/` (JSONL as well).
- Grep those files for the paths of your candidate code (see Tier 3 for how
  to pick candidates). For each hit, read around it: the user's request that
  started the task, and the assistant's stated reasoning near the Edit/Write
  calls. That text often contains the literal why ("must apply before tax
  because …", "the customer asked for …", "this guards against #482").
- Limitation to state in your report: transcripts are per-machine. You only
  see the sessions of the person running this bootstrap.

## Tier 2 — mine git history (good evidence)

- `git log --follow -p -- <file>` and `git blame` on candidate lines.
- Bugfix-shaped commits are why-gold: messages containing fix/bug/revert/
  hotfix/incident or issue references (`#123`). The commit that ADDED a guard
  clause usually says what it guards against.
- If the `gh` CLI is available, open referenced issues/PRs and read titles
  and closing comments.

## Tier 3 — rank what deserves a claim at all

Do NOT try to cover the repo. Seed 15–30 claims, chosen by load-bearing
suspicion, highest first:

1. Code paths touching money, auth, permissions, data deletion, external
   side effects (emails, webhooks, charges).
2. Guard clauses and conditionals that look arbitrary (magic numbers,
   special-cased customers, date cutoffs, early returns).
3. Comments that mention tickets, incidents, audits, or "don't remove".
4. High-churn files (many fix commits).
5. Whatever existing tests pin most heavily — a heavily-tested behavior is a
   behavior someone cared about.

Plumbing, glue and config get no claims — same restraint rule as always.

## Tier 4 — interview the developer (for what mining couldn't source)

Confirm, don't make them recall. For every candidate claim, present your best
evidence and ask for a verdict, in batches of ~10:

> `discount.ts:27` skips the discount when a coupon is present. The commit
> that added it says "fix stacking, finance audit". Proposed why: *"discounts
> must never stack (finance audit, June)"* — *"correct"*, *"wrong, ask me"*, or *"skip"*?

Only ask a fully open question ("why does this exist?") when Tiers 1–2 found
nothing and the code still ranks high. If the developer doesn't know either,
say so in the claim by OMITTING the why — an absent why is honest; an
invented one poisons the map.

Keep sessions short and resumable. After each batch, write the confirmed
nodes before continuing, so an interrupted interview still leaves value.

## Writing the nodes

- Format, pointers, hashes: exactly as the capture skill specifies. Compute
  real hashes; run `node .codepremise/validate.mjs` after each batch.
- Provenance goes at the end of the `why`, in parentheses — these claims are
  reconstructed, not generation-time, and the map must not pretend otherwise:
  - `(from agent session, 2026-05-12)` — Tier 1
  - `(from commit a1b2c3 / #482)` — Tier 2
  - `(confirmed by @login, bootstrap interview)` — Tier 4
- Add `refines` / `step` / `depends-on` links where the structure is obvious;
  don't force a hierarchy that isn't there.
- Finish with a short report: claims written, claims skipped because nobody
  knows why the code exists (list them — that's the repo's real risk list),
  and which files had no transcript coverage.