house-party-protocol 2.6.5__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.
Files changed (77) hide show
  1. house_party_protocol-2.6.5/LICENSE +21 -0
  2. house_party_protocol-2.6.5/PKG-INFO +393 -0
  3. house_party_protocol-2.6.5/README.md +364 -0
  4. house_party_protocol-2.6.5/house_party_protocol.egg-info/PKG-INFO +393 -0
  5. house_party_protocol-2.6.5/house_party_protocol.egg-info/SOURCES.txt +75 -0
  6. house_party_protocol-2.6.5/house_party_protocol.egg-info/dependency_links.txt +1 -0
  7. house_party_protocol-2.6.5/house_party_protocol.egg-info/entry_points.txt +2 -0
  8. house_party_protocol-2.6.5/house_party_protocol.egg-info/top_level.txt +1 -0
  9. house_party_protocol-2.6.5/hpp/__init__.py +3 -0
  10. house_party_protocol-2.6.5/hpp/__main__.py +7 -0
  11. house_party_protocol-2.6.5/hpp/_process.py +121 -0
  12. house_party_protocol-2.6.5/hpp/attest.py +177 -0
  13. house_party_protocol-2.6.5/hpp/brand.py +90 -0
  14. house_party_protocol-2.6.5/hpp/citations.py +477 -0
  15. house_party_protocol-2.6.5/hpp/cli.py +535 -0
  16. house_party_protocol-2.6.5/hpp/context.py +81 -0
  17. house_party_protocol-2.6.5/hpp/controls.py +175 -0
  18. house_party_protocol-2.6.5/hpp/decision.py +395 -0
  19. house_party_protocol-2.6.5/hpp/evals.py +107 -0
  20. house_party_protocol-2.6.5/hpp/evidence.py +337 -0
  21. house_party_protocol-2.6.5/hpp/examples/reliable-coding/README.md +18 -0
  22. house_party_protocol-2.6.5/hpp/examples/reliable-coding/README.pt-BR.md +19 -0
  23. house_party_protocol-2.6.5/hpp/examples/reliable-coding/benchmark-suite.json +16 -0
  24. house_party_protocol-2.6.5/hpp/examples/reliable-coding/context.json +5 -0
  25. house_party_protocol-2.6.5/hpp/examples/reliable-coding/lanes.json +4 -0
  26. house_party_protocol-2.6.5/hpp/examples/reliable-coding/monitors.json +4 -0
  27. house_party_protocol-2.6.5/hpp/examples/reliable-coding/providers.json +4 -0
  28. house_party_protocol-2.6.5/hpp/examples/reliable-coding/route-request.json +6 -0
  29. house_party_protocol-2.6.5/hpp/examples/reliable-coding/workgraph.json +8 -0
  30. house_party_protocol-2.6.5/hpp/graph.py +82 -0
  31. house_party_protocol-2.6.5/hpp/hpp.manifest.json +613 -0
  32. house_party_protocol-2.6.5/hpp/install.py +31 -0
  33. house_party_protocol-2.6.5/hpp/manifest.py +343 -0
  34. house_party_protocol-2.6.5/hpp/maps.py +223 -0
  35. house_party_protocol-2.6.5/hpp/policy.py +80 -0
  36. house_party_protocol-2.6.5/hpp/retrieval.py +242 -0
  37. house_party_protocol-2.6.5/hpp/routing.py +109 -0
  38. house_party_protocol-2.6.5/hpp/state.py +74 -0
  39. house_party_protocol-2.6.5/hpp/term.py +214 -0
  40. house_party_protocol-2.6.5/hpp/wizard.py +1051 -0
  41. house_party_protocol-2.6.5/hpp/workgraph.py +339 -0
  42. house_party_protocol-2.6.5/pyproject.toml +59 -0
  43. house_party_protocol-2.6.5/setup.cfg +4 -0
  44. house_party_protocol-2.6.5/tests/test_citation.py +72 -0
  45. house_party_protocol-2.6.5/tests/test_citations.py +419 -0
  46. house_party_protocol-2.6.5/tests/test_cli_contract.py +205 -0
  47. house_party_protocol-2.6.5/tests/test_context.py +119 -0
  48. house_party_protocol-2.6.5/tests/test_decision.py +488 -0
  49. house_party_protocol-2.6.5/tests/test_design_system.py +129 -0
  50. house_party_protocol-2.6.5/tests/test_docs_index.py +115 -0
  51. house_party_protocol-2.6.5/tests/test_done_gate.py +132 -0
  52. house_party_protocol-2.6.5/tests/test_evidence.py +358 -0
  53. house_party_protocol-2.6.5/tests/test_examples_bilingual.py +27 -0
  54. house_party_protocol-2.6.5/tests/test_graph_and_waves.py +120 -0
  55. house_party_protocol-2.6.5/tests/test_hook_capabilities.py +234 -0
  56. house_party_protocol-2.6.5/tests/test_install_for_agents.py +104 -0
  57. house_party_protocol-2.6.5/tests/test_installed_package.py +285 -0
  58. house_party_protocol-2.6.5/tests/test_lane_board_evidence_branch.py +65 -0
  59. house_party_protocol-2.6.5/tests/test_manifesto.py +183 -0
  60. house_party_protocol-2.6.5/tests/test_no_personal_paths.py +112 -0
  61. house_party_protocol-2.6.5/tests/test_policy.py +128 -0
  62. house_party_protocol-2.6.5/tests/test_process.py +61 -0
  63. house_party_protocol-2.6.5/tests/test_readme_points_to_the_site.py +74 -0
  64. house_party_protocol-2.6.5/tests/test_readme_terminal_assets.py +103 -0
  65. house_party_protocol-2.6.5/tests/test_retrieval.py +405 -0
  66. house_party_protocol-2.6.5/tests/test_site_assets_resolve.py +102 -0
  67. house_party_protocol-2.6.5/tests/test_smoke_kits.py +140 -0
  68. house_party_protocol-2.6.5/tests/test_spec_coverage.py +157 -0
  69. house_party_protocol-2.6.5/tests/test_state_and_resume.py +146 -0
  70. house_party_protocol-2.6.5/tests/test_stdlib_only.py +107 -0
  71. house_party_protocol-2.6.5/tests/test_wizard_contract.py +184 -0
  72. house_party_protocol-2.6.5/tests/test_wizard_decision_advisor.py +125 -0
  73. house_party_protocol-2.6.5/tests/test_wizard_documentation_pointer.py +122 -0
  74. house_party_protocol-2.6.5/tests/test_wizard_noninteractive.py +163 -0
  75. house_party_protocol-2.6.5/tests/test_wizard_plan_apply.py +216 -0
  76. house_party_protocol-2.6.5/tests/test_wizard_readiness.py +188 -0
  77. house_party_protocol-2.6.5/tests/test_wizard_term.py +187 -0
