irp-capture 0.1.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.
- irp_capture-0.1.0/LICENSE +21 -0
- irp_capture-0.1.0/PKG-INFO +365 -0
- irp_capture-0.1.0/README.md +344 -0
- irp_capture-0.1.0/irp/__init__.py +0 -0
- irp_capture-0.1.0/irp/core/__init__.py +0 -0
- irp_capture-0.1.0/irp/core/commands/__init__.py +1 -0
- irp_capture-0.1.0/irp/core/commands/bootstrap.py +388 -0
- irp_capture-0.1.0/irp/core/commands/capture.py +90 -0
- irp_capture-0.1.0/irp/core/commands/check.py +124 -0
- irp_capture-0.1.0/irp/core/commands/demo.py +435 -0
- irp_capture-0.1.0/irp/core/commands/inherit.py +37 -0
- irp_capture-0.1.0/irp/core/commands/why.py +92 -0
- irp_capture-0.1.0/irp/core/integrations/__init__.py +0 -0
- irp_capture-0.1.0/irp/core/integrations/slack_capture.py +35 -0
- irp_capture-0.1.0/irp/core/integrations/slack_post.py +291 -0
- irp_capture-0.1.0/irp/core/irp.py +165 -0
- irp_capture-0.1.0/irp/core/store.py +70 -0
- irp_capture-0.1.0/irp_capture.egg-info/PKG-INFO +365 -0
- irp_capture-0.1.0/irp_capture.egg-info/SOURCES.txt +22 -0
- irp_capture-0.1.0/irp_capture.egg-info/dependency_links.txt +1 -0
- irp_capture-0.1.0/irp_capture.egg-info/entry_points.txt +2 -0
- irp_capture-0.1.0/irp_capture.egg-info/top_level.txt +1 -0
- irp_capture-0.1.0/pyproject.toml +31 -0
- irp_capture-0.1.0/setup.cfg +4 -0
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Johan Lopes Helgesson
|
|
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.
|
|
@@ -0,0 +1,365 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: irp-capture
|
|
3
|
+
Version: 0.1.0
|
|
4
|
+
Summary: An append-only ledger that records why decisions were made.
|
|
5
|
+
License: MIT
|
|
6
|
+
Keywords: decision-log,local-first,append-only,devtools,ai,llm
|
|
7
|
+
Classifier: Development Status :: 3 - Alpha
|
|
8
|
+
Classifier: Intended Audience :: Developers
|
|
9
|
+
Classifier: License :: OSI Approved :: MIT License
|
|
10
|
+
Classifier: Programming Language :: Python :: 3
|
|
11
|
+
Classifier: Programming Language :: Python :: 3.9
|
|
12
|
+
Classifier: Programming Language :: Python :: 3.10
|
|
13
|
+
Classifier: Programming Language :: Python :: 3.11
|
|
14
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
15
|
+
Classifier: Topic :: Software Development :: Libraries
|
|
16
|
+
Classifier: Topic :: Utilities
|
|
17
|
+
Requires-Python: >=3.9
|
|
18
|
+
Description-Content-Type: text/markdown
|
|
19
|
+
License-File: LICENSE
|
|
20
|
+
Dynamic: license-file
|
|
21
|
+
|
|
22
|
+
# irp-capture
|
|
23
|
+
|
|
24
|
+
## Intent Record Protocol
|
|
25
|
+
|
|
26
|
+
**IRP is a decision ledger that records why things were done.**
|
|
27
|
+
|
|
28
|
+
Confirm a decision → it is written to a local file → it stays forever.
|
|
29
|
+
|
|
30
|
+
```bash
|
|
31
|
+
# Before starting something new
|
|
32
|
+
irp why
|
|
33
|
+
|
|
34
|
+
# IRP-2026-04-08-001 Decision: Use Postgres for the reporting service
|
|
35
|
+
# Why: Redis rejected — query patterns require joins
|
|
36
|
+
#
|
|
37
|
+
# → No need to reopen this debate
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
---
|
|
41
|
+
|
|
42
|
+
Three sprints ago your team made a hard call on the architecture.
|
|
43
|
+
Everyone was in the room. It was the right decision, for the right reasons.
|
|
44
|
+
Last week, someone reopened the debate.
|
|
45
|
+
Because the reasoning was not written down anywhere.
|
|
46
|
+
|
|
47
|
+
This is not a memory problem. It is a meaning problem.
|
|
48
|
+
|
|
49
|
+
---
|
|
50
|
+
|
|
51
|
+
## Who this is for
|
|
52
|
+
|
|
53
|
+
IRP is designed for teams making decisions together:
|
|
54
|
+
|
|
55
|
+
- Engineering teams choosing between approaches
|
|
56
|
+
- Design and product teams approving creative direction
|
|
57
|
+
- Pre-sales and delivery teams aligning on scope
|
|
58
|
+
|
|
59
|
+
If you are working alone, this may feel unnecessary.
|
|
60
|
+
If you are working in a team, it becomes obvious quickly.
|
|
61
|
+
|
|
62
|
+
---
|
|
63
|
+
|
|
64
|
+
## The reasoning gap
|
|
65
|
+
|
|
66
|
+
AI tools are everywhere in your workflow now.
|
|
67
|
+
Prompts, reviews, approvals, feedback loops.
|
|
68
|
+
Good reasoning happens constantly. Almost none of it is preserved.
|
|
69
|
+
|
|
70
|
+
Not because it was not captured somewhere.
|
|
71
|
+
But because nothing was designed to capture *why*.
|
|
72
|
+
|
|
73
|
+
Six months later:
|
|
74
|
+
|
|
75
|
+
- A new engineer asks why the architecture was designed this way.
|
|
76
|
+
- An audit asks which human approved this creative direction.
|
|
77
|
+
- A product decision gets relitigated because no one remembers the reasoning.
|
|
78
|
+
|
|
79
|
+
Every new AI session starts from zero.
|
|
80
|
+
Every new team member re-learns what was already decided.
|
|
81
|
+
Every tool has logs of *what happened*. None of them record *why it mattered*.
|
|
82
|
+
|
|
83
|
+
> Storing everything is easy. Knowing what mattered is not.
|
|
84
|
+
|
|
85
|
+
---
|
|
86
|
+
|
|
87
|
+
## Before / After
|
|
88
|
+
|
|
89
|
+
**Without IRP**
|
|
90
|
+
|
|
91
|
+
```
|
|
92
|
+
New engineer joins
|
|
93
|
+
→ asks why the system works this way
|
|
94
|
+
→ team debates again
|
|
95
|
+
→ decision gets re-made
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
**With IRP**
|
|
99
|
+
|
|
100
|
+
```
|
|
101
|
+
New engineer joins
|
|
102
|
+
→ runs `irp why`
|
|
103
|
+
→ sees the decision and the reasoning
|
|
104
|
+
→ moves forward without reopening it
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
---
|
|
108
|
+
|
|
109
|
+
## What IRP does
|
|
110
|
+
|
|
111
|
+
IRP is an append-only decision ledger that lives alongside your work.
|
|
112
|
+
|
|
113
|
+
Think of it as a ship's log.
|
|
114
|
+
Every course correction. Every judgment call. Every hard decision.
|
|
115
|
+
Not because the ocean would remember — but because the next watch
|
|
116
|
+
needs to know why the ship is where it is.
|
|
117
|
+
|
|
118
|
+
When a human confirms a decision, IRP records it.
|
|
119
|
+
That is the entire model.
|
|
120
|
+
|
|
121
|
+
No AI inference. No automatic capture. No vector search.
|
|
122
|
+
A human confirms a decision. IRP records it.
|
|
123
|
+
The ledger is a plain text file. It never changes an existing entry.
|
|
124
|
+
|
|
125
|
+
```
|
|
126
|
+
.irp/
|
|
127
|
+
ledger.jsonl ← append-only canonical record
|
|
128
|
+
current.json ← last 10 decisions, derived from ledger
|
|
129
|
+
```
|
|
130
|
+
|
|
131
|
+
Every entry looks like this:
|
|
132
|
+
|
|
133
|
+
```json
|
|
134
|
+
{
|
|
135
|
+
"id": "IRP-2026-04-08-001",
|
|
136
|
+
"timestamp": "2026-04-08T14:32:11Z",
|
|
137
|
+
"decision": "Use Postgres for the reporting service",
|
|
138
|
+
"why": "Redis was considered but rejected. The query patterns require joins that do not map cleanly to key-value. Team aligned on this in the April 8 architecture review.",
|
|
139
|
+
"source": "cli",
|
|
140
|
+
"confirmed_by": "johan",
|
|
141
|
+
"context": "Backend infrastructure Q2 2026"
|
|
142
|
+
}
|
|
143
|
+
```
|
|
144
|
+
|
|
145
|
+
Open the file. Read it. No tooling required.
|
|
146
|
+
|
|
147
|
+
---
|
|
148
|
+
|
|
149
|
+
## The human confirmation invariant
|
|
150
|
+
|
|
151
|
+
IRP does not decide what matters. You do.
|
|
152
|
+
|
|
153
|
+
Every entry in the ledger was confirmed by a human.
|
|
154
|
+
This is not a design limitation. It is the point.
|
|
155
|
+
|
|
156
|
+
An AI can produce a hundred options.
|
|
157
|
+
Only one was chosen, and someone chose it for a reason.
|
|
158
|
+
That reason is what IRP captures.
|
|
159
|
+
|
|
160
|
+
This makes the ledger auditable, defensible, and trustworthy
|
|
161
|
+
in a way that ambient memory systems cannot be.
|
|
162
|
+
|
|
163
|
+
---
|
|
164
|
+
|
|
165
|
+
## Under the hood
|
|
166
|
+
|
|
167
|
+
| Component | Choice | Why |
|
|
168
|
+
|---|---|---|
|
|
169
|
+
| Storage | Append-only `.jsonl` flat file | Human-readable, no database required |
|
|
170
|
+
| Retrieval | Deterministic — read the ledger | No embeddings, no similarity guessing |
|
|
171
|
+
| Capture | Human-confirmed via sensor | No AI decides what matters |
|
|
172
|
+
| Format | Plain JSON per line | Works in any editor, any language |
|
|
173
|
+
| Dependencies | Python 3.9+, no cloud | Runs entirely on your machine |
|
|
174
|
+
|
|
175
|
+
No ChromaDB. No vector index. No model dependency.
|
|
176
|
+
The ledger is the truth. Not an approximation of it.
|
|
177
|
+
|
|
178
|
+
---
|
|
179
|
+
|
|
180
|
+
## Get started
|
|
181
|
+
|
|
182
|
+
```bash
|
|
183
|
+
pip install irp-capture
|
|
184
|
+
```
|
|
185
|
+
|
|
186
|
+
```bash
|
|
187
|
+
# Set the context for your project
|
|
188
|
+
irp inherit "Project: My project — backend API, Q2 2026"
|
|
189
|
+
|
|
190
|
+
# Capture a decision
|
|
191
|
+
irp capture "Decision: Use Postgres for the reporting service" \
|
|
192
|
+
--why "Redis considered but rejected — query patterns require joins"
|
|
193
|
+
|
|
194
|
+
# Review recent decisions
|
|
195
|
+
irp why
|
|
196
|
+
```
|
|
197
|
+
|
|
198
|
+
```
|
|
199
|
+
# Output:
|
|
200
|
+
# IRP-2026-04-08-001
|
|
201
|
+
# Decision: Use Postgres for the reporting service
|
|
202
|
+
# Why: Redis considered but rejected — query patterns require joins
|
|
203
|
+
#
|
|
204
|
+
# → No need to reopen this debate
|
|
205
|
+
```
|
|
206
|
+
|
|
207
|
+
The ledger is created at `.irp/ledger.jsonl` in your working directory.
|
|
208
|
+
That file is yours. It does not leave your machine unless you choose.
|
|
209
|
+
|
|
210
|
+
---
|
|
211
|
+
|
|
212
|
+
## Sensors
|
|
213
|
+
|
|
214
|
+
Sensors are optional. The ledger is the system.
|
|
215
|
+
|
|
216
|
+
IRP captures decisions from the tools your team already uses.
|
|
217
|
+
Nothing changes about how you work.
|
|
218
|
+
|
|
219
|
+
| Sensor | How it captures |
|
|
220
|
+
|---|---|
|
|
221
|
+
| **Claude Code skill** | Type `capture` inside any Claude session. Captures the decision the moment it is made, without leaving your workflow. |
|
|
222
|
+
| **CLI** | `irp capture` — capture any decision directly from the terminal |
|
|
223
|
+
| **Slack** | Resolve a thread with a decision. The bot writes it to the ledger. |
|
|
224
|
+
| **Figma** | Resolve a design comment. The plugin captures the decision. |
|
|
225
|
+
| **Git hook** | Capture architecture decisions at commit time |
|
|
226
|
+
| **More coming** | VS Code, PR bot, SDK for custom integrations |
|
|
227
|
+
|
|
228
|
+
No tool talks to another. Everything talks to the ledger.
|
|
229
|
+
|
|
230
|
+
---
|
|
231
|
+
|
|
232
|
+
## Daily workflow
|
|
233
|
+
|
|
234
|
+
**The highest-signal moment**
|
|
235
|
+
|
|
236
|
+
When you are working with an AI assistant and a decision crystallises,
|
|
237
|
+
that is when the reasoning is sharpest.
|
|
238
|
+
The Claude Code skill lets you capture it without switching context.
|
|
239
|
+
Type `capture`. The ledger is updated. You continue working.
|
|
240
|
+
|
|
241
|
+
> The Claude skill captures decisions made *with* AI.
|
|
242
|
+
> The ledger records decisions made *by* humans.
|
|
243
|
+
|
|
244
|
+
**When to capture**
|
|
245
|
+
|
|
246
|
+
Capture when a decision is made, not when you remember to.
|
|
247
|
+
The sensors are designed to trigger at the natural confirmation moment —
|
|
248
|
+
a Slack thread resolved, a Figma comment approved, a commit pushed.
|
|
249
|
+
|
|
250
|
+
For decisions made in conversation or in a document, use the CLI:
|
|
251
|
+
|
|
252
|
+
```bash
|
|
253
|
+
irp capture "Decision: [what was decided]" --why "[why it was decided]"
|
|
254
|
+
```
|
|
255
|
+
|
|
256
|
+
**What makes a good entry**
|
|
257
|
+
|
|
258
|
+
A good decision entry answers two questions:
|
|
259
|
+
|
|
260
|
+
1. What did we choose?
|
|
261
|
+
2. What did we reject, and why?
|
|
262
|
+
|
|
263
|
+
The second question is the valuable one.
|
|
264
|
+
Anyone can find what you chose. The rejected alternatives are what gets lost.
|
|
265
|
+
|
|
266
|
+
**Review before starting something new**
|
|
267
|
+
|
|
268
|
+
Before beginning a new phase, sprint, or project:
|
|
269
|
+
|
|
270
|
+
```bash
|
|
271
|
+
irp why
|
|
272
|
+
```
|
|
273
|
+
|
|
274
|
+
This shows the last 10 confirmed decisions.
|
|
275
|
+
Takes 30 seconds. Prevents relitigating what was already decided.
|
|
276
|
+
|
|
277
|
+
---
|
|
278
|
+
|
|
279
|
+
## Common mistakes
|
|
280
|
+
|
|
281
|
+
**Capturing too much**
|
|
282
|
+
IRP is not a log. Do not capture every small choice.
|
|
283
|
+
Capture decisions that would be hard to explain six months later.
|
|
284
|
+
That is the right threshold.
|
|
285
|
+
|
|
286
|
+
**Skipping the why**
|
|
287
|
+
The decision text without the reasoning is just a log entry.
|
|
288
|
+
The reasoning is what makes it worth keeping.
|
|
289
|
+
If you cannot write one sentence of why, the decision may not be ready to capture yet.
|
|
290
|
+
|
|
291
|
+
**Expecting search**
|
|
292
|
+
The ledger is intentionally small.
|
|
293
|
+
It is meant to be read, not queried.
|
|
294
|
+
`irp why` shows your last 10 confirmed decisions in order.
|
|
295
|
+
Read it the way you would read a ship's log.
|
|
296
|
+
|
|
297
|
+
**Waiting until the end of a project**
|
|
298
|
+
The value of IRP compounds over time.
|
|
299
|
+
A decision captured the day it was made is worth ten decisions captured a month later.
|
|
300
|
+
Start capturing from day one, even if the entries are simple.
|
|
301
|
+
|
|
302
|
+
---
|
|
303
|
+
|
|
304
|
+
## Quick reference
|
|
305
|
+
|
|
306
|
+
| Task | Command |
|
|
307
|
+
|---|---|
|
|
308
|
+
| Capture inside a Claude session | `capture` (Claude Code skill) |
|
|
309
|
+
| Set project context | `irp inherit "Project: [name and context]"` |
|
|
310
|
+
| Capture a decision | `irp capture "Decision: [what]" --why "[why]"` |
|
|
311
|
+
| Review recent decisions | `irp why` |
|
|
312
|
+
| Review specific decision | `irp why --id IRP-2026-04-08-001` |
|
|
313
|
+
| Capture from stdin | `irp capture --stdin` |
|
|
314
|
+
| JSON output | Add `--json` to any command |
|
|
315
|
+
|
|
316
|
+
---
|
|
317
|
+
|
|
318
|
+
## Why not a memory tool?
|
|
319
|
+
|
|
320
|
+
Memory stores what happened.
|
|
321
|
+
|
|
322
|
+
Decisions explain why it mattered.
|
|
323
|
+
|
|
324
|
+
IRP focuses on the second.
|
|
325
|
+
|
|
326
|
+
---
|
|
327
|
+
|
|
328
|
+
## Design principles
|
|
329
|
+
|
|
330
|
+
- **Local-first.** The ledger lives on your machine. No cloud required.
|
|
331
|
+
- **Append-only.** Entries are never edited or deleted. The record is immutable.
|
|
332
|
+
- **Human-confirmed.** No entry exists without a human confirming it.
|
|
333
|
+
- **Model-agnostic.** Works with Claude, GPT, Gemini, or no AI at all.
|
|
334
|
+
- **Tool-agnostic.** Any sensor can write to the same substrate.
|
|
335
|
+
- **Plain text.** The ledger is a `.jsonl` file. Open it in any editor.
|
|
336
|
+
|
|
337
|
+
---
|
|
338
|
+
|
|
339
|
+
## Status
|
|
340
|
+
|
|
341
|
+
| Component | Status |
|
|
342
|
+
|---|---|
|
|
343
|
+
| Core CLI | Available |
|
|
344
|
+
| Claude Code skill | Available |
|
|
345
|
+
| Slack sensor | Available |
|
|
346
|
+
| Figma plugin | In progress |
|
|
347
|
+
| Git hook | In progress |
|
|
348
|
+
| pip package | In progress |
|
|
349
|
+
| SDK / API | Planned |
|
|
350
|
+
|
|
351
|
+
---
|
|
352
|
+
|
|
353
|
+
## Contributing
|
|
354
|
+
|
|
355
|
+
IRP is used to capture real decisions across CLI and Slack workflows.
|
|
356
|
+
It is early. If you are building in this space and the substrate
|
|
357
|
+
model resonates, open an issue or reach out.
|
|
358
|
+
|
|
359
|
+
The sensor pattern is open. If you want to write a sensor
|
|
360
|
+
for a tool your team uses, the format is simple and documented.
|
|
361
|
+
|
|
362
|
+
---
|
|
363
|
+
|
|
364
|
+
*IRP does not tell you what to decide.
|
|
365
|
+
It makes sure you remember why you did.*
|