Agents

• 1: Repository agent goals
• 2: Repository agent system current state
• 3: Repository agent-system architecture
• 4: Repository agent-system roadmap

1 - Repository agent goals

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.

Discover current open work through the goal catalog and its bounded resume view; status is owned by each goal record. The agent-system-phase-six-ergonomics/ goal records a completed friction-reduction attempt, with the original evidence and its limitations preserved.

The current-state document describes supported interfaces and current evidence boundaries. Closed attempts remain historical records; later implementation reviews may narrow claims they made without rewriting those immutable records.

2 - Repository agent system current state

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.

The offline context command provides a bounded advisory view:

bazel_agent bazel run //tools/agents/cmd/agent_system -- \
  --workspace-root "$PWD" --path projects/goal

Its owner documentation describes the supported flags and limitations. Catalog declarations identify source facts; they do not establish live provider health, action authorization, successful validation, or a task’s association with a goal. Missing observations remain explicit. A source digest proves identity, not freshness against a live system.

Use the owning interface

The Bazel runner also supports cached control-tool execution in current builds. If an installed runner lacks that subcommand, the supported bazel run targets remain available. Updating a shared host installation is a separate operation from changing repository source.

Keep routine work small

Simple tasks need no durable goal. For work that needs a resume point, the goal checkpoint accepts a short summary, the current candidate, evidence references, and the next action. The store maintains the record’s identity and digests; show includes the active continuation. Detailed attempt review remains available for repeated failures and maintained project history. Local progress checkpoints do not trigger publication. Deliver at a meaningful review boundary or final handoff, with explicit remote backups when needed.

Delivery can execute a caller-selected Bazel validation plan and retain its results against the prepared candidate. Its continue command reports the next state; continue --publish explicitly requests publication using those results. The tool carries the candidate and receipt between steps. It does not decide task ownership, semantic sufficiency, or whether representative output satisfies the request. Changed candidates and rebases require fresh validation; uncertain publication outcomes require inspection before another mutation. Follow the owning README’s launcher instructions when validation itself invokes Bazel.

Supported guarantees

• Skill packaging validates canonical artifacts and discovery links. Evaluation payloads are separate from runtime skill bodies.
• Goal storage validates resource revisions and artifact digests, provides bounded continuation information, and supports recovery from interrupted publication. These checks establish record integrity; criterion verdicts still require appropriate evidence.
• Delivery binds the prepared candidate, scope, remote expectations, and pull-request identity. Exact leases and state checks protect publication. The caller selects and establishes the required validation; a preparation receipt is not a test result.
• Cordis provides bounded repository tools and supervised subprocess cleanup. Its package code is trusted. The documented process boundary is not a security sandbox.

Evidence and implementation limits

The coverage projection inventories configured cases. It does not measure successful routing or task completion. Offline configuration checks are useful hygiene; stronger claims require actual result artifacts identifying the source, fixture, execution, and judge where applicable.

The shared control contracts include admission and runtime-control libraries with unit tests. Their existence does not establish enforcement by production providers. Earlier phase acceptance records describe broader gateway and runtime guarantees than those unit tests demonstrate. Treat provider integration, process isolation, and runtime fault containment as unverified until a concrete consumer and corresponding integration evidence establish them. The roadmap retains that future work.

Stored control snapshots contain package observations. Their age, missing writer identity, and lack of a live heartbeat limit their interpretation. The status reader preserves those limitations and does not create a runtime or its storage directories merely to inspect them.

Improve from task outcomes

Measure representative questions, edits, recovery, and delivery tasks before claiming an instruction or workflow is faster or more reliable. Compare task success, unauthorized actions, context bytes, commands, duration, and resume steps against the prior behavior. Keep model and fixture identities with observations; do not infer measured improvement from configuration checks or the presence of a new schema.

The local comparison fixtures provide four bounded scenarios and an observer protocol. They cover question answering, a local prose edit, recovery after a changed postcondition, and a delivery validation decision. Their simulated observations do not exercise real publication. Unobservable routing, command, context, or token metrics remain unavailable; available instruction bytes are not the same as consumed context. Results belong with the exact task candidate, not in the configured coverage inventory.

