replen 1.0.27 → 1.0.29
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -67,6 +67,28 @@ Parse the JSON response. Note:
|
|
|
67
67
|
the verdict isn't just "X is risky" but "X is risky; Y is the maintained
|
|
68
68
|
replacement, N similar projects adopted it".
|
|
69
69
|
|
|
70
|
+
### Step 2a — JIT grounding: profile this repo if onboarding hasn't yet
|
|
71
|
+
|
|
72
|
+
A large-portfolio `/replen-onboard` grounds the most-active repos fully and
|
|
73
|
+
gives the long tail a cheap version-only pass — so a registered repo can have
|
|
74
|
+
versions but **no capability profile yet**. Triaging it would fall back to
|
|
75
|
+
coarse tag matching (you'll see `filterMode: "tags"` and few/no facet-led
|
|
76
|
+
candidates). When that happens, ground it inline FIRST — it's just-in-time
|
|
77
|
+
onboarding, and it's why the user opening this repo is the right moment:
|
|
78
|
+
|
|
79
|
+
1. Confirm the gap: call `replen_onboard_state` and find this repo — if
|
|
80
|
+
`hasCapabilities` is false, it needs grounding.
|
|
81
|
+
2. Run the grounding contract (same as `/replen-onboard` step 2a–2e, condensed):
|
|
82
|
+
read the code, derive 8–15 grounded `{tag, descriptor, modality, paths}`
|
|
83
|
+
capabilities + a technical report, and push via `replen_set_capabilities`
|
|
84
|
+
(+ `replen_set_tags`, + `replen_set_versions` if not already reported).
|
|
85
|
+
Respect the cover — describe the tech, never de-sanitize the application.
|
|
86
|
+
3. Re-pull the inventory (Step 2) — now it returns real facet-led matches.
|
|
87
|
+
|
|
88
|
+
Skip this when `hasCapabilities` is already true (the common case). One quiet
|
|
89
|
+
line to the user is enough: *"This repo wasn't fully profiled yet — grounding
|
|
90
|
+
it now so the matches actually fit."*
|
|
91
|
+
|
|
70
92
|
### Step 2b — Keep the version picture fresh (cheap, do it)
|
|
71
93
|
|
|
72
94
|
If `git status` shows the lockfile changed since you last reported, or you
|
|
@@ -79,6 +79,35 @@ State the plan in one line ("12 to ground, 18 version-backfills, 3 skips") so
|
|
|
79
79
|
the user sees why it'll be fast. **A full code-read on an already-grounded repo
|
|
80
80
|
is wasted work — the pre-flight exists to prevent exactly the 24-minute re-run.**
|
|
81
81
|
|
|
82
|
+
**Then amortize the FULL-ground bucket by stack (cuts the cold read hardest).**
|
|
83
|
+
A portfolio's repos cluster by stack — 8 Next.js + Drizzle + Firebase apps share
|
|
84
|
+
~80% of their *technical* capabilities, which is exactly what Replen matches on
|
|
85
|
+
("describe the tech, not the application"). So the expensive repeated thing is
|
|
86
|
+
the *shared* thing. Group the full-ground repos by a cheap **stack fingerprint**
|
|
87
|
+
read from each manifest you already have to open (framework + ORM/DB + a couple
|
|
88
|
+
of capability-bearing deps, e.g. `next+drizzle+firebase` / `fastapi+pytorch` /
|
|
89
|
+
`hardhat+solidity`). Within each group:
|
|
90
|
+
- Ground the **first** repo fully (the 2a–2e contract).
|
|
91
|
+
- For each **sibling**, hand its grounding subagent the leader's pushed
|
|
92
|
+
`capabilities` array as a **TECH-ONLY draft to verify and diff** — the subagent
|
|
93
|
+
reads only enough to confirm which shared capabilities actually apply, drop the
|
|
94
|
+
ones that don't, and ADD this repo's domain-specific capabilities + its own
|
|
95
|
+
`paths`/versions. It does NOT re-derive the shared stack from scratch.
|
|
96
|
+
This is a *draft to verify*, never auto-accept (the "don't invent capabilities
|
|
97
|
+
the code doesn't show" rule still holds), and you template only TECH capabilities
|
|
98
|
+
— never the report, domain tags, or anything application-specific (privacy +
|
|
99
|
+
no cross-repo domain bleed). Singletons (no stack sibling) just full-ground
|
|
100
|
+
normally.
|
|
101
|
+
|
|
102
|
+
Mechanically: process the group leader first and have its subagent **return its
|
|
103
|
+
`capabilities` array** (the `{tag, descriptor, modality}` objects, paths
|
|
104
|
+
stripped) in its final message; the orchestrator passes that array into each
|
|
105
|
+
sibling subagent's prompt as `STACK DRAFT (verify against THIS repo, don't
|
|
106
|
+
auto-accept)`. Groups still run concurrently with each other — only the
|
|
107
|
+
leader→siblings step within a group is ordered. If returning the array is
|
|
108
|
+
impractical for your host, fall back to plain full-ground for the siblings (no
|
|
109
|
+
correctness loss, just no speed-up).
|
|
110
|
+
|
|
82
111
|
## Step 2 — Per-repo grounding (autonomous; fan out if you can)
|
|
83
112
|
|
|
84
113
|
**Parallelise if your host supports it.** In Claude Code, spawn one background
|
|
@@ -93,12 +122,18 @@ must not block on a 3-hour read. Tier the work so value lands fast:
|
|
|
93
122
|
are what the user is actively working on and will see footnotes for soonest.
|
|
94
123
|
2. **Cap concurrency** to what the host sustains (Claude Code parallel subagents
|
|
95
124
|
are capped automatically; don't try to launch 200 at once — launch in waves).
|
|
96
|
-
3. **Version-first
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
125
|
+
3. **Version-first is the DEFAULT for the long tail** (not a fallback). Pick a
|
|
126
|
+
full-ground budget N (the most-recently-committed repos — say the active ~20–
|
|
127
|
+
30, or what the user confirms). Everything BEYOND N gets a version-only
|
|
128
|
+
backfill: cheap, no code read, and it turns on EOL/security/dependency-
|
|
129
|
+
exclusion awareness immediately. Full capability grounding for the tail then
|
|
130
|
+
happens **just-in-time on first `/replen` in that repo** — the `/replen`
|
|
131
|
+
skill grounds a `hasVersions && !hasCapabilities` repo inline before triaging
|
|
132
|
+
(its Step 2a). This is the key to a hundreds-of-repos cold start staying
|
|
133
|
+
minutes, not hours: you never speculatively read 170 repos the user may never
|
|
134
|
+
open. Tell the user: "Grounding your N most-active repos now; the rest get
|
|
135
|
+
version-aware coverage immediately and a full profile the first time you open
|
|
136
|
+
them." Don't silently drop the tail — it's covered, just lazily.
|
|
102
137
|
|
|
103
138
|
**"Done" includes a version report** — covered by the VERSION-ONLY bucket above.
|
|
104
139
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "replen",
|
|
3
|
-
"version": "1.0.
|
|
3
|
+
"version": "1.0.29",
|
|
4
4
|
"description": "Make your AI coding tools smarter. One command, no API keys, free. Replen watches what your projects actually do and surfaces a few things worth bringing in each month. Use one as is, port a piece of another, cherry pick an idea, or build it clean room. The match happens inside your AI tool's session. A few actionable matches a month, by design.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|