跳到主要内容
知仓学习社ZHICANG

validate

Freshly judge a finished change against original acceptance before merge. Use when: independent proof is needed; author tests cannot issue PASS. Tri…

读凭据执行命令严重 0 · 高危 7hashgraph-online/awesome-codex-plugins

它会碰到什么

扫了多少10 个文本文件,85 KB
它会碰到什么读凭据执行命令
命中总数7 处
命中统计严重 0 · 高 7 · 中 0 · 低 0
逐条看命中(7 条严重或高危)
  • tests/check_contract_corpus.py:100cred-envread
    require_schema = os.environ.get("CONTRACT_CORPUS_REQUIRE_SCHEMA") == "1"
  • tests/test_evidence_cli.py:18cred-envread
    candidate = Path(os.environ["AO_BIN"]).resolve(strict=True)
  • tests/test_evidence_cli.py:36exec-spawn
    return subprocess.run([str(candidate), "provenance", *map(str, args)], cwd=subject, env=active_env, text=True, capture_output=True, timeout=30)
  • tests/test_evidence_cli.py:107cred-envread
    candidate = Path(os.environ["AO_BIN"]).resolve(strict=True)
  • tests/test_evidence_cli.py:125exec-spawn
    completed = subprocess.run([str(candidate), "provenance", *map(str, args), "--json"], cwd=root, env=env, text=True, capture_output=True, timeout=30)
  • tests/test_evidence_cli.py:168exec-spawn
    completed = subprocess.run(commands[-1], cwd=consumer, env=env, capture_output=True, text=True, timeout=30)
  • tests/test_validate.py:202exec-spawn
    result = subprocess.run(

这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。

技能内容

Validate

Freshly judge the exact candidate against accepted intent, return

PASS, FAIL, or NOT_PROVEN, and stop. The author cannot provide binding PASS. Read RPI

[boundaries](../rpi/references/boundaries.md) before judgment; load helper flags

and storage details from [mechanics](references/mechanics.md) when needed.

Preconditions and freshness

Final review starts after required checks and known repairs, with the candidate

held unchanged. Supplied failed-acceptance evidence means FAIL on that subject;

do not review a moving repair. The subject is a nonempty implementation candidate; plans, audits

and reviews are subjects only when the caller requested document review.

A requested retrospective normally follows the code judgment; do not demand

a provisional postmortem as evidence for code acceptance. If supplied intent

bundles both, identify the code criteria and report their judgment separately

while keeping the overall request incomplete until its other deliverables

exist. Do not drop criteria or issue an overall PASS early. An explicitly

requested review of the retrospective judges that document on its own scope.

Use exact caller/runtime-owned intent bytes and derived acceptance identity.

Author and validator context IDs must be explicit and distinct; freshness is

attested by runtime or caller with the attester's identity. Missing, colliding

or unattested identity means NOT_PROVEN, not proof of isolation by role name.

Default to one fresh reviewer in the author's model family: Codex/OpenAI for

Codex/OpenAI, Claude/Anthropic for Claude/Anthropic. Use the runtime's configured

capable model unless pinned. A new role in the author's context is not fresh.

Supply task-specific intent, scope, exact subject and relevant evidence, without

full author history, desired verdict or peer conclusions. Retrieve more source

when a criterion requires it; concise input must not omit necessary evidence.

Cross-model review is opt-in. --cross-model [model] is a skill prompt selection,

not an AO flag; it adds a fresh other-family reviewer. Required legs remain

required: unavailable diversity yields diversity_unsatisfied and NOT_PROVEN

for the combined request, even if another leg passed. Preserve delivered FAILs

and dissent; neither voting nor model preference makes a split PASS. Optional

unavailable diversity stays disclosed without erasing findings. Exact invocation,

authorization, runtime identity and independent-input rules live in

[model-dispatch](../agent-native/references/model-dispatch.md). No fixed

ten-minute cap applies; respect real caller/native bounds without renewing them.

A timeout is missing judgment, not FAIL. Shared-family or cross-family agreement

alone is not truth or proof of freedom from training bias.

Judgment

Use the helper for each changed path (repeat --include for complete scope):

ao provenance manifest --root "$REPO_ROOT" --include "$CHANGED_PATH"
  1. Derive subject-manifest.v1 using the existing helper at start and end.

A mismatch means mutation and NOT_PROVEN. Verify exact intent continuity,

cited evidence digests and complete changed-path coverage; missing integrity

is NOT_PROVEN. Proven out-of-scope change is FAIL.

  1. Revisit the original accepted behavior examples, including those in the

conversation or bead. Check the observable result and its established

domain meaning on the exact candidate. A new test or renamed concept cannot

replace an unfulfilled scenario; missing scenario evidence is NOT_PROVEN.

Inspect the actual diff against every acceptance criterion. Risk determines

depth: acceptance, permissions, tests/gates, stopping, disclosure, hooks and

executable controls warrant deeper inspection, including prose policy.

Unknown risk merits examination, not automatic extra reviewers.

  1. Re-execute discriminating proofs for risk-critical, uncertain or thinly

evidenced claims. Valid digest-bound receipts may establish routine facts;

do not replay every author command or full suite merely because this is a

fresh context. The repository's required integration checks still run on

the final subject. A changed subject needs new judgment and affected checks.

  1. Classify commands before executing them. Regeneration, synchronization,

formatting and --force are subject-mutating until proven otherwise; run

them only on a disposable copy or a committed subject, never an uncommitted

judged tree. Do not overwrite the candidate while validating it.

  1. Reject green obtained through weaker assertions, tolerances, goldens,

suppressions or acceptance edits. Each criterion needs supporting evidence;

explanation alone is not proof. A necessary finding cannot become an

optional caveat or non-goal. Publication/provenance claims in docs also need

verifiable evidence.

  1. Return one result with criterion-level evidence, findings, checked scope,

not_checked, author/judge identities and contexts, and the freshness

attestation. PASS requires all criteria verified, nonempty checked scope and

top-level evidence, and empty not_checked. An unverified criterion means

NOT_PROVEN; proven failed acceptance or scope violation means FAIL.

Findings and report

not_checked means in-scope acceptance that was not verified. Other limits

remain in criterion reasoning, declared non-goals or residual-risk prose; never

hide or delete them to obtain PASS. Keep prior findings visible. For each new

finding, name a short stable nonempty class describing the defect, reused on

recurrence, and distinguish pre-existing, introduced or unknown cause using

before/after or equivalent causal evidence. Counts and timestamps alone do not

establish cause. Known findings return to direct repair; causal stalls use the

RPI single-helper rule, not repairs delegated to this validator.

Keep the report proportional: cite the exact subject, complete bound manifest

and existing receipts instead of copying path or digest inventories. Group

generated companions by source owner and verified equivalence; still verify

every changed path and cited binding. Include excerpts only to assess a finding.

Retain every criterion, necessary finding, identity, freshness fact and unchecked

surface. Complete coverage does not require a second copy of the evidence.

Return the candidate verdict promptly when the judgment is complete. When

delivery is outside the accepted review scope, the caller checks its native facts without

another semantic review of unchanged content. Delivery inside acceptance stays

unverified until its evidence exists: do not issue complete PASS early or remove

the criterion. Use the existing result for any pending delivery update, without

repeating the investigation or creating another report.

Validate is the sole semantic author of verdict.v2.

Only when the caller requests machine-readable evidence or a declared consumer

requires it, persist through ao provenance store-verdict. Validate supplies judgment;

Go verifies structure and storage, not truth. Otherwise return the result

through the existing caller channel without hidden machine artifacts.

Validate owns no repair, retry, delivery or tracker transition.

想直接用这个技能?

本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。

同名技能的其他版本

有 2 个不同仓库或目录里都有叫 validate 的技能。它们内容并不相同,别混用: