This is the record of an abcd-managed repository

abcdBetav0.16.2 · 2026-11-06

Development record

Lifeboats Carry RepoPrompt Workspace Definitions Forward

intentplannedminorstandaloneitd-7

Follows itd-6 (ruled 2026-09-21 by the product thinker): the RepoPrompt route is one opt-in reviewer adapter, which shipped with itd-6 on 2026-10-12, though itd-6 counts as finished only after the live RepoPrompt run iss-2610252224353794 still owes; this record is planned as written and its spec follows that adapter. It is not in the autonomous run.

Two more prerequisites do not exist yet (recorded 2026-09-29, iss-2609240227447110). The pull hangs on abcd dev-sync, which has no verb and no code: the command tree carries none, and the only record of it is the draft itd-13 (scheduled dev-sync). The lifeboat route is missing too: embark writes only the four record families in embarkFamilies (internal/core/lifeboat/embark_types.go: ADRs, issues, intents and specs) and reports every other file as one it does not write, so .abcd/rp/workspace.json has no path from a lifeboat into a target repository, as acceptance criteria 6 and 7 (the two embark criteria) require. Specifying this record needs both, beside itd-6.

Press Release

When the RepoPrompt adapter is configured, abcd packs the RP workspace definition into the lifeboat. When dev-sync runs (and as part of /abcd:disembark), abcd reads the project's RepoPrompt workspace definition from ~/Library/Application Support/RepoPrompt/Workspaces/ and writes it into .abcd/rp/workspace.json in the repo. On /abcd:embark, the workspace is read back and offered for registration with RepoPrompt on the new machine. For personas who drive RepoPrompt, migrating to a fresh user account no longer means rebuilding workspace boundaries by hand for every active project.

"I switched user accounts and dreaded rebuilding RP workspaces for a dozen active projects from memory," said Frank, DevOps engineer. "abcd's workspace pull meant each project's .abcd/rp/workspace.json came along with the lifeboat. Embark on the new account asked whether to register each one. Thirty seconds per project instead of half an hour."

Why This Matters

The RepoPrompt adapter already pulls review content from RP's Application Support. That's the lifeboat-valuable output of RP. The parallel state that's also project-shaped and lifeboat-valuable is the workspace definition — which files RP considers part of the project's context, the partition strategy, the project boundaries. Workspace definitions are fiddly to recreate from memory; they encode real curation work.

All of this is scoped to the RepoPrompt adapter: it runs only when that adapter is configured, and every surface degrades gracefully when RP is absent. RP is one optional adapter, never a hard dependency — abcd assumes nothing about it being present.

This intent ships workspace pull only. Presets and routing are global RP state with cross-project complications; they need a richer scoping design before shipping. --preset and abcd rp link are convenience layers that need workspace pull as a foundation and are out of scope here.

See research/legacy-harvest.md for the broader v0 cleanup context.

What's In Scope

  • A RepoPrompt workspace-state adapter — new adapter in the native adapter layer. Reads the workspace whose root path matches the current repo from ~/Library/Application Support/RepoPrompt/Workspaces/. Workspace identity match: walk all workspaces, parse each workspace.json's root-path field, match against git rev-parse --show-toplevel. Multi-match: prefer the most-recently-modified.
  • Pull on dev-sync: writes .abcd/rp/workspace.json with ~/-relative path normalisation (per privacy rules). Visibility-driven gitignore handling: private repos commit; public repos exclude.
  • Pack on /abcd:disembark: dev-sync runs as a pre-pack step (already in brief). Workspace state goes into the lifeboat naturally.
  • Unpack + reconnect on /abcd:embark:
    • workspace.json is read; user is asked "register this workspace with RepoPrompt now?" — if yes, abcd writes a workspace entry under ~/Library/Application Support/RepoPrompt/Workspaces/ on the embarking machine.
    • If RP isn't installed: warn gracefully ("RepoPrompt not detected; .abcd/rp/workspace.json preserved for later sync") and continue without failing.
  • Schema validation for workspace.json. The JSON Schema ships with the RP adapter in the Go binary (internal/core/...); abcd dev-sync validates against it.
  • PII scrub on read: workspace files may include absolute paths (/Users/<username>/...). Pre-commit scrub rewrites to ~/-relative form. Same approach as session-log schema.

