requivo 0.7.0__tar.gz
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.
- requivo-0.7.0/LICENSE +21 -0
- requivo-0.7.0/PKG-INFO +383 -0
- requivo-0.7.0/README.md +351 -0
- requivo-0.7.0/pyproject.toml +77 -0
- requivo-0.7.0/setup.cfg +4 -0
- requivo-0.7.0/src/requivo/__init__.py +10 -0
- requivo-0.7.0/src/requivo/__main__.py +6 -0
- requivo-0.7.0/src/requivo/assets/context/_template.md +26 -0
- requivo-0.7.0/src/requivo/assets/context/b2b-platform.md +54 -0
- requivo-0.7.0/src/requivo/assets/context/document-management.md +74 -0
- requivo-0.7.0/src/requivo/assets/context/event-ops.md +93 -0
- requivo-0.7.0/src/requivo/assets/context/financial-reporting.md +88 -0
- requivo-0.7.0/src/requivo/assets/demo/acceptance-criteria.md +90 -0
- requivo-0.7.0/src/requivo/assets/demo/epic.md +127 -0
- requivo-0.7.0/src/requivo/assets/demo/model.json +227 -0
- requivo-0.7.0/src/requivo/assets/demo/request.md +13 -0
- requivo-0.7.0/src/requivo/assets/demo/solution-assessment.md +165 -0
- requivo-0.7.0/src/requivo/assets/framework/elicitation.md +78 -0
- requivo-0.7.0/src/requivo/assets/framework/model_schema.json +33 -0
- requivo-0.7.0/src/requivo/assets/prompts/brief.md +113 -0
- requivo-0.7.0/src/requivo/assets/prompts/criteria.md +95 -0
- requivo-0.7.0/src/requivo/assets/prompts/engine.md +78 -0
- requivo-0.7.0/src/requivo/assets/prompts/epic.md +97 -0
- requivo-0.7.0/src/requivo/assets/prompts/estimate.md +39 -0
- requivo-0.7.0/src/requivo/assets/prompts/prd.md +106 -0
- requivo-0.7.0/src/requivo/assets/prompts/release.md +46 -0
- requivo-0.7.0/src/requivo/assets/prompts/stories.md +69 -0
- requivo-0.7.0/src/requivo/cli.py +524 -0
- requivo-0.7.0/src/requivo/core/__init__.py +4 -0
- requivo-0.7.0/src/requivo/core/adapters.py +158 -0
- requivo-0.7.0/src/requivo/core/analysis.py +77 -0
- requivo-0.7.0/src/requivo/core/contracts.py +288 -0
- requivo-0.7.0/src/requivo/core/dependencies.py +140 -0
- requivo-0.7.0/src/requivo/core/discovery.py +42 -0
- requivo-0.7.0/src/requivo/core/generators.py +82 -0
- requivo-0.7.0/src/requivo/core/llm.py +279 -0
- requivo-0.7.0/src/requivo/core/persistence.py +117 -0
- requivo-0.7.0/src/requivo/paths.py +46 -0
- requivo-0.7.0/src/requivo/render/__init__.py +3 -0
- requivo-0.7.0/src/requivo/render/markdown.py +137 -0
- requivo-0.7.0/src/requivo/render/terminal.py +256 -0
- requivo-0.7.0/src/requivo.egg-info/PKG-INFO +383 -0
- requivo-0.7.0/src/requivo.egg-info/SOURCES.txt +47 -0
- requivo-0.7.0/src/requivo.egg-info/dependency_links.txt +1 -0
- requivo-0.7.0/src/requivo.egg-info/entry_points.txt +3 -0
- requivo-0.7.0/src/requivo.egg-info/requires.txt +7 -0
- requivo-0.7.0/src/requivo.egg-info/top_level.txt +1 -0
- requivo-0.7.0/tests/test_engine.py +1298 -0
- requivo-0.7.0/tests/test_golden_lib.py +165 -0
requivo-0.7.0/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 jbkkz
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
requivo-0.7.0/PKG-INFO
ADDED
|
@@ -0,0 +1,383 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: requivo
|
|
3
|
+
Version: 0.7.0
|
|
4
|
+
Summary: An open-source requirements reasoning engine for turning vague product requests into validated, traceable decisions.
|
|
5
|
+
Author: jbkkz
|
|
6
|
+
License: MIT
|
|
7
|
+
Project-URL: Homepage, https://github.com/jbkkz/requivo
|
|
8
|
+
Project-URL: Repository, https://github.com/jbkkz/requivo
|
|
9
|
+
Project-URL: Changelog, https://github.com/jbkkz/requivo/blob/main/CHANGELOG.md
|
|
10
|
+
Keywords: requirements,product,llm,anthropic,claude,prd,discovery,elicitation
|
|
11
|
+
Classifier: Development Status :: 4 - Beta
|
|
12
|
+
Classifier: Intended Audience :: Developers
|
|
13
|
+
Classifier: License :: OSI Approved :: MIT License
|
|
14
|
+
Classifier: Programming Language :: Python :: 3
|
|
15
|
+
Classifier: Programming Language :: Python :: 3.9
|
|
16
|
+
Classifier: Programming Language :: Python :: 3.10
|
|
17
|
+
Classifier: Programming Language :: Python :: 3.11
|
|
18
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
19
|
+
Classifier: Programming Language :: Python :: 3.13
|
|
20
|
+
Classifier: Topic :: Software Development :: Documentation
|
|
21
|
+
Classifier: Topic :: Scientific/Engineering :: Artificial Intelligence
|
|
22
|
+
Requires-Python: >=3.9
|
|
23
|
+
Description-Content-Type: text/markdown
|
|
24
|
+
License-File: LICENSE
|
|
25
|
+
Requires-Dist: anthropic>=0.40.0
|
|
26
|
+
Requires-Dist: python-dotenv>=1.0.0
|
|
27
|
+
Requires-Dist: pydantic>=2.0
|
|
28
|
+
Provides-Extra: dev
|
|
29
|
+
Requires-Dist: pytest>=8.0; extra == "dev"
|
|
30
|
+
Requires-Dist: ruff>=0.6; extra == "dev"
|
|
31
|
+
Dynamic: license-file
|
|
32
|
+
|
|
33
|
+
# Requivo
|
|
34
|
+
|
|
35
|
+
[](LICENSE)
|
|
36
|
+
|
|
37
|
+
> Turn vague requests into validated product decisions.
|
|
38
|
+
|
|
39
|
+
Requivo builds a structured and traceable model of what is **known**, **inferred** and still
|
|
40
|
+
**unknown** before generating product documentation — solution assessments, PRDs, user stories,
|
|
41
|
+
acceptance criteria, estimates and epics.
|
|
42
|
+
|
|
43
|
+
Built for Product Managers, Solutions Engineers and Business Analysts working on complex, configurable B2B products.
|
|
44
|
+
|
|
45
|
+
> **The model is the product. Documents are views of that model.**
|
|
46
|
+
|
|
47
|
+
---
|
|
48
|
+
|
|
49
|
+
## See it in one look
|
|
50
|
+
|
|
51
|
+
A real, rambling client email — a symptom, not a spec, with three features tangled together and a
|
|
52
|
+
constraint buried at the end:
|
|
53
|
+
|
|
54
|
+
> *"…we bring in freelancers to check guests in at the door, but nobody has a clear view of who's
|
|
55
|
+
> actually been approved to attend… afterwards finance spends weeks reconciling because the freelancer
|
|
56
|
+
> invoices never line up with the hours actually worked… We need something that ties this together…
|
|
57
|
+
> It has to work at the venue where the wifi basically doesn't. Event's in six weeks."*
|
|
58
|
+
|
|
59
|
+
**What Requivo made of it — before a line of spec was written:**
|
|
60
|
+
|
|
61
|
+
- **Two systems, not one.** It refused the "tie this together" framing: live door check-in and
|
|
62
|
+
after-the-fact invoice reconciliation are separate builds, with separate data and separate owners.
|
|
63
|
+
- **A disguised-employment (*salariat déguisé*) exposure** nobody wrote down — freelancers on fixed
|
|
64
|
+
hours doing core work — surfaced as a point for **legal review**, not a requirement.
|
|
65
|
+
- **An unresolved offline strategy** — the venue wifi "basically doesn't" work, which decides the
|
|
66
|
+
whole architecture rather than being an edge case.
|
|
67
|
+
- **A six-week deadline** the two builds now have to be **sequenced** against.
|
|
68
|
+
|
|
69
|
+
See the whole run yourself — **no API key, no setup, no network:**
|
|
70
|
+
|
|
71
|
+
```bash
|
|
72
|
+
uv run requivo demo # or, with nothing installed: python requivo.py demo
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
---
|
|
76
|
+
|
|
77
|
+
```
|
|
78
|
+
Customer request
|
|
79
|
+
│
|
|
80
|
+
▼
|
|
81
|
+
AI Discovery ◀── product + client context
|
|
82
|
+
│
|
|
83
|
+
▼
|
|
84
|
+
Structured model ← the product (out/<slug>/model.json)
|
|
85
|
+
│
|
|
86
|
+
┌─────────┬──────────┼──────────┬───────────────┐
|
|
87
|
+
▼ ▼ ▼ ▼ ▼
|
|
88
|
+
Solution PRD User stories Estimate More artifacts
|
|
89
|
+
assessment
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
---
|
|
93
|
+
|
|
94
|
+
## Why
|
|
95
|
+
|
|
96
|
+
Discovery tools either ask you *everything* — endless checklists no one finishes — or *nothing* — a
|
|
97
|
+
chat that nods along and hands back your own words. Neither helps you find the question you didn't
|
|
98
|
+
think to ask: the one that turns a "small feature" into a three-month build.
|
|
99
|
+
|
|
100
|
+
Requivo asks a question only when the answer would **materially change the solution**. The
|
|
101
|
+
rest, it infers and flags as an assumption. You spend your discovery time where it moves the needle.
|
|
102
|
+
|
|
103
|
+
### Why I built this
|
|
104
|
+
|
|
105
|
+
> After several years working on complex, configurable enterprise software, I realised that writing
|
|
106
|
+
> the specification was rarely the hardest part. The difficult part was building a shared
|
|
107
|
+
> understanding of the real problem before development started.
|
|
108
|
+
>
|
|
109
|
+
> Over time, I noticed the same reasoning pattern behind good discovery work: what do we actually
|
|
110
|
+
> know, what are we assuming, and what would materially change the solution? Requivo is my
|
|
111
|
+
> attempt to formalise that process.
|
|
112
|
+
|
|
113
|
+
---
|
|
114
|
+
|
|
115
|
+
## What it does
|
|
116
|
+
|
|
117
|
+
Requivo builds a **structured model of the solution** and refines it through a short,
|
|
118
|
+
targeted conversation. The chat is just the interface. **The product is the model** — and every
|
|
119
|
+
artifact (a solution assessment, a PRD, user stories, an estimate) is a view rendered from it.
|
|
120
|
+
|
|
121
|
+
The same discovery can later produce a PRD, a test plan, or a Jira export **without redoing the
|
|
122
|
+
conversation**.
|
|
123
|
+
|
|
124
|
+
---
|
|
125
|
+
|
|
126
|
+
## What you get
|
|
127
|
+
|
|
128
|
+
The deliverable is a **solution assessment** — a judgment on what you're about to build, not a recap
|
|
129
|
+
of what you said. It doesn't just organize the request; it **pushes back on it**, the way a senior PM
|
|
130
|
+
who has built this kind of system before would:
|
|
131
|
+
|
|
132
|
+
```
|
|
133
|
+
CHALLENGES
|
|
134
|
+
⚑ Immediate invoice on signature
|
|
135
|
+
Premise Invoices are generated the moment a contract is signed.
|
|
136
|
+
Alternative Many B2B contracts bill on a schedule — milestones, recurring
|
|
137
|
+
periods, usage — not a single lump sum at signature.
|
|
138
|
+
Consequence Signature-triggered invoicing multiplies cancellation and
|
|
139
|
+
credit-note handling when deals change before they start.
|
|
140
|
+
Recommend Validate the billing trigger with Finance before build.
|
|
141
|
+
|
|
142
|
+
DESIGN DECISIONS
|
|
143
|
+
✓ Draft-first invoices, reviewed by Finance before issuance
|
|
144
|
+
Why Finance sign-off is required for compliance.
|
|
145
|
+
Alternative Immediate issuance on the triggering event.
|
|
146
|
+
Tradeoff An extra approval step, in exchange for far lower compliance risk.
|
|
147
|
+
```
|
|
148
|
+
|
|
149
|
+
Above these sits a five-line **executive summary** (problem · solution · challenge · risks · next).
|
|
150
|
+
Below, the full analysis adds context-specific **risks**, ranked **opportunities**, a readiness
|
|
151
|
+
verdict with its single blocker — and the reasoning behind each. Every line is in a PM's language;
|
|
152
|
+
none of the engine's internals leak through.
|
|
153
|
+
|
|
154
|
+
---
|
|
155
|
+
|
|
156
|
+
## Example
|
|
157
|
+
|
|
158
|
+
```bash
|
|
159
|
+
requivo discover "We'd like to set up a leave approval system."
|
|
160
|
+
```
|
|
161
|
+
|
|
162
|
+
From that one sentence, on a platform whose context says *"approval usually hides a balance check
|
|
163
|
+
and a multi-level circuit"*, the engine asks the few questions that matter — the multi-level circuit,
|
|
164
|
+
the per-client variation, the balance rule — and leaves the low-stakes ones (reporting) alone. Each
|
|
165
|
+
answer refines the model until nothing high-value is left to ask, then the solution assessment is produced.
|
|
166
|
+
|
|
167
|
+
---
|
|
168
|
+
|
|
169
|
+
## See a complete example
|
|
170
|
+
|
|
171
|
+
Walk through a full discovery example, end to end, in
|
|
172
|
+
[`examples/leave-approval/`](examples/leave-approval/) — no install required:
|
|
173
|
+
|
|
174
|
+
| File | What it is |
|
|
175
|
+
|---|---|
|
|
176
|
+
| [`request.md`](examples/leave-approval/request.md) | The one-sentence input |
|
|
177
|
+
| [`model.json`](examples/leave-approval/model.json) | The structured model the discovery built |
|
|
178
|
+
| [`solution-assessment.md`](examples/leave-approval/solution-assessment.md) | The deliverable — challenges, design decisions, risks, next steps |
|
|
179
|
+
| [`prd.md`](examples/leave-approval/prd.md) | A PRD generated from the same model |
|
|
180
|
+
| [`epic.json`](examples/leave-approval/epic.json) | The same model as a GitHub/GitLab-importable epic |
|
|
181
|
+
|
|
182
|
+
Each of these — plus user stories, an estimate, acceptance criteria and release notes — is generated
|
|
183
|
+
from the same `model.json`. That's the whole idea:
|
|
184
|
+
|
|
185
|
+
```bash
|
|
186
|
+
requivo prd examples/leave-approval/model.json # regenerate prd.md from the saved model
|
|
187
|
+
```
|
|
188
|
+
|
|
189
|
+
For a harder case — a rambling client email conflating three features, with a legal tripwire and a fixed
|
|
190
|
+
deadline buried in it — see
|
|
191
|
+
[`examples/event-checkin-reconciliation/`](examples/event-checkin-reconciliation/): the assessment refuses
|
|
192
|
+
the "tie this together" conflation, catches a disguised-employment (*salariat déguisé*) exposure nobody
|
|
193
|
+
wrote down, and sequences the two builds against the deadline.
|
|
194
|
+
|
|
195
|
+
---
|
|
196
|
+
|
|
197
|
+
## How it works
|
|
198
|
+
|
|
199
|
+
The solution model is a set of typed *slots* — the problem, actors, business rules, permissions and
|
|
200
|
+
edge cases — grouped into four areas: **Why / What / How / Validate**.
|
|
201
|
+
|
|
202
|
+
It decides what to ask with one rule: **information value = uncertainty × impact**. It never asks
|
|
203
|
+
just because something is unknown — it asks when an answer would change what you build. Impact is
|
|
204
|
+
estimated from the product context, so the engine is only as sharp as the context you give it.
|
|
205
|
+
|
|
206
|
+
The model is not a flat snapshot: its parts rest on each other. A design decision records the facts
|
|
207
|
+
it was **derived from**; each artifact records the slots it **consumes**. So a change knows its blast
|
|
208
|
+
radius — `requivo impact` shows what a revisited slot would invalidate, and a discovery turn that moves the
|
|
209
|
+
model warns you which already-generated files no longer match it.
|
|
210
|
+
|
|
211
|
+
---
|
|
212
|
+
|
|
213
|
+
## Quickstart
|
|
214
|
+
|
|
215
|
+
**See it first — no API key, no setup.** `requivo demo` replays a real run from saved output: the messy
|
|
216
|
+
client request, the questions the engine raised, the solution assessment it produced.
|
|
217
|
+
|
|
218
|
+
```bash
|
|
219
|
+
git clone https://github.com/jbkkz/requivo && cd requivo
|
|
220
|
+
uv run requivo demo # or: python requivo.py demo (nothing installed) · requivo demo (after an install)
|
|
221
|
+
```
|
|
222
|
+
|
|
223
|
+
**Then run your own — with [uv](https://docs.astral.sh/uv/):** no virtualenv to create or activate.
|
|
224
|
+
`uv run` builds the environment from `pyproject.toml` on first run, then runs the command.
|
|
225
|
+
|
|
226
|
+
```bash
|
|
227
|
+
cp .env.example .env # set ANTHROPIC_API_KEY
|
|
228
|
+
uv run requivo discover examples/case1_leave.md # first run resolves deps; later runs are instant
|
|
229
|
+
```
|
|
230
|
+
|
|
231
|
+
<details><summary>Or the classic pip + venv install</summary>
|
|
232
|
+
|
|
233
|
+
```bash
|
|
234
|
+
git clone https://github.com/jbkkz/requivo && cd requivo
|
|
235
|
+
python -m venv .venv && source .venv/bin/activate
|
|
236
|
+
pip install -U pip setuptools # a fresh venv may ship a pip too old for editable installs
|
|
237
|
+
pip install -e . # installs deps + the `requivo` command (and the `pc` alias)
|
|
238
|
+
cp .env.example .env # set ANTHROPIC_API_KEY
|
|
239
|
+
requivo discover examples/case1_leave.md
|
|
240
|
+
```
|
|
241
|
+
|
|
242
|
+
</details>
|
|
243
|
+
|
|
244
|
+
It runs an interactive loop — showing what's understood, asking the priority questions, folding your
|
|
245
|
+
answers back in — then writes `out/<slug>/model.json` and produces the solution assessment.
|
|
246
|
+
Regenerate any deliverable from a saved model without redoing discovery (prefix each with `uv run`
|
|
247
|
+
if you use uv, or activate the venv first):
|
|
248
|
+
|
|
249
|
+
```bash
|
|
250
|
+
requivo prd out/<slug>/model.json # also: stories · estimate · criteria · release · brief
|
|
251
|
+
requivo epic out/<slug>/model.json --github --gitlab # + a tool-neutral epic.json and tracker issue plans
|
|
252
|
+
requivo impact out/<slug>/model.json permissions # what rests on a slot: decisions + artifacts that go stale
|
|
253
|
+
```
|
|
254
|
+
|
|
255
|
+
### Two interfaces, one engine
|
|
256
|
+
|
|
257
|
+
The product is the engine; the interfaces are thin layers over the same `requivo` core.
|
|
258
|
+
|
|
259
|
+
- **Terminal** — `requivo <command>` (or `uv run requivo <command>` with no manual venv, or `python
|
|
260
|
+
requivo.py <command>` with nothing installed at all). The short alias `pc` still works.
|
|
261
|
+
- **Claude Code** — `/pc-discover`, `/pc-status`, `/pc-generate`, `/pc-help` wrap the same CLI.
|
|
262
|
+
|
|
263
|
+
The legacy flag CLI (`python src/engine.py "…" --prd`, `--from out/<slug>/model.json`) still works
|
|
264
|
+
unchanged.
|
|
265
|
+
|
|
266
|
+
---
|
|
267
|
+
|
|
268
|
+
## Before you rely on it
|
|
269
|
+
|
|
270
|
+
- **What leaves your machine.** Each discovery or generation turn sends, as one Anthropic API call:
|
|
271
|
+
your request text, the framework schema, and **every** context card — bundled plus any in your
|
|
272
|
+
`REQUIVO_CONTEXT_DIR` — (the system prompt), to
|
|
273
|
+
the Claude model named by `MODEL` (default `claude-sonnet-5`). Nothing else is transmitted; this
|
|
274
|
+
project stores nothing beyond `out/` on your own disk, and has no telemetry. `requivo demo`, `requivo status`
|
|
275
|
+
and `requivo impact` make **no** network call at all.
|
|
276
|
+
- **Cost.** A discovery is a few calls (one per turn, up to 8) plus one per generated artifact. The
|
|
277
|
+
system prompt is prompt-cached across a session, so the repeated calls of a run are cheap. Every
|
|
278
|
+
`requivo` command that hits the API prints its own footprint when it finishes — calls, tokens (with the
|
|
279
|
+
cached share), latency, and an estimated cost — so you see the real number for *your* request
|
|
280
|
+
rather than guessing. (Tokens are exact; the cost is a labelled estimate from a dated rate table.)
|
|
281
|
+
- **Models.** Developed and measured against `claude-sonnet-5`; any current Claude model works via the
|
|
282
|
+
`MODEL` env var.
|
|
283
|
+
- **Known limits.** Output is **non-deterministic** — the golden harness measures change above a noise
|
|
284
|
+
floor rather than asserting exact text. By default every context card is loaded for every request, so
|
|
285
|
+
cards can dilute one another (see [Knowing whether a card helped](#knowing-whether-a-card-helped)) —
|
|
286
|
+
scope a session to the relevant ones with `requivo discover --context b2b-platform,financial-reporting`.
|
|
287
|
+
The model can simply be wrong.
|
|
288
|
+
- **Not professional advice.** When the engine flags a legal, tax, or regulatory exposure (e.g. the
|
|
289
|
+
disguised-employment risk in the event example), that is a prompt to get **expert review** — never a
|
|
290
|
+
substitute for it. Nothing it produces is legal, financial, or compliance advice.
|
|
291
|
+
|
|
292
|
+
---
|
|
293
|
+
|
|
294
|
+
## Add your product
|
|
295
|
+
|
|
296
|
+
The engine is domain-agnostic; the context makes it smart. The built-in cards live in the package at
|
|
297
|
+
`src/requivo/assets/context/`; working from a clone (or an editable `pip install -e .`), drop
|
|
298
|
+
a card there describing your product, its entities, and its recurring traps:
|
|
299
|
+
|
|
300
|
+
```
|
|
301
|
+
src/requivo/assets/context/
|
|
302
|
+
hris.md ← HR / people platforms
|
|
303
|
+
crm.md ← sales & pipeline tools
|
|
304
|
+
erp.md ← finance & operations suites
|
|
305
|
+
my-product.md ← yours
|
|
306
|
+
```
|
|
307
|
+
|
|
308
|
+
Better context → sharper impact estimates → better questions. Files prefixed with `_` are ignored.
|
|
309
|
+
|
|
310
|
+
**Installed via pip, no checkout?** Drop your cards in a user directory instead — no need to touch the
|
|
311
|
+
package:
|
|
312
|
+
|
|
313
|
+
```bash
|
|
314
|
+
export REQUIVO_CONTEXT_DIR=~/.config/requivo/context # this is also the default location
|
|
315
|
+
mkdir -p "$REQUIVO_CONTEXT_DIR" && $EDITOR "$REQUIVO_CONTEXT_DIR/my-product.md"
|
|
316
|
+
```
|
|
317
|
+
|
|
318
|
+
User cards are merged with the built-in ones; a user card whose name matches a built-in **overrides**
|
|
319
|
+
it, so you can tweak a bundled card without editing the package.
|
|
320
|
+
|
|
321
|
+
### Knowing whether a card helped
|
|
322
|
+
|
|
323
|
+
Behavior here is tuned by editing Markdown, and the engine is non-deterministic — so "did that card
|
|
324
|
+
make the engine sharper?" is a real question, and one run can't answer it. A small harness does:
|
|
325
|
+
|
|
326
|
+
```bash
|
|
327
|
+
python scripts/golden_run.py <slug> # capture a fixed request K times (K=3)
|
|
328
|
+
python scripts/golden_diff.py # what moved, above the measured noise floor
|
|
329
|
+
python scripts/golden_diff.py <slug> --questions # the questions and challenges themselves
|
|
330
|
+
```
|
|
331
|
+
|
|
332
|
+
A fixed request set (one per problem *form*) is captured K times and compared against the committed
|
|
333
|
+
baseline. A change is reported only when the runs agreed before *and* after — anything that flickers
|
|
334
|
+
run-to-run is noise and stays silent. `--brief` extends this to the assessment itself, tracking the
|
|
335
|
+
complexity verdict and which premises the engine chose to contest.
|
|
336
|
+
|
|
337
|
+
It measures movement, not improvement — the questions are what tell you the direction. When the
|
|
338
|
+
finance card landed, the engine stopped asking *"what exactly are these totals?"* and started asking
|
|
339
|
+
*"a traceable adjustment entry, or an override?"*. That's the read that matters.
|
|
340
|
+
|
|
341
|
+
---
|
|
342
|
+
|
|
343
|
+
## Roadmap
|
|
344
|
+
|
|
345
|
+
**Current**
|
|
346
|
+
- Discovery engine — priority questions, multi-turn refinement, solution assessment (with challenges)
|
|
347
|
+
- Artifact generators — PRD, user stories, uncertainty-aware estimate, acceptance criteria, delivery
|
|
348
|
+
epic, release notes
|
|
349
|
+
- Tool-neutral epic export (`epic.json`) — importable into GitHub / GitLab issues
|
|
350
|
+
- Tracker adapters — idempotent, n8n-ready issue-creation plans for GitHub (`epic.github.json`) and
|
|
351
|
+
GitLab (`epic.gitlab.json`, with structured issue links)
|
|
352
|
+
- The model as a durable product (`model.json`), regenerable via `--from`
|
|
353
|
+
- A dependency graph over the model — `requivo impact` shows a change's blast radius, and a discovery turn
|
|
354
|
+
flags the already-generated artifacts a change makes stale
|
|
355
|
+
- Two interfaces over one presentation-free engine — a `requivo` subcommand CLI and Claude Code slash
|
|
356
|
+
commands (`/pc-discover`, `/pc-status`, `/pc-generate`), each a thin layer over the same core
|
|
357
|
+
- A regression harness for prompt and context changes — consensus over repeated runs, so a real effect
|
|
358
|
+
is separable from sampling noise, on the discovery *and* on the assessment
|
|
359
|
+
- A self-contained wheel — prompts, schema and context cards ship inside the package, so `pip install`
|
|
360
|
+
works outside the clone; outputs go to `./out` in your working directory, never into the install
|
|
361
|
+
- A user-level context directory (`REQUIVO_CONTEXT_DIR`) — add or override product cards on a pip-installed
|
|
362
|
+
setup without a source checkout; user cards merge with the built-ins
|
|
363
|
+
|
|
364
|
+
**Upcoming**
|
|
365
|
+
- An HTTP API / MCP façade — another thin layer over the same core (for n8n and future web UIs)
|
|
366
|
+
- Jira adapter, alongside GitHub and GitLab
|
|
367
|
+
- Delivery integrations — authenticated push (via n8n), Notion and Confluence
|
|
368
|
+
- Context tooling — validation and assisted generation of product context cards
|
|
369
|
+
|
|
370
|
+
**Vision**
|
|
371
|
+
- A full artifact chain from a single model — the reasoning layer beneath product delivery
|
|
372
|
+
- Multiple surfaces over one engine — **Requivo Core** (this engine), **Requivo for Claude Code**,
|
|
373
|
+
**Requivo Web**, and eventually **Requivo Cloud**
|
|
374
|
+
|
|
375
|
+
---
|
|
376
|
+
|
|
377
|
+
## License
|
|
378
|
+
|
|
379
|
+
[MIT](LICENSE) © jbkkz
|
|
380
|
+
|
|
381
|
+
---
|
|
382
|
+
|
|
383
|
+
> _Requivo was previously named Product Copilot._
|