Agent on Alwaldend

Agent control contracts

Mon, 01 Jan 0001 00:00:00 +0000

Agent control contracts

This project owns the repository-internal shared vocabulary used to compose agent-system declarations and derived catalogs. It does not own component payload schemas, user authority, runtime observations, or generated catalogs.

The initial api/v1alpha1 package defines stable references, atomic effects, authority and budget envelopes, independent path-policy axes, information and retention classes, availability reasons, evidence applicability, and the common operation and artifact envelopes. Validation fails closed for unknown effects and malformed identities. JSON decoding is strict and canonical encoding is deterministic.

Agents

Mon, 01 Jan 0001 00:00:00 +0000

Repository agent system

This project owns the repository-wide agent-system contract, its durable improvement goals, and reusable cross-repository skills. It does not centralize component facts or runtime state: each fact remains canonical at its natural owner, and system-wide views are derived projections.

Start here

Document	Purpose
Current state	Evidence-backed baseline and material seams
Architecture	Canonical abstraction tower, authorities, and invariants
Roadmap	Dependency-ordered future work and acceptance signals
Durable goals	Versioned attempts, evidence, and acceptance state
Root agent guide	Current repository-wide operating policy

The current-state document describes supported entry points and their evidence boundaries. Dated audits remain in the goal records. The architecture defines the intended composition contract; the roadmap does not claim that proposed interfaces already exist.

Bazel agent

Mon, 01 Jan 0001 00:00:00 +0000

bazel_agent is the repository Bazel entry point for agents. It keeps the Bazel invocation behind a validated subcommand while consistently applying the agent configuration:

bazel_agent bazel test //path/to/package:all
    ->
bazel test --config=agent //path/to/package:all

bazel is the only Bazel entry point, and it is a validated subcommand. The runner accepts a known Bazel command after the bazel keyword, rejects arbitrary leading arguments, and places --config=agent after the command. Targets, command options, and arguments after the -- separator of a bazel run invocation pass through unchanged. Later options therefore retain Bazel’s normal precedence and can override settings supplied by the agent configuration. The runner resolves bazel from PATH and replaces itself with that process, so signals and the final exit status are not mediated by another wrapper process. Uses of the persistent Bazel server follow the host Codex network policy; the host-bot profile allows loopback so the client-server connection is not blocked.

Goal

Mon, 01 Jan 0001 00:00:00 +0000

This project owns the goal execution skill and the deterministic local store that supports it. Ordinary tasks use init for the objective and acceptance, checkpoint --summary --subject --next-action for local progress, and show for bounded continuation. The store derives IDs and digests while retaining explicit resource-version checks. Detailed attempt plans and histories remain available for maintained goals, repeated failures, and complex coordination.

projects/goal/
  api/v1alpha1/      Portable resource types and domain validation
  cmd/goal/          Cobra command wiring and command tests
  docs/              Current architecture and generated diagrams
  internal/fsstore/  Local persistence, per-goal locking, and store tests
  skills/goal/       Model-facing execution protocol and evaluations

Go dependencies flow from cmd/goal to internal/fsstore to api/v1alpha1. The API package has no filesystem or command dependency. The Go toolchain is Bazel’s @rules_go//go; run the package targets below rather than a host-installed go.

Goal command

Mon, 01 Jan 0001 00:00:00 +0000

goal is the command surface for the repository goal skill. Portable resource types and domain validation live in api/v1alpha1; deterministic local persistence lives in internal/fsstore. The command keeps authoritative Kubernetes-inspired YAML envelopes and digest-bound attempt Markdown separate from the bounded generated README.md projection, uses the same record format for workspace and project goals, and stores session focus separately under ignored workspace scratch.

The record layout is:

goals/<goal-id>/
  goal.yaml
  criteria.yaml
  criteria-revisions/<revision>.yaml
  README.md
  attempts/<attempt-id>/
    attempt.yaml
    plan.md
    result.md
    evidence/

<owner-root>/goals/<goal-id>/ is the preferred project placement, not a CLI constraint. Direct initialization, promotion, and migration also accept other safe in-workspace goals roots while recording the explicit owner root.

Repository agent goals

Mon, 01 Jan 0001 00:00:00 +0000

Repository agent goals

Each child directory is an owner-local durable goal record. Canonical resource files and attempt artifacts are created and validated through the repository goal workflow; do not edit generated records or projections directly.

Goal evidence may contain source and operational analysis, including non-secret live or generated facts. It must never contain credentials, other secrets, or personal information. Inspect raw artifacts before promoting their content. Structured task artifacts such as FrictionRecord and LearningProposal JSON files are task scratch: keep them under out/<task>/ and cite them from goal evidence Markdown rather than committing them into evidence/, which accepts only .md files.

Repository agent system current state

Mon, 01 Jan 0001 00:00:00 +0000

Repository agent system current state

This is the maintained guide to the checked-in interfaces. Source links below identify their owners; runtime availability must be observed in the current session. Historical audits and acceptance claims remain in the immutable goal records. Their dates and evidence tiers limit what they prove.

Start with the affected path

Read applicable AGENTS.md instructions and the nearest owner README. Use the available Cordis repository-context handlers for bounded reads and searches, or the native tools when Cordis is unavailable. Cordis availability does not determine whether offline repository work is possible.

Repository agent-system architecture

Mon, 01 Jan 0001 00:00:00 +0000

Repository agent-system architecture

Status and purpose

This document defines the target composition contract for the repository as one agent-driven system. It is normative about boundaries, invariants, and ownership. A named interface or record is not a current capability merely because it appears here. The current-state snapshot describes implemented behavior; the roadmap orders the work needed to reach this design.

The objective is to let an agent form an accurate situation model, choose the least costly safe action, prove the exact result, and make later work cheaper. The design must remain useful with no daemon, network, credential, runtime extension, or active durable goal.

Repository agent-system roadmap

Mon, 01 Jan 0001 00:00:00 +0000

Repository agent-system roadmap

This document records intentional future work. The current-state guide owns the supported interface summary; component documentation and executable tests establish implementation details. The architecture describes composition responsibilities. Historical phase plans and acceptance records remain in the immutable goals. A completed historical phase does not establish a current runtime guarantee.

First: measure and simplify ordinary tasks

Use representative question, edit, recovery, and delivery scenarios to compare the current workflow with a candidate. Keep source, instructions, fixture, model, observation method, and execution identity with each result. Measure task success, unauthorized actions, commands, context actually consumed, duration, and resume steps where the observer can establish them. Record unavailable measurements explicitly. Configuration validation and shorter documents do not establish behavioral improvement.