Preserve useful safeguards while reducing repeated consumer instructions. Retire obsolete workarounds and completed tracking when justified. Clean runs after a fix are not a reason to remove useful diagnostics or regression tests. Historical proposals suggesting otherwise do not define current policy.

The architecture describes composition responsibilities. It does not replace these implementation boundaries or authorize new work.

3 - Repository agent-system architecture

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.

System thesis

The repository should have one composition protocol, not one mutable brain.

Each fact stays at its narrow natural owner. Typed, versioned references join facts across owners. Deterministic bounded projections make those joins cheap to read. An execution gateway enforces effects at the point where they occur. No catalog, agent, skill, plan, or receipt may silently become an independent authority.

This yields four structural rules:

1. One mutation authority per fact. A fact changes only at its owner.
2. Many derived views. Human maps, JSON catalogs, context capsules, and status views are replaceable projections with provenance.
3. Typed transitions. Cross-layer claims carry stable identities, versions or digests, completeness, and limitations.
4. Effects are admitted at execution. Selection and planning advise; explicit authority plus an executable contract controls mutation.

Physical co-location is not required for logical cohesion. Repository-agent documents and goals belong under projects/agents. A future repository-internal controller or executor may belong under tools/agents. Component declarations remain with their component.

Mutation authorities

The architecture owns only this composition model. It must not restate mutable component values. If two authorities conflict, a projection reports the conflict and its sources; it does not choose a winner. A relevant unresolved conflict blocks effectful admission.

Common artifact envelope

Cross-layer artifacts should share a small logical envelope. The roadmap owns the eventual schema and migration; payloads remain subsystem-specific.

ArtifactEnvelope
  apiVersion, kind, id
  producerRef
  authorityRefs[]?
  inputRefs[]: {kind, id, version?, digest, role}
  subjectRef?
  completeness: complete | partial | truncated | unknown
  limitations[]
  informationClass
  retentionClass
  digest

Observation or expiry times belong on live observations. Deterministic catalog content must not contain nondeterministic generation timestamps. Artifacts never contain credentials, secret-value hashes, personal information, environment dumps, absolute checkout paths, unreviewed raw logs, or full transcripts.

An authority reference is optional and repeatable. A deterministic catalog or ordinary observation does not gain authority merely by using this envelope. The artifact digest covers canonical schema-defined bytes without recursively including its own digest field.

A SubjectRef identifies the thing a claim is about. Depending on the claim, it can bind repository identity, base/commit/tree OIDs, the explicit task-owned dirty input set, relevant configuration and toolchain digests, an environment or remote resource selector, and a timed remote observation. Claims must not use a weaker subject merely because it is easier to obtain.

The abstraction tower

Each layer consumes contracts from the layer above, adds one kind of fact, and produces a bounded contract for the layer below.

0. Intent, outcome, and authority

Owner: the user interaction; durable acceptance belongs to the goal when one exists.

Input: the request, explicit constraints, and prior accepted context.

Output: an outcome, acceptance questions, scope, authority envelope, and resource limits.

Invariant: a question, skill selection, plan, prior permission, or tool availability never widens authority. Conditional authority is usable only after its condition is evidenced. Missing authority is unknown, not permission.

Repository policy may define an explicit implementation request to include ordinary feature-branch commit, publication, and review through the delivery workflow. That default must be visible in the authority envelope and never extends to tags, releases, deployments, infrastructure changes, or destruction.

Simple bounded tasks may keep this state in the active interaction. Iterative, delegated, or resumable work uses a durable goal and attempt.

1. Topology, classification, and ownership

Owners: paths, nearest READMEs, CODEOWNERS, MODULE.bazel, BUILD files, and explicit boundary declarations.

Input: workspace identity plus affected paths or labels.

Output: component and workspace identity, applicable policy sources, review accountability, dependency role, and classification axes.

Invariant: keep these axes independent:

• checked-in source disclosure;
• log and evidence handling;
• Bazel target visibility;
• allowed build consumers;
• artifact and documentation publication; and
• secret or personal-information presence and live-environment association.

Checked-in content in this public repository is public information unless it contains an accidental secret or personal information. Operational facts do not become confidential merely because they are generated or live, but raw artifacts require inspection because they can contain prohibited content. Public information status does not make a target eligible for production consumption or artifact publication.

2. Policy and action admission

