Tendril report verification

Type: agentic-system-analyses/types/agentic-system-verification.md

Verification

The reports support a bounded implementation account. The previous runtime blocker is repaired: generated-program mutation and human editor mutation now have separate declarations, admission owners, statuses and route fields. I judged the current members afresh and independently traced the source; neither the earlier verification nor the correction answer was treated as evidence of support. The supplied report-check says none. The runtime answer reports the separation; the other three answers are empty. No structural finding requires routing.

The SRC-1 checkout HEAD is the reviewed revision and its working tree is clean. Its top-level tracked entries agree with the coverage table in boundary. The desktop, sidecar, registry and generated-program executor form a connected shipped system, not merely a storage API with an excluded caller. No evidence contradicts the target class or whole-system boundary.

Independent source coverage

I read the complete SRC-1 implementation files tendril-agent/src/agent.ts, tendril-agent/src/config.ts, tendril-agent/src/index.ts, tendril-agent/src/types.ts, all four tendril-agent/src/loop/ modules, and tendril-agent/src/transport/protocol.ts and tendril-agent/src/transport/stream.ts. On the desktop side I read the complete tendril-ui/src/App.tsx, both hooks, tendril-ui/src/context/AgentContext.tsx, tendril-ui/src/components/FileExplorer.tsx, tendril-ui/src/components/CapabilityBrowser.tsx, tendril-ui/src/components/ToolTrace.tsx, tendril-ui/src/stronghold.ts, and the Rust acp, config, workspace, files, capabilities, lib and events modules under tendril-ui/src-tauri/src/. I also read tendril-ui/src-tauri/capabilities/default.json and the settings state/save implementation in tendril-ui/src/components/SettingsPanel.tsx.

For claims and evaluators I read SRC-1, README.md, Makefile, .github/workflows/quality-gate.yml, tendril-agent/tests/registry.test.ts, tendril-agent/tests/sandbox.test.ts and tendril-agent/tests/integration.test.ts. These reads provide implementation and doctrine/design evidence, not observed operation or passing test results. I did not execute the target, tests, examples or providers. The source register remains boundary's SRC-1; no new evidence identity is introduced.

Runtime and correction disposition

The four provider components—RT-CMP-bedrock-model, RT-CMP-openai-model, RT-CMP-anthropic-model and RT-CMP-ollama-model—match the constructor branches. Their symbolic adapters are distinguished from external distributed-parametric models. Git and model-ID strings do not pin weights; provider-internal mutation remains uninspected. No learning absence follows from the lack of a Tendril weight-update API.

RT-OBJ-system-prompt, RT-BAP-prompt-guidance and RT-CLM-action-sequence correctly identify the constructor instruction, display-only file copy and requested list/match/create/execute sequence. The callbacks have no sequence or semantic-match state machine. RT-RTE-prompt-stream correctly distinguishes acknowledgement, iteration, streamed updates and completion. The session UUID does not reconstruct the Agent; the adapter forwards extracted current text, not the desktop transcript. Latest usage assignment and post-error completion are implementation facts, not validity guarantees.

RT-RTE-capability-admission accurately traces model authorship, schema/name checks, index-before-source persistence and exact-name replacement. Registration does not run the candidate first or preserve an old version. RT-RTE-capability-execution accurately traces named source loading, argument parsing, temporary prelude/script, Deno grants and result settlement. Loading does not consult index membership. The grant covers workspace files, including registry files; default network access is unrestricted. Timeout, output cap and cancellation are best-effort process controls, not reversal of prior effects. The executable consumer and persistence horizon in RT-BAP-capability-source match that chain.

The repair is supported by SRC-1, tendril-agent/src/loop/sandbox.ts, tendril-ui/src/components/FileExplorer.tsx and tendril-ui/src-tauri/src/files.rs. RT-RTE-program-mutation owns afforded workspace mutation under an existing Deno grant, with no second content approval and no supplied mutating program. RT-RTE-editor-mutation owns the wired human selection/edit/confirmation and path-checked backend write. Declining confirmation vetoes that UI save only. Each part has its own seven route fields, status, rejection/recovery account and evidence limits. Both are genuinely contained by RT-RTE-workspace-mutation. The container now explicitly limits its afforded assessment to shared bypass capacity rather than assigning one approval policy or implementation status to both parts. Its identity and supported bypass findings remain intact. The previous blocker is therefore discharged, not moved into Limits.

RT-RTE-settings-restart is supported by App persistence/restart, Rust configuration handling and Node startup parsing. Lightweight Rust checks differ from Zod validation; DENO_PATH takes precedence. Searches and constructor/registry reads confirm that maxTurns and maxCapabilities declarations are not consumed as the asserted runtime enforcement bounds. The record already withholds those bounds. Generic workspace containment and specialized source reading remain correctly separated rather than promoted into an application-wide security guarantee.

Memory findings

I checked every memory declaration and annotation against the corresponding producer and consumer. MEM-OBJ-selection-text separates model-interpreted descriptions and invocation policy from MEM-OBJ-index-metadata, whose date/path/attribution/version fields have fixed bookkeeping uses. The fixed version and attribution are not revision history or provenance attestation. MEM-OBJ-tool-source is retained executable content, not a raw trace or tested implementation. MEM-OBJ-agent-display is process-local React state. Its debug collector can retain 501 entries and grow chunk text without a byte/token bound, as the report states.

