generated from coulomb/repo-seed
134 lines
4.8 KiB
Markdown
134 lines
4.8 KiB
Markdown
---
|
|
id: RREG-WP-0003
|
|
type: workplan
|
|
title: "Repository Ability Registry — Automatic Repository Exploration"
|
|
domain: capabilities
|
|
repo: repo-registry
|
|
status: active
|
|
owner: codex
|
|
topic_slug: foerster-capabilities
|
|
created: "2026-04-26"
|
|
updated: "2026-04-28"
|
|
state_hub_workstream_id: "c121d462-f2e4-45d3-9d2d-9c04a3556953"
|
|
---
|
|
|
|
# RREG-WP-0003 — Automatic Repository Exploration
|
|
|
|
## Goal
|
|
|
|
Make the first-run experience feel like a useful product: a user can register a
|
|
repository, ask the registry to explore it, and quickly land on a populated,
|
|
source-linked ability profile. The system must preserve the core trust model:
|
|
deterministic facts are observed, interpreted ability claims are reviewable, and
|
|
canonical registry truth is either explicitly approved by a human or by a clearly
|
|
configured trusted automation mode.
|
|
|
|
## P0: One-Click Register And Explore
|
|
|
|
```task
|
|
id: RREG-WP-0003-T01
|
|
status: done
|
|
priority: high
|
|
state_hub_task_id: "ab718ce7-d38f-4080-9385-99be1bf80475"
|
|
```
|
|
|
|
Add a UI and API flow that registers a repository and immediately starts analysis
|
|
when requested. In the UI, the repository registration form should offer a clear
|
|
`Explore after registration` option enabled by default. The resulting screen should
|
|
show analysis progress/result, observed facts, candidate abilities, and the next
|
|
recommended action without requiring the user to hunt for the analysis button.
|
|
|
|
Acceptance: registering `/home/worsch/repo-registry` from the UI can complete an
|
|
analysis run in one flow and land on the reviewable candidate graph.
|
|
|
|
## P0: Self-Analysis Quality Pass
|
|
|
|
```task
|
|
id: RREG-WP-0003-T02
|
|
status: done
|
|
priority: high
|
|
state_hub_task_id: "d0d98e1b-8d21-4bdf-af58-edbb34e8a929"
|
|
```
|
|
|
|
Use this repository as the first golden demo target. Improve deterministic
|
|
scanning and candidate generation where needed so repo-registry produces a useful
|
|
ability map for itself: repository ingestion, deterministic scanning, candidate
|
|
review workflow, discovery/search, UI curation, and operational/state-hub
|
|
coordination should be visible as source-linked claims.
|
|
|
|
Acceptance: a self-analysis run produces non-trivial, source-linked candidate
|
|
abilities and capabilities that a curator would recognize as the repo's real
|
|
purpose. A one-to-one correspondence of observed fact to generated feature is a
|
|
quality smell: features should describe user-visible or operational behavior, with
|
|
facts as drilldown evidence, not mirror individual scanner facts.
|
|
|
|
## P0: Abstraction Strategy And LLM Boundary
|
|
|
|
```task
|
|
id: RREG-WP-0003-T06
|
|
status: done
|
|
priority: high
|
|
state_hub_task_id: "51890aff-511d-4635-85c4-fe4db0b7dd01"
|
|
```
|
|
|
|
Document and test how the registry should climb from deterministic observed facts
|
|
to useful ability/capability/feature abstractions. Explicitly compare what can be
|
|
done deterministically against what likely needs LLM assistance. Preserve the trust
|
|
boundary: deterministic scanners establish facts; abstraction may propose claims;
|
|
review or trusted automation decides approved registry truth.
|
|
|
|
Acceptance: `docs/` contains an abstraction strategy note with examples from the
|
|
three trial repos, and candidate generation has at least one regression guard
|
|
against feature granularity collapsing into one feature per observed fact.
|
|
|
|
## P1: Guided Review To Populated Registry
|
|
|
|
```task
|
|
id: RREG-WP-0003-T03
|
|
status: done
|
|
priority: medium
|
|
state_hub_task_id: "5c4b5bb1-390c-4782-bb70-104b0006fe67"
|
|
```
|
|
|
|
Polish the candidate review path so the user can approve, edit, merge, or reject
|
|
generated claims from a single coherent screen. After approval, route to the
|
|
approved ability map and make search/discovery/export actions immediately visible.
|
|
|
|
Acceptance: after self-analysis, a user can populate the canonical registry with
|
|
approved entries in one review session and then see them in search, discovery, and
|
|
export.
|
|
|
|
## P1: Trusted Auto-Populate Mode
|
|
|
|
```task
|
|
id: RREG-WP-0003-T04
|
|
status: todo
|
|
priority: medium
|
|
state_hub_task_id: "076385fe-4dbf-4aca-b89f-c7372d9eebd9"
|
|
```
|
|
|
|
Add an explicit opt-in automation mode for local/demo use that approves a
|
|
candidate graph automatically after analysis. This must be visibly labeled and
|
|
record a review decision showing that the approval was automated. The default
|
|
production posture should remain review-first.
|
|
|
|
Acceptance: a local user can choose fully automated exploration that registers,
|
|
analyzes, and populates the approved registry, while default mode still requires
|
|
review.
|
|
|
|
## P2: First-Run Delight And Diagnostics
|
|
|
|
```task
|
|
id: RREG-WP-0003-T05
|
|
status: todo
|
|
priority: low
|
|
state_hub_task_id: "b812a7fb-19ef-418a-83a2-15bf26fd3f4a"
|
|
```
|
|
|
|
Add clear success states, useful empty states, and diagnostics for common first-run
|
|
problems such as invalid local paths, inaccessible Git URLs, empty repos, and runs
|
|
that produce only weak candidates.
|
|
|
|
Acceptance: trying the product on repo-registry itself feels understandable and
|
|
useful even when a scan finds gaps or weak evidence.
|