Owners: applicable AGENTS.md, owner-local policy, and the executable provider or owning build macro.

Input: authority envelope, topology slice, and requested operation.

Output: an admission decision with stable reason codes, required preconditions, and an exact allowed effect set.

Invariant: every runnable operation declares atomic effects such as:

source.read       source.write       task_state.write
host.write        history.write      code.execute
credential.consume
network.read      remote.write       remote.destroy

The executable/provider owns effects; a skill references them rather than copying them. Unknown effects fail closed. Known read-only discovery may degrade visibly. Remote writes and destruction require exact resource, environment, candidate, pre-state, authority, and expiry bindings.

history.write is distinct from source.write: commits, local ref moves, tags, and rewrites alter history even when worktree bytes do not change. Operation scopes such as edit, commit, feature publication, review mutation, release-ref publication, deployment, and destruction map to additive atomic effects rather than substituting for them.

Review accountability, component ownership, task path/hunk or commit ownership, goal-storage ownership, remote-ref ownership, external-resource ownership, and user authority are separate relations. Unknown ownership fails closed for history rewrite, credential expansion, publication, remote mutation, and destruction.

3. Capability and provider selection

Owners: canonical skills for routing and procedure; executable and runtime providers for actual capability contracts.

Input: intent, policy slice, available providers, effects, evidence maturity, and cost.

Output: the smallest sufficient capability set, ordering, exclusions, fallbacks, and an explanation of every choice.

Invariant: selection is advisory and never grants authority. Required dependencies are acyclic. Conflicts, unavailable providers, unsupported platforms, and unverified behavior are explicit. Full instructions and schemas load only after compact metadata selects them.

4. Durable work and planning

Owner: the current task coordinator and, for durable work, owner-local goal resources.

Input: intent, criteria, context slice, capability choices, prior evidence, and relevant defects.

Output: a WorkPacket or goal attempt plus CapabilityPlan and ActionPlan, with exact inputs, affected criteria, hypotheses where needed, checks, omissions, fallbacks, fixed regressions, budgets, stop conditions, and a strategy-reset condition.

Invariant: a plan does not authorize and does not prove. Delegated workers receive immutable bindings and disjoint output ownership; only the coordinator mutates canonical goal state. A repeated stable defect changes strategy rather than accumulating indistinguishable retries.

5. Execution providers

Owners: Bazel and bazel_agent, native repository tools, Cordis or another runtime provider, and explicit external adapters.

Input: admitted operation, exact subject and inputs, task/run identity, deadline, quotas, and cancellation contract.

Output: immutable ActionReceipt records plus bounded task-local raw-log pointers.

Invariant: executors remain thin and signal-transparent. Scratch is isolated by workspace, task, run, and worker; generated execution receives only declared filesystem, environment, process, network, and credential capabilities. Desired and observed state remain separate. A control kernel must stay responsive when optional data-plane extensions fail.

6. Observation, evidence, and acceptance

Owners: providers own observations; the task or goal acceptance policy owns semantic sufficiency.

Input: receipts, subject, validation profile, declared policy, known limitations, and—only for semantic judgment—a criterion revision.

Output: three distinct records:

• EvidenceEvaluation derives applicable, stale, insufficient, unavailable, or unverifiable with stable reasons;
• execution-owned, criterion-neutral ValidationSet aggregates exact candidate, plan/check identities, sanitized invocations, provider/configuration provenance, results, coverage, and limitations; and
• goal/task-owned EvidenceAssertion applies evidence to an exact criterion and subject with satisfied, not_satisfied, or unknown.

Invariant: receipts prove what ran and what was observed; they do not prove that selected checks were semantically sufficient. One immutable validation set may support non-goal delivery and multiple criterion assertions. Partial, truncated, skipped, or unknown evidence cannot support complete coverage. Reuse requires matching relevant input, policy, contract, configuration, toolchain, and subject-class digests.

7. Delivery, review, version, and release

Owners: Git and the forge own remote facts; repository delivery owns feature publication and review operations; versioning and release keep their separate identities.

Input: exact candidate, authority, an applicable criterion-neutral ValidationSet, expected remote state, and operation-specific policy.

Output: delivery, synchronization, review, version, release, and deployment receipts linked by exact subject references.

