agent-harness GitHub

Purpose: Preserved candidate product brief for a possible future public decision-replay extraction. Status: ACTIVE for the replay tool since 2026-09-29 (RP-006, AGENT_HARNESS_OPERATIONS AH-006): the owner approved the clean repository, name, licence and publication. Outreach still needs owner direction. Text below that says DEFERRED records the earlier plan. Authority relationship: AGENT_HARNESS_AGENT_BRIEF.md wins for current repository mission and defers public extraction until internal stability and demonstrated demand. If AH-10 is later unlocked, this document supplies candidate product requirements; AGENT_HARNESS_OPERATIONS.md still wins for replay-kernel contracts and CLAUDE_CONFIG_OPERATIONS.md for owner supervision. Last-reviewed date: 2026-07-30 Owner: Cristian Tcaci

Decision register

Deferred repository design

Deferred candidate names

Candidate Classification Decision rationale
CharterReplay / charter-replay DECISION: working recommendation Distinctive, tied to the small charter corpus, and broad enough to compare recorded and executable policies without claiming full agent replay. The README tagline supplies immediate meaning.
PolicyReplay / policy-replay OPEN alternative Maximally descriptive but generic, harder to search, and more likely to collide with existing policy-replay terminology.
CommandPolicyReplay / command-policy-replay OPEN alternative Technically explicit and honest, but long for a repository, package, and CLI command.

Product definition

CharterReplay compares two coding-agent command-policy decision sources over a pinned corpus and fails when the candidate introduces configured safety or interruption regressions.

Non-Goals

Sixty-second README specification

1. One-line purpose

Compare coding-agent command policies against a pinned replay corpus and catch decision regressions before release.

2. Demo GIF

3. One install command

pipx install charter-replay

4. One replay command

charter-replay replay \
  --baseline recorded:examples/legacy-baseline/decisions.jsonl \
  --candidate process:python,examples/candidate-policy/policy.py \
  --corpus corpora/charter/events.jsonl \
  --output reports/demo

5. One limitation statement

This re-evaluates recorded command events and decisions. It does not reproduce the original agent, environment, shell effects, or operating-system boundary.

Public repository layout

charter-replay/
  REPLAY_TOOL_PRODUCT.md
  README.md
  LICENSE
  SECURITY.md
  CONTRIBUTING.md
  pyproject.toml
  src/charter_replay/
    __init__.py
    cli.py
    compare.py
    corpus.py
    digests.py
    manifests.py
    policy_sources.py
    reports.py
    schemas/
  corpora/charter/
  examples/
    legacy-baseline/
    candidate-policy/
    dcg/
  tests/
    unit/
    contract/
    charter/
  docs/
    decision-replay-boundary.md
    postmortem.md
    continuation-review.md
  .github/workflows/

Versioning and release process

Licence decision

SECURITY.md contract

CONTRIBUTING.md contract

DCG compatibility worked example

Outreach checklist

Message Named target Specific question
1 @Dicklesworthstone, maintainer of destructive_command_guard “Would a release-to-release recorded decision diff like this be useful in DCG rule-pack CI, and which output field would make it actionable?”
2 @sheeki03, maintainer of Tirith “Can the generic process contract represent a useful subset of Tirith decisions without misrepresenting its broader payload/config coverage?”
3 agent-sh maintainers of Agnix “Would the charter corpus format be useful for configuration-rule regression cases, or should configuration validation remain a separate future corpus?”
4 @clay-good, maintainer of agent-replay “Is the distinction between decision replay and trajectory replay clear, and is there a compatibility boundary worth documenting?”
5 Maintainers of microsoft/agent-governance-toolkit “Does the recorded-decision source format complement policy replay fixtures, and what minimum provenance would make cross-tool comparison trustworthy?”

Success and continuation gates

Portfolio completion

Product continuation

Deferred backlog with evidence triggers

Deferred idea Implement only when…
Capability manifest A second real adapter lacks information that materially changes comparison validity
Richer event model A real non-command event must be replayed
Authorisation context An actual approval workflow becomes part of replay
Hazard taxonomy Two policies cannot be compared meaningfully using simple case labels
Metamorphic tests A real normalisation variation causes a regression
Policy DSL Repeated code-based rules demonstrate a stable common grammar
Public Configuration Doctor package Internal Doctor v2 is stable and external users repeatedly cannot determine which configuration is active
Live runtime adapter Users ask to move from offline comparison to interception
Public Claude-config blueprint At least two components prove useful across multiple repositories
Promotion Engine Several manual promotion decisions reveal a repeatable workflow
Academic paper External comparisons produce a defensible methodological contribution

Autonomy and self-improvement references

Quality gates

python -m pytest -q tests/unit tests/contract
python -m ruff check .
python -m pytest -q
python -m build
charter-replay replay --baseline recorded:examples/legacy-baseline/decisions.jsonl --candidate process:python,examples/candidate-policy/policy.py --corpus corpora/charter/events.jsonl --output .local/release-proof

Historical public-product allocation

Deferred AH-10 task candidates

Task 1 — Create the clean local repository and reserve the working identity

Task 2 — Import the allowlisted replay bundle and package skeleton

Task 3 — Build the sixty-second README

Task 4 — Add licence-decision package, security policy, and contribution contract

Task 5 — Record the demo GIF from a fictional clean terminal

Task 6 — Add release CI and build a local v0.1.0 candidate

Task 7 — Finish the postmortem and launch bundle

Task 8 — Produce the DCG compatibility worked example

Task 9 — Draft the five targeted outreach messages

Task 10 — Prepare the owner release handoff and continuation record