harnessie 0.6.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.
- harnessie-0.6.0/LICENSE +202 -0
- harnessie-0.6.0/NOTICE +38 -0
- harnessie-0.6.0/PKG-INFO +163 -0
- harnessie-0.6.0/README.md +145 -0
- harnessie-0.6.0/harness/__init__.py +25 -0
- harnessie-0.6.0/harness/adversarial.py +264 -0
- harnessie-0.6.0/harness/approval.py +96 -0
- harnessie-0.6.0/harness/audit.py +96 -0
- harnessie-0.6.0/harness/cli.py +198 -0
- harnessie-0.6.0/harness/evals.py +659 -0
- harnessie-0.6.0/harness/events.py +72 -0
- harnessie-0.6.0/harness/explain.py +174 -0
- harnessie-0.6.0/harness/firstrun.py +124 -0
- harnessie-0.6.0/harness/ids.py +76 -0
- harnessie-0.6.0/harness/init_project.py +83 -0
- harnessie-0.6.0/harness/live_scorecard.py +320 -0
- harnessie-0.6.0/harness/loop.py +224 -0
- harnessie-0.6.0/harness/memory.py +203 -0
- harnessie-0.6.0/harness/models/__init__.py +42 -0
- harnessie-0.6.0/harness/models/anthropic.py +111 -0
- harnessie-0.6.0/harness/models/base.py +112 -0
- harnessie-0.6.0/harness/models/openai_compat.py +113 -0
- harnessie-0.6.0/harness/ownership.py +116 -0
- harnessie-0.6.0/harness/preflight.py +115 -0
- harnessie-0.6.0/harness/quarantine.py +101 -0
- harnessie-0.6.0/harness/roles.py +133 -0
- harnessie-0.6.0/harness/routing.py +96 -0
- harnessie-0.6.0/harness/runner.py +730 -0
- harnessie-0.6.0/harness/sandbox.py +199 -0
- harnessie-0.6.0/harness/state.py +64 -0
- harnessie-0.6.0/harness/tools/__init__.py +4 -0
- harnessie-0.6.0/harness/tools/builtin.py +311 -0
- harnessie-0.6.0/harness/tools/registry.py +186 -0
- harnessie-0.6.0/harness/trust_manifest.py +71 -0
- harnessie-0.6.0/harness/verify.py +241 -0
- harnessie-0.6.0/harnessie.egg-info/PKG-INFO +163 -0
- harnessie-0.6.0/harnessie.egg-info/SOURCES.txt +66 -0
- harnessie-0.6.0/harnessie.egg-info/dependency_links.txt +1 -0
- harnessie-0.6.0/harnessie.egg-info/entry_points.txt +2 -0
- harnessie-0.6.0/harnessie.egg-info/requires.txt +4 -0
- harnessie-0.6.0/harnessie.egg-info/top_level.txt +1 -0
- harnessie-0.6.0/pyproject.toml +32 -0
- harnessie-0.6.0/setup.cfg +4 -0
- harnessie-0.6.0/tests/test_adversarial.py +265 -0
- harnessie-0.6.0/tests/test_approval.py +114 -0
- harnessie-0.6.0/tests/test_audit.py +103 -0
- harnessie-0.6.0/tests/test_consent.py +168 -0
- harnessie-0.6.0/tests/test_evals.py +70 -0
- harnessie-0.6.0/tests/test_explain.py +106 -0
- harnessie-0.6.0/tests/test_firstrun.py +66 -0
- harnessie-0.6.0/tests/test_graceful_boundaries.py +139 -0
- harnessie-0.6.0/tests/test_guide_artifacts.py +93 -0
- harnessie-0.6.0/tests/test_ids.py +18 -0
- harnessie-0.6.0/tests/test_live_scorecard.py +28 -0
- harnessie-0.6.0/tests/test_loop.py +127 -0
- harnessie-0.6.0/tests/test_memory_tools.py +150 -0
- harnessie-0.6.0/tests/test_ownership.py +139 -0
- harnessie-0.6.0/tests/test_preflight.py +71 -0
- harnessie-0.6.0/tests/test_quarantine.py +146 -0
- harnessie-0.6.0/tests/test_registry.py +127 -0
- harnessie-0.6.0/tests/test_repo_configs.py +190 -0
- harnessie-0.6.0/tests/test_roles_cli.py +73 -0
- harnessie-0.6.0/tests/test_routing_verify.py +129 -0
- harnessie-0.6.0/tests/test_runner.py +317 -0
- harnessie-0.6.0/tests/test_sandbox.py +198 -0
- harnessie-0.6.0/tests/test_state_memory.py +35 -0
- harnessie-0.6.0/tests/test_triage.py +160 -0
- harnessie-0.6.0/tests/test_trust_manifest.py +44 -0
harnessie-0.6.0/LICENSE
ADDED
|
@@ -0,0 +1,202 @@
|
|
|
1
|
+
|
|
2
|
+
Apache License
|
|
3
|
+
Version 2.0, January 2004
|
|
4
|
+
http://www.apache.org/licenses/
|
|
5
|
+
|
|
6
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
7
|
+
|
|
8
|
+
1. Definitions.
|
|
9
|
+
|
|
10
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
11
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
12
|
+
|
|
13
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
14
|
+
the copyright owner that is granting the License.
|
|
15
|
+
|
|
16
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
17
|
+
other entities that control, are controlled by, or are under common
|
|
18
|
+
control with that entity. For the purposes of this definition,
|
|
19
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
20
|
+
direction or management of such entity, whether by contract or
|
|
21
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
22
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
23
|
+
|
|
24
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
25
|
+
exercising permissions granted by this License.
|
|
26
|
+
|
|
27
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
28
|
+
including but not limited to software source code, documentation
|
|
29
|
+
source, and configuration files.
|
|
30
|
+
|
|
31
|
+
"Object" form shall mean any form resulting from mechanical
|
|
32
|
+
transformation or translation of a Source form, including but
|
|
33
|
+
not limited to compiled object code, generated documentation,
|
|
34
|
+
and conversions to other media types.
|
|
35
|
+
|
|
36
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
37
|
+
Object form, made available under the License, as indicated by a
|
|
38
|
+
copyright notice that is included in or attached to the work
|
|
39
|
+
(an example is provided in the Appendix below).
|
|
40
|
+
|
|
41
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
42
|
+
form, that is based on (or derived from) the Work and for which the
|
|
43
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
44
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
45
|
+
of this License, Derivative Works shall not include works that remain
|
|
46
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
47
|
+
the Work and Derivative Works thereof.
|
|
48
|
+
|
|
49
|
+
"Contribution" shall mean any work of authorship, including
|
|
50
|
+
the original version of the Work and any modifications or additions
|
|
51
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
52
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
53
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
54
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
55
|
+
means any form of electronic, verbal, or written communication sent
|
|
56
|
+
to the Licensor or its representatives, including but not limited to
|
|
57
|
+
communication on electronic mailing lists, source code control systems,
|
|
58
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
59
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
60
|
+
excluding communication that is conspicuously marked or otherwise
|
|
61
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
62
|
+
|
|
63
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
64
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
65
|
+
subsequently incorporated within the Work.
|
|
66
|
+
|
|
67
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
68
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
69
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
70
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
71
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
72
|
+
Work and such Derivative Works in Source or Object form.
|
|
73
|
+
|
|
74
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
75
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
76
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
77
|
+
(except as stated in this section) patent license to make, have made,
|
|
78
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
79
|
+
where such license applies only to those patent claims licensable
|
|
80
|
+
by such Contributor that are necessarily infringed by their
|
|
81
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
82
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
83
|
+
institute patent litigation against any entity (including a
|
|
84
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
85
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
86
|
+
or contributory patent infringement, then any patent licenses
|
|
87
|
+
granted to You under this License for that Work shall terminate
|
|
88
|
+
as of the date such litigation is filed.
|
|
89
|
+
|
|
90
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
91
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
92
|
+
modifications, and in Source or Object form, provided that You
|
|
93
|
+
meet the following conditions:
|
|
94
|
+
|
|
95
|
+
(a) You must give any other recipients of the Work or
|
|
96
|
+
Derivative Works a copy of this License; and
|
|
97
|
+
|
|
98
|
+
(b) You must cause any modified files to carry prominent notices
|
|
99
|
+
stating that You changed the files; and
|
|
100
|
+
|
|
101
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
102
|
+
that You distribute, all copyright, patent, trademark, and
|
|
103
|
+
attribution notices from the Source form of the Work,
|
|
104
|
+
excluding those notices that do not pertain to any part of
|
|
105
|
+
the Derivative Works; and
|
|
106
|
+
|
|
107
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
108
|
+
distribution, then any Derivative Works that You distribute must
|
|
109
|
+
include a readable copy of the attribution notices contained
|
|
110
|
+
within such NOTICE file, excluding those notices that do not
|
|
111
|
+
pertain to any part of the Derivative Works, in at least one
|
|
112
|
+
of the following places: within a NOTICE text file distributed
|
|
113
|
+
as part of the Derivative Works; within the Source form or
|
|
114
|
+
documentation, if provided along with the Derivative Works; or,
|
|
115
|
+
within a display generated by the Derivative Works, if and
|
|
116
|
+
wherever such third-party notices normally appear. The contents
|
|
117
|
+
of the NOTICE file are for informational purposes only and
|
|
118
|
+
do not modify the License. You may add Your own attribution
|
|
119
|
+
notices within Derivative Works that You distribute, alongside
|
|
120
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
121
|
+
that such additional attribution notices cannot be construed
|
|
122
|
+
as modifying the License.
|
|
123
|
+
|
|
124
|
+
You may add Your own copyright statement to Your modifications and
|
|
125
|
+
may provide additional or different license terms and conditions
|
|
126
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
127
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
128
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
129
|
+
the conditions stated in this License.
|
|
130
|
+
|
|
131
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
132
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
133
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
134
|
+
this License, without any additional terms or conditions.
|
|
135
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
136
|
+
the terms of any separate license agreement you may have executed
|
|
137
|
+
with Licensor regarding such Contributions.
|
|
138
|
+
|
|
139
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
140
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
141
|
+
except as required for reasonable and customary use in describing the
|
|
142
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
143
|
+
|
|
144
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
145
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
146
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
147
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
148
|
+
implied, including, without limitation, any warranties or conditions
|
|
149
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
150
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
151
|
+
appropriateness of using or redistributing the Work and assume any
|
|
152
|
+
risks associated with Your exercise of permissions under this License.
|
|
153
|
+
|
|
154
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
155
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
156
|
+
unless required by applicable law (such as deliberate and grossly
|
|
157
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
158
|
+
liable to You for damages, including any direct, indirect, special,
|
|
159
|
+
incidental, or consequential damages of any character arising as a
|
|
160
|
+
result of this License or out of the use or inability to use the
|
|
161
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
162
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
163
|
+
other commercial damages or losses), even if such Contributor
|
|
164
|
+
has been advised of the possibility of such damages.
|
|
165
|
+
|
|
166
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
167
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
168
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
169
|
+
or other liability obligations and/or rights consistent with this
|
|
170
|
+
License. However, in accepting such obligations, You may act only
|
|
171
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
172
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
173
|
+
defend, and hold each Contributor harmless for any liability
|
|
174
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
175
|
+
of your accepting any such warranty or additional liability.
|
|
176
|
+
|
|
177
|
+
END OF TERMS AND CONDITIONS
|
|
178
|
+
|
|
179
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
180
|
+
|
|
181
|
+
To apply the Apache License to your work, attach the following
|
|
182
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
183
|
+
replaced with your own identifying information. (Don't include
|
|
184
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
185
|
+
comment syntax for the file format. We also recommend that a
|
|
186
|
+
file or class name and description of purpose be included on the
|
|
187
|
+
same "printed page" as the copyright notice for easier
|
|
188
|
+
identification within third-party archives.
|
|
189
|
+
|
|
190
|
+
Copyright 2026 Snap Synapse LLC
|
|
191
|
+
|
|
192
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
193
|
+
you may not use this file except in compliance with the License.
|
|
194
|
+
You may obtain a copy of the License at
|
|
195
|
+
|
|
196
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
197
|
+
|
|
198
|
+
Unless required by applicable law or agreed to in writing, software
|
|
199
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
200
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
201
|
+
See the License for the specific language governing permissions and
|
|
202
|
+
limitations under the License.
|
harnessie-0.6.0/NOTICE
ADDED
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
Harnessie
|
|
2
|
+
Copyright 2026 Snap Synapse LLC (https://snapsynapse.com/)
|
|
3
|
+
|
|
4
|
+
Licensed under the Apache License, Version 2.0. See LICENSE.
|
|
5
|
+
|
|
6
|
+
TRADEMARKS
|
|
7
|
+
|
|
8
|
+
"Harnessie" and harnessie.com are marks of Snap Synapse LLC. Per Section 6
|
|
9
|
+
of the Apache License, this license does not grant permission to use them.
|
|
10
|
+
|
|
11
|
+
PAICE.WORK PBC STANDARDS AND SPECIFICATIONS
|
|
12
|
+
|
|
13
|
+
Harnessie adopts lessons from, and credits, standards stewarded by
|
|
14
|
+
PAICE.work PBC (https://paice.work/): Turnfile, AIDR (AI Decision Records),
|
|
15
|
+
Graceful Boundaries, and GuideCheck. Those specifications, their names, and
|
|
16
|
+
their canonical texts remain the property of PAICE.work PBC and are NOT
|
|
17
|
+
licensed by this repository. Harnessie's relationship to them is adoption
|
|
18
|
+
and credit, not ownership; conformance is asserted only where a tracked
|
|
19
|
+
document cites the achieved level and its proving tests (see INTENT.md §7
|
|
20
|
+
and GOVERNANCE.md). Nothing in this repository grants any right to the
|
|
21
|
+
PAICE.work PBC specifications beyond what their own licenses provide.
|
|
22
|
+
|
|
23
|
+
PAICE.WORK PBC ORIGINATED CODE
|
|
24
|
+
|
|
25
|
+
As of this version, no PAICE.work PBC code is vendored into this
|
|
26
|
+
repository. Standing rule: code originating in PAICE.work PBC repositories
|
|
27
|
+
enters Harnessie only under an explicit written grant from PAICE.work PBC,
|
|
28
|
+
recorded in this NOTICE with the grant date, the source, and the scope,
|
|
29
|
+
before the vendored code appears in any public commit. Planned under the
|
|
30
|
+
0.7.0 roadmap: a containment boundary adapted from PAICE.work PBC
|
|
31
|
+
production PII-handling code; that adaptation will not merge before its
|
|
32
|
+
grant line appears here.
|
|
33
|
+
|
|
34
|
+
THIRD-PARTY MATERIALS
|
|
35
|
+
|
|
36
|
+
This repository currently vendors no third-party code beyond the Python
|
|
37
|
+
standard library. Future vendored components and their licenses will be
|
|
38
|
+
credited here.
|
harnessie-0.6.0/PKG-INFO
ADDED
|
@@ -0,0 +1,163 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: harnessie
|
|
3
|
+
Version: 0.6.0
|
|
4
|
+
Summary: Harnessie: a brain-agnostic multi-agent harness (orchestrator / workers / verifiers) with verification gates, consent-based orchestration, ownership lanes, adversarial decision records, routing policy, and a tamper-evident audit log.
|
|
5
|
+
Author-email: Sam Rogers <subscriptions@snapsynapse.com>
|
|
6
|
+
License: Apache-2.0
|
|
7
|
+
Project-URL: Homepage, https://harnessie.com/
|
|
8
|
+
Project-URL: Repository, https://github.com/snapsynapse/harnessie
|
|
9
|
+
Project-URL: Assistant-Guide, https://harnessie.com/.well-known/assistant-guide.txt
|
|
10
|
+
Requires-Python: >=3.11
|
|
11
|
+
Description-Content-Type: text/markdown
|
|
12
|
+
License-File: LICENSE
|
|
13
|
+
License-File: NOTICE
|
|
14
|
+
Requires-Dist: pyyaml>=6.0
|
|
15
|
+
Provides-Extra: dev
|
|
16
|
+
Requires-Dist: pytest>=8.0; extra == "dev"
|
|
17
|
+
Dynamic: license-file
|
|
18
|
+
|
|
19
|
+
# Harnessie
|
|
20
|
+
|
|
21
|
+
A brain-agnostic multi-agent harness: orchestrator, swappable workers, independent verifiers, verification gates between every phase, consent-based orchestration, per-agent file ownership, adversarial decision records with human-only arbitration, self-maintaining project memory with stamped provenance and dated expiry, cost routing as declared config, and a tamper-evident audit log that records operator and agent actions in one composite timeline.
|
|
22
|
+
|
|
23
|
+
Harnessie is built to be the safest and easiest first AI harness for people. "Safest" is not a slogan here; it is a set of checkable properties: guarantees live in code, not prompts ([GOVERNANCE.md](GOVERNANCE.md)); every control that cannot be enforced fails closed instead of running unenforced; nothing ships on an agent's say-so (independent fresh-context verifiers gate every side-effecting phase); an OS sandbox confines shell work; a seven-layer prompt-injection defense with a written threat model ([SECURITY.md](SECURITY.md)) covers the rest; and a hash-chained audit log records every agent and operator action in one tamper-evident timeline. If you find a way to break any of these claims, that is a bug report we want. "Easiest" means the person running it does not need to be a developer: runs carry declared token and dollar ceilings, every halt is a named condition with one plain operator action, and disagreement between agents becomes a human decision, never a silent merge.
|
|
24
|
+
|
|
25
|
+
The operating thesis: the harness structure carries the quality floor, the model carries the ceiling. Run it with Claude Fable 5 as the orchestrator and it exploits effort dials, long autonomous turns, and verifier subagents. Swap the workers (or everything) for Haiku, GLM, Qwen, or any OpenAI-compatible local endpoint by editing one YAML file, and the gates, jails, budgets, and retry ladders keep output honest.
|
|
26
|
+
|
|
27
|
+
Beneath that thesis sit five engineering habits, each proven separately in the author's other tools and standards before it landed here as code: deterministic checks run before any model judgment (the gate order in [docs/GUIDE.md](docs/GUIDE.md)); evaluation comes before implementation — a governance mechanic without a red-then-green scenario pair does not merge ([EVALS.md](EVALS.md)); remembered facts carry verified and verify-by dates and expire visibly, never silently ([GOVERNANCE.md](GOVERNANCE.md)); every agent and operator action lands in one hash-chained, tamper-evident timeline ([docs/threat-model.md](docs/threat-model.md)); and any control that cannot be enforced fails closed rather than running unenforced ([SECURITY.md](SECURITY.md)). The same habits produced the standards Harnessie adopts — [Turnfile](https://turnfile.work/), [AIDR](https://aidr.work/), [Graceful Boundaries](https://gracefulboundaries.dev/) — which is why they fit together.
|
|
28
|
+
|
|
29
|
+
## Quick start
|
|
30
|
+
|
|
31
|
+
```bash
|
|
32
|
+
pip install -e ".[dev]"
|
|
33
|
+
python3 -m pytest -q # mock brain, no network
|
|
34
|
+
python3 -m harness.cli eval # deterministic eval scorecard
|
|
35
|
+
python3 -m harness.cli verify-manifest
|
|
36
|
+
export ANTHROPIC_API_KEY=sk-ant-... # or point tiers at a local endpoint
|
|
37
|
+
python3 -m harness.cli run workflows/build-and-verify.yaml --goal "a CLI todo app with tests"
|
|
38
|
+
python3 -m harness.cli report <run_id>
|
|
39
|
+
python3 -m harness.cli audit <run_id> # verify the hash chain + governance timeline
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
Installed CLI usage can scaffold a fresh project layout:
|
|
43
|
+
```bash
|
|
44
|
+
harnessie init my-harnessie-project
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
Worked end-to-end example with sample data: [examples/policy-compliance/README.md](examples/policy-compliance/README.md).
|
|
48
|
+
|
|
49
|
+
## Documentation
|
|
50
|
+
|
|
51
|
+
- [docs/quickstart.md](docs/quickstart.md): the gentlest path for someone who has never cloned a repo or written YAML, assuming no git or shell fluency, with a glossary and an honest Windows/WSL2 page.
|
|
52
|
+
- [docs/getting-started.md](docs/getting-started.md): the five-minute path from install to a green run and reading the evidence.
|
|
53
|
+
- [docs/GUIDE.md](docs/GUIDE.md): the complete user guide, concepts through extension, including workflow authoring, brain configuration, ownership, governance, and the halt-recovery table.
|
|
54
|
+
- [docs/brains.md](docs/brains.md): the brain-agnostic receipt, the models actually run under the harness with a link to the record that proves each.
|
|
55
|
+
- [assistant-guide.txt](assistant-guide.txt): a bounded, human-verifiable guide (GuideCheck Level 3 profile) for an assistant reviewing a Harnessie checkout before you authorize a run; served at [harnessie.com/.well-known/assistant-guide.txt](https://harnessie.com/.well-known/assistant-guide.txt) with a sidecar manifest for provenance.
|
|
56
|
+
|
|
57
|
+
The engineering references below (ARCHITECTURE, GOVERNANCE, SECURITY, ROADMAP) sit at the repo root; the user-facing guides live under `docs/`.
|
|
58
|
+
|
|
59
|
+
## Layout
|
|
60
|
+
|
|
61
|
+
```text
|
|
62
|
+
harness/ the runtime: models/ tools/ loop verify routing memory state roles quarantine
|
|
63
|
+
sandbox ownership adversarial audit runner cli events
|
|
64
|
+
agents/ role prompts (markdown): orchestrator.md, workers/, verifiers/
|
|
65
|
+
workflows/ declared phase sequences (YAML) with per-phase gates, task classes, and
|
|
66
|
+
adversarial contested phases (mode: adversarial)
|
|
67
|
+
config/models.yaml model tiers, routing table, budgets: the ONLY file to edit to swap brains
|
|
68
|
+
OWNERSHIP.yaml ownership lanes + first-writer auto-claims; operator-owned, agents cannot reach it
|
|
69
|
+
decisions/ the repo's own AIDR decision records (AIDR-0001 = v0.2 direction,
|
|
70
|
+
AIDR-0002 = v0.3 direction; both human-arbitrated 2026-07-06
|
|
71
|
+
with independent positions from four providers)
|
|
72
|
+
memory/ project memory: MEMORY.md index + facts/ (stamped provenance, verify_by
|
|
73
|
+
expiry) + archive/ (expired facts; nothing deletes) — maintained by
|
|
74
|
+
workflows/memory-triage.yaml under approval gates
|
|
75
|
+
examples/ worked end-to-end example (policy-compliance) with sample data
|
|
76
|
+
runs/ per-run journal.jsonl (resume ledger) + events.jsonl (hash-chained audit)
|
|
77
|
+
+ proofs/ + decisions/ (contested-phase records) (gitignored)
|
|
78
|
+
evals/ deterministic scorecards over mock-brain golden/risky/recovery scenarios
|
|
79
|
+
docs/MANIFEST.yaml trust-bundle integrity manifest for machine-readable public artifacts
|
|
80
|
+
tests/ the done-tests for every subsystem
|
|
81
|
+
docs/ reserved for the canonical web page (GitHub Pages publish source once public)
|
|
82
|
+
*.md at root ARCHITECTURE, GOVERNANCE, SECURITY, ROADMAP, IMPLEMENTATION_PLAN, PROMPTS, EVALS, NEXT,
|
|
83
|
+
session-url-log, plus INTENT (9-section standard), CHANGELOG, README,
|
|
84
|
+
LICENSE (Apache-2.0) + NOTICE; source-verification.json is the build provenance data
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
Dogfooding this repo under Claude Code uses a local `.claude/` (subagent defs, a `/run-workflow` command, a pytest hook). Per repo convention `.claude/` is gitignored, so it does not ship; the canonical role prompts it wraps live in `agents/`, and the CLI is the primary interface.
|
|
88
|
+
|
|
89
|
+
## Requirements
|
|
90
|
+
|
|
91
|
+
Python 3.11+ and PyYAML (installed by `pip install -e .`). The stdlib-only model adapters need no vendor SDK. The OS sandbox uses native macOS `sandbox-exec` when it can actually apply a Seatbelt profile; on Linux it uses bubblewrap, firejail, or docker (in that order of preference). Every backend is admitted only after a startup smoke test proves it can confine here; a present-but-unusable backend, and any platform with none (Windows), fails closed so shell-using workflows are blocked rather than run unconfined (see [SECURITY.md](SECURITY.md)).
|
|
92
|
+
|
|
93
|
+
Live provider scorecards are opt-in and never part of the default no-network suite. With credentials and a local endpoint configured, run:
|
|
94
|
+
```bash
|
|
95
|
+
HARNESSIE_LIVE=1 \
|
|
96
|
+
HARNESSIE_OPENAI_COMPAT_BASE_URL=http://localhost:11434/v1 \
|
|
97
|
+
python3 -m harness.cli eval --live
|
|
98
|
+
```
|
|
99
|
+
Without `HARNESSIE_LIVE=1` or provider configuration, the live scorecard reports explicit `SKIP` rows and exits cleanly.
|
|
100
|
+
|
|
101
|
+
## Design in one breath
|
|
102
|
+
|
|
103
|
+
Goal enters, orchestrator (frontier, high effort) decomposes it into task packets with acceptance criteria and out-of-scope fences; task packets are offers, and workers consent (or decline with a counter-proposal) before side-effecting tools unlock; workers (cheap tiers) execute inside a jailed workspace with allowlisted tools, owning the files they create and never each other's; every worker phase exits through a gate that runs deterministic checks first, then an independent fresh-context verifier that never sees the worker's reasoning and fails closed; contested decisions fan out to an adversarial panel whose positions, objections, and dissent land in a decision record only a human may arbitrate; failures reformulate the task with evidence and escalate effort-then-tier before halting for a human; everything is journaled, budgeted, resumable, hash-chain audited, and leaves proof artifacts on disk.
|
|
104
|
+
|
|
105
|
+
For long runs, approval-gated tools can be authorized by a small headless policy file:
|
|
106
|
+
```yaml
|
|
107
|
+
allow:
|
|
108
|
+
- tool: expire_fact
|
|
109
|
+
phase: triage
|
|
110
|
+
deny:
|
|
111
|
+
- tool: deploy
|
|
112
|
+
```
|
|
113
|
+
Run with `--approval-policy approvals.yaml`, or use `--approve-interactive` to prompt on a TTY. Independent phases can fan out by sharing a `parallel:` label; each runs under `workspace/.phases/<phase>` and gates independently before later phases see its report.
|
|
114
|
+
|
|
115
|
+
Optional extra review can use local OpenAI-compatible endpoints such as Ollama or CLI fan-out across agents. That is useful evidence, especially for patches touching orchestration, but it does not replace the deterministic suite: `pytest`, `harnessie eval`, manifest verification, and scrub/audit checks remain the proof surface.
|
|
116
|
+
|
|
117
|
+
Full rationale and the verified source-to-decision map: [ARCHITECTURE.md](ARCHITECTURE.md). Governance layer (consent, ownership, contest, audit): [GOVERNANCE.md](GOVERNANCE.md). Prompt-injection and secret-handling model: [SECURITY.md](SECURITY.md). The "safest" claim as a falsifiable table, each row citing enforcing code and its test, versus prevailing harness patterns: [docs/threat-model.md](docs/threat-model.md). What comes next and platform support: [ROADMAP.md](ROADMAP.md).
|
|
118
|
+
|
|
119
|
+
## What governs a run
|
|
120
|
+
|
|
121
|
+
A run's behavior is not in one file; each decision has one owner. To predict or change what a run will do, edit the owner, not the prompt:
|
|
122
|
+
|
|
123
|
+
| Decision | Governed by |
|
|
124
|
+
|---|---|
|
|
125
|
+
| Which model runs each task class, and how to swap brains | `config/models.yaml` (tiers + routing table) |
|
|
126
|
+
| Token and dollar ceilings, effort per task class | `config/models.yaml` (budget + routing) |
|
|
127
|
+
| Which phases run, in what order, with which gates and verifiers | the workflow YAML in `workflows/` |
|
|
128
|
+
| Which files each agent may write | `OWNERSHIP.yaml` (lanes + first-writer claims) |
|
|
129
|
+
| What each role may do (tools, shell allowlist, approval) | the tool registry (`harness/tools/builtin.py`) + role prompts in `agents/` |
|
|
130
|
+
|
|
131
|
+
## When a run halts
|
|
132
|
+
|
|
133
|
+
Silence is never success: every run ends in a named stop condition, and each maps to one operator action. Resuming is `harnessie run <same workflow> --goal ...` with the same run id: resume re-runs only phases that did not pass, so fixing the cause and re-running is safe.
|
|
134
|
+
|
|
135
|
+
| Stop condition | What it means | What to do |
|
|
136
|
+
|---|---|---|
|
|
137
|
+
| `complete` / phase `passed` | task done, gate satisfied | nothing; the next phase proceeds |
|
|
138
|
+
| `declined` | the worker declined the offered task packet | read the counter-proposal in the report; revise the packet or accept the objection, then re-run |
|
|
139
|
+
| `needs_human` | a gate's checks or verifier failed after the retry ladder exhausted | read the proof artifacts under `runs/<id>/proofs/` and the report; fix the task or the acceptance criteria; re-run |
|
|
140
|
+
| `needs_arbitration` | a contested phase produced dissent | open `runs/<id>/decisions/DR-<phase>.md`, record your arbitration decision in it, then re-run (resume keys on that record) |
|
|
141
|
+
| `stuck` | the model repeated an identical failing or refused call | inspect the refusal (`harnessie audit <id>`); fix the tool grant, allowlist, or task; re-run |
|
|
142
|
+
| `budget` | the run hit its token or dollar ceiling | raise the ceiling in `config/models.yaml` or narrow the goal; re-run |
|
|
143
|
+
| `max_steps` | the loop hit its step ceiling without completing | raise `max_steps` for the phase or simplify the task |
|
|
144
|
+
| `model_error` | the provider errored twice in a row | check the endpoint and API key; re-run |
|
|
145
|
+
| `no_action` | the model produced no tool call even after a nudge | usually a role-prompt or model-fit issue; check the role prompt in `agents/` |
|
|
146
|
+
|
|
147
|
+
## Built on open standards
|
|
148
|
+
|
|
149
|
+
Harnessie's governance mechanics are code-enforced imports of two open, vendor-neutral standards, and the design philosophy beneath both:
|
|
150
|
+
|
|
151
|
+
- [Turnfile](https://turnfile.work/): consent-based coordination, ownership lanes, authority order, and bounded rebuttal became the task-packet offer contract, `OWNERSHIP.yaml`, and the objection rounds in contested phases.
|
|
152
|
+
- [AIDR](https://aidr.work/): the decision-record lifecycle, preserved dissent, human-only arbitration, and structurally earned claims became the contested-phase records in `decisions/` and `runs/<id>/decisions/`. This repo dogfoods AIDR for its own direction decisions.
|
|
153
|
+
- [The Aggregated Intelligence tenets](https://paice.foundation/papers/aggregated-intelligence-tenets.html): intelligence lives in the arrangement, not the node; disagreement is the engine, not the exhaust; independence before influence; consensus is evidence, never authority; authority is human because accountability is human. The full tenet-to-mechanism mapping is [GOVERNANCE.md](GOVERNANCE.md) §7.
|
|
154
|
+
|
|
155
|
+
These are lesson imports, not conformance claims: Harnessie asserts no Turnfile or AIDR conformance. If the harness makes you ask why its rules work, those standards are the answer.
|
|
156
|
+
|
|
157
|
+
## Contributing
|
|
158
|
+
|
|
159
|
+
See [CONTRIBUTING.md](CONTRIBUTING.md) for setup, the eval-first change discipline, and how consequential decisions are recorded. Bug and feature templates live under [.github/](.github/).
|
|
160
|
+
|
|
161
|
+
## License
|
|
162
|
+
|
|
163
|
+
Apache-2.0. See [LICENSE](LICENSE) and [NOTICE](NOTICE) (copyright Snap Synapse LLC; trademark and PAICE.work PBC spec/code carveouts).
|
|
@@ -0,0 +1,145 @@
|
|
|
1
|
+
# Harnessie
|
|
2
|
+
|
|
3
|
+
A brain-agnostic multi-agent harness: orchestrator, swappable workers, independent verifiers, verification gates between every phase, consent-based orchestration, per-agent file ownership, adversarial decision records with human-only arbitration, self-maintaining project memory with stamped provenance and dated expiry, cost routing as declared config, and a tamper-evident audit log that records operator and agent actions in one composite timeline.
|
|
4
|
+
|
|
5
|
+
Harnessie is built to be the safest and easiest first AI harness for people. "Safest" is not a slogan here; it is a set of checkable properties: guarantees live in code, not prompts ([GOVERNANCE.md](GOVERNANCE.md)); every control that cannot be enforced fails closed instead of running unenforced; nothing ships on an agent's say-so (independent fresh-context verifiers gate every side-effecting phase); an OS sandbox confines shell work; a seven-layer prompt-injection defense with a written threat model ([SECURITY.md](SECURITY.md)) covers the rest; and a hash-chained audit log records every agent and operator action in one tamper-evident timeline. If you find a way to break any of these claims, that is a bug report we want. "Easiest" means the person running it does not need to be a developer: runs carry declared token and dollar ceilings, every halt is a named condition with one plain operator action, and disagreement between agents becomes a human decision, never a silent merge.
|
|
6
|
+
|
|
7
|
+
The operating thesis: the harness structure carries the quality floor, the model carries the ceiling. Run it with Claude Fable 5 as the orchestrator and it exploits effort dials, long autonomous turns, and verifier subagents. Swap the workers (or everything) for Haiku, GLM, Qwen, or any OpenAI-compatible local endpoint by editing one YAML file, and the gates, jails, budgets, and retry ladders keep output honest.
|
|
8
|
+
|
|
9
|
+
Beneath that thesis sit five engineering habits, each proven separately in the author's other tools and standards before it landed here as code: deterministic checks run before any model judgment (the gate order in [docs/GUIDE.md](docs/GUIDE.md)); evaluation comes before implementation — a governance mechanic without a red-then-green scenario pair does not merge ([EVALS.md](EVALS.md)); remembered facts carry verified and verify-by dates and expire visibly, never silently ([GOVERNANCE.md](GOVERNANCE.md)); every agent and operator action lands in one hash-chained, tamper-evident timeline ([docs/threat-model.md](docs/threat-model.md)); and any control that cannot be enforced fails closed rather than running unenforced ([SECURITY.md](SECURITY.md)). The same habits produced the standards Harnessie adopts — [Turnfile](https://turnfile.work/), [AIDR](https://aidr.work/), [Graceful Boundaries](https://gracefulboundaries.dev/) — which is why they fit together.
|
|
10
|
+
|
|
11
|
+
## Quick start
|
|
12
|
+
|
|
13
|
+
```bash
|
|
14
|
+
pip install -e ".[dev]"
|
|
15
|
+
python3 -m pytest -q # mock brain, no network
|
|
16
|
+
python3 -m harness.cli eval # deterministic eval scorecard
|
|
17
|
+
python3 -m harness.cli verify-manifest
|
|
18
|
+
export ANTHROPIC_API_KEY=sk-ant-... # or point tiers at a local endpoint
|
|
19
|
+
python3 -m harness.cli run workflows/build-and-verify.yaml --goal "a CLI todo app with tests"
|
|
20
|
+
python3 -m harness.cli report <run_id>
|
|
21
|
+
python3 -m harness.cli audit <run_id> # verify the hash chain + governance timeline
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
Installed CLI usage can scaffold a fresh project layout:
|
|
25
|
+
```bash
|
|
26
|
+
harnessie init my-harnessie-project
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
Worked end-to-end example with sample data: [examples/policy-compliance/README.md](examples/policy-compliance/README.md).
|
|
30
|
+
|
|
31
|
+
## Documentation
|
|
32
|
+
|
|
33
|
+
- [docs/quickstart.md](docs/quickstart.md): the gentlest path for someone who has never cloned a repo or written YAML, assuming no git or shell fluency, with a glossary and an honest Windows/WSL2 page.
|
|
34
|
+
- [docs/getting-started.md](docs/getting-started.md): the five-minute path from install to a green run and reading the evidence.
|
|
35
|
+
- [docs/GUIDE.md](docs/GUIDE.md): the complete user guide, concepts through extension, including workflow authoring, brain configuration, ownership, governance, and the halt-recovery table.
|
|
36
|
+
- [docs/brains.md](docs/brains.md): the brain-agnostic receipt, the models actually run under the harness with a link to the record that proves each.
|
|
37
|
+
- [assistant-guide.txt](assistant-guide.txt): a bounded, human-verifiable guide (GuideCheck Level 3 profile) for an assistant reviewing a Harnessie checkout before you authorize a run; served at [harnessie.com/.well-known/assistant-guide.txt](https://harnessie.com/.well-known/assistant-guide.txt) with a sidecar manifest for provenance.
|
|
38
|
+
|
|
39
|
+
The engineering references below (ARCHITECTURE, GOVERNANCE, SECURITY, ROADMAP) sit at the repo root; the user-facing guides live under `docs/`.
|
|
40
|
+
|
|
41
|
+
## Layout
|
|
42
|
+
|
|
43
|
+
```text
|
|
44
|
+
harness/ the runtime: models/ tools/ loop verify routing memory state roles quarantine
|
|
45
|
+
sandbox ownership adversarial audit runner cli events
|
|
46
|
+
agents/ role prompts (markdown): orchestrator.md, workers/, verifiers/
|
|
47
|
+
workflows/ declared phase sequences (YAML) with per-phase gates, task classes, and
|
|
48
|
+
adversarial contested phases (mode: adversarial)
|
|
49
|
+
config/models.yaml model tiers, routing table, budgets: the ONLY file to edit to swap brains
|
|
50
|
+
OWNERSHIP.yaml ownership lanes + first-writer auto-claims; operator-owned, agents cannot reach it
|
|
51
|
+
decisions/ the repo's own AIDR decision records (AIDR-0001 = v0.2 direction,
|
|
52
|
+
AIDR-0002 = v0.3 direction; both human-arbitrated 2026-07-06
|
|
53
|
+
with independent positions from four providers)
|
|
54
|
+
memory/ project memory: MEMORY.md index + facts/ (stamped provenance, verify_by
|
|
55
|
+
expiry) + archive/ (expired facts; nothing deletes) — maintained by
|
|
56
|
+
workflows/memory-triage.yaml under approval gates
|
|
57
|
+
examples/ worked end-to-end example (policy-compliance) with sample data
|
|
58
|
+
runs/ per-run journal.jsonl (resume ledger) + events.jsonl (hash-chained audit)
|
|
59
|
+
+ proofs/ + decisions/ (contested-phase records) (gitignored)
|
|
60
|
+
evals/ deterministic scorecards over mock-brain golden/risky/recovery scenarios
|
|
61
|
+
docs/MANIFEST.yaml trust-bundle integrity manifest for machine-readable public artifacts
|
|
62
|
+
tests/ the done-tests for every subsystem
|
|
63
|
+
docs/ reserved for the canonical web page (GitHub Pages publish source once public)
|
|
64
|
+
*.md at root ARCHITECTURE, GOVERNANCE, SECURITY, ROADMAP, IMPLEMENTATION_PLAN, PROMPTS, EVALS, NEXT,
|
|
65
|
+
session-url-log, plus INTENT (9-section standard), CHANGELOG, README,
|
|
66
|
+
LICENSE (Apache-2.0) + NOTICE; source-verification.json is the build provenance data
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
Dogfooding this repo under Claude Code uses a local `.claude/` (subagent defs, a `/run-workflow` command, a pytest hook). Per repo convention `.claude/` is gitignored, so it does not ship; the canonical role prompts it wraps live in `agents/`, and the CLI is the primary interface.
|
|
70
|
+
|
|
71
|
+
## Requirements
|
|
72
|
+
|
|
73
|
+
Python 3.11+ and PyYAML (installed by `pip install -e .`). The stdlib-only model adapters need no vendor SDK. The OS sandbox uses native macOS `sandbox-exec` when it can actually apply a Seatbelt profile; on Linux it uses bubblewrap, firejail, or docker (in that order of preference). Every backend is admitted only after a startup smoke test proves it can confine here; a present-but-unusable backend, and any platform with none (Windows), fails closed so shell-using workflows are blocked rather than run unconfined (see [SECURITY.md](SECURITY.md)).
|
|
74
|
+
|
|
75
|
+
Live provider scorecards are opt-in and never part of the default no-network suite. With credentials and a local endpoint configured, run:
|
|
76
|
+
```bash
|
|
77
|
+
HARNESSIE_LIVE=1 \
|
|
78
|
+
HARNESSIE_OPENAI_COMPAT_BASE_URL=http://localhost:11434/v1 \
|
|
79
|
+
python3 -m harness.cli eval --live
|
|
80
|
+
```
|
|
81
|
+
Without `HARNESSIE_LIVE=1` or provider configuration, the live scorecard reports explicit `SKIP` rows and exits cleanly.
|
|
82
|
+
|
|
83
|
+
## Design in one breath
|
|
84
|
+
|
|
85
|
+
Goal enters, orchestrator (frontier, high effort) decomposes it into task packets with acceptance criteria and out-of-scope fences; task packets are offers, and workers consent (or decline with a counter-proposal) before side-effecting tools unlock; workers (cheap tiers) execute inside a jailed workspace with allowlisted tools, owning the files they create and never each other's; every worker phase exits through a gate that runs deterministic checks first, then an independent fresh-context verifier that never sees the worker's reasoning and fails closed; contested decisions fan out to an adversarial panel whose positions, objections, and dissent land in a decision record only a human may arbitrate; failures reformulate the task with evidence and escalate effort-then-tier before halting for a human; everything is journaled, budgeted, resumable, hash-chain audited, and leaves proof artifacts on disk.
|
|
86
|
+
|
|
87
|
+
For long runs, approval-gated tools can be authorized by a small headless policy file:
|
|
88
|
+
```yaml
|
|
89
|
+
allow:
|
|
90
|
+
- tool: expire_fact
|
|
91
|
+
phase: triage
|
|
92
|
+
deny:
|
|
93
|
+
- tool: deploy
|
|
94
|
+
```
|
|
95
|
+
Run with `--approval-policy approvals.yaml`, or use `--approve-interactive` to prompt on a TTY. Independent phases can fan out by sharing a `parallel:` label; each runs under `workspace/.phases/<phase>` and gates independently before later phases see its report.
|
|
96
|
+
|
|
97
|
+
Optional extra review can use local OpenAI-compatible endpoints such as Ollama or CLI fan-out across agents. That is useful evidence, especially for patches touching orchestration, but it does not replace the deterministic suite: `pytest`, `harnessie eval`, manifest verification, and scrub/audit checks remain the proof surface.
|
|
98
|
+
|
|
99
|
+
Full rationale and the verified source-to-decision map: [ARCHITECTURE.md](ARCHITECTURE.md). Governance layer (consent, ownership, contest, audit): [GOVERNANCE.md](GOVERNANCE.md). Prompt-injection and secret-handling model: [SECURITY.md](SECURITY.md). The "safest" claim as a falsifiable table, each row citing enforcing code and its test, versus prevailing harness patterns: [docs/threat-model.md](docs/threat-model.md). What comes next and platform support: [ROADMAP.md](ROADMAP.md).
|
|
100
|
+
|
|
101
|
+
## What governs a run
|
|
102
|
+
|
|
103
|
+
A run's behavior is not in one file; each decision has one owner. To predict or change what a run will do, edit the owner, not the prompt:
|
|
104
|
+
|
|
105
|
+
| Decision | Governed by |
|
|
106
|
+
|---|---|
|
|
107
|
+
| Which model runs each task class, and how to swap brains | `config/models.yaml` (tiers + routing table) |
|
|
108
|
+
| Token and dollar ceilings, effort per task class | `config/models.yaml` (budget + routing) |
|
|
109
|
+
| Which phases run, in what order, with which gates and verifiers | the workflow YAML in `workflows/` |
|
|
110
|
+
| Which files each agent may write | `OWNERSHIP.yaml` (lanes + first-writer claims) |
|
|
111
|
+
| What each role may do (tools, shell allowlist, approval) | the tool registry (`harness/tools/builtin.py`) + role prompts in `agents/` |
|
|
112
|
+
|
|
113
|
+
## When a run halts
|
|
114
|
+
|
|
115
|
+
Silence is never success: every run ends in a named stop condition, and each maps to one operator action. Resuming is `harnessie run <same workflow> --goal ...` with the same run id: resume re-runs only phases that did not pass, so fixing the cause and re-running is safe.
|
|
116
|
+
|
|
117
|
+
| Stop condition | What it means | What to do |
|
|
118
|
+
|---|---|---|
|
|
119
|
+
| `complete` / phase `passed` | task done, gate satisfied | nothing; the next phase proceeds |
|
|
120
|
+
| `declined` | the worker declined the offered task packet | read the counter-proposal in the report; revise the packet or accept the objection, then re-run |
|
|
121
|
+
| `needs_human` | a gate's checks or verifier failed after the retry ladder exhausted | read the proof artifacts under `runs/<id>/proofs/` and the report; fix the task or the acceptance criteria; re-run |
|
|
122
|
+
| `needs_arbitration` | a contested phase produced dissent | open `runs/<id>/decisions/DR-<phase>.md`, record your arbitration decision in it, then re-run (resume keys on that record) |
|
|
123
|
+
| `stuck` | the model repeated an identical failing or refused call | inspect the refusal (`harnessie audit <id>`); fix the tool grant, allowlist, or task; re-run |
|
|
124
|
+
| `budget` | the run hit its token or dollar ceiling | raise the ceiling in `config/models.yaml` or narrow the goal; re-run |
|
|
125
|
+
| `max_steps` | the loop hit its step ceiling without completing | raise `max_steps` for the phase or simplify the task |
|
|
126
|
+
| `model_error` | the provider errored twice in a row | check the endpoint and API key; re-run |
|
|
127
|
+
| `no_action` | the model produced no tool call even after a nudge | usually a role-prompt or model-fit issue; check the role prompt in `agents/` |
|
|
128
|
+
|
|
129
|
+
## Built on open standards
|
|
130
|
+
|
|
131
|
+
Harnessie's governance mechanics are code-enforced imports of two open, vendor-neutral standards, and the design philosophy beneath both:
|
|
132
|
+
|
|
133
|
+
- [Turnfile](https://turnfile.work/): consent-based coordination, ownership lanes, authority order, and bounded rebuttal became the task-packet offer contract, `OWNERSHIP.yaml`, and the objection rounds in contested phases.
|
|
134
|
+
- [AIDR](https://aidr.work/): the decision-record lifecycle, preserved dissent, human-only arbitration, and structurally earned claims became the contested-phase records in `decisions/` and `runs/<id>/decisions/`. This repo dogfoods AIDR for its own direction decisions.
|
|
135
|
+
- [The Aggregated Intelligence tenets](https://paice.foundation/papers/aggregated-intelligence-tenets.html): intelligence lives in the arrangement, not the node; disagreement is the engine, not the exhaust; independence before influence; consensus is evidence, never authority; authority is human because accountability is human. The full tenet-to-mechanism mapping is [GOVERNANCE.md](GOVERNANCE.md) §7.
|
|
136
|
+
|
|
137
|
+
These are lesson imports, not conformance claims: Harnessie asserts no Turnfile or AIDR conformance. If the harness makes you ask why its rules work, those standards are the answer.
|
|
138
|
+
|
|
139
|
+
## Contributing
|
|
140
|
+
|
|
141
|
+
See [CONTRIBUTING.md](CONTRIBUTING.md) for setup, the eval-first change discipline, and how consequential decisions are recorded. Bug and feature templates live under [.github/](.github/).
|
|
142
|
+
|
|
143
|
+
## License
|
|
144
|
+
|
|
145
|
+
Apache-2.0. See [LICENSE](LICENSE) and [NOTICE](NOTICE) (copyright Snap Synapse LLC; trademark and PAICE.work PBC spec/code carveouts).
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
"""Harnessie, a brain-agnostic multi-agent harness.
|
|
2
|
+
|
|
3
|
+
Subsystem map (each module is one explicit boundary):
|
|
4
|
+
|
|
5
|
+
models/ ModelInterface + provider adapters (Anthropic, OpenAI-compatible, mock)
|
|
6
|
+
tools/ ToolRegistry: single source of truth for capabilities AND policy
|
|
7
|
+
loop.py AgentLoop: goal -> context -> model -> permission gate -> tool -> repeat
|
|
8
|
+
verify.py VerificationGate: deterministic checks + model verifier + retry ladder
|
|
9
|
+
routing.py Routing policy: task tier -> (model, effort), escalation ladder, budgets
|
|
10
|
+
memory.py Project memory (markdown facts w/ provenance) + proof artifacts
|
|
11
|
+
state.py Run journal (JSONL) for resumability and audit
|
|
12
|
+
roles.py Role definitions (orchestrator / worker / verifier) loaded from agents/
|
|
13
|
+
quarantine.py Prompt-injection ingress filter + secret detection/redaction
|
|
14
|
+
sandbox.py OS confinement of child commands (workspace-only writes, network deny)
|
|
15
|
+
ownership.py Ownership lanes: agents own their files, never each other's
|
|
16
|
+
adversarial.py Contested phases: positions, objections, decision records, lint
|
|
17
|
+
audit.py Hash-chain verification + governance timeline for any run
|
|
18
|
+
runner.py WorkflowRunner: executes workflows/*.yaml phase by phase through gates
|
|
19
|
+
events.py Structured, hash-chained event log shared by everything above
|
|
20
|
+
|
|
21
|
+
Security model: SECURITY.md. Architecture and source map: ARCHITECTURE.md.
|
|
22
|
+
Governance layer (consent, ownership, contest, audit): GOVERNANCE.md.
|
|
23
|
+
"""
|
|
24
|
+
|
|
25
|
+
__version__ = "0.5.0"
|