Documentation

Harness

Use the Gajae Code harness to run coding-agent sessions with observable lifecycle, submit gates, and workspace-aware control.

Why a harness?

A coding model is useful only when it can be steered, observed, paused, and verified. The harness turns an agent run into a managed session with lifecycle state, owner liveness, branch context, and submission gates.

Design intent: do not rely on a terminal screenshot or a half-remembered prompt. Track whether the owner is live, whether the session is ready for input, and which workspace/branch the work belongs to.

Typical loop

gjc
/skill:deep-interview
/skill:ralplan
gjc ultragoal create-goals --brief "implement, verify, and report evidence"
gjc ultragoal complete-goals

Visible routed tmux sessions

For Clawhip or chatops-visible work, use the public gjc-session plugin skill and scripts/gjc-session/ helpers instead of ad hoc shell wrappers. The helper pattern is:

scripts/gjc-session/create.sh <session-name> <worktree-path>
scripts/gjc-session/prompt.sh <session-name> @task.md
scripts/gjc-session/tail.sh <session-name> 80

create gives the pane a stable name and a dedicated worktree, prompt injects the task after readiness, and tail reads bounded output for readiness or evidence checks. harness-tmux-owner-start.sh is the owner starter: keep long-running interactive gjc sessions under tmux ownership, not under short timeout wrappers that can kill the process mid-task.

Operational guardrails

Use dedicated worktrees for risky implementation and review work.
Keep branch metadata aligned with the actual checkout.
Submit follow-up prompts only after the session is observable and ready.
Use stable, public-safe session names that identify the project and task without exposing private routing IDs.
Retire completed sessions instead of leaving stale panes behind.