---
id: HARNESS-WP-0002
title: "Rename completion and glas-harness alignment"
status: proposed
state_hub_workstream_id: "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.

```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.

```task
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.

```task
id: HARNESS-WP-0002-T03
status: todo
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.

```task
id: HARNESS-WP-0002-T04
status: todo
priority: low
state_hub_task_id: "31e2b763-8f04-4523-bd2b-ce4506b55700"
```