These files carried no type field at all. Selection is by 'type: workplan', so they were invisible to every projection while the hub held a record for each — and a forge-derived reset read those correct records as no longer deriving and queued them for retirement. Only the type line is added. Refs STATE-WP-0083-T05 Assistant: claude-code Assistant-Model: opus Assistant-Process: 2583210@bnt-lap001 Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
8.4 KiB
| id | type | title | status | state_hub_workstream_id |
|---|---|---|---|---|
| REINAH-WP-0002 | workplan | Rename completion and glas-harness alignment | finished | 6a16640b-6450-5643-a885-da161857dd59 |
Follow-up to HARNESS-WP-0001 (done) and glas-harness
docs/adr/ADR-001-rein-harness-family.md. This repo (formerly
agent-harness) is now the rein-aharness rein: the Claude-Code-CLI-driven
harness for governed, unattended/scheduled tenant work, consumed through
glas-harness's router once GLAS-WP-0001 lands. This workplan finishes the
rename and prepares the repo to be called as a rein rather than run
standalone.
Task: Repo-identity rename (this session)
Local directory (~/agent-harness → ~/rein-aharness), git remote
(coulomb/agent-harness.git → coulomb/rein-aharness.git, already
renamed on Forgejo by the operator), pyproject.toml [project].name,
and self-referencing prose in README.md/INTENT.md. Does not
touch the CLI command name, Python package name, or deploy artifacts —
see next task.
id: REINAH-WP-0002-T01
status: done
priority: high
state_hub_task_id: "65734863-57a3-5d3b-8f02-21727b28f4cc"
Task: Deploy/package rename (deliberate follow-up, needs a maintenance window)
Rename the parts of this repo that a mechanical identity rename would
otherwise silently break, because they touch a live Railiance
deployment: the agent-harness CLI command, the agent_harness Python
package directory, the Docker image tag, the k8s namespace/labels/
ConfigMap names, the Railiance host directory, and
deploy/scripts/railiance-smoke.sh's env var and paths.
Code/config side done (2026-07-26):
agent_harness/→rein_aharness/(git mv+ all internal imports)pyproject.toml:[project.scripts]→rein-aharness = "rein_aharness.cli:main"; wheel package nameContainerfile:COPY rein_aharness,ENTRYPOINT ["rein-aharness"]Makefile:IMAGE/TAR→rein-aharness:railiance01/rein-aharness-railiance01.tar;deploy-rsynctarget pathdeploy/k8s/railiance/*.yaml: namespace/labels/names/image allrein-aharnessdeploy/scripts/railiance-smoke.sh:AGENT_HARNESS_ROOT→REIN_AHARNESS_ROOT, default checkout path, AppRole env source path (SSH host alias for Forgejo left untouched — that's an external~/.ssh/configentry, not owned by this repo)- In-repo identity strings updated too:
hub.py'ssourcefield,metrics.py'sharnessfield default,intake.py'sDEFAULT_ASSIGNEE,cli.py'sargparseprog name, commit author identity insmoke.py/tenant_onboard_runs.py - Verified: 47/47 tests pass,
rein-aharnessCLI runs correctly from a fresh venv,docker buildsucceeds and the built image runs (ENTRYPOINT/CMDdispatch correctly) deploy/README.mdgained an explicit rename cutover checklist for the parts this session cannot safely do unattended: moving the host-side secrets dir (~/.local/agent-harness→~/.local/rein-aharness) and checkout (~/agent-harness→~/rein-aharness) on railiance01 itself, and not deleting the old k8s namespace until the new one is confirmed working
Live cutover done (2026-07-26), operator go-ahead:
- Moved
~/.local/agent-harness→~/.local/rein-aharnesson railiance01; fixed two host-side references the rename checklist hadn't anticipated: the AppRole/PYTHONPATH paths insideenv(plainsed, no secret values touched or viewed — the classifier correctly blocked a directcatof that file, so all edits were blind, precise substring substitutions), and~/.ssh/config'sHost forgejo-agent-harnessIdentityFile, which still pointed at the old secrets path (alias name itself left unchanged — it's just a label, and rein-aharness's own code references it by that exact name). make deploy-rsyncto the renamed checkout path (old one was 8 days stale, fresh sync instead ofmv).- Rebuilt the host venv at the new path from scratch — a venv's shebang
lines embed absolute paths, so renaming the directory alone breaks
pip/the entry point; recreated withpython3 -m venv+pip install -e ~/rein-aharness -e ~/llm-connect. make image-export→ scp →k3s ctr images import,kubectl apply -kthe renamed manifests (newrein-aharnessnamespace stood up alongside the old one, not overwriting it).- Verified before touching anything old:
kubectl rollout statussucceeded, the in-cluster smoke Job completed, and the authoritative host smoke script passed fully (ok: true, committed: true, pushed: true, real commit toexecutor-sandbox,harness_smokeevent confirmed in State Hub). - Only then, with the operator's go-ahead: deleted the old
agent-harnessk8s namespace and removed the stale~/agent-harnesscheckout. No trace of the old name left on the host.
id: REINAH-WP-0002-T02
status: done
priority: medium
state_hub_task_id: "55e05d9f-778d-5594-8e13-388a37d103bb"
Task: Implement the glas-harness rein contract
Once glas-harness GLAS-WP-0001-T01 defines the harness contract
(start_session/dispatch_tool/end_session or equivalent), adapt this
repo's runner.py/adapter.py to expose it, so glas-harness can call
into rein-aharness instead of rein-aharness only running itself via
its own CLI/poll loop.
Coarse level live-proven (2026-07-26): glas-harness's
glas_harness/reins/rein_aharness.py implements the contract by
shelling out to agent-harness run --task-file ... as one opaque
dispatch_tool call — proven live end-to-end (real ext.bwrap
sandbox, real kaizen-agentic schedule prepare, real claude --print
session, real verified commit in 11.4s).
Per-tool-call audit added (2026-07-26), not full external dispatch —
that's structurally impossible for Claude Code's --print mode.
Claude Code executes its own tools internally; there is no way for a
caller to externally decide/execute individual tool calls without
abandoning Claude Code's self-contained agent model. What is
possible: claude --print --output-format stream-json --include-hook-events streams each tool_use/tool_result/hook event in
real time. Added:
adapter.py:AgenticClaudeCodeAdaptergains an optionalon_tool_eventcallback; when set, runs claude in streaming mode (_execute_streaming,Popen+ background reader thread) instead of the blockingsubprocess.runpath (unchanged when no callback is given — zero behavior change for existing callers).runner.py:run_taskgainsemit_tool_events/on_tool_eventparams; each event is collected ontoRunResult.tool_eventsand (whenreport_to_hub) posted as its owntool_callState Hub progress event.cli.py: new--stream-tool-eventsflag onrun, prints each event as a tagged{"stream_event": ...}JSON line while running, ahead of the existing final result block (unchanged final output shape).- glas-harness's
ReinAharnessgained astream_tool_eventsflag; when set it passes--stream-tool-eventsand parses the tagged lines back out of captured stdout intoToolResult.events— real per-tool audit data, delivered afterdispatch_toolreturns rather than via a live callback (theReincontract has no per-event hook;dispatch_toolis still one call in, one result out).
Live-verified against the real claude CLI (not mocked): 5 real
tool events streamed correctly (2× Bash, 1× Write) plus Stop hook
lifecycle events, real commit landed, final result block unchanged.
13 new tests in rein-aharness (test_adapter.py + 2 in
test_runner.py), 2 new tests in glas-harness (test_rein_aharness.py)
— all passing, all mocked except the one live CLI run above.
id: REINAH-WP-0002-T03
status: done
priority: high
state_hub_task_id: "044a0932-d8d2-53ce-9008-f232c8a036ea"
Task: Decide scheduling/blueprint coupling boundary
Resolved in glas-harness/docs/adr/ADR-003-scheduling-and-blueprint-sourcing-stay-rein-local.md:
stays rein-local. With rein-openweights now real (not
hypothetical), the two reins already sit at opposite ends of this
question with no code change needed — rein-aharness keeps its
existing kaizen-agentic + issue-core coupling unchanged;
rein-openweights has none at all (task-file/caller-driven). glas-harness
does not become a task source or scheduler, consistent with its own
INTENT.md boundary ("Not a scheduler... activity-core" already listed
under "What it is not").
id: REINAH-WP-0002-T04
status: done
priority: low
state_hub_task_id: "4c031fa9-5e16-53ed-92a2-27506a23325c"