# https://github.com/amitpatole/verel Project Manual Generated at: 2026-06-23 17:09:52 UTC ## Table of Contents - [Overview & the Five-Organ Architecture](#page-1) - [Verdict Bus, Graders & Self-Healing CI](#page-2) - [Brain, Scope Lattice & Shared Verified Memory](#page-3) - [Fleet, Tool-smith, Surfaces & Operations](#page-4) ## Overview & the Five-Organ Architecture ### Related Pages Related topics: [Verdict Bus, Graders & Self-Healing CI](#page-2), [Brain, Scope Lattice & Shared Verified Memory](#page-3), [Fleet, Tool-smith, Surfaces & Operations](#page-4)
Related Source Files The following source files were used to generate this page: - [README.md](https://github.com/amitpatole/verel/blob/main/README.md) - [src/verel/README.md](https://github.com/amitpatole/verel/blob/main/src/verel/README.md) - [src/verel/verdict/models.py](https://github.com/amitpatole/verel/blob/main/src/verel/verdict/models.py) - [src/verel/memory/__init__.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/__init__.py) - [src/verel/memory/local.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/local.py) - [src/verel/memory/consolidate.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/consolidate.py) - [src/verel/memory/revise.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/revise.py) - [src/verel/memory/view.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/view.py) - [src/verel/senses/sight.py](https://github.com/amitpatole/verel/blob/main/src/verel/senses/sight.py) - [src/verel/ci/__init__.py](https://github.com/amitpatole/verel/blob/main/src/verel/ci/__init__.py) - [src/verel/ci/graders.py](https://github.com/amitpatole/verel/blob/main/src/verel/ci/graders.py) - [src/verel/toolsmith/seccomp.py](https://github.com/amitpatole/verel/blob/main/src/verel/toolsmith/seccomp.py) - [src/verel/registry/store.py](https://github.com/amitpatole/verel/blob/main/src/verel/registry/store.py) - [src/verel/agents/__init__.py](https://github.com/amitpatole/verel/blob/main/src/verel/agents/__init__.py)
# Overview & the Multi-Organ Architecture ## Purpose and Thesis Verel is an agent framework positioned as a **verification substrate** — a layer any agent can call (locally or over MCP) so that work is treated as a *hypothesis* until a grader returns a verdict. The single load-bearing idea, lifted from the project README, is that an agent's output is never trusted by default: it must be reduced to a unified `pass / warn / fail` before it is allowed to compound into long-term memory. > *"an agent's output is a hypothesis until a grader returns a verdict. Verel unifies every check — tests, types, lint, vision, perf, security — into one `pass / warn / fail`, and only verified work is allowed to compound into memory."* > Source: [src/verel/README.md:1-15]() This shape was hardened in v0.30.0 (the **verification substrate** release) and extended in v0.31.0 (the **shared verified brain**) so that any agent over MCP can `recall`, `remember`, and `verify` against the same trust substrate. Source: [v0.31.0 release notes](https://github.com/amitpatole/verel/releases/tag/v0.31.0). ## The Organ Map The package is divided into specialized modules ("organs") that each speak the verdict contract. The canonical list, taken from the module guide, is: | Organ | Package | Import surface | Role | |---|---|---|---| | ⚖️ Verdict bus | `verel.verdict` | `gate`, `Report`, `Issue` | Unified eval contract every sense speaks | | 👁️ Eyes / senses | `verel.senses` | `perceive`, `watch` | AgentVision as a grounded perception sense (extra `verel[sight]`) | | 🧠 Brain | `verel.memory` | `LocalMemory`, `consolidate_failures` | Trust layer — only verified facts/skills compound | | 🚁 Fleet | `verel.fleet` | `Scheduler`, `Task` | Agents managing agents, every node gated by the bus | | 🔧 Tool-smith | `verel.toolsmith` | `ToolSmith`, `run_container` | Agents build + sandbox their own tools | | ♻️ Agent-run CI/CD | `verel.ci` | `run_stage`, `self_heal` | Tests/lint/types/perf/security as graders, self-healing | | 📦 Skill registry | `verel.registry` | `PublicRegistry`, `import_skill` | Publish/fetch signed skills — trust does not travel | Source: [src/verel/README.md:17-39]() > **Note on terminology:** the module README labels this table *"The six organs at a glance"*, but the table itself lists seven rows. The page preserves the source's actual surface so newcomers can map tasks to packages. ## The Verdict Bus — the Central Contract Every other organ — eyes, brain, fleet, tool-smith, CI, registry — produces a `Report` and asks `gate()` to reduce a set of reports to one verdict. The models that flow on that bus live in `verel.verdict.models`: - `Report` — one grader's evaluation, carrying a `Verdict` (`PASS`/`WARN`/`FAIL`), a `GraderKind`, a summary, and a list of `Issue`s. - `Issue` — typed finding with `kind`, `severity`, `source` (the originating grader), an optional `locator`, and a NIRVANA-computed `fingerprint` that the bus assigns after construction. - `Gate` — the reducer, which collapses a list of `Report`s under a few non-negotiable rules. Source: [src/verel/verdict/models.py:1-60]() The bus is intentionally thin: it does not know about perception, memory, or CI — it only knows how to *combine verdicts*. This is what lets a CI stage and a vision saccade and a remote brain attestation all land on the same `Verdict` and be reasoned about uniformly. ## The Memory / Brain Layer The brain is the trust substrate. Its public surface is re-exported from `verel.memory.__init__`, including the four-tier trust model (`MemoryRecord`, `Trust`, `MemoryView`, `LocalMemory`), the embedding shims (`Embedder`, `HashEmbedder`, `OpenAIEmbedder`), the consolidation and revision passes, the failure ledger, the held-out promotion gate, and the HA surface (`ReplicatedMemory`, `AntiEntropy`). Source: [src/verel/memory/__init__.py:1-30]() Three behaviors distinguish verel's brain from a plain vector store: 1. **Interference rule.** A write with the same `(subject, predicate, scope)` key supersedes the prior record rather than duplicating it; identical text *corroborates* (raises confidence and `support_count`, resets `retrieval_strength`). Source: [src/verel/memory/local.py:1-40]() 2. **Two-layer consolidation.** Failures are clustered (semantically when an embedder is present, otherwise by the coarse `detail['kind']`) and lifted into structured `DESIGN_RULE`s, then clustered again into `SCHEMA` principles. Both layers write `trust=candidate` — trust is never auto-verified. Source: [src/verel/memory/consolidate.py:1-30]() 3. **Contradiction-driven revision.** When a rule accumulates counterexamples, the rule is *weakened*, *split* into a narrowed general rule plus an exception, or *rejected* — never auto-verified. Source: [src/verel/memory/revise.py:1-20]() These three rules are the substrate's way of enforcing the **"trust does not travel"** property called out in v0.30.0. The release-notes progression v0.31.0 → v0.32.0 → v0.34.0 layers remote-brain access, ed25519 authenticated principals, and fact-bound cross-principal attestation on top of the same in-process trust model. ## The Agent, Senses, CI, and Tool-Smith Organs - **Agents (`verel.agents`)** — currently the coding agent and a `FixHook` factory. Source: [src/verel/agents/__init__.py:1-10]() - **Senses (`verel.senses`)** — `SightResult` carries one `Report` per source-grader (`dom`/`ocr`/`cv`/`vision`) plus a combined `Percept` envelope, mapped through a closed 4-value source-to-grader table. Source: [src/verel/senses/sight.py:1-30]() - **CI / grading (`verel.ci`)** — re-exports `run_stage`, `self_heal`, `HealResult`, the rollback policy/decision/outcome trio, and the pre-commit installer. Source: [src/verel/ci/__init__.py:1-12]() The current `LANGS` table grades Python (`pytest`+`ruff`+`mypy`), JS (`jstest`+`eslint`+`tsc`), and Go (`gotest`+`govet`); Rust is a tracked gap (Issue #1). Source: [src/verel/ci/graders.py:1-10]() - **Tool-smith (`verel.toolsmith`)** — agents that build and sandbox their own tools, with a seccomp-bpf denylist layered on top of a bwrap container when the `container` extra is installed. Source: [src/verel/toolsmith/seccomp.py:1-25]() - **Registry (`verel.registry`)** — `PublicRegistry` is a content-addressed store of signed `SkillArtifact`s; the content hash is the namespace and a foreign-origin overwrite is refused. Source: [src/verel/registry/store.py:1-25]() ## How the Organs Compose ```mermaid flowchart LR A[Agent / FixHook
verel.agents] --> R[Reports] S[Senses / AgentVision
verel.senses] --> R C[CI Graders
verel.ci] --> R T[Tool-smith
verel.toolsmith] --> R R --> G[Verdict Bus
verel.verdict.gate] G -->|PASS / WARN / FAIL| M[Memory / Brain
verel.memory] M -->|verified facts & skills| Reg[Skill Registry
verel.registry] M -. recall / remember .-> MCP[(MCP substrate
v0.35.0)] Reg -. signed skills .-> MCP G -. runreceipt .-> MCP ``` Reading the diagram bottom-up: every organ emits `Report`s; the bus gates them; only gated results compound into the brain; the brain, the registry, and the run-receipt surface are all reachable over MCP since v0.30.0, and the HTTP transports are now TLS-hardened since v0.36.0. ## Common Failure Modes and Gaps - **Mis-attributed feedback in the brain.** Without the corroboration/contradiction accounting in [src/verel/memory/local.py](), a single bad actor can poison a shared brain — the reason `AuthorTrust` and `import_belief` re-verification exist on top of the local view. - **Auto-verification creep.** A bug elsewhere could shortcut `trust=candidate` to `verified`; the design rule in [src/verel/memory/consolidate.py:1-30]() and [src/verel/memory/revise.py:1-20]() is that revision only *lowers* trust or *narrows* scope. - **Undetected missing extras.** Issue #2 notes that `verel doctor` does not yet show which optional extras (e.g., `verel[sight]`, `verel[container]`) are installed or which provider keys are present — newcomers may install `verel` and assume a sense is wired when it is not. - **Monorepo CI gaps.** Issue #4 requests a recipe for *gating a monorepo with per-package stages*; the `LANGS` table in [src/verel/ci/graders.py:1-10]() today keys a stage to a single language, so per-package gating is still caller-side composition. - **Parser coverage.** Issue #3 asks for broader grader-parser fixtures in `tests/test_ci_senses.py`; the parsers in [src/verel/ci/graders.py]() are pure functions over `(stdout, stderr)`, so the gap is purely a test-data gap, not a design gap. ## See Also - [Developer guide / cookbook](https://github.com/amitpatole/verel/blob/main/docs/usage.md) — task-oriented recipes referenced by the monorepo gap (Issue #4). - [v0.36.0 release notes — TLS for routable brain/lease/registry binds](https://github.com/amitpatole/verel/releases/tag/v0.36.0) — the transport layer that hardens the brain, lease, and registry services. - [v0.34.0 — cross-principal verified tier (fact-bound attestation)](https://github.com/amitpatole/verel/releases/tag/v0.34.0) — the most recent addition to the trust substrate. - Issue #1 — add Rust toolchain graders to `verel.ci.graders`. - Issue #2 — extend `verel doctor` to report installed extras and key presence. --- ## Verdict Bus, Graders & Self-Healing CI ### Related Pages Related topics: [Overview & the Five-Organ Architecture](#page-1), [Fleet, Tool-smith, Surfaces & Operations](#page-4)
Related Source Files The following source files were used to generate this page: - [src/verel/README.md](https://github.com/amitpatole/verel/blob/main/src/verel/README.md) - [src/verel/verdict/__init__.py](https://github.com/amitpatole/verel/blob/main/src/verel/verdict/__init__.py) - [src/verel/verdict/constants.py](https://github.com/amitpatole/verel/blob/main/src/verel/verdict/constants.py) - [src/verel/verdict/models.py](https://github.com/amitpatole/verel/blob/main/src/verel/verdict/models.py) - [src/verel/verdict/fingerprint.py](https://github.com/amitpatole/verel/blob/main/src/verel/verdict/fingerprint.py) - [src/verel/ci/__init__.py](https://github.com/amitpatole/verel/blob/main/src/verel/ci/__init__.py) - [src/verel/ci/graders.py](https://github.com/amitpatole/verel/blob/main/src/verel/ci/graders.py) - [src/verel/ci/pipeline.py](https://github.com/amitpatole/verel/blob/main/src/verel/ci/pipeline.py) - [src/verel/ci/medic.py](https://github.com/amitpatole/verel/blob/main/src/verel/ci/medic.py) - [src/verel/memory/view.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/view.py) - [src/verel/memory/local.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/local.py) - [src/verel/memory/consolidate.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/consolidate.py) - [src/verel/memory/revise.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/revise.py) - [src/verel/memory/promotion.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/promotion.py) - [src/verel/senses/sight.py](https://github.com/amitpatole/verel/blob/main/src/verel/senses/sight.py) - [tests/test_ci_senses.py](https://github.com/amitpatole/verel/blob/main/tests/test_ci_senses.py)
# Verdict Bus, Graders & Self-Healing CI Verel treats an agent's output as a *hypothesis* until a grader returns a verdict. The **verdict bus** is the single contract every sense (vision, tests, lint, types, security, perf) speaks, and the **self-healing CI** organ reuses the same contract to gate commits, merge requests, inner dev loops, and post-merge smoke runs. This page explains how the contract works, which graders ship, and how failures are classified, recorded, and replayed. ## The Verdict Bus — One Contract, One Reducer The bus is defined under `src/verel/verdict/`. Every grader — AgentVision, `pytest`, `ruff`, the LLM judge, a code-review skill — produces a `Report` carrying a `Verdict` (`pass`/`warn`/`fail`), a `GraderKind`, and a list of `Issue` objects. The reducer is `gate()`, exposed in [`src/verel/verdict/__init__.py`](https://github.com/amitpatole/verel/blob/main/src/verel/verdict/__init__.py). `gate()` enforces three non-negotiable rules, all parameterised by named constants in [`src/verel/verdict/constants.py`](https://github.com/amitpatole/verel/blob/main/src/verel/verdict/constants.py): | Rule | Constant | Effect | |---|---|---| | Advisory ceiling | `ADVISORY_CEIL = Severity.WARNING` | Open-ended graders (`VISION`, `LLM_JUDGE`, `ACOUSTIC`, `AUDIO_LLM`) can never gate a `CRITICAL` — they are clamped to `warn` | | Gating severity | `GATING_SEVERITY = Severity.ERROR` | Issues at/above `ERROR` count as `gating_failures` for the progress signal | | Windowed progress | `W = 4` | `progressed()` requires strict shrinkage of the gating-failure set over a 4-step window | ```python from verel.verdict import Report, Issue, IssueKind, Severity, GraderKind, Verdict, gate, assign r = assign(Report(verdict=Verdict.FAIL, summary="2 type errors", grader=GraderKind.TYPECHECK, issues=[Issue(kind=IssueKind.OTHER, severity=Severity.ERROR, source=GraderKind.TYPECHECK, message="bad return", locator="app.py:42")])) print(gate([r], required={GraderKind.TYPECHECK}).verdict) # Verdict.FAIL ``` `assign()` lives in [`src/verel/verdict/fingerprint.py`](https://github.com/amitpatole/verel/blob/main/src/verel/verdict/fingerprint.py); it scrubs volatile fields (line numbers, addresses, floats) so the same underlying issue produces the same fingerprint across runs. The model surface (`Report`, `Issue`, `RunReceipt`, `GateResult`, and the enums `Verdict` / `Severity` / `GraderKind` / `IssueKind`) is defined in [`src/verel/verdict/models.py`](https://github.com/amitpatole/verel/blob/main/src/verel/verdict/models.py). A `gate()` that requires a grader also demands a signed `RunReceipt` — the **attestation** rule, issued via `sign_receipt()` and checked by `verify_signature()` in [`src/verel/verdict/gate.py`](https://github.com/amitpatole/verel/blob/main/src/verel/verdict/gate.py). Without a receipt, a required grader fails closed. ## Code Graders — Deterministic, Pure, Testable [`src/verel/ci/graders.py`](https://github.com/amitpatole/verel/blob/main/src/verel/ci/graders.py) defines a `GraderSpec` per toolchain: a frozen command, a parser, and a `LangToolchain` binding. Parsers are **pure functions over `(stdout, stderr)`**, so the corpus in [`tests/test_ci_senses.py`](https://github.com/amitpatole/verel/blob/main/tests/test_ci_senses.py) drives them offline. The command runner is injectable (`subprocess_runner` by default) for the same reason. | Language | Test grader | Lint / type | Security / audit | |---|---|---|---| | Python | `pytest_spec` / `parse_pytest` | `ruff_spec` / `parse_ruff`, `mypy_spec` / `parse_mypy` | `bandit_spec` / `parse_bandit` | | JS / TS | `jstest_spec` (TAP) / `parse_tap` | `eslint_spec` / `parse_eslint`, `tsc_spec` / `parse_tsc` | `npm_audit_spec` / `parse_npm_audit` | | Go | `gotest_spec` / `parse_go_test` | `govet_spec` / `parse_go_vet` | — | | Any | `perf_spec` / `parse_perf` | — | — | The full list of language tags and the `LANGS` mapping is exported from [`src/verel/ci/__init__.py`](https://github.com/amitpatole/verel/blob/main/src/verel/ci/__init__.py). Each parser emits `Issue` records with stable `source=GraderKind.*` so the fingerprint reducer does not confuse a `mypy` error with a `ruff` warning, and `run_grader()` signs a `RunReceipt` keyed on `suite_sha()` plus a `bound_input_digest` of the changed files — the same digest that the gate receipts over. > Community note: the project tracks a feature request to add a **Rust** toolchain (`cargo test` + `clippy`) following the existing `GraderSpec` pattern ([issue #1](https://github.com/amitpatole/verel/issues/1)), and to widen the parser corpus with real tool output ([issue #3](https://github.com/amitpatole/verel/issues/3)). Both are mechanical extensions of the current grader table. ## Self-Healing CI — Stages, Medic, and Failure Memory [`src/verel/ci/pipeline.py`](https://github.com/amitpatole/verel/blob/main/src/verel/ci/pipeline.py) exposes four named stages and a single entry point, `run_stage(stage, ...)`. Each `Stage` pairs a list of `GraderSpec`s with a `required` set; `run_stage` runs every grader, gates the resulting `Report`s, and consults a `FailureLedger` for regressions. A `StageResult` carries the verdict, the underlying `GateResult`, the raw reports, and any regressions. ```mermaid flowchart LR A[Change set] --> B[run_stage] B --> C[run_grader ×N] C --> D[Verdict bus: gate()] D --> E{Required & receipted?} E -- no --> F[FAIL: hollow gate] E -- yes --> G[FailureLedger regression?] G -- yes --> H[FAIL: known regression] G -- no --> I[ci-medic classify] I --> J[(RETRY · REGEN · QUARANTINE · FIX)] J --> K[Verdict: PASS / WARN / FAIL] ``` The **ci-medic** ([`src/verel/ci/medic.py`](https://github.com/amitpatole/verel/blob/main/src/verel/ci/medic.py)) is deterministic, not LLM-driven. It pattern-matches grader output to one of four `Action`s: | `Action` | Trigger class | What happens | |---|---|---| | `RETRY` | `INFRA` / `TRANSIENT` (timeouts, 5xx, connection errors) | Re-run the stage; do not "fix" | | `REGEN_LOCKFILE` | `DEP_DRIFT` (ModuleNotFound, solver errors) | Regenerate the lockfile and retry | | `QUARANTINE_FLAKY` | `FLAKY` (a signature seen flipping pass/fail) | Demote `ERROR` → `WARNING`; ticket + memory entry; never silently dropped | | `FIX_BRANCH` | `GENUINE` (real regression) | Spin an `ultracode` fix loop | A diagnostic `Diagnosis` may be **enriched** by an LLM later, but the classification itself is regex-driven so the medic cannot be gamed. Destructive follow-ups (`FIX_BRANCH`, lockfile regeneration) are additionally filtered through the `RollbackPolicy` engine (`rollback.py`) and the `canary_rollback` helper exported from the same package, so a medic misclassification cannot push destructive changes on advisory evidence. A `self_heal()` loop is exposed from [`src/verel/ci/__init__.py`](https://github.com/amitpatole/verel/blob/main/src/verel/ci/__init__.py) (along with `HealResult` / `HealRound`); it iterates the medic's recommendations, re-runs the stage, and stops when a non-`RETRY` action succeeds or the round budget is exhausted. Pre-commit hook installation lives in `hooks.py` (`install_precommit`, `is_installed`). ## Failure Memory — Anti-Regression, Consolidation, Revision The same `Report` stream that gates a commit is also written into the **failure ledger**, defined in [`src/verel/memory/view.py`](https://github.com/amitpatole/verel/blob/main/src/verel/memory/view.py) as a `FAILURE`-kind `MemoryRecord`. The pipeline consults this ledger via `regression_report()` in `failure_ledger.py`, so a change that reintroduces a previously-fixed signature is gated `FAIL` from memory alone — no need to re-run the failing test to notice the regression. Records are persisted by [`src/verel/memory/local.py`](https://github.com/amitpatole/verel/blob/main/src/verel/memory/local.py): a write with the same `(subject, predicate, scope)` **supersedes** the prior record, accumulating `support_count` and bumping `epistemic_confidence`; conflicting writes drop confidence via `contradict()`. Three higher-level modules then turn failures into durable, falsifiable memory: - [`src/verel/memory/consolidate.py`](https://github.com/amitpatole/verel/blob/main/src/verel/memory/consolidate.py) clusters failures (semantically if an embedder is available, by `detail['kind']` otherwise), induces a structured `DesignRule` per cluster, and clusters rules into a 2nd-order `SCHEMA`. All writes are `trust=candidate` — verification is never granted by consolidation alone. - [`src/verel/memory/revise.py`](https://github.com/amitpatole/verel/blob/main/src/verel/memory/revise.py) handles the contraction half: a counterexample in a rule's domain **narrows** the rule (supersedes the original via the same `subj_pred_key`) and may **split** it into a narrowed general rule + a specific exception, both `candidate`. Confidence collapse leads to `rejected`. - [`src/verel/memory/promotion.py`](https://github.com/amitpatole/verel/blob/main/src/verel/memory/promotion.py) gates the climb from `candidate` to `verified` behind a signed, human-owned `HeldOutCorpus`; the rule must reach `PROMOTE_F1 = 0.8` on canary-marked cases to be promoted. The bus surface that ties this together — `verdict.fact_commitment`, `attest_fact`, `verify_fact_attestation` — was hardened across v0.32.0 – v0.36.0 (see the [release notes](https://github.com/amitpatole/verel/releases)) so peer beliefs and shared-brain reads carry the same attestation contract as a local grader. ## Common Failure Modes - **Hollow gate** — a stage declares a `required` grader but the report lacks a `RunReceipt`. `gate()` fails closed. Fix: ensure `run_grader` ran (not just a parser on cached output) and that `sign_receipt` produced a signature. - **Advisory gating ignored** — code treats an `LLM_JUDGE` or `VISION` `CRITICAL` as blocking. The advisory ceiling in `constants.py` will clamp it to `WARN`; the bug is in the consumer. - **Flaky test thrash** — a `QUARANTINE_FLAKY` action is the correct response; do not loop `FIX_BRANCH` on a known flaky signature, and do not delete the test. - **Monorepo scope** — `run_stage` takes a `diff_files` set, so a stage can be filtered to one package. Community recipe for per-package gating in monorepos is tracked in [issue #4](https://github.com/amitpatole/verel/issues/4). ## See Also - [Developer guide — usage cookbook](https://github.com/amitpatole/verel/blob/main/docs/usage.md) - [`src/verel/memory/view.py`](https://github.com/amitpatole/verel/blob/main/src/verel/memory/view.py) — `MemoryRecord`, `Trust`, `MemoryKind` - [v0.30.0 release — the verification substrate](https://github.com/amitpatole/verel/releases/tag/v0.30.0) - [v0.36.0 release — TLS for routable brain/lease/registry binds](https://github.com/amitpatole/verel/releases/tag/v0.36.0) --- ## Brain, Scope Lattice & Shared Verified Memory ### Related Pages Related topics: [Overview & the Five-Organ Architecture](#page-1), [Fleet, Tool-smith, Surfaces & Operations](#page-4)
Related Source Files The following source files were used to generate this page: - [src/verel/README.md](https://github.com/amitpatole/verel/blob/main/src/verel/README.md) - [src/verel/memory/__init__.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/__init__.py) - [src/verel/memory/view.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/view.py) - [src/verel/memory/local.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/local.py) - [src/verel/memory/share.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/share.py) - [src/verel/memory/principal.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/principal.py) - [src/verel/memory/consolidate.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/consolidate.py) - [src/verel/memory/revise.py](https://github.com/amitpatole/verel/blob/main/src/verel/memory/revise.py) - [src/verel/ci/graders.py](https://github.com/amitpatole/verel/blob/main/src/verel/ci/graders.py)
# Brain, Scope Lattice & Shared Verified Memory ## Overview & Role in the Substrate Verel's **brain** is the trust layer that turns per-episode perceptions into durable, recallable knowledge for agents. It sits behind the same `MemoryView` Protocol regardless of backend (local SQLite, hosted HTTP `MemoryServer`, replicated cluster, or a mem0/Ollama adapter), so an agent never has to change code to swap substrates. The thesis, taken from the module guide ([`src/verel/README.md`](https://github.com/amitpatole/verel/blob/main/src/verel/README.md)), is that an agent's output is a *hypothesis* until a grader returns a verdict; the brain's job is to keep that hypothesis from polluting future runs. The two orthogonal quantities the brain tracks are **`epistemic_confidence`** (how strongly the substrate believes the claim) and **`retrieval_strength`** (how reachable the claim is right now), kept separate on purpose so belief and reachability can be tuned independently ([`src/verel/memory/view.py`](https://github.com/amitpatole/verel/blob/main/src/verel/memory/view.py)). ```mermaid flowchart LR A[Agent / MCP tool] -->|verel_recall / verel_remember| B[MemoryView] B --> C[Scope Lattice
self < team < org < global] C --> D[LocalMemory
SQLite] C --> E[MemoryServer
HTTP/TLS] C --> F[ReplicatedMemory
HA cluster] B --> G[Trust gate:
candidate → verified] G --> H[Consolidate / Revise] H -->|DesignRule, Schema| D H -->|counterexample| I[Reject / Narrow] ``` ## MemoryRecord, Trust Tiers & the Interference Rule Every belief is a `MemoryRecord` with a content-addressed identity: the `id` is derived from the normalized `(subject, predicate, scope)` triple via `make_key` / `make_id` ([`src/verel/memory/view.py`](https://github.com/amitpatole/verel/blob/main/src/verel/memory/view.py)). The `kind` is one of `FACT`, `DESIGN_RULE`, `SCHEMA`, `FAILURE`, or `SKILL` — the same key is used regardless of kind, so a FACT and a SKILL with the same `(subject, predicate, scope)` share an id, which is why [`src/verel/memory/principal.py`](https://github.com/amitpatole/verel/blob/main/src/verel/memory/principal.py) keeps the five **reserved predicates/scopes** server-side and refuses a client write that collides with them. Trust progresses through explicit tiers rather than a free-floating float ([`src/verel/memory/view.py`](https://github.com/amitpatole/verel/blob/main/src/verel/memory/view.py)): | Tier | Source | Notes | |---|---|---| | `candidate` | initial write, all induced rules/schemas | NEVER auto-verified — only corroboration can lift it | | `verified` | held-out eval gate / corroboration / fact-bound attestation (v0.34.0) | requires a *verifier* in the importer's own context | | `rejected` | contradict collapsed confidence below the reject floor | revision only lowers trust, never raises it without evidence | The **interference rule** in `LocalMemory.write` is what keeps the store honest: if an incoming `MemoryRecord` collides on the `subj_pred_key`, the existing record is *superseded* (same text bumps `support_count` and confidence by 0.1, resets `retrieval_strength`); conflicting text is still kept but `contradict`-marked so the rule can collapse later ([`src/verel/memory/local.py`](https://github.com/amitpatole/verel/blob/main/src/verel/memory/local.py)). ## Scope Lattice & Recall Resolution Recalls are scoped. The lattice resolves **DOWN** — a read at `self` sees `self < team < org < global`, so an agent never gets a team claim when it asked for self, but team can see what its members learned. Scope strings are typed: `repo:`, `global`, `component:`, and the reserved `meta:authors` ledger used by `AuthorTrust` ([`src/verel/memory/share.py`](https://github.com/amitpatole/verel/blob/main/src/verel/memory/share.py)). The MCP surface `verel_recall(query, scope, kind, k)` introduced in v0.31.0 rides this lattice directly; with `VEREL_BRAIN_URL` set (v0.35.0) the same call reaches the remote `MemoryServer`, and v0.36.0 hardens the transport with TLS so a non-loopback bind fails closed ([releases: v0.31.0, v0.35.0, v0.36.0](https://github.com/amitpatole/verel/releases)). A recall that returns a peer-authored belief is *not* trusted on the say-so of the peer — the importer re-verifies through a `Verifier` callback before confidence is updated, and the outcome is logged into `AuthorTrust` with a Laplace-smoothed prior. This is the principle the module guide calls **"trust does not travel"** ([`src/verel/README.md`](https://github.com/amitpatole/verel/blob/main/src/verel/README.md)). ## Consolidation, Revision & Schema Induction Consolidation is the *growth* half of memory; revision is the *contraction* half. Both are offline-batch and use an injectable `ChatFn` so they're testable without network ([`src/verel/memory/consolidate.py`](https://github.com/amitpatole/verel/blob/main/src/verel/memory/consolidate.py), [`src/verel/memory/revise.py`](https://github.com/amitpatole/verel/blob/main/src/verel/memory/revise.py)). - **Cluster** recurring failures — semantically when an embedder is wired in, otherwise by the coarse `detail['kind']` label. - **Induce a structured `DESIGN_RULE`** with `{condition, action, applies_to}` slots, written as `trust=candidate` and `epistemic_confidence=0.5`. - **Induce a `SCHEMA`** (order-2) by clustering rules; `induce_hierarchy` keeps walking up to `max_order=4`. Height never confers trust — every node still has to earn it. When a new failure lands in a rule's domain, [`revise_with_counterexample`](https://github.com/amitpatole/verel/blob/main/src/verel/memory/revise.py) (1) records the counterexample (no corroboration), (2) `contradict`s the rule (confidence drops by `contradiction_delta=0.2`), and (3) once `split_after=2` counterexamples accumulate, splits the over-broad rule into a **narrowed** rule (which *supersedes* the original via the interference key) plus an **exception** rule — both `candidate` and both re-earning trust the normal way. If confidence collapses below the reject floor the rule is REJECTED. Revision only ever lowers trust or narrows scope, mirroring the same direction the `GraderKind` bus enforces for CI verdicts ([`src/verel/ci/graders.py`](https://github.com/amitpatole/verel/blob/main/src/verel/ci/graders.py)). ## See Also - [Module guide: src/verel/README.md](https://github.com/amitpatole/verel/blob/main/src/verel/README.md) — six organs at a glance and the `gate` / `verdict` contract - [v0.36.0 release notes — TLS for routable brain/lease/registry binds](https://github.com/amitpatole/verel/releases/tag/v0.36.0) - [v0.35.0 release notes — MCP recall/remember over a remote authenticated brain](https://github.com/amitpatole/verel/releases/tag/v0.35.0) - [v0.34.0 release notes — cross-principal verified tier (fact-bound attestation)](https://github.com/amitpatole/verel/releases/tag/v0.34.0) - [v0.32.0 release notes — the authenticated multi-principal brain](https://github.com/amitpatole/verel/releases/tag/v0.32.0) - [v0.31.0 release notes — the shared verified brain](https://github.com/amitpatole/verel/releases/tag/v0.31.0) --- ## Fleet, Tool-smith, Surfaces & Operations ### Related Pages Related topics: [Overview & the Five-Organ Architecture](#page-1), [Verdict Bus, Graders & Self-Healing CI](#page-2), [Brain, Scope Lattice & Shared Verified Memory](#page-3)
Related Source Files The following source files were used to generate this page: - [src/verel/README.md](https://github.com/amitpatole/verel/blob/main/src/verel/README.md) - [src/verel/fleet/__init__.py](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/__init__.py) - [src/verel/fleet/manager.py](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/manager.py) - [src/verel/fleet/scheduler.py](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/scheduler.py) - [src/verel/fleet/worker.py](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/worker.py) - [src/verel/fleet/worktree.py](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/worktree.py) - [src/verel/fleet/lease.py](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/lease.py) - [src/verel/fleet/control_plane.py](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/control_plane.py) - [src/verel/fleet/fence_sink.py](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/fence_sink.py) - [src/verel/fleet/task.py](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/task.py) - [src/verel/fleet/multirepo.py](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/multirepo.py) - [src/verel/fleet/saga.py](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/saga.py) - [src/verel/fleet/llm_manager.py](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/llm_manager.py) - [src/verel/toolsmith/__init__.py](https://github.com/amitpatole/verel/blob/main/src/verel/toolsmith/__init__.py) - [src/verel/toolsmith/registry.py](https://github.com/amitpatole/verel/blob/main/src/verel/toolsmith/registry.py) - [src/verel/toolsmith/container.py](https://github.com/amitpatole/verel/blob/main/src/verel/toolsmith/container.py) - [src/verel/toolsmith/sandbox.py](https://github.com/amitpatole/verel/blob/main/src/verel/toolsmith/sandbox.py) - [src/verel/toolsmith/seccomp.py](https://github.com/amitpatole/verel/blob/main/src/verel/toolsmith/seccomp.py) - [src/verel/toolsmith/smith.py](https://github.com/amitpatole/verel/blob/main/src/verel/toolsmith/smith.py) - [src/verel/cli.py](https://github.com/amitpatole/verel/blob/main/src/verel/cli.py) - [src/verel/ci/__main__.py](https://github.com/amitpatole/verel/blob/main/src/verel/ci/__main__.py) - [src/verel/mcp_server.py](https://github.com/amitpatole/verel/blob/main/src/verel/mcp_server.py) - [src/verel/agents/coder.py](https://github.com/amitpatole/verel/blob/main/src/verel/agents/coder.py)
# Fleet, Tool-smith, Surfaces & Operations Verel's "Fleet" and "Tool-smith" organs operationalize the rest of the substrate: the fleet is *agents managing agents*, and the tool-smith is *agents building and certifying their own tools*. Together with the operator-facing surfaces — the `verel` CLI, the `verel-ci` git-hook CLI, and the `verel-mcp` server — they close the loop from a grader verdict to a multi-tenant, sandboxed action that another party can verify. ## Fleet — agents managing agents The fleet module exports a v1-cut control plane: roles, retries, heartbeats, a single-writer scheduler over a Task DAG, manager fan-out, and a worker adapter that gates every node through the verdict bus (`Source: [src/verel/fleet/__init__.py:1-7]()`). The DAG lives in [`task.py`](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/task.py) and exposes `Task`, `TaskState`, `Role`, `Barrier`, `BarrierKind`, `BudgetLease`, and `RetryPolicy`. A scheduler in [`scheduler.py`](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/scheduler.py) walks the DAG, and workers in [`worker.py`](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/worker.py) wrap `ultracode_worker` / `worktree_ultracode_worker` so every node still passes through `gate()` before being marked done. Coordination primitives are kept small but real: - **Leases** — [`lease.py`](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/lease.py) ships `InMemoryLeaseStore` and `SqliteLeaseStore`, with `Lease`, `LeaseStore`, and a `FencingError` for split-brain handling. - **Worktrees** — [`worktree.py`](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/worktree.py) defines `Worktree`, `WorktreeManager`, and `LeaseHeld`, the isolation boundary used when many workers must edit the same repo concurrently. - **Manager fan-out** — [`manager.py`](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/manager.py) re-exports `plan_over_artifacts`, `to_tasks`, `validate_fanout`, `clamp`, plus the `FanOut` / `Subtask` models; the LLM-driven variant lives in [`llm_manager.py`](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/llm_manager.py) (`decide_fanout`). - **Multi-repo & sagas** — [`multirepo.py`](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/multirepo.py) plans cross-repo graphs (`plan_multi_repo`, `repo_of`, `CrossDep`); [`saga.py`](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/saga.py) runs compensating workflows (`run_saga`, `git_revert_head`, `SagaResult`). - **Remote control plane** — [`control_plane.py`](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/control_plane.py) hosts `ControlPlaneServer` + `RemoteLeaseStore` so a fleet on different machines shares one lease authority. - **Git fencing** — [`fence_sink.py`](https://github.com/amitpatole/verel/blob/main/src/verel/fleet/fence_sink.py) wires `validate_push`, `push_options`, and `write_pre_receive_hook` for pre-receive enforcement. The README explicitly scopes what is *not* in v1: "Worker fencing + git fencing sink are v3" (`Source: [src/verel/fleet/__init__.py:5-7]()`), so treat remote worker fencing as a roadmap item, not a current control. ## Tool-smith — agents building their own tools The tool-smith organ implements the `detect → scaffold → test → register → reuse` lifecycle. Tools live as `SKILL` records in procedural memory behind the same `MemoryView`, gated by the same attested eval discipline as facts/skills — verified-and-auto for read-only/idempotent tools, human-review-gated for destructive ones (`Source: [src/verel/toolsmith/__init__.py:1-7]()`). Core pieces: | File | Role | |---|---| | [`smith.py`](https://github.com/amitpatole/verel/blob/main/src/verel/toolsmith/smith.py) | `ToolSmith`, `ToolSpec`, `ToolCase`, `eval_tool_cases`, `BuildResult` | | [`registry.py`](https://github.com/amitpatole/verel/blob/main/src/verel/toolsmith/registry.py) | `ToolRegistry`, `ToolRecord`, `SideEffect`, semantic `find()` | | [`sandbox.py`](https://github.com/amitpatole/verel/blob/main/src/verel/toolsmith/sandbox.py) | `run_sandboxed`, `SandboxError` — in-process guardrail | | [`container.py`](https://github.com/amitpatole/verel/blob/main/src/verel/toolsmith/container.py) | `best_runner`, `bwrap_available`, `run_container` — real isolation | | [`seccomp.py`](https://github.com/amitpatole/verel/blob/main/src/verel/toolsmith/seccomp.py) | `build_bpf`, `PROFILE_*`, `DENIED_SYSCALLS` / `ALLOWED_SYSCALLS` | | [`seccomp_learn.py`](https://github.com/amitpatole/verel/blob/main/src/verel/toolsmith/seccomp_learn.py) | `learn_syscall_profile`, `strace_available` | The README is explicit that "the in-process tool guard is a guardrail, not a sandbox — real isolation is the `bwrap` container runner (`isolation='container'`): no network, read-only system-only fs, ephemeral tmp, cleared env, and a seccomp-bpf syscall filter (`verel[container]`)" (`Source: [README.md:42-50]()`). Three profiles, weakest→strongest: **denylist** (default), **allowlist**, and **capability** (`Source: [src/verel/toolsmith/__init__.py:23-32]()`). The Coder agent in [`agents/coder.py`](https://github.com/amitpatole/verel/blob/main/src/verel/agents/coder.py) (`LLMCoder`, `make_fix_hook`) bridges the verdict bus to file rewriting — `make_fix_hook` returns an async `FixHook` that `ultracode_loop` calls when a gate fails, so the same org produces a candidate patch that is immediately re-gated. ## Surfaces — how operators reach the substrate Three top-level surfaces are documented in the package README (`Source: [src/verel/README.md:23-30]()`): - `cli.py` → `verel {doctor, loop, fleet, heal, ci}` — the operator's day-to-day surface. Community issue [#2](https://github.com/amitpatole/verel/issues/2) flags that `doctor` should additionally report installed extras and provider-key presence, which is a current gap. - `ci/__main__.py` → `verel-ci {check, precommit, install}` — the git-hook / pre-commit surface; the LangToolchain map currently covers `python`, `js`, and `go` (`Source: [src/verel/ci/graders.py]()`), with Rust requested in issue [#1](https://github.com/amitpatole/verel/issues/1) and broader real-sample coverage in [#3](https://github.com/amitpatole/verel/issues/3). - `mcp_server.py` → `verel-mcp` — exposes the four hero verbs (`gate`, `sight`, `recall`/`remember`, `verify`) to any MCP-capable agent. ## Operations, security posture, and known gaps TLS for non-loopback binds is the headline of [v0.36.0](https://github.com/amitpatole/verel/releases/tag/v0.36.0): `MemoryServer`, `ControlPlaneServer`, and `RegistryServer` accept `certfile=`/`keyfile=`/`ssl_context=`, loopback stays zero-config. Bind hardening fails closed when non-loopback is requested without cert material. Operationally, three community-acknowledged gaps remain on these surfaces: 1. **Monorepo gating recipe** — `verel-ci` is repo-scoped; issue [#4](https://github.com/amitpatole/verel/issues/4) asks for a `docs/usage.md` recipe and an `examples/demo_monorepo_ci.py` running separate inner loops per package. 2. **Rust graders** — issue [#1](https://github.com/amitpatole/verel/issues/1) wants `parse_cargo_test` / `parse_clippy` next to the Python/JS/Go parsers. 3. **Doctor completeness** — issue [#2](https://github.com/amitpatole/verel/issues/2) wants a small table of optional extras and present keys. Until those land, the operational rule of thumb is: keep the verdict bus as the single entry point, keep destructive tools behind the allowlist or capability seccomp profile, and route any non-loopback fleet/brain/registry bind through TLS. ## See Also - Verdict Bus & Eyes (sight, memory, registry) - Memory Substrate — local, shared, revision, and librarian - Skill Registry — artifacts, transfer, and H2 measurement - Verel Security Model — sandbox vs. container, seccomp profiles --- --- ## Pitfall Log Project: amitpatole/verel Summary: Found 25 structured pitfall item(s), including 1 high/blocking item(s). Top priority: Security or permission risk - Security or permission risk requires verification. ## 1. Security or permission risk - Security or permission risk requires verification - Severity: high - Evidence strength: source_linked - Finding: Developers should check this security_permissions risk before relying on the project: verel doctor: report installed extras and key presence - User impact: Developers may expose sensitive permissions or credentials: verel doctor: report installed extras and key presence - Evidence: failure_mode_cluster:github_issue | https://github.com/amitpatole/verel/issues/2 ## 2. Installation risk - Installation risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Developers should check this installation risk before relying on the project: Add a Rust toolchain (cargo test + clippy) to the CI graders - User impact: Developers may fail before the first successful local run: Add a Rust toolchain (cargo test + clippy) to the CI graders - Evidence: failure_mode_cluster:github_issue | https://github.com/amitpatole/verel/issues/1 ## 3. Installation risk - Installation risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Developers should check this installation risk before relying on the project: v0.28.0 — quorum reads: a point read survives the leader being down - User impact: Upgrade or migration may change expected behavior: v0.28.0 — quorum reads: a point read survives the leader being down - Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.28.0 ## 4. Installation risk - Installation risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Developers should check this installation risk before relying on the project: v0.29.0 — security hardening: full attack-surface audit + red-team - User impact: Upgrade or migration may change expected behavior: v0.29.0 — security hardening: full attack-surface audit + red-team - Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.29.0 ## 5. Installation risk - Installation risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Developers should check this installation risk before relying on the project: v0.29.1 — security: 3-round adversarial red-team - User impact: Upgrade or migration may change expected behavior: v0.29.1 — security: 3-round adversarial red-team - Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.29.1 ## 6. Installation risk - Installation risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Developers should check this installation risk before relying on the project: v0.29.2 — CI fix for the v0.29.1 security release - User impact: Upgrade or migration may change expected behavior: v0.29.2 — CI fix for the v0.29.1 security release - Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.29.2 ## 7. Installation risk - Installation risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Developers should check this installation risk before relying on the project: v0.30.0 — the verification substrate - User impact: Upgrade or migration may change expected behavior: v0.30.0 — the verification substrate - Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.30.0 ## 8. Installation risk - Installation risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Developers should check this installation risk before relying on the project: v0.31.0 — the shared verified brain - User impact: Upgrade or migration may change expected behavior: v0.31.0 — the shared verified brain - Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.31.0 ## 9. Installation risk - Installation risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Developers should check this installation risk before relying on the project: v0.32.0 — the authenticated multi-principal brain - User impact: Upgrade or migration may change expected behavior: v0.32.0 — the authenticated multi-principal brain - Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.32.0 ## 10. Installation risk - Installation risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Developers should check this installation risk before relying on the project: v0.34.0 — cross-principal verified tier (fact-bound attestation) - User impact: Upgrade or migration may change expected behavior: v0.34.0 — cross-principal verified tier (fact-bound attestation) - Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.34.0 ## 11. Installation risk - Installation risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Developers should check this installation risk before relying on the project: v0.35.0 — MCP recall/remember over a remote authenticated brain - User impact: Upgrade or migration may change expected behavior: v0.35.0 — MCP recall/remember over a remote authenticated brain - Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.35.0 ## 12. Installation risk - Installation risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow. - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: community_evidence:github | https://github.com/amitpatole/verel/issues/1 ## 13. Installation risk - Installation risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow. - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: community_evidence:github | https://github.com/amitpatole/verel/issues/3 ## 14. Installation risk - Installation risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow. - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: community_evidence:github | https://github.com/amitpatole/verel/issues/2 ## 15. Configuration risk - Configuration risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow. - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: capability.host_targets | https://github.com/amitpatole/verel ## 16. Configuration risk - Configuration risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Developers should check this configuration risk before relying on the project: v0.36.0 — TLS for routable brain/lease/registry binds - User impact: Upgrade or migration may change expected behavior: v0.36.0 — TLS for routable brain/lease/registry binds - Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.36.0 ## 17. Capability evidence risk - Capability evidence risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Project evidence flags a capability evidence risk. Review the linked source before relying on this workflow. - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: community_evidence:github | https://github.com/amitpatole/verel/issues/4 ## 18. Capability evidence risk - Capability evidence risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: README/documentation is current enough for a first validation pass. - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: capability.assumptions | https://github.com/amitpatole/verel ## 19. Maintenance risk - Maintenance risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow. - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: evidence.maintainer_signals | https://github.com/amitpatole/verel ## 20. Security or permission risk - Security or permission risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: no_demo - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: downstream_validation.risk_items | https://github.com/amitpatole/verel ## 21. Security or permission risk - Security or permission risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: no_demo - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: risks.scoring_risks | https://github.com/amitpatole/verel ## 22. Capability evidence risk - Capability evidence risk requires verification - Severity: low - Evidence strength: source_linked - Finding: Developers should check this conceptual risk before relying on the project: Broaden grader-parser test coverage with more real tool-output samples - User impact: Developers may hit a documented source-backed failure mode: Broaden grader-parser test coverage with more real tool-output samples - Evidence: failure_mode_cluster:github_issue | https://github.com/amitpatole/verel/issues/3 ## 23. Capability evidence risk - Capability evidence risk requires verification - Severity: low - Evidence strength: source_linked - Finding: Developers should check this conceptual risk before relying on the project: Docs: add a 'gate a monorepo with per-package stages' recipe - User impact: Developers may hit a documented source-backed failure mode: Docs: add a 'gate a monorepo with per-package stages' recipe - Evidence: failure_mode_cluster:github_issue | https://github.com/amitpatole/verel/issues/4 ## 24. Maintenance risk - Maintenance risk requires verification - Severity: low - Evidence strength: source_linked - Finding: issue_or_pr_quality=unknown。 - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: evidence.maintainer_signals | https://github.com/amitpatole/verel ## 25. Maintenance risk - Maintenance risk requires verification - Severity: low - Evidence strength: source_linked - Finding: release_recency=unknown。 - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: evidence.maintainer_signals | https://github.com/amitpatole/verel