Invariant: use the effectful protocol:

inspect -> prepare -> immutable candidate -> validate -> authorize
        -> execute -> verify -> receipt

Delivery validates candidate-bound evidence but does not select semantic checks. Feature publication does not imply tag or deployment authority. Version identity and release snapshot identity are joined by a typed handoff, not by assuming that any Git tag has the same meaning.

8. Reviewed learning and accretion

Owner: the component that will adopt the lesson through ordinary review and delivery.

Input: exact task evidence, review dispositions, stable defect identity, measured friction, and regression results.

Output: a LearningProposal, then—only after acceptance—an owner-local document, contract, check, evaluation, skill, or global invariant.

Invariant: learning is never automatic mutation. It is minimized, public, reviewed, regression-backed, measurable, reversible, and given a retirement path. Runtime promotion creates a normal candidate; it does not write project source or goal state directly.

Provenance spine

The complete traversable chain is:

ContextCapsule
  -> GoalAttempt / WorkPacket
  -> CapabilityPlan / ActionPlan
  -> AuthorityBinding + AdmissionDecision
  -> ActionReceipt(s)
  -> EvidenceEvaluation + ValidationSet + EvidenceAssertion(s)
  -> accepted candidate
  -> Delivery / Review / ReleaseRef / ReleaseManifest / Deployment receipts
  -> GoalOutcome
  -> LearningProposal / LearningAdoption

The logical records serve distinct purposes:

• ContextCapsule says what was known, applicable, authorized, available, stale, and omitted before planning.
• WorkPacket says what outcome and criteria a bounded unit will pursue.
• CapabilityPlan and ActionPlan say what was selected, omitted, ordered, budgeted, and expected to prove the result.
• AuthorityBinding and AdmissionDecision say which exact effects, subject, environment, policy, pre-state, and expiry were checked before execution.
• ActionReceipt says what provider executed or observed against which exact inputs and with what result and resource use.
• ValidationSet records criterion-neutral check execution and coverage; EvidenceAssertion makes the separate criterion judgment.
• Delivery, review, release-ref, manifest, and deployment receipts say which external transition occurred and which postcondition was observed.
• GoalOutcome records durable acceptance or the honest terminal state.
• LearningProposal requests owner review; LearningAdoption identifies the exact accepted change, regression, delivery, and measured effect.

Plans do not authorize. Receipts do not judge semantic sufficiency. Delivery receipts do not prove that validation selection was complete. Learning proposals do not edit policy.

Every edge binds the relevant subject and catalog-slice, policy, contract, and input digests.

Temporal work loop

The tower defines composition; this loop defines control over time:

