replen 1.0.28 → 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.
|
@@ -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
|
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": {
|