rein-aharness/workplans/HARNESS-WP-0002-rename-and-glas-harness-alignment.md

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, 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 name
• Containerfile: COPY rein_aharness, ENTRYPOINT ["rein-aharness"]
• Makefile: IMAGE/TAR → rein-aharness:railiance01 / rein-aharness-railiance01.tar; deploy-rsync target path
• deploy/k8s/railiance/*.yaml: namespace/labels/names/image all rein-aharness
• deploy/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/config entry, not owned by this repo)
• In-repo identity strings updated too: hub.py's source field, metrics.py's harness field default, intake.py's DEFAULT_ASSIGNEE, cli.py's argparse prog name, commit author identity in smoke.py/tenant_onboard_runs.py
• Verified: 47/47 tests pass, rein-aharness CLI runs correctly from a fresh venv, docker build succeeds and the built image runs (ENTRYPOINT/CMD dispatch correctly)
• deploy/README.md gained 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

Still open — the actual live cutover: running the checklist on railiance01, rebuilding+importing the image there, applying the renamed k8s manifests, and running the host smoke script against the live deployment. Not attempted from this session — real production surgery on binky-control's live automation, needs the operator present for the actual host-side moves and a confirmed rollback point.

id: HARNESS-WP-0002-T02
status: progress
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"