agentic-scorecard 0.3.0 → 0.4.0

package/AGENT_PROMPT.md

@@ -1,69 +1,85 @@
-# Ask an AI coding agent to run ADRB v0.3
+# Ask an AI coding agent to run ADRB v0.4
 
 These prompts are vendor-neutral. The agent needs terminal access to the repository and permission
 to download the published npm package. The default benchmark runs locally, reads only tracked paths,
 invokes no model, uploads no source, and makes no network calls after installation.
 
-## Recommended: repository baseline
+## Recommended: complete agent-assisted assessment
 
 Copy and paste:
 
 ```text
-Assess this repository's readiness for AI-agent pull-request work.
-
-From the repository root, run:
-npx --yes agentic-scorecard@0.3.0 assess . --profile pr-creation --scope tracked --format markdown --output .agentic/reports/agentic-readiness-v0.3.0.md
-
-Do not change product source, configuration, policies, or tests. Do not invent evidence or mark an
-attestation as met. Read the report and tell me:
-1. the normative score out of 40 and the repository-detected progress against its offline ceiling;
-2. the highest passed readiness profile and whether pr-creation passes;
-3. each target-profile blocker and its evidence scope;
-4. the five highest-value improvements in dependency order;
-5. which findings are repository gaps versus external or outcome evidence not yet established; and
-6. any likely false positive or false negative.
-
-Keep repository-detected, agent-collected, and human-attested evidence separate. Treat UNKNOWN as
-unresolved, not failed. Leave generated artifacts uncommitted unless I explicitly ask otherwise. If
-the command cannot run, explain the exact blocker without modifying the repository to work around
-it.
+Perform the complete ADRB v0.4 assessment of this repository for AI-agent pull-request work.
+
+Do not change product source, tests, configuration, policies, Git history, or the user's current
+checkout. First inspect the repository's commit, tracked-file status, upstream tracking branch, and
+ahead/behind state. If read-only network access is already authorized, fetch the upstream before
+comparing it. Select the commit before creating an assessment worktree. Default to the current HEAD;
+a dirty checkout does not change that selection, so assess HEAD from an isolated clean worktree. Use
+the fetched upstream commit only when I asked for the latest/current upstream state and the branch is
+behind. If the checkout is both dirty and behind, state both facts and preserve HEAD by default unless
+I explicitly asked for upstream or another commit. State the exact commit you selected and why.
+
+Before running the scorecard, choose and state an absolute durable artifact directory outside any
+temporary worktree. Do not delete that directory during worktree cleanup. In the commands below,
+replace `<artifact-dir>` with that path. The npm package and immutable ADRB benchmark are both
+version 0.4.0, so report filenames also use 0.4.0.
+
+From that clean target, run the repository-only baseline:
+npx --yes agentic-scorecard@0.4.0 assess . --profile pr-creation --scope tracked --format markdown --output <artifact-dir>/agentic-readiness-v0.4.0-baseline.md
+
+Then prepare unresolved evidence:
+npx --yes agentic-scorecard@0.4.0 init-evidence . --output <artifact-dir>/agent-evidence.yaml --request-output <artifact-dir>/evidence-request.md
+
+Read the baseline, `<artifact-dir>/evidence-request.md`, and the empty target-bound
+`<artifact-dir>/agent-evidence.yaml`. Investigate nuanced repository-scoped requests only from
+tracked files at the selected commit. Before accessing Git hosting settings, CI, dashboards, logs,
+ticketing, or any other connected system, tell me exactly which least-privileged read-only tools,
+accounts, repositories, branches, dashboards, and time ranges you need, and why. Wait for my
+authorization.
+
+After authorization, attempt only eligible requests. For every attempted claim, record its status,
+scope, concise derivation, collection time, 30-day-or-shorter expiry, and durable privacy-safe
+references. Repository claims must use `repo:<path>[#Lx-Ly]`; do not merely restate a keyword match.
+A permission error, stale source, or inconclusive result remains unknown and records the error.
+Never infer a pass, invent an attestation, or treat unavailable evidence as a failure.
+
+Do not place credentials, prompts, source excerpts, raw logs, personal data, customer data, private
+URLs that reveal secrets, or sensitive dashboard contents in generated files.
+
+When authorized evidence collection is complete, run:
+npx --yes agentic-scorecard@0.4.0 assess . --profile pr-creation --scope tracked --agent-evidence <artifact-dir>/agent-evidence.yaml --format markdown --output <artifact-dir>/agentic-readiness-v0.4.0-assisted.md
+
+Tell me the repository-detected progress and normative score, the highest passed profile, whether
+pr-creation passes, every target blocker, and the five highest-value improvements. Compare baseline
+and assisted reports control by control. Keep repository-detected, agent-collected, and
+human-attested evidence separate; treat UNKNOWN as unresolved, not failed; and flag likely false
+positives or negatives. If I decline external access, stop after the baseline and label it clearly as
+a repository-only baseline. Before removing a temporary worktree, verify that every report, evidence
+request, and evidence bundle you cite exists in the durable artifact directory, then tell me that
+directory's absolute path. Leave generated artifacts uncommitted unless I explicitly ask otherwise.
+Do not describe any result as certified, compliant, safe, secure, or independently verified.
 ```
 
-## Agent-assisted unresolved evidence
-
-Use this only after reviewing the repository baseline:
-
-```text
-Investigate the controls that the ADRB v0.3 baseline could not establish.
-
-First ensure tracked files match HEAD and the repository has a commit, then run:
-npx --yes agentic-scorecard@0.3.0 init-evidence .
-
-Read `.agentic/evidence-request.md` and the empty target-bound
-`.agentic/agent-evidence.yaml` bundle. The request includes only unresolved controls that permit
-agent-collected evidence. Before accessing any connected system, tell me which read-only tools,
-accounts, repositories, branches, dashboards, and time ranges you need. Wait for my authorization.
-
-After authorization, use only least-privileged read-only operations. For each attempted control,
-record the source-backed status, scope, concise derivation, collection time, 30-day-or-shorter
-expiry, and durable privacy-safe references. For repository-scoped claims, cite only tracked files
-at the bound commit using `repo:<path>[#Lx-Ly]`; do not use a repository claim to restate a keyword
-match. Add only claims you actually investigated. A permission error or inconclusive result must
-remain unknown and include the error; never infer a pass.
+The agent is an evidence investigator. The scorecard remains the scoring authority.
 
-Do not paste credentials, prompts, source excerpts, raw logs, personal data, customer data, or
-sensitive dashboard contents into the bundle.
+## Fast repository-only baseline
 
-Then run:
-npx --yes agentic-scorecard@0.3.0 assess . --profile pr-creation --scope tracked --agent-evidence .agentic/agent-evidence.yaml --format markdown --output .agentic/reports/agentic-readiness-v0.3.0-assisted.md
+Use this when you want an offline first look and accept that platform, organization, and outcome
+controls will remain unresolved:
 
-Summarize every score change and keep agent-collected evidence distinct from deterministic
-repository evidence and human attestations. Do not describe the result as certified, compliant,
-safe, secure, or independently verified.
+```text
+Run a fast repository-only ADRB v0.4 baseline for AI-agent pull-request work. Verify and state the
+selected commit and whether tracked files match HEAD, then run:
+npx --yes agentic-scorecard@0.4.0 assess . --profile pr-creation --scope tracked --format markdown --output .agentic/reports/agentic-readiness-v0.4.0-baseline.md
+
+Do not change repository files or invent evidence. Summarize repository-detected progress before
+the normative score, target-profile blockers, and the five highest-value repository improvements.
+Separate true repository gaps from platform, organization, and outcome evidence that this offline
+scan cannot establish. Treat UNKNOWN as unresolved, not failed, and call the result a repository-only
+baseline rather than a complete assessment. Leave generated artifacts uncommitted.
 ```
 
-The agent is an evidence investigator. The scorecard remains the scoring authority.
-
 ## Choose a different authority level
 
 Replace `pr-creation` with one of:
@@ -79,7 +95,7 @@ No benchmark profile grants production deployment authority.
 ## Guided remediation
 
 ```text
-Read the latest ADRB v0.3 report and create a remediation proposal for the failed target-profile
+Read the latest ADRB v0.4 report and create a remediation proposal for the failed target-profile
 controls. Do not implement changes yet. Group recommendations into repository changes, platform or
 organizational controls, and outcome measurement. For each include the control ID, risk reduced,
 systems affected, accountable role, verification method, dependencies, and effort estimate. Never
@@ -90,7 +106,7 @@ authorize.
 ## Reassessment
 
 ```text
-Re-run the pinned ADRB v0.3.0 benchmark for the same profile and tracked scope. Compare reports
+Re-run the pinned ADRB v0.4.0 benchmark with agentic-scorecard@0.4.0 for the same profile and tracked scope. Compare reports
 control by control. Explain changes using evidence and identify changed commit state, expired
 claims, scope differences, regressions, or newly established controls. Compare normative and
 repository-detected progress separately. Write a new dated report; do not overwrite the previous

package/README.md

@@ -16,26 +16,33 @@ The benchmark measures the harness, not the model brand. It assesses ten dimensi
 maturity levels and applies non-compensating floors to five autonomy profiles. A high total score
 cannot hide a critical security, testing, governance, or recovery gap.
 
-This repository is a **v0.3 reference implementation** intended for public review and piloting. It
-is not a certification standard. The immutable v0.1 and v0.2 benchmarks remain available for
+This repository is a **v0.4 reference implementation** intended for public review and piloting. It
+is not a certification standard. The immutable v0.1, v0.2, and v0.3 benchmarks remain available for
 historical reproduction; scores from different benchmark versions are not directly comparable.
 
 ## Ask your coding agent
 
-You do not need to install or learn the CLI yourself. Paste this prompt into Codex, Claude Code,
+You do not need to install or learn the CLI yourself. Paste this instruction into Codex, Claude Code,
 GitHub Copilot, Cursor, or another coding agent that has terminal access to your repository:
 
-> Assess this repository's readiness for AI-agent pull-request work. From the repository root, run
-> `npx --yes agentic-scorecard@0.3.0 assess . --profile pr-creation --scope tracked --format markdown --output .agentic/reports/agentic-readiness-v0.3.0.md`.
-> Do not change product source code or invent attestations. Read the resulting report and summarize
-> the score, highest passed profile, whether `pr-creation` passes, target-profile blockers, and the
-> five highest-value improvements. Separate repository gaps from external and outcome evidence, and
-> keep repository-detected, agent-collected, and human-attested evidence distinct. Flag likely false
-> positives or negatives. Leave generated artifacts uncommitted unless I ask you to commit them.
-
-That is the recommended first assessment. The agent downloads the pinned benchmark package, runs the
-read-only local collector, and explains the results. For alternate authority levels or a guided
-remediation session, use the prompts in [AGENT_PROMPT.md](AGENT_PROMPT.md).
+> Perform the complete ADRB v0.4 assessment of this repository for AI-agent pull-request work using
+> `agentic-scorecard@0.4.0`. First select and state the commit without modifying my checkout; preserve
+> HEAD when the checkout is dirty, and use upstream only if I requested the latest upstream state.
+> Assess it from a clean worktree and keep all generated artifacts in a durable directory outside any
+> temporary worktree. Run the tracked repository baseline, then run `init-evidence`, read its evidence
+> request, and tell me which least-privileged read-only connected systems you need. Wait for my
+> authorization before accessing them. After authorized collection, rerun the assessment and compare
+> the baseline and assisted reports control by control. Keep repository-detected, agent-collected, and
+> human-attested evidence separate; never invent evidence; treat UNKNOWN as unresolved; and leave
+> generated artifacts uncommitted.
+
+The complete copy-and-paste prompt, including privacy limits and exact commands, is in
+[AGENT_PROMPT.md](AGENT_PROMPT.md). It makes the evidence-assisted workflow the recommendation. A
+fast filesystem scan remains available, but it is explicitly a **repository-only baseline** and
+cannot establish platform, organization, or outcome controls by itself.
+
+The reference CLI/package and immutable benchmark are both version 0.4.0. Generated report and
+evidence filenames use the benchmark version.
 
 ## Feedback and community
 
@@ -70,7 +77,7 @@ A supported Node.js LTS release (20.19+, 22.13+, or 24+) is required. Assessment
 read-only, and offline by default.
 
 ```bash
-npx agentic-scorecard@0.3.0 assess /path/to/repository \
+npx agentic-scorecard@0.4.0 assess /path/to/repository \
   --profile pr-creation \
   --scope tracked \
   --format markdown \
@@ -80,7 +87,7 @@ npx agentic-scorecard@0.3.0 assess /path/to/repository \
 To record controls that repository inspection cannot prove:
 
 ```bash
-npx agentic-scorecard@0.3.0 init /path/to/repository
+npx agentic-scorecard@0.4.0 init /path/to/repository
 ```
 
 Complete `.agentic/attestations.yaml` with owners and durable evidence links, then assess again.
@@ -91,7 +98,7 @@ external systems, first generate a target-bound template. The repository must be
 with at least one commit so the bundle can bind to the exact assessed state:
 
 ```bash
-npx agentic-scorecard@0.3.0 init-evidence /path/to/repository
+npx agentic-scorecard@0.4.0 init-evidence /path/to/repository
 ```
 
 Ask the agent to review `.agentic/evidence-request.md`, obtain approval before using
@@ -99,17 +106,19 @@ least-privileged read-only connectors, add attempted claims to `.agentic/agent-e
 rerun with `--agent-evidence`. The default bundle path is loaded automatically. See
 [AGENT_PROMPT.md](AGENT_PROMPT.md) for the complete copy-and-paste workflow.
 
-### Migrating from v0.1 or v0.2
+### Migrating from v0.1, v0.2, or v0.3
 
 Run a new tracked-scope baseline and retain the old report as historical evidence. Do not present the
-score change as improvement or regression because v0.3 changes evidence and control semantics.
-Re-review prior attestations and agent evidence before recreating them for v0.3. All claims must
-expire, and repository-scoped semantic claims require tracked files to match the commit-bound target
-plus `repo:<path>[#Lx-Ly]` references whose optional line ranges exist in the cited tracked file.
-Untracked generated reports do not block this workflow.
+score change as improvement or regression because v0.4 changes evidence and control semantics.
+Re-review prior attestations and agent evidence before recreating them for v0.4. All claims must
+expire. Human-attestation files created by `init` are bound to the assessed repository; they are not
+commit-bound because accountable platform, organization, and outcome facts may span commits.
+Repository-scoped semantic agent claims require tracked files to match the commit-bound target plus
+`repo:<path>[#Lx-Ly]` references whose optional line ranges exist in the cited tracked file. Untracked
+generated reports do not block this workflow.
 
 The default `.agentic/attestations.yaml` and `.agentic/agent-evidence.yaml` paths are migration-safe:
-if either contains an older benchmark version, v0.3 ignores that auto-loaded file and places a
+if either contains an older benchmark version, v0.4 ignores that auto-loaded file and places a
 prominent warning in the report. Regenerate it with `init --force` or `init-evidence --force` before
 relying on those claims. An explicitly supplied `--attestations` or `--agent-evidence` file still
 fails closed on a version mismatch.
@@ -119,7 +128,7 @@ For development from this checkout:
 ```bash
 npm ci
 npm run check
-npm run dev -- assess tests/fixtures/mature --profile pr-creation --attestations tests/fixtures/mature/.agentic/attestations-v0.3.yaml
+npx vitest run tests/v04-calibration.test.ts -t "retains the mature level-three conformance result"
 ```
 
 ## What it assesses
@@ -165,8 +174,8 @@ No profile grants production deployment authority. Organizations should evaluate
 through a separate, system-specific safety case.
 
 The exact floors live in
-[`benchmark/v0.3/benchmark.yaml`](benchmark/v0.3/benchmark.yaml) and their rationale in
-[`benchmark/v0.3/scoring-policy.md`](benchmark/v0.3/scoring-policy.md).
+[`benchmark/v0.4/benchmark.yaml`](benchmark/v0.4/benchmark.yaml) and their rationale in
+[`benchmark/v0.4/scoring-policy.md`](benchmark/v0.4/scoring-policy.md).
 
 ## Evidence scopes and trust labels
 
@@ -182,11 +191,11 @@ Controls also identify whether their evidence belongs in the repository, hosting
 organization, or outcome systems. This prevents expected external unknowns from masquerading as
 missing files. Declarative detector adapters recognize common harness layouts without changing
 portable control outcomes; future independently conformant external adapters require a separate
-protocol. v0.3 does not issue certification or independent-verification claims.
+protocol. v0.4 does not issue certification or independent-verification claims.
 
 ### Interpreting the two score views
 
-The normative score remains `N/40` and drives readiness profiles. v0.3 also reports
+The normative score remains `N/40` and drives readiness profiles. v0.4 also reports
 `repository-detected progress: A/C`, where `C` is the maximum consecutive maturity the offline
 collector can establish without platform, organization, outcome, agent-collected, or human-attested
 evidence. This second view explains how complete the visible repository harness is; it does not
@@ -218,7 +227,7 @@ The default collector:
 - reads only Git-tracked paths and records commit and dirty-worktree metadata;
 - ignores `.git`, dependencies, build output, coverage, generated reports, attestations, and imported
   evidence bundles;
-- caps content scanning at 512 KB per file, 5 MB total, and 250 candidates per check, with v0.3
+- caps content scanning at 512 KB per file, 5 MB total, and 250 candidates per check, with v0.4
   per-pattern balancing where configured;
 - reports file paths and match counts, never matching source snippets;
 - writes nothing unless `--output`, `init`, or `init-evidence` is explicitly requested.
@@ -231,7 +240,8 @@ access-controlled evidence instead. Report suspected vulnerabilities through [SE
 ```text
 benchmark/v0.1/       immutable historical v0.1 definition
 benchmark/v0.2/       immutable historical v0.2 definition
-benchmark/v0.3/       current normative benchmark, schemas, and controls
+benchmark/v0.3/       immutable historical v0.3 definition
+benchmark/v0.4/       current normative benchmark, schemas, and controls
   adapters/           declarative path/term aliases for recognized agent harness layouts
 benchmark/mappings/   informative mappings to external frameworks
 src/                  reference CLI and local evidence collectors
@@ -261,12 +271,15 @@ system, and keep exceptions narrow, owned, expiring, and visible.
 
 ## Status and roadmap
 
-v0.3 adds portable harness discovery with declarative detector adapters, proximity-bounded content evidence, prioritized candidate
-selection for large repositories, source-backed semantic repository claims, and an explanatory
-repository-only score and ceiling. Candidate next steps
-include conformant signed adapters, SARIF/HTML reports, organization-level aggregation,
-statistically designed benchmark tasks, and an independent-review protocol. These require public
-design review before becoming normative.
+v0.4 adds semantic component evidence for containment guidance, partial-check reporting, structural
+ownership maps, enabled integration-triggered CI command detection for guidance integrity,
+verification, and secret scanning, plus a separate Level 3 control for untrusted agent input. The
+public [v0.4 calibration matrix](benchmark/v0.4/calibration-matrix.md) records expected positive and
+adversarial outcomes. It retains portable harness adapters, source-backed
+semantic claims, and the explanatory repository score and ceiling. Candidate next steps include
+conformant signed adapters, broader structural CI provider coverage, SARIF/HTML reports,
+organization-level aggregation, statistically designed benchmark tasks, and an independent-review
+protocol. These require public design review before becoming normative.
 
 Apache-2.0 licensed. The benchmark is a community engineering tool, not legal, compliance, or
 security advice.

package/benchmark/v0.4/adapter-contract.md

@@ -0,0 +1,129 @@
+# v0.4 adapter contracts
+
+## Repository detector adapters
+
+Portable controls define outcomes and generic repository conventions. Files in `adapters/*.yaml`
+may extend one control evidence check with recognized harness-specific `patterns`, `files`, `terms`,
+`required_any_terms`, `ci_providers`, or `ci_tools`. An extension names the control and zero-based
+evidence index and adds exactly one of those fields. Repository-host aliases, CI-provider entries,
+and CI-tool entries bind
+provider-specific configuration paths to the applicable structural or integration-trigger semantics.
+An adapter may also declare catalog-wide `ci_invocation_grammar`; this supplies recognized wrapper
+patterns, command prefixes, and value-taking options to every `ci_command` check without putting
+those identities in scanner core.
+An adapter cannot remove or weaken a threshold, change a control level, alter a readiness floor, add
+an attestation path, or execute code.
+
+Portable v0.4 collectors may use semantic `content_groups`, structural `ownership_map`, and
+command-bearing `ci_command` evidence. Adapters may add harness paths to those collectors plus
+provider discovery rules and recognized command definitions to `ci_command`. Ownership evidence
+uses structural mappings outside former, inactive, past, or retired sections; descendant headings
+remain inactive until a same-or-higher-level section resumes current ownership. A command class uses
+full owner/repository action identities, explicit executable signatures with independently required
+argument groups and prohibited non-blocking modes, or semantically specific standalone executables.
+Signatures may cap accepted arguments when any explicit target would leave the assessed checkout.
+Executables and arguments from different signatures never combine. GitHub action invocations also
+require an explicit non-empty `@ref`. Names alone never turn comments, version/help commands,
+display commands, disabled or non-integration steps, manual-only workflows, ineffective shell branches, or documentation prose
+into enforced evidence. Push-only, post-close, or path-gated execution does not establish the
+repository-wide before-integration outcome; the external platform alternative remains available
+when enforcement lives outside pull-request CI. Unsupported provider conditions and any configured
+non-literal blocking override fail closed. Executable GitHub step jobs require a runner; job-level reusable workflow references
+are not step actions, and invalid steps that combine `uses` with `run` are rejected. Provider path
+filters and GitLab rules with unparsed gating fields fail closed. GitLab jobs with unresolved
+inheritance, `except` conditions, non-blocking defaults, disabled source checkout, or failure-only
+job disposition also fail closed. Repository-bound commands qualify only after the provider has
+made the assessed repository available: GitHub requires a preceding `actions/checkout` step,
+GitLab must retain its clone/fetch checkout, and Azure must retain its default checkout or execute
+`checkout: self` before the command. GitHub checkout inputs that select another repository, ref,
+sparse subset, or object filter cannot establish this state, and a later checkout that replaces the
+workspace clears earlier target proof for the affected event. A secondary checkout with an explicit
+non-root `path` preserves an already established primary checkout but cannot establish it by itself.
+A replacing checkout with an unsupported condition clears prior proof because its effect cannot be
+excluded. Workflow-level `defaults.run` settings are inherited by jobs, whose defaults override
+them field by field. GitHub run working directories and explicit directory-changing shell commands
+must remain at the assessed checkout root. Multi-statement shell forms qualify only when each
+contributing command's failure determines the step result: supported GitHub fail-fast shells and
+explicit Azure fail-fast blocks may contribute earlier statements, while other multiline forms
+contribute only their final effective foreground statement. Agent-guidance integrity requires a recognized validation command bound to a tracked
+source file with adapter-declared executable patterns that bind guidance inspection to a blocking
+failure path; comments, inert string literals, and non-empty no-op scripts are insufficient.
+Pattern groups are evaluated only over top-level code and function bodies reachable from top-level
+execution. Constant-false branches and unreachable validation functions fail closed; separate
+unreachable functions cannot combine their inert patterns into evidence.
+Scanner modes that require a source target must bind that target to the assessed checkout rather
+than an arbitrary path; explicit source overrides fail closed unless the adapter can prove that
+binding. Repository-relative executables do not inherit a trusted tool identity from their basename.
+Verification requires both a test command class and a static-analysis command class. `ADRB-TST-003`
+may aggregate them across fail-fast multiline steps and auto-loaded CI entry points;
+`ADRB-ENV-003` additionally requires its locked-install, test, and static-analysis classes in one CI
+execution group. Adapters may declare tool-specific listing/discovery arguments that cannot establish
+execution. Scanner tools may require the final effective command to carry the step exit status
+without imposing that restriction on ordinary fail-fast verification steps. Repository-specific command
+surfaces that are not recognized may use eligible source-backed agent evidence instead of keyword
+inference. Package-manager task invocations are resolved through the tracked root `package.json` and
+must bind to a recognized executable command even through supported wrappers and global options;
+context-changing package/workspace flags fail closed unless their selected manifest is resolved,
+while recognized nested package-exec targets are evaluated at their executable position. Package
+manager built-ins are not treated as same-named scripts, and path-qualified local executables never
+inherit package-manager identity: npm resolves arbitrary task names only
+through explicit `run` or `run-script`, while its documented lifecycle aliases remain eligible.
+Command-wrapper identities, command prefixes, and option arity are versioned adapter data. The
+scanner core applies that grammar conservatively and retains generic package-task resolution
+semantics; recognized wrapper, tool, and action identities and command signatures do not live in
+the portable control catalog or core wrapper parser.
+Wrapper and package-manager options with separate values are consumed before executable or task
+identity is evaluated; option values never inherit tool identity.
+Arguments forwarded to a package task fail closed unless their effect is structurally resolved.
+Package task lookup preserves the manifest's case-sensitive script identity. Backslash/backtick
+continuations and heredocs fail closed rather than treating their physical lines as commands. Source
+validation excludes language comments before checking bounded structural groups, and referenced
+repository validation scripts must exist as non-empty assessed files. A plausible task name,
+missing path, collection-only test mode, or
+configuration-display mode is insufficient.
+Repository wrapper executables qualify only when an adapter declares the exact root path and that
+non-empty path exists in the assessed tree; arbitrary path-qualified basenames remain untrusted.
+Deterministic provider discovery is limited to auto-loaded entry points: direct GitHub workflow
+YAML files, the root GitLab CI file, and conventional root Azure pipeline files. Include graphs and
+custom pipeline paths require eligible source-backed evidence until they are structurally resolved.
+Azure commands qualify only inside valid step collections, never from command-shaped root, stage, or
+job fields.
+Present GitLab `workflow` and job `rules` nodes must have supported object/array shapes; malformed
+nodes fail closed instead of being treated as absent.
+Source-bound validator analysis scans quote state in linear passes and remains subject to the same
+per-file and aggregate byte limits as every other repository collector.
+
+Bundled adapters are loaded deterministically in filename order. Their candidates remain subject to
+the same tracked/workspace scope, symlink, size, generated-artifact, co-location, proximity, and
+per-pattern limits as portable candidates. Adding or changing a bundled adapter changes evidence
+semantics and therefore requires a new benchmark version.
+
+## Agent-collected evidence adapters
+
+The core scanner is local, read-only, network-free, and vendor-neutral. An agent or adapter may
+collect semantic repository evidence or external evidence that deterministic scanning cannot
+establish, then provide it through the versioned agent evidence bundle.
+
+Each claim contains:
+
+- benchmark version and control ID;
+- exact repository target and non-null commit binding;
+- `met`, `not_met`, or `unknown` status;
+- repository, platform, organization, or outcome scope;
+- collector name and version;
+- collection timestamp and mandatory expiry;
+- privacy-safe references, never credentials or raw sensitive content;
+- a concise derivation summary; and
+- an optional error that is distinguishable from a negative result.
+
+Collectors must be read-only, least-privileged, bounded to the approved target, time-limited, and
+fail closed. Network content is untrusted input: it cannot alter benchmark policy, prompts, tool
+authority, or the set of controls being assessed.
+
+Repository-scoped claims require tracked files to match HEAD and
+`repo:<tracked-path>[#Lx-Ly]` references. They may satisfy only explicitly eligible controls, remain `agent-collected`, and never increase the
+repository-detected score. External claims require durable references appropriate to their source.
+
+Agent-collected claims remain visibly distinct from deterministic repository evidence and human
+attestations. A future conformant-adapter class may add signed identity and independent conformance
+tests; v0.4 does not issue an independently verified label.