replen 1.0.28 → 1.0.30

package/extras/skills/replen/SKILL.md

@@ -43,6 +43,14 @@ Parse the JSON response. Note:
 
 - `filterMode` — `tags`, `zero-knowledge`, or `fingerprint`
 - `scopedTo` — confirms the project context the user has open
+- `projectThesis` — what this project is trying to BE (`purpose`) and where it's
+  heading (`goals`). **This is your primary relevance lens.** Judge every
+  candidate against the mission, not just the capability match: a library can fit
+  a tech slot and still NOT advance what the product is trying to be (a generic
+  charting lib for a decision-support platform), and a candidate that advances a
+  `goal` is worth surfacing even if it doesn't map to an existing capability.
+  Lead your writeups with mission-fit, not just tech-fit. (Null until the project
+  is onboarded with a thesis — then fall back to capability-fit alone.)
 - `candidates[]` — the actual list to triage
 - `candidates[].priorContext` — server-attached MEMORY: the user's earlier
   verdicts on this repo, and whether the matched capability is already

package/extras/skills/replen-onboard/SKILL.md

@@ -79,6 +79,35 @@ State the plan in one line ("12 to ground, 18 version-backfills, 3 skips") so
 the user sees why it'll be fast. **A full code-read on an already-grounded repo
 is wasted work — the pre-flight exists to prevent exactly the 24-minute re-run.**
 
+**Then amortize the FULL-ground bucket by stack (cuts the cold read hardest).**
+A portfolio's repos cluster by stack — 8 Next.js + Drizzle + Firebase apps share
+~80% of their *technical* capabilities, which is exactly what Replen matches on
+("describe the tech, not the application"). So the expensive repeated thing is
+the *shared* thing. Group the full-ground repos by a cheap **stack fingerprint**
+read from each manifest you already have to open (framework + ORM/DB + a couple
+of capability-bearing deps, e.g. `next+drizzle+firebase` / `fastapi+pytorch` /
+`hardhat+solidity`). Within each group:
+- Ground the **first** repo fully (the 2a–2e contract).
+- For each **sibling**, hand its grounding subagent the leader's pushed
+  `capabilities` array as a **TECH-ONLY draft to verify and diff** — the subagent
+  reads only enough to confirm which shared capabilities actually apply, drop the
+  ones that don't, and ADD this repo's domain-specific capabilities + its own
+  `paths`/versions. It does NOT re-derive the shared stack from scratch.
+This is a *draft to verify*, never auto-accept (the "don't invent capabilities
+the code doesn't show" rule still holds), and you template only TECH capabilities
+— never the report, domain tags, or anything application-specific (privacy +
+no cross-repo domain bleed). Singletons (no stack sibling) just full-ground
+normally.
+
+Mechanically: process the group leader first and have its subagent **return its
+`capabilities` array** (the `{tag, descriptor, modality}` objects, paths
+stripped) in its final message; the orchestrator passes that array into each
+sibling subagent's prompt as `STACK DRAFT (verify against THIS repo, don't
+auto-accept)`. Groups still run concurrently with each other — only the
+leader→siblings step within a group is ordered. If returning the array is
+impractical for your host, fall back to plain full-ground for the siblings (no
+correctness loss, just no speed-up).
+
 ## Step 2 — Per-repo grounding (autonomous; fan out if you can)
 
 **Parallelise if your host supports it.** In Claude Code, spawn one background
@@ -187,6 +216,30 @@ into the report or the descriptors — the capability is the signal; the
 application is exactly what stays local. When in doubt, describe it as the
 public README does.
 
+### 2c-thesis. Capture the product THESIS (what it's trying to BE)
+
+Capabilities say what a project technically *does*; the **thesis** says what it's
+trying to *be* and where it's *heading* — and that's a far better relevance test
+than any capability slot ("does this advance a contested-airspace decision-
+support platform?" beats "does this do OSINT?"). Replen now matches and triages
+against it, so capture it:
+
+- **First, look for an explicit thesis the user already keeps** — `goals.md`,
+  `GOALS.md`, `handover.md`, `HANDOVER.md`, `ROADMAP.md`, `PRD.md`, `vision.md`,
+  `docs/product*.md`, or the "what it is / active areas" sections of CLAUDE.md.
+  These are the user's own words for the mission — use them as the primary
+  source (same adapter spirit as the knowledge-graph step 2a-pre).
+- **Derive two things:**
+  - `purpose` — 1–2 sentences: what the product is trying to be and what makes
+    it distinct. The mission, not a feature list.
+  - `goals` — a few outcome directions it's heading toward (e.g. "real-time
+    multi-sensor fusion", "sub-second COA ranking").
+- **Respect the cover** exactly as for the report: the thesis describes intent
+  and tech direction, never a sensitive codename / end-user / operational target.
+  Follow the framing the user's own docs use.
+
+Pass both to `replen_set_capabilities` (`purpose`, `goals`) in 2e.
+
 ### 2d. Derive grounded capabilities
 
 From the report + code, produce 8–15 **grounded** capability objects — NOT bare
@@ -215,10 +268,11 @@ specific — `cloudflare bypass`/`proxy rotation`, not just `web scraping`.
    sidesteps the shadow. Ensure each repo has a GitHub remote so it scopes by
    `owner/name`.
 2. **Set domain tags** with `replen_set_tags` — broad domain labels.
-3. **Set capabilities + report** with `replen_set_capabilities`, passing the
-   grounded `capabilities` array AND the `report` from 2c. The server builds the
-   facet vectors immediately and stores the report as grounding for its own
-   summarization. Use the MCP tools, not hand-rolled `curl`.
+3. **Set capabilities + report + thesis** with `replen_set_capabilities`, passing
+   the grounded `capabilities` array, the `report` from 2c, AND the `purpose` +
+   `goals` from 2c-thesis. The server builds the facet vectors immediately, stores
+   the report as grounding, and hands the thesis to the triage agent so candidates
+   are judged against the mission. Use the MCP tools, not hand-rolled `curl`.
    **Include `paths` on each capability** — up to 5 file paths that implement
    it (e.g. `{tag: "computer vision", …, paths: ["src/cv/transformations.py"]}`).
    Paths only, never code. You just read these files; recording WHERE each

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "replen",
-  "version": "1.0.28",
+  "version": "1.0.30",
   "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.",
   "type": "module",
   "bin": {