Orient -> Bind -> Plan -> Admit -> Act -> Prove -> Decide
                                              |-> replan
                                              |-> deliver -> verify -> close
                                              |-> wait or escalate
                                              `-> stop
                                                     |
                                                   Learn

Orientation obtains the smallest context capable of exposing uncertainty. Binding freezes the intended outcome, exact subject, authority, criteria, and budgets. Planning names omissions, fallback, stop conditions, and the cheapest evidence capable of falsifying the current hypothesis. Admission checks the exact plan against current policy and pre-state. Decision either accepts, changes strategy, waits for named external state, escalates authority, or stops honestly.

A declared transient failure permits at most one same-input retry. A deterministic recurrence requires a changed hypothesis or strategy. A remote operation with unknown postcondition is observed and reconciled before any second write.

Bounded context capsule

The target zero-context interface is one read-only, bounded projection. It may be a repository tool and optionally an MCP surface, but it cannot require MCP to function. It contains:

• repository, workspace, worktree, revision, and dirty-input identity;
• task/session, coordinator, worker, and run identity;
• requested outcome, authority, budgets, and durable goal binding if any;
• applicable instruction and owner-document paths with digests;
• component, workspace, review owner, and classification slice;
• candidate capabilities with effects, cost, dependencies, providers, and evidence maturity;
• provider boot/incarnation ID, catalog ETag, desired/observed revisions, action-contract hashes, observation time, expiry, and unavailable reasons;
• relevant checks and reusable evidence, not raw logs; and
• provenance, observation time, freshness, completeness, truncation, and safe next discovery actions.

The capsule is a join over owner-local catalogs and observations. It stores no independent truth. A missing optional provider yields a structured unavailable field; it does not make the whole capsule fail.

Resource economy

An agent climbs this cost ladder only when existing evidence cannot answer the acceptance question:

1. checked, cached metadata and narrow source reads;
2. targeted static queries and reusable subject-bound receipts;
3. narrow local builds and tests;
4. broad or uncached validation;
5. external reads and stochastic/model-assisted evaluation; and
6. authorized remote mutation or destructive work.

Budgets inherit from repository defaults to task to plan to operation/worker. A child may narrow but never silently expand a hard bound. Reserve capacity for cancellation cleanup and final verification. Track context/input bytes, compute and target/workspace scope, elapsed time, output/log/artifact bytes, retention, retries, worker fan-out, concurrency, and cacheability. Use measured p50/p95 workloads to set numeric defaults.

Credentials, network access, history or remote writes, and destruction are non-fungible authority scopes, never spendable budget. Compatible Bazel work is batched. Context loads summaries and digests first, then full bodies, schemas, source, or logs only on demand. A global catalog change triggers cheap applicability reevaluation, not automatic reruns of unrelated evidence.

Accretion protocol

sanitized bounded friction event
  -> aggregation by stable signature and consequence
  -> LearningProposal with destination owner
  -> minimized regression or routing fixture
  -> destination-owner review
  -> one appropriate contract, policy, tool, test, or skill change
  -> normal validation and delivery
  -> LearningAdoption and regenerated evidence status
  -> recurrence and resource measurement

Raw transcripts, credentials, unreviewed runtime values, secret-bearing logs, personal information, and accidental local state never enter the promotion path. Ignored task-private out/<task>/ may temporarily contain secret-bearing material under restrictive access and cleanup, but that material is not tracked or imported as durable evidence. A global invariant is an exceptional owner-approved destination, not the automatic final rung of the sequence.

Failure and degradation semantics

• unknown means the system lacks a fact; it is not false, safe, or allowed.
• unavailable names a provider or source that could not be observed.
• stale means a once-valid observation no longer matches its applicability inputs.
• partial and truncated bound what a result can prove.
• Desired state and observed state are always separate fields.
• Runtime observations identify boot/incarnation, catalog, desired and observed revisions, action contract, observation time, and expiry.
• Provider lifecycle is explicit: loading, ready, degraded, failed, timed_out, draining, or disabled.
• Shared mutable task, goal, and runtime state uses a cross-process lock or lease plus expected version/digest; atomic rename alone is not concurrency control.
• Nested work uses one absolute deadline with cancellation and cleanup margin.
• Failures carry phase, stable code/signature, subject, observed state, valid partial result, retry class, cost spent, redacted artifact references, and next safe action. Retry class is never, same-input-once, after-state-change, or requires-human.
• Read-only discovery returns the useful safe subset with explicit gaps.
• Effectful admission fails closed on unknown effects, authority, environment, subject, policy conflicts, or relevant stale state.
• Secret-bearing raw output stays in task-private scratch and only a bounded allowlisted summary may cross into ordinary evidence.

Measures

Optimization is evaluated with representative zero-context tasks, not by file count or architectural novelty. Track at least:

• task correctness and unsupported-claim rate;
• unauthorized or incorrectly scoped mutation rate;
• reads, tool calls, context bytes or tokens, and elapsed/resource cost before the first correct action;
• redundant checks and exact evidence reuse rate;
• steps and missing facts required to resume durable work;
• stale, partial, and conflict detection accuracy;
• provider startup and degraded-status latency; and
• the rate at which repeated defects gain a regression, owner, delivery identity, and eventual retirement.

Non-goals

• No hand-maintained central manifest duplicating owner-local facts.
• No universal mega-skill or always-loaded copy of every procedure.
• No mandatory daemon, database, vector store, or runtime extension for basic orientation and safe degradation.
• No raw transcript ingestion, secret promotion, or automatic doctrine edits.
• No inference of authority from selection, planning, receipts, ownership, or tool availability.
• No durable goal requirement for a simple one-step task.
• No broad //... validation or live model evaluation by default.
• No physical repository reorganization merely to make the conceptual model look centralized.

4 - Repository agent-system roadmap

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.

Local simulated delivery scenarios can exercise candidate selection and validation decisions without publishing anything. They do not prove forge integration, remote concurrency, or successful real publication. Use the owning delivery integration tests for their encoded cases, and distinguish those tests from model behavior.

Reduce repeated common-path instructions and load exceptional procedures only when their triggering condition occurs. Keep exact candidate, task ownership, authority, leases, recovery, and review completion requirements. Improve entrypoint capability detection and workspace-relative path handling before introducing another execution interface.

Acceptance requires measured task outcomes with no new critical boundary failures. A small exploratory comparison is useful evidence, not a universal performance claim. Retain useful diagnostics and regressions after clean runs; remove obsolete workarounds and completed tracking when their purpose expires.

Next: reduce manual discovery and validation work

Extend bounded offline context only with facts that have an identifiable owner and observation method. Prefer observed Git state and direct routes to applicable policy, owner documentation, build declarations, and explicit goal records. Never infer authorization or task-to-goal association from proximity, ownership, a catalog entry, or an available tool.

Check suggestions must explain their selection basis and uncovered scope. Nearest-package selection is not dependency analysis. Root configuration, build-graph changes, ignored paths, and nested workspaces can require explicit checks beyond the returned labels. Avoid accidental broad builds while keeping the mandatory repository quality and affected semantic checks.

Delivery preparation binds the candidate and publication expectations. The caller selects applicable validation. The delivery tool can execute that plan, record candidate-bound results, and carry them into explicitly requested publication. The manual publication path also remains supported. Neither a preparation receipt nor an asserted commit ID proves that tests ran. Broader evidence imports must specify their trust boundary and preserve caller responsibility for semantic sufficiency.

Reuse observations only while their relevant inputs remain unchanged. Reuse test evidence across a message-only amendment only when tree, configuration, toolchain, environment, and every other relevant input are stable. Rerun commit-sensitive or uncertain checks. A receipt alone never establishes reuse.

Acceptance requires representative edits to select sufficient checks, explain omissions, and invalidate evidence when a relevant input changes. Preserve cheap read-only discovery when optional providers are unavailable.

Expand behavioral evidence when it answers a concrete question

The configured coverage inventory is not a successful-run ledger. Extend routing scenarios across positive, adjacent-negative, inert-payload, exclusion, conflict, and composition cases when the corresponding skill is changed or a recurring failure demonstrates a gap.

Stronger aggregated evidence needs actual execution artifacts bound to the source, fixture, model or provider, and judge where applicable. Keep live stochastic evaluations manual or scheduled and separate from normal wildcard tests. Use isolated writable fixtures for Git, Bazel, forge, infrastructure, secret-handling, and runtime trajectories before making claims about them. Never reuse shared authentication in a mode that requires exclusive access while concurrent sessions are active.

Promote a repeated lesson only with an owner, minimized public reproducer, regression, supported contract, fallback, measured cost, delivered revision, and a reasoned retirement rule. A schema or proposal does not establish that this learning loop runs automatically.

Runtime integration remains conditional work

Shared admission and control libraries have unit-test coverage. Production provider enforcement, process isolation, and runtime fault containment remain unverified. Build further runtime machinery only for an identified consumer whose required behavior and failure modes justify it.

For that consumer, test bounded status during a stuck extension, package deadlines, desired versus observed revision, cancellation and cleanup, cross-task storage isolation, and the actual filesystem, process, network, credential, and output boundaries. Trusted in-process code is not a security sandbox. A source contract cannot substitute for consumer integration evidence.

Keep bounded native and offline fallbacks available. A missing optional provider must produce an explicit unavailable result rather than preventing ordinary repository work.

Constraints on further work

• Facts remain at their owning sources; generated views carry provenance and limits rather than becoming new mutation authorities.
• Keep goals, delivery, release, review, and provider state separate. Add joins through typed references only when a real workflow needs them.
• Do not add a mandatory daemon, database, vector store, network call, or central orchestrator for basic orientation.
• Do not relocate components merely to match conceptual diagrams.
• Keep reviewed evidence bounded and free of credentials and personal data.
• Use workspace goals for temporary coordination and owner-local maintained records only when durable project history is justified.
• Choose the least costly check that answers acceptance; broad audits remain separately scoped work.