3.8 KiB
| id | title | status | state_hub_workstream_id |
|---|---|---|---|
| HARNESS-WP-0002 | Rename completion and glas-harness alignment | active | c53fe489-845b-42b3-8e7f-c7e4e6f16b25 |
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: HARNESS-WP-0002-T01
status: done
priority: high
state_hub_task_id: "bf04ed50-cbe2-4f8f-9876-d06c579d19e6"
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 (pyproject.toml [project.scripts], agent_harness/cli.py entry point), the
agent_harness Python package directory, the Docker image tag
(agent-harness:railiance01), the k8s namespace/labels/ConfigMap names
(deploy/k8s/railiance/*.yaml), the Railiance host directory
(~/agent-harness/deploy/...), and deploy/scripts/railiance-smoke.sh's
AGENT_HARNESS_ROOT env var and SSH remote alias. Do this as one
reviewed change with a Railiance re-deploy and smoke-test run
immediately after, not as incidental cleanup.
id: HARNESS-WP-0002-T02
status: todo
priority: medium
state_hub_task_id: "7c5d23cd-d7fd-4c79-8847-448b83feb673"
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.
Partially done, live-proven at the coarse level (2026-07-26):
glas-harness's glas_harness/reins/rein_aharness.py implements the
contract today 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). Still
open: this repo does not itself expose per-tool-call hooks — glas-harness
cannot yet intercept/policy-check individual tool calls mid-session,
only the whole run as a unit. That deeper refactor (runner.py driving
the Claude Code session turn-by-turn rather than one claude --print
call) is what remains of this task.
id: HARNESS-WP-0002-T03
status: progress
priority: high
state_hub_task_id: "228e999c-807b-4456-a286-4e3ab4fc8e90"
Task: Decide scheduling/blueprint coupling boundary
This repo depends directly on kaizen-agentic (blueprints) and
activity-core/issue-core (task intake). Decide, once
rein-openweights exists as a second rein with a possibly different
triggering model, whether that coupling stays rein-local (each rein
sources its own tasks) or moves into glas-harness as a shared concern.
Record the answer in glas-harness/docs/adr/ before T03 forces the
question implicitly.
id: HARNESS-WP-0002-T04
status: todo
priority: low
state_hub_task_id: "31e2b763-8f04-4523-bd2b-ce4506b55700"