@bjoernrochel/sevro 0.1.0-rc.2 → 0.1.0-rc.21

package/docs/installing.md

@@ -0,0 +1,88 @@
+# Install, update, or remove Sevro
+
+Use Bun 1.3.13 for this TypeScript/Bun CLI. Installation does not make it a
+Node-only executable. Full validation and native isolation target macOS and
+Ubuntu 24.04 x64. See the [bounded platform evidence](native-hosts.md#validated-platform-scope);
+Windows remains unverified.
+
+## Install locally
+
+```sh
+mkdir sevro-demo
+cd sevro-demo
+bun init -y
+```
+
+Then install the [current release](#current-release) in that directory.
+
+Run the [packaged deterministic example](getting-started.md#from-an-installed-package)
+to verify installation. It needs neither model credentials nor Darrow.
+Local installation records the selected version in the project lockfile.
+
+<!-- sevro-current-release:start -->
+
+## Current release
+
+The current release is `0.1.0-rc.21`. Install this exact version:
+
+```sh
+bun add --exact @bjoernrochel/sevro@0.1.0-rc.21
+```
+
+<!-- sevro-current-release:end -->
+
+## Make the command available
+
+The examples call `sevro` from `PATH`. For a local installation, run this from
+the directory containing its `node_modules`:
+
+```sh
+export PATH="$PWD/node_modules/.bin:$PATH"
+```
+
+This selects the locally installed version for the current shell, including
+after changing directories. If your installed `sevro` is already on `PATH`,
+no adjustment is needed. Bun must also be on `PATH`: the executable uses
+`#!/usr/bin/env bun`.
+
+## Published package and checkout
+
+See [licensing](licensing.md) for Sevro's source-available terms and historical
+licensing transitions.
+
+The npm package contains sources, schemas, examples, documentation,
+LICENSE, and contribution guidance. It excludes tests, developer scripts, Git
+metadata, and repository guide mounts. Use a source checkout for the guide.
+
+Source checkouts can include changes beyond their package version; compare the
+exact release tag when establishing provenance.
+
+## Work from source
+
+```sh
+git clone https://github.com/BjRo/sevro.git
+cd sevro
+bun install --frozen-lockfile
+```
+
+Run the [checkout tutorial](getting-started.md#from-a-contributor-checkout).
+`bun run test:package-install` packs and installs a local tarball in temporary
+directories; it does not publish. [Contributing](../CONTRIBUTING.md) lists checks.
+
+## Update
+
+Review a release's license and compatibility, then use the exact installation
+command for the [current release](#current-release) from your existing project.
+To select a different published version, substitute that exact version in the
+command, then rerun the [packaged example](getting-started.md#from-an-installed-package).
+Rollback uses the prior exact version and another verification run.
+[Releases](releases.md) explains artifact provenance.
+
+## Remove
+
+```sh
+bun remove @bjoernrochel/sevro
+```
+
+This updates the dependency and lockfile, not saved cases, results, or model
+logins. Remove those separately only when wanted.

package/docs/licenses/BUSL-1.1-0.1.0-rc.2.txt

@@ -0,0 +1,159 @@
+Business Source License 1.1
+
+License text copyright (c) 2017 MariaDB Corporation Ab, All Rights Reserved.
+"Business Source License" is a trademark of MariaDB Corporation Ab.
+
+-----------------------------------------------------------------------------
+
+Parameters
+
+Licensor:             Björn Rochel <bjoern@bjro.de>
+
+Licensed Work:        Sevro — a standalone evaluation runner for coding agents.
+                      The Licensed Work is (c) 2026 Björn Rochel.
+
+Additional Use Grant: You may make production use of the Licensed Work only
+                      as follows:
+
+                        (a) use within your own organization, for any
+                            purpose, commercial or non-commercial, provided
+                            that such use is not Commercial Educational
+                            Production Use;
+
+                        (b) use while performing professional, consulting,
+                            or contract services for your own clients,
+                            provided that those services do not include
+                            Commercial Educational Production Use;
+
+                        (c) use in preparing or delivering training,
+                            workshops, courses, talks, presentations, or
+                            other educational offerings, or in creating or
+                            publishing blog posts, articles, or other
+                            educational content, provided that such
+                            production use is not Commercial Educational
+                            Production Use;
+
+                        (d) use in research, evaluation, and personal
+                            projects, provided that such use is not
+                            Commercial Educational Production Use;
+
+                      provided that such production use does not include
+                      distributing, selling, sublicensing, hosting, or
+                      otherwise offering the Licensed Work, or a derivative
+                      work of the Licensed Work, to third parties as a
+                      product or service whose principal value is the
+                      functionality of the Licensed Work.
+
+                      For purposes of this Additional Use Grant,
+                      "Commercial Educational Production Use" means
+                      production use of the Licensed Work in preparing,
+                      delivering, or publishing any educational offering or
+                      content where you or anyone acting on your behalf:
+
+                        (i) receives or expects to receive, directly or
+                            indirectly, a fee, compensation, sponsorship, or
+                            other consideration in connection with it;
+
+                        (ii) supplies it as part of, or uses it to advertise
+                             or promote, a paid product, service, membership,
+                             or engagement; or
+
+                        (iii) uses it to generate leads or obtain any other
+                              direct or indirect commercial benefit.
+
+                      Reasonable reimbursement of expenses alone does not
+                      constitute Commercial Educational Production Use.
+                      Commercial Educational Production Use is not included
+                      in this Additional Use Grant.
+
+                      For clarity, nothing in this Additional Use Grant
+                      limits the non-production rights granted under the
+                      Terms below.
+
+                      For clarity, contributing modifications back to the
+                      Licensed Work, and publishing forks that are
+                      themselves offered free of charge under this License,
+                      are permitted.
+
+Change Date:          Two years from the date on which the applicable
+                      version of the Licensed Work is first made publicly
+                      available. The Change Date is determined separately
+                      for each released version.
+
+Change License:       Mozilla Public License, version 2.0
+
+For information about alternative licensing arrangements for the Licensed Work,
+please contact: bjoern@bjro.de
+
+-----------------------------------------------------------------------------
+
+Notice
+
+Business Source License 1.1
+
+Terms
+
+The Licensor hereby grants you the right to copy, modify, create derivative
+works, redistribute, and make non-production use of the Licensed Work. The
+Licensor may make an Additional Use Grant, above, permitting limited
+production use.
+
+Effective on the Change Date, or the fourth anniversary of the first publicly
+available distribution of a specific version of the Licensed Work under this
+License, whichever comes first, the Licensor hereby grants you rights under
+the terms of the Change License, and the rights granted in the paragraph
+above terminate.
+
+If your use of the Licensed Work does not comply with the requirements
+currently in effect as described in this License, you must purchase a
+commercial license from the Licensor, its affiliated entities, or authorized
+resellers, or you must refrain from using the Licensed Work.
+
+All copies of the original and modified Licensed Work, and derivative works
+of the Licensed Work, are subject to this License. This License applies
+separately for each version of the Licensed Work and the Change Date may vary
+for each version of the Licensed Work released by Licensor.
+
+You must conspicuously display this License on each original or modified copy
+of the Licensed Work. If you receive the Licensed Work in original or
+modified form from a third party, the terms and conditions set forth in this
+License apply to your use of that work.
+
+Any use of the Licensed Work in violation of this License will automatically
+terminate your rights under this License for the current and all other
+versions of the Licensed Work.
+
+This License does not grant you any right in any trademark or logo of
+Licensor or its affiliates (provided that you may use a trademark or logo of
+Licensor as expressly required by this License).
+
+TO THE EXTENT PERMITTED BY APPLICABLE LAW, THE LICENSED WORK IS PROVIDED ON
+AN "AS IS" BASIS. LICENSOR HEREBY DISCLAIMS ALL WARRANTIES AND CONDITIONS,
+EXPRESS OR IMPLIED, INCLUDING (WITHOUT LIMITATION) WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, AND
+TITLE.
+
+MariaDB hereby grants you permission to use this License's text to license
+your works, and to refer to it using the trademark "Business Source License",
+as long as you comply with the Covenants of Licensor below.
+
+Covenants of Licensor
+
+In consideration of the right to use this License's text and the "Business
+Source License" name and trademark, Licensor covenants to MariaDB, and to all
+other recipients of the licensed work to be provided by Licensor:
+
+1. To specify as the Change License the GPL Version 2.0 or any later version,
+   or a license that is compatible with GPL Version 2.0 or a later version,
+   where "compatible" means that software provided under the Change License
+   can be included in a program with software provided under GPL Version 2.0
+   or a later version. Licensor may specify additional Change Licenses
+   without limitation.
+
+2. To either: (a) specify an additional grant of rights to use that does not
+   impose any additional restriction on the right granted in this License, as
+   the Additional Use Grant; or (b) insert the text "None".
+
+3. To specify a Change Date.
+
+4. Not to modify this License in any other way.

package/docs/licensing.md

@@ -0,0 +1,42 @@
+# Sevro licensing
+
+[LICENSE](../LICENSE) is authoritative for this checkout. Sevro Source Available
+License 1.0 allows free use in all contexts, modification, and free redistribution
+under the same terms. Commercial work, paid education, research, CI, and
+consulting are permitted.
+
+Charging for copies, licensing, or hosted access to Sevro's functionality,
+including modified/rebranded versions, requires a separate license. Charging
+for independent work performed using Sevro is allowed. A hosting label cannot
+disguise a charge for the runner. Retain copyright, license, origin, and
+modification notices. This is source-available, not an OSI open-source license.
+
+## Contributions and alternative terms
+
+[Contribution terms](../CONTRIBUTING.md#contribution-licensing) give recipients
+the public license and grant Björn Rochel additional copyright relicensing
+rights. Contributors keep copyright. Other recipients do not automatically
+receive those broader rights. The project describes its current free terms;
+it does not promise that alternative licenses will never be offered.
+
+## Earlier releases
+
+Published `0.1.0-rc.1` and `0.1.0-rc.2` retain BUSL-1.1, their original
+production grant, and their per-version change date. Each changes to MPL-2.0
+two years after its first public availability. This checkout does not revoke
+or rewrite earlier grants. The [retained rc.2 license](licenses/BUSL-1.1-0.1.0-rc.2.txt)
+records those terms.
+
+Package metadata from `0.1.0-rc.3` uses `SEE LICENSE IN LICENSE`: the new license
+has no SPDX identifier. The matching LICENSE travels in the tarball. These
+terms do not alter the already published `rc.1` or `rc.2` artifacts.
+
+## Branding and independently authored material
+
+[Brand permissions](assets/README.md) are separate. Björn Rochel created the
+logo; Pierce Brown's _Red Rising_ inspired the name. [Acknowledgements](acknowledgements.md)
+credit that inspiration without implying affiliation or ownership.
+
+The runner license does not automatically govern independently authored cases,
+datasets, extensions, prompts, or outputs. Their authors/input licenses
+determine those rights. Copies of covered Sevro code remain covered.

package/docs/native-controls.md

@@ -5,7 +5,8 @@ retain an observation with that ID. It exposes host facts for extension policy:
 
 - `method: native_control_calls`;
 - ordered `calls` containing only `ordinal`, `namespace`, and `name`;
-- `acceptedAgentCount`, a verified Codex acceptance count or `null` on Claude;
+- `acceptedAgentCount`, a verified direct native Codex acceptance count when
+  overall coverage is complete, otherwise `null` (also `null` on Claude);
 - `submittedExecCalls`, the Codex submitted-code count or `null` on Claude; and
 - `truncated`, which is `false` for a complete record and may be unknown (`null`)
   for an incomplete Codex record.
@@ -15,9 +16,71 @@ tool arguments, task messages, command bodies, or results. Call labels prove an
 invocation attempt, not success. Extensions decide which calls are prohibited.
 An unknown acceptance count cannot establish agent acceptance.
 
-Codex projects labels and counts from its bound native-session observation and
-preserves its completeness. Incomplete counts remain `null`. Submitted code remains explicit: extensions cannot
-infer absence of controls inside code that this observer did not inspect.
+Codex projects labels and counts from its bound native-session observation.
+It additionally retains `directAcceptedAgentCount`, the number of positively
+correlated direct native spawn acceptances in that source, independently of exec
+inspection. This is an observed count, not a total across unknown launch paths.
+`coverage.nativeCalls` records native-session completeness;
+`coverage.execInspection` records whether all submitted exec sources were
+understood and matched to the direct submission inventory;
+`coverage.acceptedAgents: direct_native_calls` names the scope of both acceptance
+counts. Accepted launches through exec are not included in these direct counts.
+When native capture is incomplete, even a zero observed count cannot establish
+absence. Native labels remain usable as positive attempt evidence regardless
+of an unrelated exec inspection gap. A rejected attempt is never an acceptance.
+
+When submitted code is present, both observations also retain `execCalls`:
+one receipt per native `exec` submission, with its native `ordinal`, inspection
+`completeness`, and ordered `calls` containing `index`, `namespace`, and `name`.
+The index is local to that submission; native ordinals are not synthesized.
+The original direct-call list and total `submittedExecCalls` stay unchanged.
+
+Sevro statically inspects bounded straight-line Code Mode
+programs without executing them. It accepts literal tool calls, constant result
+bindings, template interpolation and `+` composition of inspected expressions,
+direct `text`/`store` output, and literal `Promise.all`/`allSettled` batches.
+Batch results may use flat constant array bindings or result-only
+`forEach(text)` or `for ... of` output, including blocks and conditional
+result-field selection. `JSON.stringify`, `String`, object spread/shorthand,
+and nested result fields are supported. Numeric output loops must use the
+bounded shape `for (let i = 0; i < results.length; i++)`, indexing the known
+batch with that loop variable. Output loops and conditional expressions cannot
+invoke tools. Destructuring defaults, rest elements,
+holes, nested bindings, duplicate names, and shadowed globals remain unsupported.
+Tool argument strings, comments and printed tool-looking text
+do not become call labels. A rejected tool request returned by a completed
+script still appears in its submitted-call inventory. This inventory proves
+submission of those requests, not successful effects or acceptance; the existing
+acceptance count describes independently correlated direct native spawns.
+
+Dynamic lookup, aliases, shadowed globals, callbacks that invoke tools,
+conditional tool execution, and nested executors keep source inspection partial.
+Each receipt's `inspectionReason` is `null` on success, or `unsupported_source`,
+`malformed_source`, `source_limit`, or `foreign_namespace`. Unsupported syntax
+and expression/call-budget exhaustion use `unsupported_source`.
+Source is bounded at
+64 KiB, traversed expressions at 2,048, and calls at 128 per submission; tool
+labels are bounded at 64 characters. Private source and output bytes are discarded.
+The portable observation becomes partial if any submission is uninspected or
+receipt counts/ordinals disagree with the native list. `acceptedAgentCount`
+remains `null` in that case, while native coverage, direct acceptance facts and
+the native `submittedExecCalls` count remain independently available.
+`submittedExecCalls` and `truncated` depend on native capture, not exec output.
+
+Receipt `completeness` describes source inspection, independently of execution
+or displayed output. `execution` is `completed`, `failed`, or `incomplete`;
+`output` is `complete`, `truncated`, or `unavailable`. Output evidence requires
+a unique later output bound to the same native call ID, with recognized text
+blocks. `complete` describes the displayed receipt, not the whole program's
+execution. Execution status additionally requires a successful or failed script
+header. Missing, ambiguous or
+malformed output yields `incomplete`/`unavailable`; a yielded or unrecognized
+header stays `incomplete`. Displayed truncation does not change source coverage.
+A fully inspected source with no launch call proves that absence even if its
+shell output was truncated or the exec cell failed. Source inspection cannot
+prove execution or success. Missing fields in historical receipts are unknown;
+historical artifacts retain their original results and meanings.
+
 Claude records every tool-use label from the bounded stream, with namespace
 `claude`, without filtering to Skill or Agent. It requires a completed successful
 turn, valid unique tool-use IDs and names, and a non-truncated list of at most
@@ -26,4 +89,12 @@ Tool-looking text in arguments or output does not become a native call.
 
 Consumers must verify the source, completeness, shape, ordering, and counts
 before using an empty call list to establish absence. Missing or partial
-evidence cannot establish a negative assertion.
+source coverage cannot establish a negative assertion. For Codex, consumers must
+inspect every `execCalls` receipt in addition to the direct `calls` list,
+validate receipt ordinals against the direct `exec` submissions, and require
+all receipts to be complete with counts matching `submittedExecCalls`.
+They can use positively observed native attempt labels before requiring complete
+coverage for an absence pass. They must examine submitted labels for prohibited controls even when
+`acceptedAgentCount` is zero. Older consumers that require
+`submittedExecCalls === 0` remain conservative but cannot use this new evidence
+until they adopt receipt validation.

package/docs/native-hosts.md

@@ -0,0 +1,228 @@
+# Run native model hosts
+
+The basic tutorial needs none of this setup. Bundled model routes and isolated
+shell checks require macOS `sandbox-exec` or Linux `bubblewrap` (and `socat` for
+Claude Code), a supported native CLI, and model
+authentication. Complete commands/rules live in the [CLI reference](development-cli.md)
+and [Codex host reference](codex-host.md).
+
+## Validated platform scope
+
+The full source quality gate has passed on macOS arm64 and Ubuntu 24.04 x64.
+Ubuntu evidence includes [the successful source CI run for `cd7542bf`](https://github.com/BjRo/sevro/actions/runs/38692971517).
+That run exercises deterministic native-host protocols and real filesystem,
+process, network and shell isolation with the pinned prerequisites in
+[the quality contract](typescript-quality.md#environment-and-ci). It does not
+establish authenticated model success for every host/model combination.
+This is prior source evidence; changed candidates still need their own green CI.
+Other Linux distributions and Windows are unverified.
+
+On Ubuntu, install `bubblewrap`, `ripgrep`, and `socat`. Unprivileged user
+namespaces must work; Ubuntu's AppArmor policy may need a `bwrap` profile.
+[CI's setup script](../scripts/setup-ci-linux.sh) supplies and probes the
+supported runner setup. Use it as an explicit development setup step where
+appropriate; do not assume all Linux hosts have that configuration.
+
+## Codex
+
+Select `--host codex`, absolute `--codex-bin` and `--codex-auth-file` paths,
+and the desired model/effort. Sevro prepares an isolated host environment.
+Keep authentication private and outside candidate/evaluator-visible inputs.
+The default entrypoint is `exec`; app-server selection and native-goal
+observations require `rc.2` or later. Unsupported instrumentation is refused.
+
+## Claude Code
+
+Select `--host claude`, an absolute `--claude-bin`, and the desired model/effort.
+The route supports passive candidate turns. Explicit `--claude-credential-file`
+takes precedence. Otherwise this checkout forwards inherited API/OAuth
+credentials, then tries a saved credential file and macOS Keychain.
+These improvements require `rc.3` or later; check the exact installed
+release before relying on them.
+
+Repository skill mounts under `.claude/skills` require explicit
+`--claude-project-settings`; otherwise repository dispatch is refused before
+launch. The bundled route disables hooks by default and omits candidate Write
+access. [Runtime configuration](runtime-v1.md) enables native goals and selected
+plugin hooks and reuses declared host tools with private or explicitly shared caches. These changes
+require `rc.3` or later. The CLI reference covers credential scrubbing
+and follow-ups.
+
+## Skill activation evidence
+
+Both bundled adapters advertise `sevro.host.skill-activations`. Its observation
+retains qualified `observedSkills`, bounded call identities, and explicit
+`complete` or `partial` collection status. This is the sole activation collector
+for each host. It replaces Codex's command-pattern and native output-recovery
+detectors and Claude's separate nested-skill collector. Consumers must require
+this observation; the retired observation IDs are no longer emitted.
+
+Codex installs passive runner-owned hooks in its private home for each request.
+The `tool_result_body_match` method compares returned tool content against a
+snapshot of prepared repository, plugin and private user skill bodies. It does
+not parse shell commands, so variables, pipelines, Python and nested Code Mode
+calls use the same collector. Pre/post call pairs and session start/stop markers
+establish collection health. Unselected plugin handlers are removed before
+hooks are enabled, and fixture-local Codex configuration remains untrusted.
+No global hook installation or root privileges are required.
+
+This Codex receipt proves exact body exposure to the tool caller. Code Mode can
+discard that output before returning to the model. An identical ordinary
+document also matches; the receipt does not prove its source file was opened.
+Identical bodies registered under different names are reported as
+`ambiguousSkills`, with partial evidence. Exact pages can establish a body match
+across tool results from the same session and turn. Coverage is tied to the
+prepared body digest; overlapping or repeated pages cannot fill a missing range.
+The call that completes coverage receives the activation receipt. Fragments
+from different sessions or turns never combine.
+
+Page matching uses complete nonblank lines as anchors and exact fragments of
+at least 32 string code units. Fragments with multiple possible positions in a
+body cannot establish coverage. Recognizable unfinished fragments appear in
+`partialSkills` and keep the observation partial; a later complete match resolves
+them. Within each tool result, text covered by unambiguous complete-body matches
+does not also imply partial reads of skills sharing that text. Fragments returned
+outside those complete-body spans or in other tool results remain independent
+partial-read evidence. Comparison and anchor budgets also fail closed. Private receipts retain
+body offsets rather than tool text; the public observation omits those offsets.
+Shorter, transformed or unanchored fragments remain outside this matching scope.
+Newly created or changed skill bodies are outside the prepared snapshot. A
+complete empty observation is limited to this scope and the supported local
+tool hook paths.
+
+Codex separates per-skill exposure from collection health in the same
+observation. `skillExposures` contains one `{ skill, status }` entry per prepared
+catalog entry, in catalog order, with qualified skill names:
+
+| Status      | Meaning                                                                 |
+| ----------- | ----------------------------------------------------------------------- |
+| `full`      | The complete prepared body was exposed, in one result or exact pages.   |
+| `partial`   | Recognizable fragments were exposed without establishing the full body. |
+| `none`      | No exposure was detected within a complete collection's matching scope. |
+| `unknown`   | No exposure was detected, but collection gaps prevent an absence claim. |
+| `ambiguous` | Body exposure could not distinguish identically registered bodies.      |
+
+`collectionStatus` is `complete`, `partial`, or `unavailable`. No parsed hook
+receipts means `unavailable`; otherwise collection gaps mean `partial`.
+Recognized partial bodies and ambiguous identities alone do not indicate a
+collection failure. Their existing `incompleteReasons` still keep the aggregate
+activation observation partial for compatibility. Other reason codes, including
+truncated call diagnostics, keep collection partial. Older observations without
+these new fields have unknown exposure and collection status; do not infer them
+from an empty `observedSkills` list.
+
+Exposure statuses use all parsed receipts before the diagnostic `calls` list is
+bounded. A proven `full` or `partial` exposure survives collection gaps, including
+an earlier pending call, missing lifecycle hooks or an invalid receipt tail.
+Full exposure takes precedence over fragments; ambiguous identities cannot
+establish exposure of a particular named skill. `none` does not establish that
+the skill was never used outside the prepared catalog and matching scope.
+Recognizable fragments may be shared by several skill bodies. These statuses
+describe content exposure to a tool caller, not instruction compliance, model
+visibility or selection order.
+
+The Codex adapter also advertises `sevro.host.skill-exposure-claims`. When at
+least one skill has `full` or `partial` exposure, it emits that observation with
+`completeness: complete`, `method: tool_result_body_match`,
+`scope: positive_exposure`, the original `collectionStatus`, and `skillExposures`
+containing only those positive entries. It is absent when no unambiguous
+positive exposure is available. Extensions can require this evidence for a
+specific positive assertion: accept only `full` for complete body exposure,
+or explicitly accept `partial` when recognizable exposure suffices. A `partial`
+entry is not a full activation. This receipt cannot establish absence, first
+selection, a complete sequence or successful execution; collection remains
+independently qualified. Existing activation and primary-selection requirements
+are unchanged. Claude's native `Skill` seam does not emit body-exposure statuses
+or these positive body-exposure claims.
+
+Codex observations include `incompleteReasons`: an empty array for a complete
+aggregate activation observation, or all applicable reason codes for a partial
+aggregate observation. The separate `collectionStatus` isolates collection
+health from partial bodies and body ambiguity. Older
+observations without this field have unknown reasons; their missing details
+cannot be reconstructed from balanced native call/return counts.
+
+| Reason                                           | Meaning                                                                                            |
+| ------------------------------------------------ | -------------------------------------------------------------------------------------------------- |
+| `host_incomplete`                                | Host execution did not complete.                                                                   |
+| `catalog_incomplete`                             | The prepared catalog could not be collected completely.                                            |
+| `receipts_unavailable`                           | The receipt file is missing or unreadable.                                                         |
+| `invalid_receipts`                               | A malformed receipt stopped processing; earlier valid receipts remain available.                   |
+| `receipt_limit`                                  | The receipt file exceeds the collection byte limit.                                                |
+| `observer_failure`                               | The hook recorded a failure or writer limit, including input, nesting or matching-budget failures. |
+| `session_identity_missing`                       | No root session identity was available.                                                            |
+| `session_start_missing` / `session_stop_missing` | The root session lacks the corresponding lifecycle hook.                                           |
+| `pending_tool_calls`                             | Pre-tool hooks remain without matching post-tool hooks.                                            |
+| `unmatched_post_tool_use`                        | Post-tool hooks were received without pending pre-tool hooks.                                      |
+| `duplicate_tool_calls`                           | A pre-tool identity was already pending or finished.                                               |
+| `partial_hook_events`                            | A hook receipt is partial independently of body ambiguity.                                         |
+| `ambiguous_skill_bodies`                         | Complete body exposure could not distinguish skill names.                                          |
+| `partial_skill_bodies`                           | Recognized fragments remain without complete body exposure.                                        |
+| `calls_truncated`                                | Relevant call evidence exceeded its public count or byte budget.                                   |
+
+The `collection` summary reports `eventCount`, `preToolUseCount`,
+`postToolUseCount`, `pendingToolCallCount`, `unmatchedPostToolUseCount`,
+`duplicateToolCallCount` and `partialEventCount`, plus `sessionIdentified`,
+`sessionStarted` and `sessionStopped` for the root session. Counts cover all
+successfully parsed receipts, including receipts omitted from `calls`; an
+unreadable or invalid tail remains unknown. Tool pairing spans the observed
+sessions and uses session and tool-use identities. A later balanced pair is
+still counted after an earlier anomaly.
+
+`calls` is a bounded selection of complete matches, fragment-only matches,
+ambiguous or partial receipts, and receipts associated with pending, orphaned
+or duplicate tool identities. Each entry's `fragmentSkills` names recognizable
+fragments without exposing their body offsets or digests. A fragment entry can
+remain in `calls` after later complete exposure resolves `partialSkills`.
+Neither `partial: false` on an individual receipt nor an empty `partialSkills`
+array proves aggregate completeness. `truncated` describes this selected call
+list, which is never the complete observer event ledger. A pending tool hook
+can follow a rejected launch or a missing hook; it does not establish either
+cause, and a tool error with a balanced hook pair does not itself imply an
+observer gap. These diagnostics preserve unknown activation verdicts and do
+not recover activation from native transcripts.
+
+Codex also reports `primarySkill` and `primarySkillCompleteness` separately
+from whole-collection completeness. A complete collection establishes its first
+observed skill when the first matching receipt credits exactly one skill, or
+`null` when none was observed. Multiple bodies credited by the first receipt
+leave primary selection unknown even with complete collection; their catalog
+order does not prove selection order. A partial collection can still
+establish the primary skill when its only gap is pending tool calls, exactly one
+skill was credited by the first matching receipt, and every call started through
+that receipt has a matching post hook. A later pending call cannot change that
+established first selection. An earlier or overlapping pending call leaves the
+primary unknown (`null` with `primarySkillCompleteness: partial`). Other
+collection gaps remain conservative. Consumers may use the established primary
+for first-selection assertions while retaining the partial collection status;
+this claim does not establish exclusions or a complete supporting sequence.
+When a partial collection establishes the primary, the same collector emits
+`sevro.host.skill-activation-claims` as complete evidence with scope
+`primary_and_positive_presence`, the qualified `primarySkill`, and `presentSkills`.
+It retains `collectionCompleteness: partial`. Consumers cite this receipt for
+those specific claims, preserving the protocol's requirement that passing
+results cite complete evidence. It cannot establish an exclusion or an
+unobserved supporting read and is absent when the primary is unknown.
+
+Claude's `skill_tool_result` method observes its existing structured `Skill`
+stream without enabling additional command hooks. It pairs each call with a
+successful result under the same session, parent actor and tool-use ID.
+Failed calls remain failed; unmatched attempts and malformed or conflicting
+records remain partial. Native explicit command expansion can load a skill
+without a `Skill` call. Explicit-dispatch receipts describe dispatch only;
+they do not add entries to the activation observation. A direct Claude `Read`
+also falls outside the `Skill` seam and is not inferred from its file path.
+
+The collectors retain no tool arguments, outputs or skill bodies in the new
+observation. Codex catalogs at most 128 skills, each at most 1 MiB, with an
+8 MiB total body budget. Call receipts are bounded; missing collection,
+unfinished calls, catalog or receipt limits, and failed execution remain
+partial. Required evidence must not interpret these states as proof that a
+skill was unused.
+
+## Keep sources and credentials separate
+
+Declare source/private roots as documented. Never put credentials in prompts,
+argv, redacted configuration, or public evidence. Injected adapters are trusted
+code and must implement their execution contract. A synthetic native packaging
+fixture proves packaging behavior, not a successful authenticated model trial.