What's Out of Scope

  • Preset pull — Presets/ directory. Presets are global in RP; copying all into every repo's .abcd/rp/presets/ risks cross-project leakage. Explicit scoping (tag-based, or per-project preset list) is needed before this is shipped.
  • MCP routing scoping — mcp-routing.json carries 44 KB of entries across many contexts. This intent does not try to extract project-scoped subsets; that depends on a settled scoping rule.
  • --preset <name> selection — runtime preset selection at task time. Depends on preset pull; out of scope with it.
  • abcd rp link window helper — workspace-window linking via RP MCP. Workspace pull covers the migration use case; window-linking is a convenience layer for a follow-up intent.
  • Active workspace monitoring — watching for changes in RP's Application Support and auto-syncing to .abcd/rp/. Dev-sync-triggered only.
  • Auto-attach RP window to current repo session — beyond abcd rp link reporting the window ID, automatic window selection / activation.
  • Per-command preset binding — declaring in .abcd/config.json "this preset for review-collator runs, that preset for press-release-composer runs."
  • Backend switching mid-session — switching the backend RP routes to (Claude Code vs local model vs Codex) without leaving the abcd command.
  • Cross-tool portability — pulling equivalent state from another harness's workspace tooling. Couples to itd-22-harness-portability.
  • CodeMapCaches / Partitions / windowSessions / Settings — pure tool state, not project-shaped. Stays in RP's Application Support; not pulled.
  • Workspace partitioning auto-derivation — abcd inferring an RP partition strategy from .gitignore + repo structure if no workspace exists. Heuristic; out of scope.

Scope Conditions

None stated.

Acceptance Criteria

BDD format, per itd-1-acceptance-gates. This acceptance block uses Given-When-Then directly.

  • Given an abcd repo with an existing RP workspace defined in ~/Library/Application Support/RepoPrompt/Workspaces/ whose root matches the repo, when abcd dev-sync runs, then .abcd/rp/workspace.json exists and matches the source workspace definition (with ~/-relative path normalisation applied).
  • Given an abcd repo with no matching RP workspace, when abcd dev-sync runs, then the command logs a one-line note ("no RP workspace matches this repo") and continues without failing; no .abcd/rp/workspace.json is created.
  • Given an abcd repo with multiple matching RP workspaces, when abcd dev-sync runs, then the most-recently-modified workspace is selected and .abcd/rp/workspace.json is written from it.
  • Given a public repo (per brief visibility setting), when dev-sync runs, then .abcd/rp/ is added to .gitignore and not committed.
  • Given a private repo, when dev-sync runs, then .abcd/rp/ is committed (and visible in git status).
  • Given a lifeboat containing .abcd/rp/workspace.json, when /abcd:embark from <path> runs on a fresh account/machine with RP installed, then the user is interactively asked whether to register the workspace; if yes, the workspace is written to RP's Application Support and registered.
  • Given the embarker has no RP installed, when embark encounters .abcd/rp/, then the command warns gracefully ("RepoPrompt not detected; .abcd/rp/workspace.json preserved for later sync") and continues without failing.
  • Given an RP workspace whose workspace.json contains absolute paths under /Users/<username>/, when abcd dev-sync reads it, then the written .abcd/rp/workspace.json has those paths rewritten to ~/-relative form.

SOTA

