review: tighten gix-steward — cross-cutting value per call + caller discipline#1
Closed
review: tighten gix-steward — cross-cutting value per call + caller discipline#1
Conversation
Roadmap captures the brit vision: semantic layer over rust-ipfs with pillar-trailer metadata (lamad / shefa / qahal) carried in commit trailers plus optional linked ContentNodes. Seven phases from workspace scaffolding through fork-as-governance. Phase 0+1 is implementation-ready: - brit-epr crate with PillarTrailers, parser, validator - brit-verify CLI binary, end-to-end smoke tested - Zero modifications to gix-* crates (upstream-rebaseable) - RFC-822 trailer format round-trips through stock git Name rationale: brit (בְּרִית, "covenant") rhymes with git — git is the substrate, brit is the covenant laid on top. A commit is a witnessed agreement whose terms are the three pillars. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Enumerates every ContentNode type brit introduces to the Elohim Protocol vocabulary, with pillar couplings (lamad / shefa / qahal), relationships, signals, and the feature-module boundary that keeps brit-epr usable as a generic trailer engine. Exploration only — no code yet. Subsequent tasks consume this doc to revise the Phase 0+1 implementation plan and scaffold the brit-epr crate. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Elohim Protocol manifest for brit as an LLM-first development tool
that stays backward-compatible with stock git hosting. Enumerates:
- brit-epr engine vs. elohim-protocol app schema feature boundary
- LLM-first CLI command surface (git-analogous verbs)
- Skill + template artifacts for trivial LLM-driven committing
- ContentNode type catalog (Repo/Commit/Tree/Blob/Branch/Tag/
Ref/Fork/DoorwayRegistration/PerBranchReadme + extension slots)
- Commit trailer specification (canonical summary, hybrid (c))
- Linked-node resolution protocol via doorway bridge
- Backward compatibility with GitHub/GitLab/Codeberg/sourcehut
- Protocol signals brit emits
- Doorway registration format
- Cross-references to the p2p-native build system roadmap
Exploration only — no code. Next task consumes this doc to revise
the Phase 0+1 implementation plan and scaffold the brit-epr crate
behind the elohim-protocol cargo feature.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…(closed vocabulary) Two §14.1 open questions resolved after human review: §14.1 GitoxideLabs#3 — Steward key recovery is NOT a brit-schema concern. It lives in the Elohim Protocol social recovery substrate: the steward's key material is stored as sharded blobs EPR-addressed to family, friends, and institutions, and recovery reconstitutes N-of-M shards from that social graph. Solo repos are not a special case — every repo has a social recovery graph underneath because the protocol substrate guarantees one. §10 updated to reflect this; co-steward quorum rotation remains valid as a layered safety mechanism, not a replacement. §14.1 GitoxideLabs#6 — Pillar vocabulary is CLOSED within the elohim-protocol app schema. The extensibility axis is the feature-module boundary itself: different apps (carbon-accounting, music-composition, etc.) supply their own EPR manifests through their own app schemas plugged into the same brit-epr engine. Per-repo commit-template.yaml carries DEFAULTS and HINTS, not enum extensions. §6.5 example block relabeled from "enum extras" to "defaults and hints". §14.1 GitoxideLabs#4 (brit merge async default) remains open and is being pressure-tested against distributed stewardship + collective consent in a separate critique pass. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Pressure-tests the §14.1 GitoxideLabs#4 lean (async-by-default with --wait escape hatch) against 7 distributed-stewardship and collective- consent scenarios. Affirms / modifies / replaces the design based on findings. Identifies where the current §3.9 merge flow, §9 signals, and §14.1 GitoxideLabs#12 protection rules DSL need adjustment to support consent that is distributed in time and space. Findings only — no schema edits applied yet; those are listed as concrete proposals for a subsequent edit pass. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…ync-default resolved
Applies the concrete schema changes proposed by the 2026-04-11 merge
consent critique pass and adds the parent-EPR governance framing from
human review.
Changes:
§3.1 — brit merge command row rewritten to reference §5.13 proposal
lifecycle, JSON stdout contract, --wait as polling-cap,
--withdraw flag, explicit "brit does not own governance" note.
§3.1 — brit attest row reframed as unified attestation + consent
surface; --proposal <id> --consent and --as-delegate-of for
delegated consent.
§5.12 — MergeConsentContentNode marked superseded by §5.13.
§5.13 NEW — MergeProposalContentNode promoted from reserved slot to
fully specified type. Content-addressed immutable core,
mutable state signal-driven. State machine open →
partially-satisfied → consented | rejected | expired |
withdrawn. Required/optional fields. Critical framing: brit
owns the proposal type; the parent EPR owns governance.
Adapter at the doorway projects between brit and the parent
EPR's governance engine. Same model as GitHub branch
protection — brit enforces policies configured by the parent
EPR, doesn't invent governance.
§5.14 — existing "Cross-cutting: what's deliberately not a new type"
renumbered to make room for §5.13.
§9.1 — signal catalog: brit.merge.proposed payload rewritten to
carry proposal_cid + frozen requirements. Four new signals:
brit.merge.tally.progress, brit.merge.requirement.satisfied,
brit.merge.expired, brit.merge.withdrawn. brit.merge.consented
payload extended with consenting_kind and consenting_agents.
§14.1 GitoxideLabs#4 — RESOLVED. Async-by-default with §5.13 lifecycle. Parent-
EPR framing: brit reads protectionRules pointing at a
qahal_node in the parent EPR's governance context; brit
freezes the resolved requirements into the proposal; the
parent EPR's governance engine runs the tally. Phase 1 scope
explicitly EXCLUDES merge consent — trailer foundation only.
§14.1 GitoxideLabs#12 — entanglement with §14.1 GitoxideLabs#4 noted. Protection rules DSL
and merge consent co-resolve in a single Phase 2 design pass.
Critic findings at docs/schemas/reviews/2026-04-11-merge-consent-critique.md.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…overnance
The earlier schema invented branch-level "protection rules" as a
brit-specific governance concept. Human review pointed out that
every ContentNode in the protocol already has reach (qahal visibility
coupling), so every brit branch already HAS a reach — we just hadn't
named it as the central primitive. Naming it changes the shape of
the whole merge + governance story.
Changes:
Reach enum vendored from Elohim Protocol:
schemas/elohim-protocol/v1/enums/reach.schema.json
["private", "self", "intimate", "trusted", "familiar",
"community", "public", "commons"]
All DNA-notarized, enforced by doorway, consumed by brit at
build time (standalone — no path dep on elohim monorepo).
§5.5 BranchContentNode
- Reach added as a REQUIRED field, drawn from the vendored
protocol enum. Reach is per-ref (the branch has the reach;
commits inherit the reach of the ref that reaches them).
- protectionRules → extraProtectionRules (optional extras
LAYERED ON TOP of reach-change rules, not a replacement).
- New "Branch lifecycle through reach" section showing how
a feature branch climbs self → trusted → community → public.
- "Exploratory peer model" paragraph: a branch at reach=self
is an LLM agent's experiment; nothing propagates. Trust
elevation is first witness act.
§5.13 MergeProposalContentNode
- Retitled: "also known as a reach-elevation proposal".
- sourceReach and targetReach added as required fields.
- reachElevation derived boolean; false cases take fast paths.
- requirementsFrozen now says: "derived from the protocol's
reach-change governance rules for the sourceReach → targetReach
transition, plus extras".
- Framing text explicit: brit is NOT inventing merge governance;
it's using the same reach-change machinery that governs every
other reach elevation in the protocol. A commit becoming
visible to the network is no different from any other piece
of content becoming visible to the network: the reach gate
applies.
§9.1 signal catalog
- brit.branch.created payload includes reach.
- brit.branch.reach.elevated NEW — gossipped when a branch's
reach climbs (self → trusted, trusted → community, etc.).
- brit.branch.reach.reduced NEW — quarantine / withdrawal.
- brit.branch.protection.changed renamed to
brit.branch.extra-protection.changed to reflect that reach
changes have their own signals.
§14.1 GitoxideLabs#12 RESOLVED (mostly dissolved)
- The "force-push policy DSL" open question largely disappears
into the reach reframe. Reach is the central governance
gate on branches; reach-change consent rules already exist
in the protocol. extraProtectionRules is a small residual
for additive constraints (e.g., "public branch ALSO
requires security-audit attestation").
- The entanglement with §14.1 GitoxideLabs#4 is reduced: MergeProposal's
requirementsFrozen = (reach-change rules at target reach)
+ (extras from extraProtectionRules). Both from the
substrate, not a brit-specific language.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Rewrites the Phase 0+1 implementation plan to reflect the schema work:
- Engine vs. app-schema boundary established from Task 0. The
brit-epr crate ships with an unconditional `engine` module
(AppSchema trait, TrailerSet, trailer block parser, errors) and
a #[cfg(feature = "elohim-protocol")] `elohim` module with the
concrete ElohimProtocolSchema implementation.
- Phase 1 scope tightened: commit trailer parsing + structural
validation + brit-verify CLI. Explicit exclusions:
* MergeProposalContentNode + async merge consent (Phase 2+)
* Reach awareness on branches (Phase 2+)
* ContentNode adapter (Phase 2+)
* CID parsing / resolution — raw strings only (Phase 2+)
* Signal emission (Phase 2+)
* libp2p transport (Phase 3+)
* Full brit-cli subcommand surface (Phase 3+)
- Tasks restructured around the engine/elohim split:
Task 0 Scaffold crate with feature-module layout
Task 1 Engine — AppSchema trait, TrailerSet, errors
Task 2 Engine — parse_trailer_block via gix-object (TDD)
Task 3 Elohim — PillarTrailers, TrailerKey, schema impl
Task 4 Elohim — parse_pillar_trailers (TDD, 3 fixtures)
Task 5 Elohim — validate_pillar_trailers (TDD, 4 cases)
Task 6 brit-verify CLI (end-to-end smoke test)
Task 7 Submodule pointer bump in parent monorepo
- References schema doc as source of truth for types. When plan
and schema disagree, schema wins and the plan gets a follow-up.
- --no-default-features build check in Task 5 Step 5.5 proves
the engine compiles without the elohim module — the boundary
check that keeps brit legible as a standalone gitoxide fork.
Supersedes 42e04b0's initial draft. 1479 lines, 7 tasks, ~40
bite-sized steps.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Establishes the engine-vs-app-schema boundary from day 0. The engine module is unconditional; the elohim module is gated behind the elohim-protocol cargo feature (default on). Subsequent tasks land the trait, types, parser, and validator. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Engine layer is now independently compilable with --no-default-features. Proves the engine/app-schema boundary holds from day 0: the engine knows nothing about Lamad/Shefa/Qahal specifically. trailer_block.rs is a stub that Task 2 replaces with the real gix-object-backed implementation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Wraps gix_object::commit::message::BodyRef::trailers() into a schema-agnostic TrailerSet. Engine-level tests prove extraction works for happy path (4 trailers in canonical order) and no-trailers case. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ElohimProtocolSchema implements AppSchema with closed vocabulary (Lamad/Shefa/Qahal summary keys + their -Node CID counterparts). Phase 1 stores raw CID strings without parsing — CID resolution arrives in Phase 2. parse.rs and validate.rs are stubs that Tasks 4 and 5 replace with the real implementations. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Projects engine's schema-agnostic TrailerSet into the typed PillarTrailers view. Permissive: unknown trailers skipped, malformed node refs stored as raw strings. Three fixtures cover happy path, partial declaration, and malformed node-ref. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
validate_pillar_trailers enforces all three pillar summary trailers are present and non-empty. Errors in canonical order Lamad → Shefa → Qahal. No CID resolution, no graph traversal — those are Phase 2. Closes out brit-epr crate for Phase 1: 9 tests passing (engine 2, elohim parse 3, elohim validate 4), engine compiles cleanly with --no-default-features. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Opens a repo, resolves a rev, parses pillar trailers via brit-epr, runs structural validation, exits 0/1/2/3. No clap, no tracing — smallest possible end-to-end proof that the engine + elohim schema work against real git objects. Smoke-tested end-to-end during implementation: - valid commit with all three pillars → exit 0, pillars printed - upstream gitoxide commit → exit 1, missing pillar reported Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replaces gitoxide's stock README with the brit vision document.
Covers:
- Why: siloed economic/informational/social power and how coupling
the three pillars (lamad/shefa/qahal) at the protocol level
addresses it
- Four concrete unlocks:
1. Built-in contributor payment (shefa flows with the commit)
2. Provenance-aware code (choose who stewards the code you depend
on — Amazon vs Coop AWS example)
3. Deployment-aware code (EPR links that resolve per branch/env)
4. Fully distributed landing via IPFS/IPLD — but unlike other
crypto/P2P projects, landing in a network designed to scale
wisdom and care, not speculation
- How: commit trailers (backward-compat RFC-822), doorway bridge
(web2 ↔ protocol), engine/app-schema split (pluggable by design)
- Status, quick start, relationship to gitoxide, further reading
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…ward roadmap Brings brit's documentation to the same level as rakia: - Design spec (docs/specs/2026-04-12-brit-design.md): formal spec capturing schema manifest decisions, acceptance criteria, design decisions, open questions - Composition model (docs/composition.md): how brit composes with rakia, protocol schemas, rust-ipfs, storage/steward infrastructure - Phase 2-6 summaries (docs/plans/phases/): each phase documented with vision, prerequisites, sprint sketch, risks, and what it unlocks for rakia and the protocol - Roadmap reframed by protocol capability (docs/plans/README.md): phases decomposed by what the protocol gains, not what crate gets written. Parallel evolution table with rakia. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Recovered Phase 2a design doc (build attestation primitives) placed in docs/plans/phases/. Implementation plan at docs/plans/. Added .worktrees/ to .gitignore for future worktree isolation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Introduces the ContentNode trait for CID-addressed serialization and LocalObjectStore for filesystem-backed content-addressed object storage under .git/brit/objects/. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Adds AgentKey for load-or-generate keypair management (32-byte seed files) and a standalone verify_signature function for hex-encoded ed25519 signatures, wiring the signing module into the engine's public API. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Adds BuildAttestationContentNode, DeployAttestationContentNode, and ValidationAttestationContentNode under the elohim::attestation module, each implementing ContentNode with camelCase serde and 5 roundtrip tests. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Introduces BritRefManager with read/write/list operations for build, deploy, validate, and reach ref families under refs/notes/brit/. Uses git notes for per-commit build refs and blob refs for standalone deploy and validation refs. Path segments are percent-encoded to sanitize step names containing colons and at-signs. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Adds ReachLevel enum (Unknown < Built < Deployed < Verified) and compute_reach() function that derives reach from the presence of build, deploy, and validation attestations deterministically. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
… refs Implements the `brit-build-ref` binary (Task 7, Phase 2a) with clap 4 derive API. Supports put/get/list for build (per-commit notes), deploy, and validate refs, plus reach compute/get. All commands auto-load/generate an ed25519 agent key, sign attestation payloads, and store nodes in the local object store. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Re-export attestation types at crate root behind elohim-protocol feature flag. Engine-only build verified: --no-default-features still compiles. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Mark Phases 0 and 1 as complete. Add Phase 2a (build attestation primitives) to the roadmap table with link to implementation plan. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace redundant closure with method reference in list_refs_under. Allow too_many_arguments on build put function (CLI arg passthrough). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- canonical_json now recursively sorts JSON object keys via BTreeMap, making CID computation truly order-independent across implementations - list_refs_under decodes percent-encoded segments so callers see original step/check names (fixes reach compute with colon steps) - Agent key file written with 0600 permissions on unix (private key must not be world-readable on shared CI) - Object store uses atomic write (temp + rename) to prevent partial files on crash - Replaced unwrap() on stdin pipe with proper error propagation Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…Remote, Normalizer, BritInvocation stubs)
… (--check/--update/--candidate)
…ne/fetch/push tests)
…ith stable-SHA allowlist)
…s + optional normalization)
…g + library facade
…ncovered + percent)
…command captures)
…+ discovery + format + diff Replaces scaffold main.rs with full runner: discovers subcommands via recursive --help, invokes cli-journey tests into staging, formats the markdown test page, and dispatches on check/update/candidate mode. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…l 8 subcommands with staging dump Adds rakia.sh shell smoke (--help + no-arg exit-2), sources it from journey.sh, and adds cli-journey/tests/rakia.rs with one test per leaf subcommand. Each test dumps normalized output to BRIT_TEST_PAGE_STAGING/rust/rakia/<path>.txt using the hierarchical staging_dump_path helper so the runner reconstructs full paths (e.g. graph/discover.txt, baseline/read.txt). All 8 tests pass; 8 staging files produced in correct directory hierarchy. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…staging dump brit-verify is a single-purpose binary (no clap, no subcommands). Three tests cover: no-args usage error (exit 2), missing trailers (exit 1), and valid trailers round-trip (exit 0). Adds commit_file_with_message to TestRepo to support commits with custom messages (e.g., pillar trailers). Staging artifact lands at rust/brit-verify.txt showing the validated passing output. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
… all leaf subcommands 11 leaf subcommands covered (build/deploy/validate: put+get+list; reach: compute+get). Each leaf has a Rust test that invokes against a temp repo and dumps captured output to BRIT_TEST_PAGE_STAGING/rust/brit-build-ref/<group>/<leaf>.txt. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…og, status, diff, branch, commit, clone, fetch, push, tag, blame, cat) 16 tests cover all 11 daily-driver slots. brit push is not yet implemented in gitoxide — documented as a gap with a placeholder staging dump. diff expands to two leaves (tree, file); commit expands to two leaves (describe, verify); branch and tag each have list; clone and fetch exercise MockRemote with file:// transport. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Available for per-binary journey shells (rakia.sh, brit-verify.sh, brit-build-ref.sh) to feed shell-side captures into the cli-test-page runner's staging directory. No-op when BRIT_TEST_PAGE_STAGING is unset so journey.sh stays standalone-safe. Not yet wired into the existing shell tests because Task 17's recast moved the rich CLI coverage into Rust integration tests (where the structured-output binaries can be asserted on properly). The helper exists for future shell-only test scenarios where Rust tests are inappropriate (e.g., terminal-attached interactive subcommands). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…oughput; commit initial baseline Normalizer now redacts: - HH:MM:SS clock times → <CLOCK> (gitoxide progress lines) - X.XXs durations → <DUR> - throughput rates (objects/s, MB/s, etc.) → <RATE> These are pervasive in gitoxide's progress output and were causing non-determinism between consecutive test runs. Initial baseline.md committed: - brit: 12/70 covered (17%) — daily-driver subset - rakia: 8/8 covered (100%) - brit-verify: 1 binary, single capture - brit-build-ref: 11/11 covered (100%) - Total: 31 / 89 across the 4 binaries Coverage gap on brit (58 uncovered subcommands listed in baseline.md) becomes the carry-over for follow-up sprints to chip away at as we dogfood. Each subcommand can be added in ~10 lines (TestRepo + invocation + staging dump). Known remaining non-determinism: brit cat output varies (5 lines of diff between consecutive runs). Probable root cause: brit cat on a commit SHA sometimes resolves to commit text, sometimes to underlying blob. Captured as carry-over. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sprint: 2026-04-19 brit CLI test page.
- cli-journey crate: TestRepo + MockRemote + Normalizer + BritInvocation
helpers (15 self-tests) + per-binary integration tests for rakia,
brit-verify, brit-build-ref, and 11 daily-driver brit subcommands
(23 tests total in cli-journey)
- cli-test-page crate: brit-test-page binary with --check/--update/
--candidate modes, recursive --help discovery, coverage tracking,
markdown formatter, similar-crate diff (11 self-tests)
- tests/baseline.md: initial committed artifact, 31 covered subcommands
across 4 binaries (34% combined; 100% on the 3 small binaries;
daily-driver subset on brit)
- Normalizer redacts ANSI/tempdir/timestamp/SHA + (this sprint)
HH:MM:SS clock times, X.XXs durations, throughput rates
- dump-to-staging helper added to utilities.sh for future shell-only
test scenarios
Discoveries captured in sprint-result:
- brit push not implemented in gitoxide upstream (gap notice in baseline)
- brit commit is verify/sign/describe, not "make a commit"
- brit branch and tag only have list subcommands
- brit diff has its own subcommand tree (tree/file)
- brit-verify uses hand-rolled arg parser, not clap
Sprint artifact: docs/superpowers/sprint-results/2026-04-19-brit-cli-test-page.md
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Latest upstream snapshot as of 2026-04-20. No push or commit-creation changes relevant to our daily-driver gap (gitoxide's crate-status.md confirms both are incomplete in the upstream library layer, not just the CLI). Pre-merge divergence: our main: 4094b73 (79 commits of brit-specific work) upstream/main: 7d50c30 (43 commits we don't have) merge-base: 26a5f65 (9 days ago) # Conflicts: # Cargo.lock # Cargo.toml
…/main Every 6 hours plus on-demand. Fast-forward only; a failed fast-forward means gix-main has drifted and we want to know immediately rather than paper over it with a merge commit. gix-main is our pristine mirror of GitoxideLabs/gitoxide's main branch. Feature branches for upstream PRs branch off gix-main, keeping the PR diff clean of brit-specific commits. Co-authored-by: Claude <claude@anthropic.com>
Upstream has 6000+ tags. A single collision with a protected tag name (or a transient GitHub API hiccup partway through the push) would otherwise fail the entire sync run, stopping gix-main freshness. Tags are nice-to-have for our mirror, not load-bearing — gix-main's HEAD pointing at upstream/main is what actually matters. Log a warning if the tag push exits non-zero so we have a trail, but don't fail the job. Co-authored-by: Claude <claude@anthropic.com>
Tuned for brit's pure-Rust workspace — no holochain, no pnpm, no web endpoints. Lower resource limits (6Gi mem / 2 CPU) suited to building gitoxide + brit crates rather than the full elohim monorepo. Adds a Che "Contribute" badge to the README pointing at code.ethosengine.com so a devspace can be launched in one click. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Comment out setup-vscode-cli and setup-claude-mcp — these are the most likely steps to fail on first start. Re-enable once the workspace is known to come up cleanly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
rust-analyzer indexing the gitoxide workspace alongside cargo, VS Code server, and claude pushes past 6Gi and trips the OOM killer.
…iscipline Two coordinated changes to raise Steward's value-per-invocation and lower its flippancy risk: Callee side (.claude/agents/gix-steward.md): - Add CROSS-CUTTING-NOTE: line to PASS/REJECT/DESIGN-CHOICE/deferral templates. One sentence, cite file:line, "(none)" default. Not a smuggled DIRECTION-* verdict — pattern observation only, feeding the architect's moment GitoxideLabs#4 judgment. - Add pre-flight cheap-reject inside moment #1 (completion gate): TODO markers, caller attestation, matrix-row = present, ledger current. Premature completion calls bounce without running clippy / feature matrix / parity.sh. - Add "Cross-Cutting Observation Line" section spelling out the scope rules (observable only in already-gathered evidence, pattern not prescription, cite or skip, one sentence, empty is fine). - Soften "No self-scheduled direction checks" to clarify that the CROSS-CUTTING-NOTE is not a back-door DIRECTION-ADJUST. Caller side (etc/parity/prompt.md): - Add "Pre-Steward self-check" attestation block to Completion section. Sonnet must truthfully sign 7 lines (flag count match, zero TODOs, parity.sh green, fmt/clippy clean, ledger current, matrix row staged, name 2-3 likely-reject rows) before invoking Steward for completion. - Add "Steward invocation bar" per moment — explicit bars on what qualifies as a legitimate call, including moments GitoxideLabs#2/GitoxideLabs#3/GitoxideLabs#4. - PASS flow now instructs the architect to read CROSS-CUTTING-NOTE and consider moment GitoxideLabs#4 before starting the next command. Result: every Steward call does more cross-cutting work per invocation (observation line) AND the invocation itself is harder for sonnet/haiku to reach flippantly.
Mbd06b
added a commit
that referenced
this pull request
Apr 24, 2026
…brit-4GsZI Pull in the pre-flight cheap-reject + CROSS-CUTTING-NOTE protocol updates for the steward agent (upstream commit 49e8430, file .claude/agents/gix-steward.md). Raises value-per-invocation and lowers flippancy risk: * Pre-flight cheap-reject inside moment #1 (completion-gate): TODO markers, caller attestation, matrix-row = present, ledger current — premature completion calls bounce without running the heavy parity pipeline. * CROSS-CUTTING-NOTE line on every verdict (PASS / REJECT / DESIGN-CHOICE / deferral) — one sentence, cite file:line, "(none)" default. Feeds the architect's moment GitoxideLabs#4 judgment without smuggling a DIRECTION-* verdict. * Cross-Cutting Observation scope rules (observable-only, pattern-not-fix). No behavioral change in the parity loop itself; the new protocol takes effect at the next completion-gate invocation of the steward. Staged so in-flight cat-file iterations close under the existing rules.
Mbd06b
added a commit
that referenced
this pull request
Apr 24, 2026
…(steward remediation) Three title sections in tests/journey/parity/cat-file.sh had their `hash=sha1-only` marker embedded in the trailing prose of the preceding comment block rather than on its own `# hash=...` line. The runtime behavior was always correct (each `title` is wrapped by an explicit `only_for_hash sha1-only` directive on the body), but the annotation form tripped the steward's grep-able coverage gate (moment #1 completion-gate cheap-reject). Sections fixed: * --filter=blob:none (line 563) * --no-filter (line 612) * --batch (submodule entry) (line 762) After the fix: `grep -c "^# hash=" tests/journey/parity/cat-file.sh` returns 59 — matching the 60 title sections minus the file-header commentary banner (line 57 `title "gix cat-file"` which carries no `it` block and no `only_for_hash` directive; steward flagged it as a judgment call, not a blocker). No test behavior change; parity file stays green under both hash modes. Re-gate-ready.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two coordinated changes to raise Steward's value-per-invocation and lower
its flippancy risk:
Callee side (.claude/agents/gix-steward.md):
templates. One sentence, cite file:line, "(none)" default. Not a
smuggled DIRECTION-* verdict — pattern observation only, feeding the
architect's moment Name collision with
glib2GitoxideLabs/gitoxide#4 judgment.markers, caller attestation, matrix-row = present, ledger current.
Premature completion calls bounce without running clippy / feature
matrix / parity.sh.
rules (observable only in already-gathered evidence, pattern not
prescription, cite or skip, one sentence, empty is fine).
CROSS-CUTTING-NOTE is not a back-door DIRECTION-ADJUST.
Caller side (etc/parity/prompt.md):
Sonnet must truthfully sign 7 lines (flag count match, zero TODOs,
parity.sh green, fmt/clippy clean, ledger current, matrix row staged,
name 2-3 likely-reject rows) before invoking Steward for completion.
qualifies as a legitimate call, including moments Don't spend build time optimizing build-time-only crates GitoxideLabs/gitoxide#2/git pack generation GitoxideLabs/gitoxide#3/Name collision with
glib2GitoxideLabs/gitoxide#4.consider moment Name collision with
glib2GitoxideLabs/gitoxide#4 before starting the next command.Result: every Steward call does more cross-cutting work per invocation
(observation line) AND the invocation itself is harder for sonnet/haiku
to reach flippantly.