@@ -0,0 +1,21 @@
1
+ MIT License
2
+
3
+ Copyright (c) 2026 Max Parisi (Rushar Labs) — https://rusharlabs.com
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,393 @@
1
+ Metadata-Version: 2.4
2
+ Name: house-party-protocol
3
+ Version: 2.6.5
4
+ Summary: A local-first reliability harness for coding agents.
5
+ Author-email: Rushar Labs <325975192+rushar-labs@users.noreply.github.com>
6
+ Maintainer-email: Rushar Labs <325975192+rushar-labs@users.noreply.github.com>
7
+ License-Expression: MIT
8
+ Project-URL: Homepage, https://rusharlabs.com
9
+ Project-URL: Repository, https://github.com/rusharlabs/house-party-protocol
10
+ Project-URL: Changelog, https://github.com/rusharlabs/house-party-protocol/blob/main/CHANGELOG.md
11
+ Project-URL: Issues, https://github.com/rusharlabs/house-party-protocol/issues
12
+ Project-URL: Security, https://github.com/rusharlabs/house-party-protocol/blob/main/SECURITY.md
13
+ Keywords: coding-agents,claude-code,codex-cli,harness,evidence,attestation,verification,guardrails,pass-at-k,local-first
14
+ Classifier: Development Status :: 4 - Beta
15
+ Classifier: Environment :: Console
16
+ Classifier: Intended Audience :: Developers
17
+ Classifier: Operating System :: OS Independent
18
+ Classifier: Programming Language :: Python :: 3
19
+ Classifier: Programming Language :: Python :: 3.10
20
+ Classifier: Programming Language :: Python :: 3.11
21
+ Classifier: Programming Language :: Python :: 3.12
22
+ Classifier: Programming Language :: Python :: 3.13
23
+ Classifier: Topic :: Software Development :: Quality Assurance
24
+ Classifier: Topic :: Software Development :: Testing
25
+ Requires-Python: >=3.10
26
+ Description-Content-Type: text/markdown
27
+ License-File: LICENSE
28
+ Dynamic: license-file
29
+
30
+ <p align="center">
31
+ <img alt="House Party Protocol — by Rushar Labs" src="assets/hpp-logo.png" width="620">
32
+ </p>
33
+
34
+ <p align="center"><sub><code>AGENTS &nbsp;·&nbsp; EVIDENCE &nbsp;·&nbsp; MEMORY &nbsp;·&nbsp; PROTOCOL &nbsp;·&nbsp; CONTINUITY</code></sub></p>
35
+ <p align="center"><sub>spec-driven &nbsp;·&nbsp; wave-driven &nbsp;·&nbsp; lane-isolated</sub></p>
36
+
37
+ <p align="center">
38
+ <a href="https://github.com/rusharlabs/house-party-protocol/actions/workflows/ci.yml"><img alt="CI" src="https://github.com/rusharlabs/house-party-protocol/actions/workflows/ci.yml/badge.svg?branch=main"></a>
39
+ <a href="https://github.com/rusharlabs/house-party-protocol/releases/latest"><img alt="Release" src="https://img.shields.io/github/v/release/rusharlabs/house-party-protocol?color=FF6A00"></a>
40
+ <a href="https://scorecard.dev/viewer/?uri=github.com/rusharlabs/house-party-protocol"><img alt="OpenSSF Scorecard" src="https://api.scorecard.dev/projects/github.com/rusharlabs/house-party-protocol/badge"></a>
41
+ <a href="LICENSE"><img alt="MIT" src="https://img.shields.io/badge/license-MIT-0F1113"></a>
42
+ <a href="#quickstart"><img alt="Python 3.10+" src="https://img.shields.io/badge/Python-3.10%2B-FF6A00"></a>
43
+ <img alt="Claude Code and Codex CLI" src="https://img.shields.io/badge/hosts-Claude%20Code%20%7C%20Codex%20CLI-F4F1EB">
44
+ </p>
45
+
46
+ <p align="center"><sub>English &nbsp;·&nbsp; <a href="README.pt-BR.md">Português (Brasil)</a></sub></p>
47
+ <p align="center"><sub><a href="https://rusharlabs.github.io/house-party-protocol/">Project site</a> &nbsp;·&nbsp; the catalogue, the manual and the design system, rendered</sub></p>
48
+
49
+ # House Party Protocol
50
+
51
+ **Operate coding agents under evidence, not trust.**
52
+
53
+ House Party Protocol (HPP) is a local-first harness for coding agents. It sits around the work
54
+ an agent does in Claude Code or Codex CLI and turns four questions into executable contracts:
55
+ what may run, who may approve, what counts as proof, and where the next step comes from after an
56
+ interruption. The order of work is not negotiated in the conversation: a spec compiles into a
57
+ WorkGraph, the graph runs in topological waves, parallel sessions work in isolated lanes, and every
58
+ wave closes on evidence, never on a sentence.
59
+
60
+ The harness is a Python package with no runtime dependencies (`python -m hpp`), a manifest that
61
+ declares the protocol, a set of installable modules, and one distribution channel per host.
62
+ Nothing runs in the background. Every verdict it produces can be re-derived from files on disk.
63
+
64
+ ## The problem
65
+
66
+ An agent says "done". The sentence is fluent, the diff looks plausible, and nothing checked it.
67
+ The tests it reports may have run against a stale checkout, or may not have run at all; text in
68
+ a transcript is not an exit code. The approval a reviewer gave yesterday still reads "approved"
69
+ this morning, after the spec changed and three files moved. Nobody re-opened it, because nothing
70
+ tied the approval to the bytes it approved.
71
+
72
+ Two sessions share one repository. One rewrites a module while the other reviews it; the review
73
+ lands on a version that no longer exists. Or the agent that wrote the code is the one that
74
+ reviews it, with the same blind spots and a pen in hand: it "fixes and proceeds", and the defect
75
+ in the process never surfaces. A lock left by a session that died at 3 a.m. blocks every other
76
+ session at 9, because a stale lock and a live one look identical.
77
+
78
+ Then the failures that lie by being technically correct. A service answers 200 while its data is
79
+ from Tuesday. A signal stamped in the future is reported as fresh. A counter returns zero because
80
+ the pattern never matched, and zero is read as "no problems". A loop takes "one more iteration"
81
+ past its budget. A summary restored after a crash is treated as a to-do list, so a finished step
82
+ runs again and overwrites its own result. None of these raise an error. That is what makes them
83
+ expensive.
84
+
85
+ ## How the harness responds
86
+
87
+ Each failure above has a mechanism in the code, and each mechanism has a command that shows it.
88
+
89
+ | failure | mechanism | command |
90
+ |---|---|---|
91
+ | "done" without proof | append-only event log; `verified` needs recorded evidence; an out-of-order event is refused before anything is written | `hpp event append` · `hpp status` |
92
+ | stale approval | attestation bound to spec hash, base commit and a full snapshot of tracked and untracked files; any divergence blocks reuse | `hpp attest create` · `hpp attest verify` |
93
+ | author reviewing own work | maker and checker must differ (case-insensitive) or the attestation is refused; module checkers ship with no `Write` and no `Edit` | `hpp attest create --maker a --checker a` → exit 2 |
94
+ | stale lock, territory collision | Lane Map derives `alive` / `suspect` / `dead` from heartbeats; a dead lane never produces a collision | `hpp map lane --now` |
95
+ | service up, data old | Monitor Map separates `healthy`, `stale`, `skew` and `unknown`, with declared freshness and clock tolerance | `hpp map monitor --now` |
96
+ | dangerous command | policy classifier returns `ALLOW`, `MANUAL` or `BLOCK`; `enforce` maps them to exit 0, 1, 2 | `hpp policy check --mode enforce` |
97
+ | parallelism by guesswork | WorkGraph turns declared dependencies into topological waves; a cycle is an error, not an empty wave | `hpp work waves` |
98
+ | context silently truncated | compiler fits whole blocks under a character budget, records a hash per block, and refuses secret-like material | `hpp context compile` |
99
+ | one lucky run | `pass@k` and `pass^k` measured separately over `k` executions | `hpp eval run` · `hpp benchmark` |
100
+ | an advisor nobody measured | a decision made outside the harness is recorded as advisory and raise-only, with abstention and instrument failure as outcomes; a declared decider is measured on labelled cases before it is trusted — hpp itself calls no model | `hpp decide validate` · `hpp decide eval` (new in 2.6.0) |
101
+ | a green screenshot nobody can re-derive | the criterion command you declare (an end-to-end spec, a test suite) runs with its exit code measured outside the model and every declared artifact hashed; it passes only on exit 0 with every declared pattern matched by a file this run wrote, and `verify` blocks an edited record or a changed artifact — the self-hash is not a signature, so a checker re-runs the command; hpp drives no browser | `hpp evidence run` · `hpp evidence verify` (new in 2.6.0) |
102
+ | a retriever nobody measured | a retriever you declare as a command is scored on labelled queries — hit@k, recall@k, precision@k, MRR, nDCG@k — and a timeout, a crash or a malformed answer is an instrument failure counted apart, never a zero; the answer generated from what it found is not judged | `hpp retrieval eval` (new in 2.6.0) |
103
+ | citations nobody resolved | every `[ID:x]` marker must name an id of the context the answer was written from: an unknown id, a range or an empty marker blocks, a number with no marker warns — a marker that resolves proves the source exists, not that it supports the sentence | `hpp cite check` (new in 2.6.0) |
104
+ | a winner picked by whoever built it | N lanes each build their own attempt at one task; a reviewer of another lane and another model family selects the winner, the losers become a terminal `NOT-SELECTED`, and no candidate reaches `MERGED` before the choice — picking 1 of N is `pass@N`, so the winner still needs its own `VERIFIED` and `pass^k` | `lane_board.py compete` · `lane_board.py select` (lane-kit 1.4.0, new in 2.6.0) |
105
+ | installer that writes before you read | `hpp init` prints a plan; `--apply` writes one file; host wiring stays a paste | `hpp init` |
106
+
107
+ ## Cross-model by construction
108
+
109
+ The harness never assumes one brain. Two independent mechanisms, neither of which names a model:
110
+
111
+ | claim | mechanism | command |
112
+ |---|---|---|
113
+ | the reviewer is not the author | maker and checker must differ or the attestation is refused; module checkers ship with no `Write` and no `Edit` | `hpp attest create --maker a --checker a` → exit 2 |
114
+ | the verdict records WHICH reviewer | the wave-review record carries the reviewing lane and the reviewing model, so a verdict can be traced to the brain that gave it | `--verdict-by-lane` · `--verdict-by-model` |
115
+ | a missing reviewer is a state, not a silence | when no independent checker is reachable, the loop records the deferral instead of passing | `--checker-unavailable` |
116
+ | the work is routed by TIER, not by vendor | a declared request resolves to one of the provider ids YOU declared, with a risk floor and fallback only upward | `hpp route --policy economy\|balanced\|frontier` |
117
+
118
+ Two honesties about that last row. The route it returns DOES name a provider — `{'provider': ..., 'tier': ...}` — but only one that you listed in the request: the harness never chooses a vendor you did not declare, never ranks them, and never reads a price. And the shell a checker needs to inspect is a promise, not a capability: `Write` and `Edit` are absent by configuration, while `Bash` is constrained by instruction, so where that matters the working tree is captured before and after the review and compared — a checker that touched it invalidates its own findings (`rules/loop-maker-checker.md`).
119
+
120
+ Hosts today are **Claude Code** and **Codex CLI**: same protocol, same exit codes, same maps. A
121
+ lane driven by one and reviewed from the other is the ordinary case, not an integration project.
122
+
123
+ Those three rows are a state machine, not a convention. `lane-kit` keeps one append-only board per
124
+ repository and is its only writer: `CHECKPOINT-READY` only from the lane that claimed the item and
125
+ only with evidence pasted in, a verdict only from another lane **and** another model family,
126
+ `DEFERRED` the only verdict an unreachable checker can produce, and `MERGED` only on top of a
127
+ `VERIFIED` that is already on the board.
128
+
129
+ <p align="center">
130
+ <img alt="python lane_board.py render: four example items on one board — EXAMPLE-1 MERGED, EXAMPLE-2 VERIFIED and waiting on the human gate, EXAMPLE-3 DEFERRED for want of a checker, EXAMPLE-4 back to BUILDING after NEEDS-FIX — then the verdicts whose lane has not been told" src="assets/terminal/lane-board.svg" width="940">
131
+ </p>
132
+ <p align="center"><sub>The board those rows produce, as <code>multi-session/lane-kit-1.4.1/scripts/lane_board.py</code> prints it: four example items driven through the machine, every event naming the lane that wrote it, the evidence pasted at checkpoint, and — for a verdict — the lane and the model that gave it. Two attempts were refused on the way there, both <code>exit 1</code>: a verdict from the builder's own lane (<em>maker≠checker violated: reviewer (exec-b) is the SAME lane as the builder</em>) and merging a 🔴 item without <code>--human-approved</code>. The last block is the one nobody thinks to ask for — verdicts already decided whose lane has not been told. Text rendered from the command's real stdout by <code>scripts/render_terminal_svg.py</code>, like the two captures above.</sub></p>
133
+
134
+ ## Quickstart
135
+
136
+ > [!WARNING]
137
+ > **Official sources only.** This project is published at
138
+ > `github.com/rusharlabs/house-party-protocol` and through the Claude Code plugin channel
139
+ > `rusharlabs/house-party-protocol` — nowhere else. A copy under another account, or on a package
140
+ > index this README does not name, is not this project. Every release ships `SHA256SUMS` and
141
+ > every module ships `CHECKSUMS.txt`; see [SECURITY.md](SECURITY.md).
142
+
143
+ Requirements: Python 3.10 or newer (`pyproject.toml`), `git` on `PATH` for attestation, no
144
+ third-party packages. CI exercises Python 3.10 to 3.13 on Linux, macOS and Windows
145
+ (`.github/workflows/ci.yml`); older interpreters are not promised because nothing measures them.
146
+
147
+ ```bash
148
+ pip install git+https://github.com/rusharlabs/house-party-protocol@v2.6.5
149
+ hpp doctor
150
+ hpp init --target ../your-repo
151
+ ```
152
+
153
+ From 2.6.5 on, every release is also published to PyPI by the release workflow, with no
154
+ stored token: `pip install house-party-protocol==<version>` installs the same wheel.
155
+
156
+ > **Installing with an agent?** Paste this URL at it and say to follow it:
157
+ > `https://raw.githubusercontent.com/rusharlabs/house-party-protocol/main/INSTALL_FOR_AGENTS.md`
158
+ >
159
+ > [INSTALL_FOR_AGENTS.md](INSTALL_FOR_AGENTS.md) is written for the agent, not for you: it
160
+ > detects the host, checks the preconditions instead of assuming them, and requires the agent to
161
+ > read `hpp init`'s plan to you before a single file is written.
162
+
163
+ <p align="center">
164
+ <img alt="python -m hpp doctor: HPP doctor: ok · modules=10 · hosts=claude-code, codex · hooks=18 (permission gates=9 · llm egress=0)" src="assets/terminal/hpp-doctor.svg" width="474">
165
+ </p>
166
+ <p align="center">
167
+ <img alt="python -m hpp init --target your-repo --non-interactive --no-animation: six boot lines, then READINESS 9/11 verified · 2 not verified · 0 failed" src="assets/terminal/hpp-init.svg" width="860">
168
+ </p>
169
+ <p align="center"><sub>The two commands as they print from a clone of this repository. Both images are text rendered from the real output by <code>scripts/render_terminal_svg.py</code>; regenerate them after any change to the wizard.</sub></p>
170
+
171
+ The package has no runtime dependencies and ships its own manifest and benchmark suite, so `hpp`
172
+ — including `hpp benchmark` and `hpp --self-test` — answers from any directory once installed
173
+ (`pipx install git+…` works the same way). From a checkout, the CLI is the module:
174
+
175
+ ```bash
176
+ git clone https://github.com/rusharlabs/house-party-protocol.git
177
+ cd house-party-protocol
178
+ python -m hpp doctor
179
+ ```
180
+
181
+ `hpp init` runs six fixed stages and prints a plan. Each boot line completes only when its stage
182
+ has finished; readiness counts checks that ran, and each item carries the command that
183
+ reproduces it. What it can verify depends on where `hpp` runs. This repository is the emitted
184
+ distribution — harness, manifest, the ten module directories with their `CHECKSUMS.txt`,
185
+ `marketplace.json` and the module installer — and from a clone of it, against an empty target
186
+ (`python -m hpp init --target <empty-dir> --non-interactive --no-animation`), the output is:
187
+
188
+ ```text
189
+ > detecting host... ✓ greenfield · 0 existing item(s) preserved
190
+ > checking prerequisites... ✓ python 3.14.3 · protocol 2.1
191
+ > mounting profile... ✓ would-write · host=claude-code · bundle=reliable-coding · policy=audit · 3 default(s)
192
+ > loading modules... ✓ 6 modules · reliable-coding · claude-code · 6/6 checksums verified
193
+ > wiring suggestions... ✓ 7 commands to paste · 0 files written · 17 hooks declaring capabilities
194
+ > verifying evidence... ✓ policy · graph · events · benchmark
195
+ > protocol online.
196
+
197
+ READINESS every line is a check that ran; the command below it reproduces it
198
+ ████████████████░░░░ 9/11 verified · 2 not verified · 0 failed
199
+ ```
200
+
201
+ The two items not verified are the two that only a later action can prove: the profile (plan
202
+ only; `--apply` writes it) and the host wiring (a paste you do yourself). The pip install is a
203
+ different channel: the wheel carries the harness, the manifest and the benchmark suite, but no
204
+ module directories and no `marketplace.json`. The same command from that install, on the same
205
+ empty target, reads:
206
+
207
+ ```text
208
+ > detecting host... ✓ greenfield · 0 existing item(s) preserved
209
+ > checking prerequisites... ✓ python 3.14.3 · protocol 2.1
210
+ > mounting profile... ✓ would-write · host=claude-code · bundle=reliable-coding · policy=audit · 3 default(s)
211
+ > loading modules... ✓ 6 modules · reliable-coding · claude-code
212
+ > wiring suggestions... ✓ 7 commands to paste · 0 files written · 17 hooks declaring capabilities
213
+ > verifying evidence... ✓ policy · graph · events · benchmark
214
+ > protocol online.
215
+
216
+ READINESS every line is a check that ran; the command below it reproduces it
217
+ █████████████░░░░░░░ 7/11 verified · 4 not verified · 0 failed
218
+ ```
219
+
220
+ The two extra items there — distribution integrity and module checksums — are reported as not
221
+ verified because there is nothing to measure them against, never as passed. In either channel
222
+ nothing is written until you re-run with `--apply`, and then exactly one file is written:
223
+ `.hpp/profile.json`. `hpp init --json` gives the same report as JSON for CI and agents;
224
+ `--non-interactive`, `--yes` and `--profile` answer the questions without a prompt. The fourth
225
+ question is optional and new in 2.6.0: `--decision-advisor off|typesafe|openrouter|compatible` records a typed-decision
226
+ advisor you will integrate yourself (default `off`) and prints how — see
227
+ [examples/typed-decisions](examples/typed-decisions/README.md).
228
+
229
+ After `--apply`, paste the wire block the command printed. For Claude Code that is the native
230
+ plugin channel:
231
+
232
+ ```text
233
+ /plugin marketplace add rusharlabs/house-party-protocol
234
+ /plugin install operator-kit@house-party-protocol
235
+ ```
236
+
237
+ For Codex CLI the module installer copies each module into `.agents/hpp/<module>` and runs its
238
+ declared smokes. On Claude Code, a module without a plugin hook is copied by hand (each module's
239
+ README shows the `cp -r` line) and the installer detects, wires and verifies it. Either way it
240
+ plans first and applies only on a second, explicit invocation:
241
+
242
+ ```bash
243
+ python installers/kit-forge-1.4.2/kit_doctor.py install \
244
+ --kit frameworks/operator-kit-1.6.2 --host codex --target ../your-repo
245
+ python installers/kit-forge-1.4.2/kit_doctor.py install \
246
+ --kit frameworks/operator-kit-1.6.2 --host codex --target ../your-repo --apply
247
+ ```
248
+
249
+ The installer is part of this repository, at `installers/kit-forge-1.4.2/kit_doctor.py`, next
250
+ to the module directories it installs from. A pip install carries neither, and `hpp init` says
251
+ so in its wire block when it cannot find the installer beside the manifest.
252
+ `hpp install --bundle reliable-coding --host codex --target ../your-repo` is a different
253
+ command: it prints a receipt with `"mode": "plan-only"` and copies nothing.
254
+
255
+ ## Harness, protocol, modules, distribution
256
+
257
+ The product is layered, and the layers are not interchangeable.
258
+
259
+ ```text
260
+ harness python -m hpp the operating surface: doctor, init, event log,
261
+ attestation, maps, WorkGraph, policy, routing, eval,
262
+ decision records, evidence bundles, retrieval eval,
263
+ citation check
264
+ │
265
+ protocol hpp.manifest.json the invariants: roles, loop transitions and gates,
266
+ exit codes, host coverage, monitors, bundles
267
+ │
268
+ modules ten versioned dirs installable capabilities; each stands alone
269
+ │
270
+ distribution marketplace · copy Claude Code plugin channel · Codex CLI verified copy
271
+ ```
272
+
273
+ `hpp doctor` validates the manifest and, when `marketplace.json` sits beside it, cross-checks
274
+ every module path, version and plugin manifest. In this repository it prints
275
+ `HPP doctor: ok · modules=10 · hosts=claude-code, codex · hooks=18 (permission gates=9 · llm egress=0)`; the cross-check is visible only in
276
+ `hpp doctor --json`, where `distribution` reads `{"checked": true, "modules": 10, "status": "ok"}`.
277
+ From a pip install the one-line output is the same and the field reads
278
+ `{"checked": false, "status": "source-contract"}`, because no `marketplace.json` sits beside the
279
+ packaged manifest.
280
+
281
+ The protocol's loop is five transitions, each behind a named gate:
282
+
283
+ ```text
284
+ planned --work_started--> active --evidence_recorded--> evidenced --check_passed--> checked
285
+ [scope] [fresh-evidence] [read-only-checker]
286
+
287
+ checked --human_approved--> approved --verified--> verified
288
+ [human] [closure]
289
+ ```
290
+
291
+ `hpp status` projects the event log onto this machine and names the next step; `hpp resume`
292
+ returns the same answer as JSON. Neither asks a model to remember anything.
293
+
294
+ ## What each module solves
295
+
296
+ | module | version | one line |
297
+ |---|---|---|
298
+ | `operator-kit` | 1.6.2 | done gate with real exit codes, command policy in `audit` or `enforce`, governed loops with charter and stop conditions, standalone `pass@k` / `pass^k` runner, preflight, two checker agents shipped without `Write` or `Edit` |
299
+ | `lane-kit` | 1.4.1 | a lane board for concurrent sessions: claim, territory, liveness, maker ≠ checker, and a router that picks a checker from a different provider |
300
+ | `continuity-kit` | 1.4.1 | handoff written before a stop or compaction, re-derivation commands instead of remembered state, guards against replaying finished steps |
301
+ | `health-kit` | 1.3.3 | config-driven service probes that write a cache a statusline reads without touching the network; service health kept apart from data health |
302
+ | `gotcha-memory` | 1.0.3 | records failed commands by error family, detects recurrence, injects the lesson before the next run; warn-only, secrets redacted by shape |
303
+ | `kit-forge` | 1.4.2 | assembles modules from source, lints for IP and PII, installs in six stages, writes and verifies `CHECKSUMS.txt`, checks the marketplace |
304
+ | `claude-dev-kit` | 1.3.3 | authoring of skills, hooks and plugins for Claude Code, reversible settings wiring, secret scan on write |
305
+ | `dev-squad-kit` | 1.1.1 | twelve development roles as commands and subagents with explicit tools, plus parallel read-and-consolidate skills |
306
+ | `agent-framework-wizard` | 1.2.1 | six-step scaffold for a new agent or skill project, answerable from a file for non-interactive runs |
307
+ | `supabase-pack` | 1.1.2 | RLS audit through `pg_policies` and advisors instead of a table flag; Edge Function scaffold |
308
+
309
+ The `reliable-coding` bundle is the first six. Each module installs on its own; `integrates_with`
310
+ in the manifest is optional composition, `requires` is a hard dependency, and today no module
311
+ requires another. Host coverage is declared per module as `native`, `explicit-command` or
312
+ `unsupported`; `claude-dev-kit` is `unsupported` on Codex CLI, and `hpp init` halts rather than
313
+ plan it there.
314
+
315
+ ## Proving an installation
316
+
317
+ A claim about the harness is accepted only with its command. These are the ones the project runs
318
+ on itself.
319
+
320
+ ```bash
321
+ python -m hpp doctor # manifest contract; distribution when present
322
+ python -m hpp benchmark -k 3 # ten executable controls, three runs each
323
+ python -m hpp --self-test # capability graph non-empty + benchmark gate
324
+ python -m pytest tests -q # stdlib-only suite, no network
325
+ python -m hpp policy check --mode enforce --command "rm -rf src" # exit 2, BLOCK
326
+ python -m hpp graph --view operational --format json | sha256sum # same hash on every run
327
+ ```
328
+
329
+ The benchmark's ten controls each execute a real mechanism with a positive and a negative case:
330
+ manifest contract, policy enforcement, WorkGraph waves, lane collision, monitor freshness,
331
+ context provenance, routing floor, event/evidence gate, graph determinism and evidence
332
+ attestation. `pass^k = 1.00` is required for the gate to pass. The suite file and its hash are
333
+ in the JSON report (`hpp benchmark -k 3 --json`). See [PROOF.md](docs/PROOF.md) for the claim
334
+ matrix and [BENCHMARK.md](docs/BENCHMARK.md) for the scenarios.
335
+
336
+ In this repository, `python installers/kit-forge-1.4.2/kit_doctor.py verify <module-dir>`
337
+ compares every file of a module against its `CHECKSUMS.txt`, and
338
+ `python installers/kit-forge-1.4.2/kit_doctor.py marketplace .` checks the whole tree.
339
+
340
+ ## Honest limits
341
+
342
+ - HPP is a CLI. There is no daemon, scheduler, queue, server, database or remote telemetry. If a
343
+ check did not run, nothing ran it.
344
+ - HPP never calls a model. Routing returns a tier and a provider id from declarations you pass
345
+ in; it does not pick a vendor, a model name or a price.
346
+ - Maps are projections of manifests, event logs and JSON you provide. The Monitor Map does not
347
+ probe anything; you supply `last_signal`. The Lane Map does not know your sessions; you supply
348
+ heartbeats. `--now` is explicit so that no projection depends on the ambient clock.
349
+ - The context budget is measured in characters, not tokens.
350
+ - The policy classifier is a small, explicit rule set (recursive delete in any flag order,
351
+ force push, push to `main`/`master`, `curl | sh`, `DROP`/`TRUNCATE`, and `MANUAL` for any push
352
+ or outbound transfer). It never executes the command and it does not claim to catch every
353
+ destructive form.
354
+ - Attestation requires `git`. It hashes the remote identity and stores the hash, not the URL.
355
+ It binds a verdict to bytes; it does not judge whether the verdict was right.
356
+ - On Claude Code, lifecycle hooks are native once you paste the wiring. On Codex CLI there are no
357
+ lifecycle hooks; the same capabilities are explicit commands. `hpp doctor` and the manifest
358
+ report this as `native`, `explicit-command` or `unsupported`, and no adapter pretends
359
+ otherwise.
360
+ - `hpp init` writes one file with `--apply` and never edits `settings.json`, hooks or
361
+ `AGENTS.md`. Enabling hooks remains a human action.
362
+ - The benchmark proves the harness on the checkout and platform where it ran. It says nothing
363
+ about the quality of any model.
364
+
365
+ ## Reading order
366
+
367
+ [MANIFESTO.md](MANIFESTO.md) — what the project defends and refuses ·
368
+ [CONCEPTS.md](docs/CONCEPTS.md) — the vocabulary, with what each term is not ·
369
+ [METHOD.md](docs/METHOD.md) — the working method, one command per practice ·
370
+ [ARCHITECTURE.md](docs/ARCHITECTURE.md) — how the pieces fit and what deliberately does not
371
+ exist · [GRAPH-MODEL.md](docs/GRAPH-MODEL.md) · [LOOPS.md](docs/LOOPS.md) ·
372
+ [BENCHMARK.md](docs/BENCHMARK.md) · [PROOF.md](docs/PROOF.md) · [BRAND.md](docs/BRAND.md) — the
373
+ identity · [DESIGN.md](docs/DESIGN.md) — the tokens, the components and what a pull request with
374
+ an interface has to satisfy ·
375
+ [TIPS.md](docs/TIPS.md) · [manual](https://rusharlabs.github.io/house-party-protocol/MANUAL.html) · [catalogue](https://rusharlabs.github.io/house-party-protocol/CATALOG.html) ·
376
+ [CHANGELOG.md](CHANGELOG.md) · [AGENTS.md](AGENTS.md) for agents working in this repository.
377
+
378
+ ## Development
379
+
380
+ Module directories in the distribution are emitted artifacts. Changes start in the sources, get
381
+ a test that fails before the fix and passes after it, and go through the forge. Before declaring
382
+ anything done:
383
+
384
+ ```bash
385
+ python -m pytest tests -q
386
+ python -m hpp doctor
387
+ python -m hpp benchmark -k 3
388
+ ```
389
+
390
+ ## License
391
+
392
+ MIT. Copyright (c) 2026 Max Parisi, Rushar Labs. Any module that carries adapted material keeps
393
+ the `NOTICE` file its license requires.