Surveyed on 2026-10-23; sources, evidence tiers and the local fit risks are in the harness, interop and lifeboats SOTA note.

  • RepoPrompt's documentation is served as plain text at repoprompt.com/llms.txt (read in the 2026-10-23 adjudication; the HTML pages are script-rendered and returned a title only). It publishes no on-disk workspace file schema, so the format this record would validate is undocumented; it does document a manage_workspaces MCP tool (list, switch, create, delete, add_folder, remove_folder and tab actions), which registers a workspace by name and folders only, and it says that presets, not workspaces, save and restore the file selection, prompt and settings.
  • Apple's file system guide describes Application Support as "app-specific data and support files … that your app creates and manages", under the app's bundle identifier, and says nothing about another app reading or writing there; writing a workspace entry into RepoPrompt's directory on embark writes into a store abcd does not own.
  • Fowler's Tolerant Reader is the pattern for an undocumented file: take only the elements used, make minimal structural assumptions, confine parsing to one place; schema-bound readers "tend to break when the provider adds a field".
  • abcd's existing RepoPrompt route is an MCP client on loopback that starts no process and reads no file (internal/adapter/repoprompt).
  • Where the research contradicts this planned record: the in-scope lines that a JSON Schema ships with the adapter and that embark writes under ~/Library/Application Support/RepoPrompt/Workspaces/. The ruling (planned as written, its spec to follow itd-6, which shipped on 2026-10-12) stands; the spec-writing interview can weigh this.

Path 2 — carry the workspace file as an opaque, provenance-stamped artefact read tolerantly (path strings rewritten only where provably home-rooted), and on embark offer it to the person and to RepoPrompt's own interface rather than writing another app's store. That interface is now concrete and limited: manage_workspaces can create a workspace by name and folders, not restore its selections or prompts. The independent fit-challenge is still owed before the build, and the questions below are kept for it.

Questions this pass raised for the fit-challenge before the build. They are kept here, not under Open Questions, so they do not hold a build the record already rules ready:

  • RepoPrompt exposes a workspace-registering MCP tool (manage_workspaces, name and folders only): is calling it on embark acceptable where writing its Application Support directory is not, and is a workspace re-created by name and folders, without its selections and prompts, worth the call?

Open Questions

  • Workspace identity disambiguation when multiple match. Most-recently-modified is the proposed default; should the user be prompted instead? Probably no (keep dev-sync non-interactive), revisit if the heuristic misfires.
  • Provenance field: should .abcd/rp/workspace.json carry a _source field noting which RP install / Library version produced it? Helps debugging cross-version issues. Recommended yes; confirm during implementation.
  • Conflict resolution on embark: if the embarker has a workspace with a clashing UUID (unlikely but possible), what's the policy? Probably: rename the embarked one with a suffix (<name>-from-lifeboat).

Audit Notes

Empty. Populated by intent-fidelity-reviewer when intent moves to shipped/.

References

Frontmatter

iditd-7
typeintent
lifecycleplanned
kindstandalone
severityminor

.abcd/development/intents/planned/itd-7-rp-workspace-portability.md
open on GitHub ↗ · commit history ↗

Referenced by9

  • adr-34Intent lifecycle and phase scheduling are orthogonal axesrelated
  • iss-2610262031532231itd-7 has disembark's pre-pack step write .abcd/rp/workspace.json into the repository being read; invariant 6 says disembark never writes to the source.related
  • iss-2610262031537827itd-7 depends on a dev-sync pre-pack step it calls 'already in brief'; the brief lists dev-sync only among out-of-scope work not yet under way.related
  • iss-2610262033075573itd-7 relies on disembark running dev-sync before the pack and writing a workspace file into the repo; the disembark chapter has no such step and never writes to the sourcerelated
  • iss-2610262034360121itd-7 builds its workspace pull on dev-sync, a pre-pack step it says is already in the brief; the board chapter says no dev-sync verb or code exists anywhere.related
  • iss-2610262034363298itd-7 has disembark write the RepoPrompt workspace into the repository; the board chapter says disembark is read-only and writes only to an operator-chosen destination.related
  • iss-2610262039347531itd-7 packs the RepoPrompt workspace by running dev-sync, which writes into the repo, as a disembark pre-pack step 'already in brief'; the configuration chapter says disembark never writes to the source repositoryrelated
  • iss-2610262041227792itd-7 has disembark write the RepoPrompt workspace file into the repository; the glossary defines disembark as reading the source repository without writing to itrelated
  • iss-2610262045089996itd-7 has disembark run dev-sync, which writes .abcd/rp/workspace.json into the repo; itd-88 says disembark never writes into the source repositoryrelated

