harneloop 0.0.2__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 (42) hide show
  1. harneloop-0.0.2/LICENSE +201 -0
  2. harneloop-0.0.2/PKG-INFO +424 -0
  3. harneloop-0.0.2/README.md +399 -0
  4. harneloop-0.0.2/pyproject.toml +39 -0
  5. harneloop-0.0.2/setup.cfg +4 -0
  6. harneloop-0.0.2/src/harneloop/__init__.py +3 -0
  7. harneloop-0.0.2/src/harneloop/__main__.py +5 -0
  8. harneloop-0.0.2/src/harneloop/adapters.py +76 -0
  9. harneloop-0.0.2/src/harneloop/attempts.py +259 -0
  10. harneloop-0.0.2/src/harneloop/candidate.py +216 -0
  11. harneloop-0.0.2/src/harneloop/cli.py +635 -0
  12. harneloop-0.0.2/src/harneloop/diagnostics.py +65 -0
  13. harneloop-0.0.2/src/harneloop/environment.py +191 -0
  14. harneloop-0.0.2/src/harneloop/errors.py +2 -0
  15. harneloop-0.0.2/src/harneloop/evidence.py +133 -0
  16. harneloop-0.0.2/src/harneloop/intake.py +163 -0
  17. harneloop-0.0.2/src/harneloop/interactive.py +379 -0
  18. harneloop-0.0.2/src/harneloop/locking.py +52 -0
  19. harneloop-0.0.2/src/harneloop/onboarding.py +176 -0
  20. harneloop-0.0.2/src/harneloop/operational_map.py +119 -0
  21. harneloop-0.0.2/src/harneloop/packaging.py +48 -0
  22. harneloop-0.0.2/src/harneloop/paths.py +56 -0
  23. harneloop-0.0.2/src/harneloop/preferences.py +209 -0
  24. harneloop-0.0.2/src/harneloop/runs.py +177 -0
  25. harneloop-0.0.2/src/harneloop/setup_flow.py +229 -0
  26. harneloop-0.0.2/src/harneloop/state.py +308 -0
  27. harneloop-0.0.2/src/harneloop/target.py +93 -0
  28. harneloop-0.0.2/src/harneloop/templates.py +102 -0
  29. harneloop-0.0.2/src/harneloop/unit.py +154 -0
  30. harneloop-0.0.2/src/harneloop/validation.py +46 -0
  31. harneloop-0.0.2/src/harneloop/versioning.py +264 -0
  32. harneloop-0.0.2/src/harneloop/yamlio.py +41 -0
  33. harneloop-0.0.2/src/harneloop.egg-info/PKG-INFO +424 -0
  34. harneloop-0.0.2/src/harneloop.egg-info/SOURCES.txt +40 -0
  35. harneloop-0.0.2/src/harneloop.egg-info/dependency_links.txt +1 -0
  36. harneloop-0.0.2/src/harneloop.egg-info/entry_points.txt +2 -0
  37. harneloop-0.0.2/src/harneloop.egg-info/requires.txt +4 -0
  38. harneloop-0.0.2/src/harneloop.egg-info/top_level.txt +1 -0
  39. harneloop-0.0.2/tests/test_concurrency.py +99 -0
  40. harneloop-0.0.2/tests/test_core_lifecycle.py +861 -0
  41. harneloop-0.0.2/tests/test_repo_structure.py +63 -0
  42. harneloop-0.0.2/tests/test_user_cli_support.py +255 -0
