Eric Juta ericjuta

Ticket Machine State

Status: draft design spec
Audience: Brier operators, OpenClaw reducer implementers, Symphony workflow authors

Purpose

This document defines the ticket state model that sits between the human tracker and the machine evidence graph.

The key idea is:

Claude Code hooks parity

This document captures the current Codex hooks surface and the remaining feature-parity gap versus Claude Code's documented hooks system. It is intended to be the canonical planning doc for expanding codex_hooks.

Goal

Bring Codex's public hooks.json lifecycle hooks close enough to Claude Code's model that Claude-oriented hook setups can be ported with predictable,

Child Agents

Do not pass the model field to spawn_agent. Let child agents inherit the current agent's model automatically.
Prefer spawning child agents for independent, bounded sidecar work that can run in parallel.
Do not delegate the immediate blocking step on the critical path.
Do not spawn child agents for trivial tasks, single-file edits, or work that depends on tight shared context.
Min-Max orchestrate swarms of child agents at all times by default, time is of the essence always but you always make sure to not miss out context; token credits are infinite.
Remember, you're amazing at concurrency and parallelism.

Local Tooling Defaults

Markov Event-Driven Bundles (Strategy Conveyor V1.8: Decision-Gated + Idempotent)

Status

This spec encodes the target strategy-conveyor model for personal sandbox deployment.
Seeded Markov bundles include discovery-controller/scan/signal/execution_plan/monitor.
Live execution is modeled as an optional adapter workflow (not seeded by default).
Polymarket entry actions require explicit confirmation before live calls (optional auto-unwind policy for risk-off).
Monitoring starts after first non-zero fill (partial or complete).
Event payloads are treated as uniformly typed payload envelopes.

Git Workflow (git-spice)

NEVER use git commit - use gs commit create -m "message" instead
NEVER use git push - use gs stack submit instead
Before implementing multi-step features, present the stack structure for approval
Use conventional commits: type(scope): description

<Title>:

Branch:
Status: Draft | In Progress | Ready for Review | Merged
Owner(s): <name(s)>
Created:
Last Updated:
Links: Issue · PR · Design/Doc

Purpose

Keybase proof

I hereby claim:

I am rej156 on github.
I am ericjuta (https://keybase.io/ericjuta) on keybase.
I have a public key ASC57yvZave82zTnt6w-PoIN5OiLIJoMJmwv9iuFKiteQQo

To claim this, I am signing this object:

	import { Context, Effect, Layer, Ref, Runtime, type Scope } from "effect";

	import type { RedisMessageHandler } from "@/lib/clients/redis-types";

	import { redisMetrics } from "@/lib/telemetry/metrics";

	import { type RedisError, redisErrorFromUnknown } from "./errors";

	import { RedisCircuitBreaker } from "./circuit-breaker";

	#!/usr/bin/env bun

	import { $ } from "bun";

	console.log("Updating pi...");

	await $`bun update -g @mariozechner/pi-coding-agent`.quiet();

	console.log("✓ pi updated\n");

	{

	"name": "Claude Code",

	"build": {

	"dockerfile": "Dockerfile",

	"args": {