mentions18

  • dcn-26092500000000282026-09-25 — The build's open-question check reads the record's own settled convention and stays fail-closed (lane implementer, autonomous run A, fix round 1 of the loop lane, on iss-2609252053576085; the lane's first ruling, that every list item under `## Open Questions` is a question whatever it says, lived only in its report and refused intents the record had settled). `intent.OpenQuestions` recognises exactly two markers, learned from the 12 planned intents that carry list items there. A section whose first non-blank line is an italic `_All resolved …_`, with at most one count word (`_All four resolved …_`), is settled whole (itd-111, itd-93); `_All but one resolved_` is not. An item explicitly marked resolved or deferred is not a question: a bold span opening with the word (`**Resolved — …**`, `**Deferred**`, `**Deferred to a follow-up intent**`, `**explicitly deferred**`, `**explicit deferral**`) or the word as a label (`resolved:`, `RESOLVED:`, `Deferred:`), anywhere in the item including its continuation lines. Everything else stays a question: an item led `**Open` whatever it goes on to say (itd-60's "Open, and not gating scope"), an item that only points to another record (itd-76's "travel with itd-126"), `**Out of scope …**`, and a question that merely mentions deferral. With the rule, itd-111 and itd-93 pass the check; itd-7, itd-60, itd-65, itd-66, itd-76, itd-82, itd-117, itd-131, itd-2609170822093401 and itd-2609211116005482 still refuse, each on an item the record does not mark settled. Relabelling those items is the product thinker's call through the planning interview, not the loop's.
  • dcn-26092900000000072026-09-29 — The product thinker answered twenty-six owed rulings and the published-history question in one interview, asked one at a time by orchestrator abcd-23 of autonomous run A (recorded by lane recRulings for orchestrator abcd-cb). The answers are kept verbatim in the local-tier file `.abcd/.work.local/scratch/reports/rulings-answered-2609-29.md`, dated 2026-09-29, and are restated here because that file is not committed. Published history is left as it is, with no rewrite. The build loop's fidelity audit runs once, on the lane that closes the spec, over the whole delivery (AI). On the vendor denylist the product thinker answered, verbatim: "I think we need an allow list rather than trying to catch a deny list." The interviewer's reading of that answer, recorded as a reading and not as the product thinker's words, is that the per-provider allowlist is the control and the vendor denylist is not extended to chase spellings, with whether the bundled `anthropic/*` entry stays as a backstop left to the technical facilitator (AA(a)). Only a route the person set up on their own machine may use their paid key, and a repository's own route to it is refused, which replaces the route half of itd-2609081951381895 decision 8 (AA(b)). The live site setup, the API adapter and the decision adapter may each close on tests against a simulated service, with the live paid check recorded as owed to a person (iss-2609291925387011, iss-2609291925393913, iss-2609291925398978). itd-111's last criterion is met by an agent's timing check on macOS plus the Linux CI run, so the intent may be finished. Automated dependency updates are switched on, pushed with a personal or app token the person creates and stores as a repository secret (itd-2609221842494980; creating the token is the person's act, and the lane builds everything else and names the secret it expects). itd-6 adds a Go MCP module, proposed for the person's explicit sign-off before it is fetched; closing itd-6 on a fake server was not ruled in this interview. (A later answer the same day, H1b in the local-tier file `.abcd/.work.local/scratch/reports/rulings-answered-2609-29-b.md`, dated 2026-09-29, rules that it is not: itd-6 is finished only after running once against the real RepoPrompt app, a check owed to a person.) For itd-148: the store under the home folder wins (adr-2609091248200336); the store draft itd-2609091014076309 owns add, list and clean-up and itd-148 uses them; a session that declares itself the coordinator is exempt from the write block in the primary checkout and every other session is blocked; and the store draft is planned first, with nothing from the store draft, the merged-worktree clean-up included, built before its planning interview (Q4). itd-148's own wait is not part of that ruling: it follows from Q2, because itd-148 uses the store's verbs, and is carried by the `blocked_by` below. itd-148 and spc-42 are rewritten to match in this change, and itd-148 is now `blocked_by` the store draft. A release retrospective is seeded from a release, the intents a tag shipped (AD); itd-24 and its spec are rewritten to the release in this change. An unpointed route is refused naming the one setting to add, as built in 35100512e, so AC11 of itd-2609170822093401 is complete (BR1). A missed target becomes `next`, whatever the following release is numbered (BS1). Spec pieces keep "step" and the lane stages are renamed, a breaking change to the JSON fields `step`, `performed` and `refusal.step` that resolves iss-2609291313276243 and corrects the glossary entry `core/step.md` (BU1), and the old command spellings are removed in that same breaking release (BT1). The text board shows Later as a count only while the site and `--json` keep the full list (BV1), and an intent in progress appears only under Now (BV2). A pause of zero is allowed (BW1); drain stays in the agents' help list until it runs end to end (BX1); a managed repository must hold the drain eligibility decision in its own record, and drain refuses there until it does (BX2); a capture without a remedy is refused (BX3), which tightens the one-line capture friction `commands/capture.md` promises, so the lane that builds it reconciles that page, the principle wording and every caller that files a capture; a run's pick reason keeps the shared `pursued:` kind with its marker (BZ1); and an intent whose blocker was superseded waits on the successor, transitively (BZ2). The five itd-48 follow-ups are planned as one intent, drafted as itd-2609291923559186 (BT2), and all warn rules share one shrink-only baseline file in which a new warning fails, drafted as itd-2609291924469783 (BT3); both drafts wait on their planning interviews. Each ruling that contradicts a shipped behaviour or another record is amended in the change that builds it, not here. itd-7's planning interview stays owed.
  • iss-2608270908349721graveyard's intent and wontfix-issue signals keep the silent first-wins drop the ADR path just lost, and the package has no canonicaliser for itd or iss ids, so itd-7 and itd-007 read as distinct findings — the two remaining families of the resolved ADR collision defect
  • iss-2609240227447110itd-7 (planned, spec_id null) hangs its workspace pull on abcd dev-sync, which has no verb and no code: the CLI's command list carries no dev-sync, grep over internal/ and cmd/ finds none, and the only record of it is the draft itd-13 (scheduled dev-sync). Its lifeboat route does not exist either: embark writes only four record families, adrs, issues, intents and specs (embarkFamilies in internal/core/lifeboat/embark_types.go), and names every other file as one it does not write, so .abcd/rp/workspace.json has no path from a lifeboat into a target repository as acceptance criteria 6 and 7 require. itd-6 Decision 4 already has itd-7 waiting; the record does not say that its own two prerequisites are missing as well.
  • iss-2610252224353794Ruling H1b says itd-6 is finished only after one live run against the real RepoPrompt app, a check owed to a person. itd-6 moved to shipped/ with every test on a test-owned MCP server (internal/adapter/repoprompt/mcptest/mcptest.go) and no record of the run, and no ledger record tracks it; the command-line runner's equivalent is tracked as iss-2609301519558538.
  • iss-2610262030410509Invariant 17 makes the intent-to-spec relation 1:n; the intent chapter's kinds table maps a standalone intent to one spec (1:1)
  • iss-2610262033557020The intent chapter's kinds table maps a standalone intent to one spec (1:1); the record-families map says an intent has one or more specs.
  • itd-1Every Intent Has Acceptance Criteria; Every Audit Verifies Them
  • itd-6RepoPrompt over MCP is one opt-in reviewer route, beside the host's own agents
  • itd-13Reviews and Memory Stay Fresh, Always
  • itd-22abcd Reaches Any Harness Through an Adaptor
  • itd-28Spec-Tied Reviews Live Next To The Spec They Reviewed
  • itd-88Know What a Repo Can and Cannot Tell You — Before You Trust the Lifeboat
  • itd-2609091034175565Before an agent starts on an item, it reserves it on the shared remote, and everyone who works on the project sees the reservation
  • itd-2609111003026787A gate catches the intent whose work is live while its spec is still open
  • itd-2609212103568351The status board shows Now, Next and Later, computed from the record
  • spc-2609120450289528A gate catches the intent whose work is live while its spec is still open
  • spc-2609211950427074rp-mcp-only-integration