@@ -0,0 +1,201 @@
1
+ Apache License
2
+ Version 2.0, January 2004
3
+ http://www.apache.org/licenses/
4
+
5
+ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
6
+
7
+ 1. Definitions.
8
+
9
+ "License" shall mean the terms and conditions for use, reproduction,
10
+ and distribution as defined by Sections 1 through 9 of this document.
11
+
12
+ "Licensor" shall mean the copyright owner or entity authorized by
13
+ the copyright owner that is granting the License.
14
+
15
+ "Legal Entity" shall mean the union of the acting entity and all
16
+ other entities that control, are controlled by, or are under common
17
+ control with that entity. For the purposes of this definition,
18
+ "control" means (i) the power, direct or indirect, to cause the
19
+ direction or management of such entity, whether by contract or
20
+ otherwise, or (ii) ownership of fifty percent (50%) or more of the
21
+ outstanding shares, or (iii) beneficial ownership of such entity.
22
+
23
+ "You" (or "Your") shall mean an individual or Legal Entity
24
+ exercising permissions granted by this License.
25
+
26
+ "Source" form shall mean the preferred form for making modifications,
27
+ including but not limited to software source code, documentation
28
+ source, and configuration files.
29
+
30
+ "Object" form shall mean any form resulting from mechanical
31
+ transformation or translation of a Source form, including but
32
+ not limited to compiled object code, generated documentation,
33
+ and conversions to other media types.
34
+
35
+ "Work" shall mean the work of authorship, whether in Source or
36
+ Object form, made available under the License, as indicated by a
37
+ copyright notice that is included in or attached to the work
38
+ (an example is provided in the Appendix below).
39
+
40
+ "Derivative Works" shall mean any work, whether in Source or Object
41
+ form, that is based on (or derived from) the Work and for which the
42
+ editorial revisions, annotations, elaborations, or other modifications
43
+ represent, as a whole, an original work of authorship. For the purposes
44
+ of this License, Derivative Works shall not include works that remain
45
+ separable from, or merely link (or bind by name) to the interfaces of,
46
+ the Work and Derivative Works thereof.
47
+
48
+ "Contribution" shall mean any work of authorship, including
49
+ the original version of the Work and any modifications or additions
50
+ to that Work or Derivative Works thereof, that is intentionally
51
+ submitted to Licensor for inclusion in the Work by the copyright owner
52
+ or by an individual or Legal Entity authorized to submit on behalf of
53
+ the copyright owner. For the purposes of this definition, "submitted"
54
+ means any form of electronic, verbal, or written communication sent
55
+ to the Licensor or its representatives, including but not limited to
56
+ communication on electronic mailing lists, source code control systems,
57
+ and issue tracking systems that are managed by, or on behalf of, the
58
+ Licensor for the purpose of discussing and improving the Work, but
59
+ excluding communication that is conspicuously marked or otherwise
60
+ designated in writing by the copyright owner as "Not a Contribution."
61
+
62
+ "Contributor" shall mean Licensor and any individual or Legal Entity
63
+ on behalf of whom a Contribution has been received by Licensor and
64
+ subsequently incorporated within the Work.
65
+
66
+ 2. Grant of Copyright License. Subject to the terms and conditions of
67
+ this License, each Contributor hereby grants to You a perpetual,
68
+ worldwide, non-exclusive, no-charge, royalty-free, irrevocable
69
+ copyright license to reproduce, prepare Derivative Works of,
70
+ publicly display, publicly perform, sublicense, and distribute the
71
+ Work and such Derivative Works in Source or Object form.
72
+
73
+ 3. Grant of Patent License. Subject to the terms and conditions of
74
+ this License, each Contributor hereby grants to You a perpetual,
75
+ worldwide, non-exclusive, no-charge, royalty-free, irrevocable
76
+ (except as stated in this section) patent license to make, have made,
77
+ use, offer to sell, sell, import, and otherwise transfer the Work,
78
+ where such license applies only to those patent claims licensable
79
+ by such Contributor that are necessarily infringed by their
80
+ Contribution(s) alone or by combination of their Contribution(s)
81
+ with the Work to which such Contribution(s) was submitted. If You
82
+ institute patent litigation against any entity (including a
83
+ cross-claim or counterclaim in a lawsuit) alleging that the Work
84
+ or a Contribution incorporated within the Work constitutes direct
85
+ or contributory patent infringement, then any patent licenses
86
+ granted to You under this License for that Work shall terminate
87
+ as of the date such litigation is filed.
88
+
89
+ 4. Redistribution. You may reproduce and distribute copies of the
90
+ Work or Derivative Works thereof in any medium, with or without
91
+ modifications, and in Source or Object form, provided that You
92
+ meet the following conditions:
93
+
94
+ (a) You must give any other recipients of the Work or
95
+ Derivative Works a copy of this License; and
96
+
97
+ (b) You must cause any modified files to carry prominent notices
98
+ stating that You changed the files; and
99
+
100
+ (c) You must retain, in the Source form of any Derivative Works
101
+ that You distribute, all copyright, patent, trademark, and
102
+ attribution notices from the Source form of the Work,
103
+ excluding those notices that do not pertain to any part of
104
+ the Derivative Works; and
105
+
106
+ (d) If the Work includes a "NOTICE" text file as part of its
107
+ distribution, then any Derivative Works that You distribute must
108
+ include a readable copy of the attribution notices contained
109
+ within such NOTICE file, excluding those notices that do not
110
+ pertain to any part of the Derivative Works, in at least one
111
+ of the following places: within a NOTICE text file distributed
112
+ as part of the Derivative Works; within the Source form or
113
+ documentation, if provided along with the Derivative Works; or,
114
+ within a display generated by the Derivative Works, if and
115
+ wherever such third-party notices normally appear. The contents
116
+ of the NOTICE file are for informational purposes only and
117
+ do not modify the License. You may add Your own attribution
118
+ notices within Derivative Works that You distribute, alongside
119
+ or as an addendum to the NOTICE text from the Work, provided
120
+ that such additional attribution notices cannot be construed
121
+ as modifying the License.
122
+
123
+ You may add Your own copyright statement to Your modifications and
124
+ may provide additional or different license terms and conditions
125
+ for use, reproduction, or distribution of Your modifications, or
126
+ for any such Derivative Works as a whole, provided Your use,
127
+ reproduction, and distribution of the Work otherwise complies with
128
+ the conditions stated in this License.
129
+
130
+ 5. Submission of Contributions. Unless You explicitly state otherwise,
131
+ any Contribution intentionally submitted for inclusion in the Work
132
+ by You to the Licensor shall be under the terms and conditions of
133
+ this License, without any additional terms or conditions.
134
+ Notwithstanding the above, nothing herein shall supersede or modify
135
+ the terms of any separate license agreement you may have executed
136
+ with Licensor regarding such Contributions.
137
+
138
+ 6. Trademarks. This License does not grant permission to use the trade
139
+ names, trademarks, service marks, or product names of the Licensor,
140
+ except as required for reasonable and customary use in describing the
141
+ origin of the Work and reproducing the content of the NOTICE file.
142
+
143
+ 7. Disclaimer of Warranty. Unless required by applicable law or
144
+ agreed to in writing, Licensor provides the Work (and each
145
+ Contributor provides its Contributions) on an "AS IS" BASIS,
146
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
147
+ implied, including, without limitation, any warranties or conditions
148
+ of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
149
+ PARTICULAR PURPOSE. You are solely responsible for determining the
150
+ appropriateness of using or redistributing the Work and assume any
151
+ risks associated with Your exercise of permissions under this License.
152
+
153
+ 8. Limitation of Liability. In no event and under no legal theory,
154
+ whether in tort (including negligence), contract, or otherwise,
155
+ unless required by applicable law (such as deliberate and grossly
156
+ negligent acts) or agreed to in writing, shall any Contributor be
157
+ liable to You for damages, including any direct, indirect, special,
158
+ incidental, or consequential damages of any character arising as a
159
+ result of this License or out of the use or inability to use the
160
+ Work (including but not limited to damages for loss of goodwill,
161
+ work stoppage, computer failure or malfunction, or any and all
162
+ other commercial damages or losses), even if such Contributor
163
+ has been advised of the possibility of such damages.
164
+
165
+ 9. Accepting Warranty or Additional Liability. While redistributing
166
+ the Work or Derivative Works thereof, You may choose to offer,
167
+ and charge a fee for, acceptance of support, warranty, indemnity,
168
+ or other liability obligations and/or rights consistent with this
169
+ License. However, in accepting such obligations, You may act only
170
+ on Your own behalf and on Your sole responsibility, not on behalf
171
+ of any other Contributor, and only if You agree to indemnify,
172
+ defend, and hold each Contributor harmless for any liability
173
+ incurred by, or claims asserted against, such Contributor by reason
174
+ of your accepting any such warranty or additional liability.
175
+
176
+ END OF TERMS AND CONDITIONS
177
+
178
+ APPENDIX: How to apply the Apache License to your work.
179
+
180
+ To apply the Apache License to your work, attach the following
181
+ boilerplate notice, with the fields enclosed by brackets "[]"
182
+ replaced with your own identifying information. (Don't include
183
+ the brackets!) The text should be enclosed in the appropriate
184
+ comment syntax for the file format. We also recommend that a
185
+ file or class name and description of purpose be included on the
186
+ same "printed page" as the copyright notice for easier
187
+ identification within third-party archives.
188
+
189
+ Copyright [yyyy] [name of copyright owner]
190
+
191
+ Licensed under the Apache License, Version 2.0 (the "License");
192
+ you may not use this file except in compliance with the License.
193
+ You may obtain a copy of the License at
194
+
195
+ http://www.apache.org/licenses/LICENSE-2.0
196
+
197
+ Unless required by applicable law or agreed to in writing, software
198
+ distributed under the License is distributed on an "AS IS" BASIS,
199
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
200
+ See the License for the specific language governing permissions and
201
+ limitations under the License.
@@ -0,0 +1,424 @@
1
+ Metadata-Version: 2.4
2
+ Name: harneloop
3
+ Version: 0.0.2
4
+ Summary: Artifact-aware framework for building self-evolving AI agent harnesses.
5
+ Author: Kristofer Jussmann
6
+ License-Expression: Apache-2.0
7
+ Project-URL: Homepage, https://harneloop.kaelux.dev/
8
+ Project-URL: Documentation, https://github.com/Ker102/Harneloop#readme
9
+ Project-URL: Repository, https://github.com/Ker102/Harneloop
10
+ Project-URL: Issues, https://github.com/Ker102/Harneloop/issues
11
+ Project-URL: Changelog, https://github.com/Ker102/Harneloop/releases
12
+ Keywords: ai-agents,agent-harness,artifact-evaluation,llm,self-improving-agents
13
+ Classifier: Development Status :: 3 - Alpha
14
+ Classifier: Environment :: Console
15
+ Classifier: Intended Audience :: Developers
16
+ Classifier: Programming Language :: Python :: 3
17
+ Classifier: Topic :: Software Development :: Testing
18
+ Requires-Python: >=3.11
19
+ Description-Content-Type: text/markdown
20
+ License-File: LICENSE
21
+ Requires-Dist: PyYAML
22
+ Requires-Dist: rich
23
+ Provides-Extra: dev
24
+ Dynamic: license-file
25
+
26
+ # Harneloop
27
+
28
+ Harneloop is an open-source, agent-first framework for building and evolving task-specific AI agent harnesses through artifact-aware testing, trace-backed diagnosis, and evidence-gated promotion.
29
+
30
+ The agent attempts a real task, captures the resulting artifacts, logs, traces, and state, compares the result with the desired outcome, and traces likely mistakes back through the recorded run. It can then propose a candidate change to its instructions, context, tools, retrieval, validators, or environment and test again. The working harness stays unchanged until evidence shows that the candidate improves the target without unacceptable regressions.
31
+
32
+ ## Lifecycle At A Glance
33
+
34
+ ![Harneloop lifecycle: observe the real task and evidence, improve the harness through a candidate, then promote only when improvement is proven](docs/assets/Harneloopvisual.png)
35
+
36
+ Each task-specific development environment is a portable **harness unit** containing its goal, environment map, harness material, experiments, evidence, regression cases, and restorable versions. Agents can reason freely and add what they need inside candidate workspaces; Harneloop structures the lifecycle and protects promotion rather than forcing every task through a fixed script. Units can be paused, moved, continued by another compatible agent or machine, and exported into their target environment.
37
+
38
+ Setup is agent-first: give a capable agent the repository link and describe what you want to improve. It can install Harneloop, onboard itself, inspect or build the testing environment, and create the first harness unit, asking only when important context or permission is missing. A guided manual setup and full CLI are also available.
39
+
40
+ > Harneloop is not another agent runtime or evaluation dashboard. It is the artifact-aware development and versioning layer an agent uses to build a better harness without replacing the working version before an improvement is proven.
41
+
42
+ **Project status:** [v0.0.2 public alpha](https://github.com/Ker102/Harneloop/releases/tag/v0.0.2). The core lifecycle works, but commands and file formats may still change before a stable release.
43
+
44
+ **Contributions are welcome.** Early users can help by testing Harneloop on new task families, reporting failures, improving agent integrations, or contributing focused lifecycle and documentation changes. See [Contributing](#contributing).
45
+
46
+ ## Evidence From A Real Case Study
47
+
48
+ Harneloop was used to develop the custom ViperMesh harness unit for Blender spatial-reasoning and scene-construction tasks. The comparison kept the acting model fixed at **GPT-5.5 High** and tested the evolved ViperMesh harness against the **Anthropic x Blender MCP server baseline**, isolating the harness as the main changed system layer.
49
+
50
+ - ViperMesh was faster on **6 of 7** comparable live tasks, with a **2.534x mean speedup**.
51
+ - Preliminary neutral LLM visual evaluation improved by **8.19 points** across seven live render pairs.
52
+ - Local acting-agent token usage was **90.91% lower** on the documented comparable token pair.
53
+
54
+ Harneloop did not generate the scenes itself. It structured the evidence and artifact loop that exposed weaknesses, guided tool and harness development, and verified whether those changes improved the benchmark. Read the methodology, limitations, and complete results in the [ViperMesh case study](https://www.kristoferjussmann.me/case-studies/vipermesh).
55
+
56
+ These results provide direct empirical evidence that Harneloop's process works in a real, artifact-heavy agent environment: the acting model stayed the same while the evolved harness produced measurable gains in speed, visual performance, and token efficiency.
57
+
58
+ ## Start Here
59
+
60
+ - **Using Harneloop through an agent:** [Agent Quick Start](#agent-quick-start)
61
+ - **Installing it yourself:** [Install And Start](#install-and-start)
62
+ - **Understanding harness units:** [What Is A Harness Unit?](#what-is-a-harness-unit)
63
+ - **Understanding the loop:** [The Lifecycle, Made Simple](#the-lifecycle-made-simple)
64
+ - **Measured proof:** [ViperMesh case study](https://www.kristoferjussmann.me/case-studies/vipermesh)
65
+ - **Connecting a real environment:** [Environment Setup](#environment-setup)
66
+ - **Changing defaults:** [Configuration](#configuration)
67
+ - **Technical architecture:** [Core lifecycle](docs/architecture/core-lifecycle.md), [runtime layers](docs/architecture/runtime-layers.md), and [concurrency](docs/architecture/concurrency.md)
68
+ - **Full agent instructions:** [Agent onboarding](docs/agent-onboarding.md)
69
+ - **Visual process:** [Lifecycle at a glance](#lifecycle-at-a-glance), [editable compact diagram](docs/framework-process-compact.md), and [detailed framework diagram](docs/framework-process.md)
70
+
71
+ ## Why Harneloop Exists
72
+
73
+ Models often repeat the same failures because the useful lessons from one attempt never become a tested part of their working environment. Adding a larger prompt or collecting an evaluation score does not solve the whole problem.
74
+
75
+ The model is only one part of an agent's performance. The harness around it determines what context it sees, which tools it can use, how it interacts with the environment, what it remembers, how results are inspected, and whether mistakes become durable improvements. For many task-specific problems, this makes the harness the highest-leverage improvement surface available: it can produce significant gains without retraining the model, and every change remains inspectable, testable, reversible, and portable.
76
+
77
+ Harneloop makes that work structured and efficient. Instead of accumulating one-off prompt edits, it lets an agent develop multiple independent harness units, test changes through real attempts, preserve evidence and history, and continue or export each successful harness as a coherent package.
78
+
79
+ Harneloop gives the operating agent a controlled improvement loop:
80
+
81
+ - work on the real task rather than only a synthetic benchmark;
82
+ - capture renders, screenshots, files, traces, logs, structured state, or other artifacts;
83
+ - inspect those artifacts visually, structurally, or behaviorally;
84
+ - trace weak results back to instructions, tools, context, retrieval, environment, or model limits;
85
+ - develop improvements as isolated candidate patches;
86
+ - test candidates against new attempts and regression cases;
87
+ - promote only changes supported by valid evidence;
88
+ - preserve restorable versions and package the resulting harness for reuse.
89
+
90
+ The agent is free to reason and experiment inside the harness workspace. Harneloop controls the integrity-sensitive boundaries: records, protected state, evidence, promotion, snapshots, rollback, and packaging.
91
+
92
+ ### Why Improve The Harness Before The Weights?
93
+
94
+ Research across agent interfaces, retrieval, tools, and iterative feedback shows that changing the system around a model can substantially improve task performance without changing the model's weights. In task settings where context, retrieval, tools, feedback, or environment interaction are the main bottlenecks, harness-level methods can outperform fine-tuning, sometimes substantially, while preserving the underlying model's general capabilities. Harneloop grew from practical problems encountered while building agent harnesses; the following work independently supports its harness-first direction:
95
+
96
+ - [Self-Harness](https://arxiv.org/abs/2606.09498) found that agents could mine weaknesses from execution traces, propose harness changes, validate them with regression tests, and improve held-out pass rates across three model families.
97
+ - [SWE-agent](https://arxiv.org/abs/2405.15793) showed that a purpose-built agent-computer interface substantially improved how language models navigated repositories, edited code, and executed tests.
98
+ - [Reflexion](https://arxiv.org/abs/2303.11366) improved agents through trial-and-error, linguistic feedback, and episodic memory rather than weight updates.
99
+ - [Self-Refine](https://arxiv.org/abs/2303.17651) reported an average absolute improvement of roughly 20 percentage points across seven evaluated tasks using iterative feedback and refinement without additional training.
100
+ - [Fine-Tuning or Retrieval?](https://aclanthology.org/2024.emnlp-main.15/) found that RAG consistently outperformed unsupervised fine-tuning on the knowledge-injection tasks it evaluated, including both existing and new knowledge.
101
+ - [Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations?](https://arxiv.org/abs/2405.05904) found that models struggled to acquire new factual knowledge through supervised fine-tuning and became more likely to hallucinate as that new knowledge was learned.
102
+
103
+ Together with the ViperMesh case study, this supports a practical harness-first strategy: **optimize the harness first, measure the result, and modify model weights only when evidence shows that the harness has reached its useful limit.** Harness changes are faster to inspect, reverse, reuse, and validate, and on applicable tasks can deliver larger gains than weight modification without permanently changing the base model.
104
+
105
+ This does not establish that a harness will always outperform every possible fine-tuning method. Fine-tuning can still be valuable for behavior, style, latency, specialized representations, or capabilities that cannot be supplied effectively at inference time. A strong harness and a well-chosen fine-tune can also complement each other.
106
+
107
+ ## What Is A Harness Unit?
108
+
109
+ A **harness unit** is a portable workspace for improving one task family. Each unit develops independently and keeps its own target definition, environment map, harness material, experiments, evidence, regression cases, and promoted versions.
110
+
111
+ A new unit begins with this structure:
112
+
113
+ ```text
114
+ my-harness-unit/
115
+ unit.yaml identity and current version
116
+ UNIT_AGENT.md instructions for agents entering the unit
117
+ operational-map.md current understanding of tools, artifacts, and workflow
118
+ target/ task goal and suggested first tests
119
+ environment/ contract for commands, MCP tools, apps, and artifact paths
120
+ agent-facing/ promoted instructions and context
121
+ tools/ unit-specific helper tools
122
+ observers/ ways to inspect outputs
123
+ validators/ deterministic or agent-driven checks
124
+ regression-cases/ failures that future candidates should not repeat
125
+ candidates/ isolated proposed harness changes
126
+ runtime/ local runs and captured artifacts
127
+ versions/ restorable promoted snapshots
128
+ provenance/ human-readable change history
129
+ ```
130
+
131
+ This is not a restrictive template. Agents can add research, scripts, retrieval data, infrastructure declarations, memory, custom observers, or entirely new folders. The framework protects only the files and lifecycle rules needed to keep the unit understandable and recoverable.
132
+
133
+ ### Portable Unit Versus Local Working Data
134
+
135
+ The reusable harness material belongs in the portable unit. Raw traces, temporary experiments, caches, secrets, unpromoted candidates, and every historical render do not.
136
+
137
+ The default `thin` package contains the promoted knowledge and contracts needed to rebuild or integrate the harness. Runtime evidence remains local unless a future package profile explicitly includes it.
138
+
139
+ ## The Lifecycle, Made Simple
140
+
141
+ 1. **Describe the goal.** The user explains what the agent should become better at.
142
+ 2. **Map the environment.** The operating agent discovers how the real task is performed and where useful evidence comes from.
143
+ 3. **Reconcile assumptions.** Important context is confirmed, delegated, or clearly marked as inferred before the first real run.
144
+ 4. **Run a baseline.** The agent attempts the task before changing the harness.
145
+ 5. **Inspect and conclude.** It evaluates the artifacts and explicitly accepts, changes, reruns, requests input, or stops.
146
+ 6. **Create or extend candidates when needed.** Related changes accumulate in coherent isolated batches; independent issues can have parallel candidates.
147
+ 7. **Validate in proportion to risk.** The agent uses structural, targeted, representative, or full checks and attaches evidence.
148
+ 8. **Promote, revise, wait, or stop.** Supported improvements become a version. Weak candidates are revised or rejected.
149
+ 9. **Export or package.** The promoted harness can be applied to a coding agent, application agent, or another compatible environment.
150
+
151
+ Finished runs are immutable. Candidate evidence is checked when attached and checked again at promotion, so deleted runs, missing artifacts, or missing evidence files cannot support a release.
152
+
153
+ Candidates are not one-per-commit wrappers. A setup or tooling candidate can collect several related changes and receive a focused smoke test, while a behavior-changing harness candidate may require real artifact attempts and regressions. Target-harness, evaluation, and infrastructure changes can proceed independently. If one is promoted, parallel candidates based on the old version must rebase and produce fresh evidence before they can follow.
154
+
155
+ The image near the top of this README shows this loop at a glance. The [compact lifecycle document](docs/framework-process-compact.md) contains its editable Mermaid source. See the [detailed process diagram](docs/framework-process.md) for capability gaps, human input, waiting, stopping, and the complete artifact-aware loop.
156
+
157
+ ## What Makes It Different?
158
+
159
+ ### Artifact-aware
160
+
161
+ Harneloop treats the produced thing as evidence. The agent can inspect an image, scene, UI, document, generated repository, runtime trace, database state, or any other useful output instead of trusting its own textual report.
162
+
163
+ ### Harness-building, not only scoring
164
+
165
+ The purpose is not merely to report that an agent failed. The operating agent diagnoses the failure and develops a concrete harness change that may include prompts, principles, examples, retrieval, tools, observers, validators, regression cases, or environment automation.
166
+
167
+ ### Evidence-gated self-improvement
168
+
169
+ The active agent cannot freely rewrite the promoted harness. It creates a candidate, tests it, attaches evidence, and promotes it through the framework. Every promoted version can be inspected and restored.
170
+
171
+ ### Environment-agnostic
172
+
173
+ The core does not depend on Blender, SVGs, Python agents, or a specific model provider. A unit can use terminal commands, MCP servers, browser automation, desktop apps, APIs, manual steps, or a custom tool interface.
174
+
175
+ ### Reasoning remains open-ended
176
+
177
+ Harneloop structures the lifecycle without turning the operating agent into a fixed script. The agent still chooses the appropriate tests, artifacts, evaluation strategy, tools, and stopping point for the task.
178
+
179
+ ## Agent Quick Start
180
+
181
+ Harneloop is designed to be used primarily by talking to an agent with filesystem and terminal access.
182
+
183
+ Give the agent the repository and a prompt like this:
184
+
185
+ ```text
186
+ Read this repository's README.md and docs/agent-onboarding.md.
187
+ Use Harneloop to create a harness unit that improves an agent at: [describe the task].
188
+
189
+ Inspect my existing environment before deciding how to test it. Ask only for context
190
+ that can materially change the work, and do not silently treat assumptions as confirmed.
191
+ Run a baseline, inspect its artifacts, and conclude the attempt before deciding whether
192
+ a candidate is needed. Do not promote a candidate without evidence.
193
+ ```
194
+
195
+ The agent should then:
196
+
197
+ 1. Install the Harneloop tool if needed and run `harneloop doctor`.
198
+ 2. Read `harneloop onboard --format json` or [the onboarding guide](docs/agent-onboarding.md).
199
+ 3. Create or continue a provisional harness unit and inspect the actual environment.
200
+ 4. Reconcile confirmed, delegated, inferred, and unknown context through the adaptive intake checkpoint.
201
+ 5. Update `operational-map.md` with the current understanding.
202
+ 6. Perform a baseline and inspect the resulting artifacts.
203
+ 7. Conclude the attempt before accepting the current harness or proposing improvements.
204
+
205
+ ### Instructions For Agents Reading This Repository
206
+
207
+ If you are the operating agent:
208
+
209
+ - Do not assume every task has a test command.
210
+ - Do not assume Harneloop discovers endpoints, tools, screenshots, or artifact paths for you.
211
+ - Run `harneloop brief <unit>` and read `AGENTS.md`, `UNIT_AGENT.md`, and `operational-map.md` when entering a unit or recovering from context loss.
212
+ - Apply the unit brief only while working on that harness unit; unrelated project work remains outside its scope.
213
+ - Use `harneloop intake status` to surface only unresolved questions that can materially change the work.
214
+ - Use `harneloop candidate list <unit>` to recover all open work; do not assume a harness unit can have only one active candidate.
215
+ - Batch related changes into coherent candidates and scale validation to impact instead of running a full benchmark after every setup edit.
216
+ - Keep evaluator and target-harness changes separate when possible so the evidence remains trustworthy.
217
+ - Inspect the real environment and map it into `target/` and `environment/`.
218
+ - Prefer real artifact inspection when deterministic checks cannot establish quality.
219
+ - Separate your own capabilities from tools being designed for the target agent.
220
+ - Optimize for the best verified result rather than rebuilding everything: research and reuse suitable tools, skills, libraries, examples, and prior work while recording provenance and respecting license, security, cost, and permission boundaries.
221
+ - Put proposed harness changes in a candidate workspace.
222
+ - Use Harneloop commands for runs, artifacts, evidence, promotion, rollback, wait, stop, and resume.
223
+ - Ask before adding credentials, paid services, external access, security-sensitive tools, or expensive infrastructure.
224
+ - Update the operational map when assumptions, artifact paths, tools, or automation change.
225
+ - Never stop at run completion: inspect the artifacts and record an explicit decision with `harneloop attempt conclude`.
226
+
227
+ Machine-readable onboarding is available through:
228
+
229
+ ```bash
230
+ harneloop onboard --format json
231
+ ```
232
+
233
+ ## Install And Start
234
+
235
+ Harneloop currently installs from GitHub as an isolated, user-level tool through [uv](https://docs.astral.sh/uv/getting-started/installation/). The resulting `harneloop` command works from any directory on Windows, macOS, and Linux.
236
+
237
+ ```bash
238
+ uv tool install git+https://github.com/Ker102/Harneloop.git
239
+ harneloop doctor
240
+ harneloop setup
241
+ ```
242
+
243
+ If `uv` reports that its tool directory is not on `PATH`, run `uv tool update-shell` and open a new terminal. Contributors working from a clone can install the live checkout with `uv tool install --editable .`; see [development setup](docs/development.md).
244
+
245
+ `harneloop setup` opens the guided human-facing CLI. Running `harneloop` without a command opens the broader interactive menu in a terminal. Agents can use the explicit non-interactive commands directly.
246
+
247
+ Useful first commands:
248
+
249
+ ```bash
250
+ harneloop onboard
251
+ harneloop template list
252
+ harneloop units list
253
+ harneloop settings show
254
+ ```
255
+
256
+ Harness units created by `harneloop setup` or `harneloop init-unit` are registered automatically. Existing units can be added once with:
257
+
258
+ ```bash
259
+ harneloop units register /path/to/my-unit
260
+ ```
261
+
262
+ After registration, use the unit ID or name from any directory instead of a relative path:
263
+
264
+ ```bash
265
+ harneloop units list
266
+ harneloop status my-unit --format markdown
267
+ harneloop environment status my-unit
268
+ ```
269
+
270
+ ## What The Agent Asks You
271
+
272
+ New-unit onboarding is intentionally short. The agent should collect five pieces of context:
273
+
274
+ 1. What should this harness help an agent become better at?
275
+ 2. Where will the harness be used?
276
+ 3. Should you define success, should the agent propose it, or should it be decided after a baseline?
277
+ 4. Should validation prioritize quality, visual evidence, balance, or resource efficiency?
278
+ 5. Does a testing environment already exist, partly exist, or need to be built?
279
+
280
+ You do not need to know the perfect tests or artifacts in advance. When appropriate, the agent should propose them after inspecting the task and environment. It may ask about constraints, protected areas, cost limits, or human review only when those details matter.
281
+
282
+ ## Environment Setup
283
+
284
+ Harneloop records an environment mapping; the operating agent creates that mapping.
285
+
286
+ The CLI cannot magically know which MCP tool controls an application, where a render is saved, how a browser flow is reset, or what database state proves success. The agent must inspect the real workspace and connect those details to the harness unit.
287
+
288
+ Three setup modes are supported:
289
+
290
+ | Mode | Use it when | Agent behavior |
291
+ |---|---|---|
292
+ | `existing` | The task environment already works | Connect and document it; do not rebuild it without reason |
293
+ | `assisted` | Some pieces exist | Identify and add the smallest missing setup needed for a baseline |
294
+ | `managed` | The environment must be created | Build it explicitly and document infrastructure changes |
295
+
296
+ An environment can be command-driven, MCP-driven, manual, or fully custom. For example, a Blender harness may use an existing MCP server with no single run command. The agent can call tools, render the scene, capture screenshots and structured scene state, then attach those outputs to a Harneloop run.
297
+
298
+ Read [environment onboarding](docs/environment-onboarding.md) for detailed examples.
299
+
300
+ ## Configuration
301
+
302
+ Most users should begin with the defaults. The first useful configuration is usually inside the harness unit, not in global settings.
303
+
304
+ ### Harness-unit Configuration
305
+
306
+ | File or area | Change it when |
307
+ |---|---|
308
+ | `operational-map.md` | Tools, artifact locations, assumptions, constraints, or the workflow changes |
309
+ | `target/brief.yaml` | The task family, success definition, expected artifacts, or known risks change |
310
+ | `environment/contract.yaml` | Commands, MCP tools, setup mode, interaction mode, or output paths change |
311
+ | `agent-facing/` | A tested candidate promotes new instructions or reusable context |
312
+ | `observers/` and `validators/` | The unit needs better artifact inspection or deterministic checks |
313
+ | `regression-cases/` | A discovered failure should be tested in future iterations |
314
+ | `tools/` and `infrastructure/` | Better performance requires unit-specific capabilities or services |
315
+
316
+ Do not manually edit framework-owned `.evolve/`, `versions/`, `provenance/`, `runtime/`, or candidate metadata. Use the CLI lifecycle commands.
317
+
318
+ ### Global Preferences
319
+
320
+ View preferences with `harneloop settings show` and change one with:
321
+
322
+ ```bash
323
+ harneloop settings set validation.prefer_visual_artifacts true
324
+ harneloop settings set agent_behavior.autonomy_level balanced
325
+ harneloop settings set runtime.token_efficiency_mode false
326
+ ```
327
+
328
+ Important preference groups are:
329
+
330
+ - `agent_behavior`: autonomy, risky-action confirmation, and promotion strictness;
331
+ - `validation`: agent-decided validation, visual-artifact preference, and resource mode;
332
+ - `export`: default target adapter and package profile;
333
+ - `runtime`: telemetry detail, token-efficiency mode, and local unit registry behavior.
334
+
335
+ In the alpha, preferences are durable defaults and guidance for the CLI and operating agent. Not every preference is enforced automatically by every engine command yet. Evidence-required promotion is enforced unless the explicit development override is used.
336
+
337
+ ## Example Use Cases
338
+
339
+ - Improve spatial reasoning and scene construction for a Blender or CAD agent.
340
+ - Improve SVG, image, slide, document, or UI generation through rendered artifact review.
341
+ - Build a coding-agent harness for a repository with recurring implementation or debugging failures.
342
+ - Improve browser automation using screenshots, DOM state, traces, and task outcomes.
343
+ - Develop better tool selection and recovery behavior for an MCP-based agent.
344
+ - Evolve retrieval, examples, validators, and context for a research or data-processing workflow.
345
+ - Build a reusable internal harness, then export it for Codex, Cursor, or a custom application agent.
346
+
347
+ Harneloop is most useful when the task is repeated, outputs can be inspected, and failures can become durable improvements. It is unnecessary for a one-off task where no learning will be reused.
348
+
349
+ ## Core CLI Lifecycle
350
+
351
+ The explicit commands are intended for agents, automation, and technical users:
352
+
353
+ ```bash
354
+ harneloop init-unit ./my-unit --id my-unit --name "My Harness Unit" --template artifact-review
355
+ harneloop target set my-unit --task "..." --success "..."
356
+ harneloop environment connect my-unit --name "..." --mode existing --description "..."
357
+ harneloop attempt plan my-unit --goal "..." --method "..."
358
+ harneloop run start my-unit --task "Baseline attempt"
359
+ harneloop artifact add my-unit run-0001 ./output.png --kind image
360
+ harneloop run finish my-unit run-0001 --status succeeded --summary "Baseline captured"
361
+ harneloop candidate create my-unit --summary "Improve artifact construction" --plane target_harness --validation-tier representative
362
+ harneloop run start my-unit --task "Test candidate improvement" --candidate-id cand-0001
363
+ harneloop artifact add my-unit run-0002 ./improved-output.png --kind image
364
+ harneloop run finish my-unit run-0002 --status succeeded --summary "Candidate result captured"
365
+ harneloop candidate evidence add my-unit cand-0001 --kind artifact_review --summary "..." --run-id run-0002 --artifact-id artifact-0001 --validation-tier representative
366
+ harneloop candidate stage my-unit cand-0001 ready
367
+ harneloop promote my-unit cand-0001 --version 0.1.0
368
+ harneloop export my-unit --adapter codex
369
+ harneloop package my-unit --output ./my-unit-0.1.0.tar.gz
370
+ ```
371
+
372
+ This sequence is illustrative, not a fixed recipe. Tool-driven agents may perform many actions between `run start` and `run finish`, capture several artifacts, create multiple attempts, or wait for external results.
373
+
374
+ ## Safety And Integrity
375
+
376
+ - YAML and JSON control files are written atomically.
377
+ - Concurrent ID allocation and read-modify-write operations use harness-local locks.
378
+ - Finished runs cannot be changed or finished again.
379
+ - Candidate overlays cannot modify protected framework state.
380
+ - Evidence references must exist when attached and at promotion time.
381
+ - Candidate evidence must match the candidate's current base version and declared validation tier.
382
+ - Parallel candidates survive another promotion but must rebase and collect fresh evidence before promotion.
383
+ - Promoted versions are stored as restorable snapshots.
384
+ - Rollback is a recorded framework action.
385
+ - Thin packages exclude runtime data, candidates, caches, and common secret files.
386
+
387
+ ## Documentation
388
+
389
+ - [How Harneloop works](docs/framework-process.md)
390
+ - [Agent onboarding](docs/agent-onboarding.md)
391
+ - [Environment onboarding](docs/environment-onboarding.md)
392
+ - [Core lifecycle](docs/architecture/core-lifecycle.md)
393
+ - [Runtime layers and future Rust boundary](docs/architecture/runtime-layers.md)
394
+ - [Concurrency and file safety](docs/architecture/concurrency.md)
395
+ - [Product principles](docs/product-principles.md)
396
+ - [Local demo](docs/demo-first-test.md)
397
+ - [Development notes](docs/development.md)
398
+
399
+ ## Contributing
400
+
401
+ Contributions, issue reports, and independent harness-unit case studies are welcome. Particularly useful contributions include:
402
+
403
+ - testing Harneloop on task families beyond the existing case study;
404
+ - reporting reproducible lifecycle, portability, or agent-onboarding failures;
405
+ - improving target-agent adapters, validators, packaging, and cross-platform behavior;
406
+ - contributing focused documentation, examples, or regression coverage.
407
+
408
+ Read [CONTRIBUTING.md](CONTRIBUTING.md) before substantial changes. Open an issue first for architectural work so its scope and compatibility impact can be discussed. Security issues should follow [SECURITY.md](SECURITY.md) rather than a public issue.
409
+
410
+ ## Development
411
+
412
+ Run the test suite from the repository:
413
+
414
+ ```bash
415
+ python -m unittest discover -s tests
416
+ ```
417
+
418
+ The project currently uses Python 3.11 or newer. A future Rust runtime may own stronger protected lifecycle, packaging, file-watching, or desktop-distribution responsibilities after the product surface stabilizes.
419
+
420
+ Harneloop is the selected product identity for the alpha and public-launch path. The package, CLI, harness-unit metadata, documentation, and repository use the same name.
421
+
422
+ ## License
423
+
424
+ Harneloop is available under the [Apache License 2.0](LICENSE).