MEM-RTE-capability-list reloads and projects all four selection fields, without relevance ranking or a listing-specific budget. Bodies and bookkeeping are omitted. MEM-BAP-selection-guidance assigns guidance, not enforced suppression or source verification. MEM-RTE-capability-browser has a human consumer and per-card source cache; index refresh does not explicitly invalidate cached source. The source reader lacks the generic file reader's root validation and explicit size cap. These distinctions are supported.

The memory annotations preserve separate human/program admission, transient output versus durable source, prompt display versus active instruction, and desktop state versus opaque SDK history. Withdrawal must account for both index and source: removing an index entry does not disable an executable filename. No coupled removal, versioned rollback, structured outcome-to-revision history or mandatory rationale is supplied by the inspected registry API. That does not establish that arbitrary generated contents contain no reasons or evaluators. The write/read accounts retain this uncertainty and do not infer exercised trace learning or improvement.

Epistemic, workflow and relation findings

I checked all epistemic objects and ledger functions. EPI-OBJ-capability and EPI-OBJ-triggers-suppression distinguish a behavioral description from selection policy. EPI-OBJ-tool-code, EPI-OBJ-tool-output and EPI-OBJ-agent-text distinguish retained programs, transient stdout and generated answer text. Without instances, particular propositions cannot be classified as checked derivations or non-entailed conjectures. EPI-RTE-model-production appropriately leaves the content relation indeterminate.

EPI-RTE-summary-projection preserves selected wording while omitting attribution context. EPI-RTE-execution-check produces process/resource signals; EPI-RTE-result-disposition consumes them to resolve or reject output. Zero exit admits trimmed stdout, not truth, and successful stderr is omitted. EPI-RTE-display-result correctly treats completed/end-turn labels as presentation. EPI-RTE-failure-repair assesses requested repair as claimed/doctrine-only, independently of the wired write mechanism. No observed repair, evidence-consuming epistemic acceptance or subsequent lifecycle integration is inferred.

EPI-RTE-development-check identifies repository checks and their dependent CI build-check, not a runtime generated-capability gate. Test fixtures and skip conditions do not establish passing results or general answer correctness. EPI-CLM-session-smarter and EPI-CLM-live-data accurately retain the strong improvement claim and live-data preference while withholding longitudinal benefit, freshness and truth. File-mediated self-extension is supported; learning, reflection, theory-building and exercised self-improvement remain separate unestablished properties, not a bundled negative.

The workflow account and its three annotations connect one prompt-supported request/list/create/execute/return sequence. Rejection is mechanical, the same model is the instructed repairer, and delivery is an event path rather than task acceptance. No independent reviewer or successful repair is invented. Empty workflow declaration kinds do not conceal a competing route identity.

I checked every Part of: relation for semantic containment, including the new mutation parts. Candidate generation, answer text and presentation belong to prompt-stream; descriptions, invocation policy, summary read-back and repair instruction belong to admission's explicitly stated scope; stdout, execution signals and result disposition belong to execution. Cross-kind containment is explained and does not identify a payload with its writer. I checked the source anchors and evidence strengths for all declarations; none declares an evidenced absence requiring a system-complete search.

Both amendments in reconciliation preserve identity: tool-code/source identify the same retained bytes, and summary-projection/list identify the same read/projection/delivery route. Neither erases qualifications. Selection text can remain a valid container alongside finer descriptive and policy objects. Objects are not merged with authority paths, and check/disposition parts remain distinct. The reconciler's integration dispositions correctly recognize the new mutation parts and remove the prior missing-part conflict. The epistemic ledger's implemented grant-capacity row does not contradict an afforded particular program-write route; its human row does not extend confirmation to program writes. Memory and workflow dependencies remain supported. No unresolved substantive cross-report disagreement was found.

Omission questions and stopping decision

I selected consequential omission questions from the frozen tree, shipped command registrations and producer/consumer dependencies: whether host/editor or program writes bypass registration; whether another shipped reader makes display state into durable model memory; whether initialization, settings or developer evaluators impose a semantic admission gate; and whether execution requires registry membership. Searches across SRC-1, tendril-agent/src, tendril-ui/src and tendril-ui/src-tauri/src covered agent construction, persistence/write operations, checkpoint/compaction/summarization, browser storage and both declared turn/capacity controls. Direct traces above resolve the material hits. ToolTrace summarization is human presentation, not model-context compaction. Stronghold retention supplies credentials, not experience-derived knowledge.

The selected questions have supported dispositions: alternate writers are separately represented; display and browser consumers do not establish model checkpoints; configuration controls startup rather than task-answer warrant; developer checks do not gate workspace registration; and source-file loading is independent of index admission. No identified material challenge remains without disposition. Optional expansion stops here because further historical-document or arbitrary-generated-program inspection is not reasonably required to retain these bounded conclusions. This is not evidence of exhaustive historical claims coverage, SDK context-management absence, or an evaluator-free generated corpus. The reports already express those uncertainties locally. They do not undermine the retained capability account and are not new unresolved findings requiring publication Limits.

Blockers

none

Limits

none