From baa7c58a36df1b83f3d3302b7ccbe40df4e1d60c Mon Sep 17 00:00:00 2001 From: Hiroshi Shinaoka Date: Sun, 6 Sep 2026 03:18:55 +0900 Subject: [PATCH] docs: make agent reviews optional and audits bounded --- rules/common/repository.md | 130 ++++------ skills/tensor4all-rules-audit/SKILL.md | 238 ++++-------------- .../references/audit-prompts.md | 123 ++------- 3 files changed, 106 insertions(+), 385 deletions(-) diff --git a/rules/common/repository.md b/rules/common/repository.md index 6f61eac..80d48fe 100644 --- a/rules/common/repository.md +++ b/rules/common/repository.md @@ -10,6 +10,24 @@ - Repository-local rules override shared rules when they are more specific. Shared rules should capture durable cross-project policy. +## Proportionate Workflow + +- Work directly by default. Subagents, panels, and independent AI reviews are + optional and require an explicit user request; using different model families + is not a mandatory gate. +- Read the applicable rules once and revisit affected sections when scope changes. + Do not repeatedly load unchanged policy files before every small edit. +- Routine fixes need a focused test and a self-review of the coherent final diff, + not a separate design approval. Record a short design for changes to public + contracts, architecture, or safety-critical boundaries. +- A correction within the agreed design does not restart design approval or a + full review. Recheck the affected behavior; reopen decisions only when their + scope or semantics change. +- If work stalls, reassess the approach and report blockers rather than adding + more infrastructure or repeating unsuccessful delegation/review cycles. +- These workflow defaults do not waive required CI, human approvals, numerical + correctness, memory safety, or data preservation. + ## Public Surface - Keep public APIs deliberate and small. Do not expose implementation details @@ -98,9 +116,9 @@ to every repository that publishes: - Audit tooling and audit prompts, human or AI, must not flag a site governed by an `// INVARIANT:` marker as a violation. They must instead check whether the stated invariant still holds and report only when it does not. -- Rejecting an audit finding as a false positive is complete only when the - marker (or a source-contract test) has landed at the site, per the - false-positive ledger rule in Work Logs And Design Records. +- Reject unsupported findings with source evidence. Add a marker or test only + when the invariant needs clarification or regression protection; an incorrect + review report alone does not require a code change. ## API Evolution @@ -140,93 +158,37 @@ to every repository that publishes: ## Work Logs And Design Records -- Nontrivial refactors, cleanup streams, AI-assisted implementation, and PRs - that make explicit design tradeoffs must leave a curated work log under - `docs/worklogs/`. The work log should record the session summary, code and - documents read, reference implementations considered, decisions made, - alternatives rejected or deferred, verification performed, and remaining - risks. -- Work logs are not raw transcripts and are not implementation plans. They are - reviewer-facing decision records for the completed work. Keep them concise - enough to review, but specific enough that a later reviewer can understand - why an abstraction, split, macro, descriptor, public API choice, or deferral - was selected. -- PR bodies for work that requires a work log must link the relevant - `docs/worklogs/` file. Reviewers should read linked work logs before - challenging scope, abstraction choices, or design intent. +- Use a concise work log for multi-phase work or non-obvious design tradeoffs. + A small fix can record its rationale and checks in the PR body; AI assistance + alone does not require another document. +- Record decisions, verification and unresolved risks once. Link that record + instead of duplicating it across a design, work log, issue and PR. +- Work logs are curated decision records, not transcripts or per-edit approval + ledgers. Read a linked record when reviewing the design choices it explains. - When a PR establishes or changes durable design intent, update the appropriate document under `docs/design/` in the same PR. Use work logs for session-level rationale and design docs for decisions future implementation and review should continue to follow. -- When a bug report or audit finding is a false positive because of an - intentional invariant, record the evidence in the issue or PR ledger and add - a nearby `// INVARIANT:` source comment (see Invariant Markers above), - rustdoc note, or source-contract test when that invariant is not obvious - from the code. Do not just skip the - finding; leave enough context that later humans and AI agents do not - rediscover the same non-bug as suspicious. +- Explain a rejected finding briefly with source evidence. Add a nearby comment + or regression test when an actual non-obvious invariant warrants it; do not + modify correct code merely to close an inaccurate review report. - Before adding a new audit or repository rule, inventory nearby existing rules and merge, tighten, or relocate overlapping guidance when possible. Prefer one sharper general rule over many narrow bullets that future agents must reconcile. -## Final Cross-Phase Multi-Agent Audit - -Human/process protocol. This section is intentionally not routed to the -diff-scoped review bot. - -Repository-scale, multi-phase implementation programs require one final audit -after every phase and its task-local reviews are complete, but before the -umbrella issue or implementation branch is declared ready for integration. - -- Audit one exact candidate commit. Every report must name that commit, and an - auditor must not audit a lane whose implementation or task-local review it - performed. The lanes may run in batches when agent concurrency is limited. -- Assign a distinct independent auditor to each required lane: - 1. **Specification and architecture:** accepted issues, phase acceptance - criteria, semantic parity, lowering, and migration compatibility. - 2. **Safety and resource lifecycle:** aliasing, unsafe boundaries, - lifetimes, locks, buffers, caches, and cleanup on success, error, - cancellation, and unwind. - 3. **Performance and parallelism:** current-main baseline, fast paths, - allocations and request/container overhead, worker ownership, - thread-count and placement control, and backend synchronization. - 4. **Public API and documentation:** facade boundaries, typed errors, - feature combinations, runnable examples, and source/checker consistency. - 5. **Backend and hardware lanes** relevant to the repository: CPU - placement and resource arbitration, GPU/multi-device context ownership, - and cross-device failure handling when such backends exist. -- After all lane reports, a separate integration auditor must check - cross-phase invariants, duplicated or contradictory findings, and the - closure evidence. -- Each lane report must record the candidate commit; relevant feature, - toolchain, and hardware configuration; inspected files, public contracts, - and issue acceptance criteria; fresh commands and complete result - classifications; findings classified as `Critical`, `Important`, or - `Minor`; and explicit limitations or skipped hardware paths. Performance - results must be classified as `PASS`, `FAIL`, or `INCONCLUSIVE`. Do not infer - a pass from an implementer's earlier run. Source scanners and mutation tests - support, but do not replace, call-path review and runtime tests. -- Each lane applies the repository's applicable rule sections (public boundary - audits, unsafe boundary, materialization/copies, performance-gated - experiment protocol, cache ownership, documentation policy, work logs) to - its scope instead of restating their checklists. -- Environment-limited CPU, GPU, or multi-device paths must retain reproducible - diagnostics and an identified verification owner. -- This gate supplements rather than replaces task-local TDD, specification - review, code-quality review, CI, and required performance gates. -- The final audit passes only when every `Critical` and `Important` finding is - fixed and independently re-reviewed; every `Minor` finding is fixed or has a - written rationale and accepted tracking issue; every required performance - gate is `PASS`; and the integration auditor reports no unresolved - cross-phase contradiction. `INCONCLUSIVE` blocks promotion until a valid - rerun or explicit accepted scope decision is recorded. -- The final worklog must link every lane report, the integration report, the - exact candidate commit, and the final verification commands. -- Auditing is read-only: audit agents must not modify the candidate while - reviewing it. A finding fix creates a new exact candidate revision. Before - the audit can pass, every lane report must be refreshed to name and validate - that final revision: each auditor reviews the intervening diff, every - affected lane reruns its relevant evidence, and an unaffected lane may carry - earlier runtime evidence forward only with a recorded diff-impact rationale. - The separate integration auditor runs last against the same final revision. +## Final Integration Review + +For multi-phase work, the main agent checks the integrated result against the +agreed requirements before declaring completion. Identify the candidate state, +relevant tests, unresolved findings and unavailable hardware. Check affected +architecture, lifecycle, numerical, performance and documentation boundaries; +do not create a fixed set of reviewer roles or duplicate task-level evidence. + +A multi-agent or cross-model audit is optional, only when explicitly requested. +Human approval and required CI remain separate requirements. Correctness defects +and required measurements without valid evidence still block completion. + +After a correction, review the relevant delta and rerun affected checks. Unaffected +evidence need not be regenerated solely because the commit changed. Record why +it still applies; do not restart every review lane for a small fix. diff --git a/skills/tensor4all-rules-audit/SKILL.md b/skills/tensor4all-rules-audit/SKILL.md index cf2e5c4..8d8522f 100644 --- a/skills/tensor4all-rules-audit/SKILL.md +++ b/skills/tensor4all-rules-audit/SKILL.md @@ -1,201 +1,55 @@ --- name: tensor4all-rules-audit -description: Use when auditing tensor4all-rs against REPOSITORY_RULES.md, AGENTS.md, README.md, public API docs, GitHub issue context, or repository-wide source risks with lightweight subagents, a single aggregated GitHub issue or issue body, and a standalone remediation PR. +description: Audit a tensor4all repository's applicable rules and source for concrete problems, duplication and excessive process, returning a bounded evidence-based report. --- # Tensor4all Rules Audit -## Overview - -Audit tensor4all-rs by using lightweight subagents as broad source scanners, while the main agent owns rule interpretation, evidence checks, severity, deduplication, iteration, final issue aggregation, and PR-ready remediation context. - -## Core Rules - -- Read `README.md`, `REPOSITORY_RULES.md`, and applicable `AGENTS.md` before dispatching. -- Generate/read API docs first when public surface matters: `cargo run -p api-dump --release -- . -o docs/api`, then inspect `docs/api/*.md` before source. -- Use mini subagents for coverage and candidate discovery only. They report possible issues; they do not decide final severity or create issues. -- Keep the main agent on coordination. Do not broadly read source files in the main context; read only the minimal cited lines needed to verify a candidate or prepare a tightly scoped recheck. -- The main agent must verify every accepted finding directly in source/API docs before treating it as real. -- Analyze subagent reports for meta-problems: ambiguous rules, false-positive-prone rule wording, missing design docs, design/doc inconsistency, and repeated documentation drift patterns. -- Do not pass an old full issue body to subagents. Maintain and pass only short summaries of accepted findings, rejected/false-positive candidates, and related GitHub issues. -- Preserve paths, APIs, and evidence in summaries exactly. Do not rewrite them from memory or replace placeholder/example paths with guessed real paths. -- Before dispatching or rechecking, gather a concise summary of relevant GitHub issues so subagents can avoid rediscovering already tracked work. -- Resolve and record the audited repository commit before dispatching. Default to `origin/main` after fetching it. -- Verify before dispatching that the audited commit exists on GitHub and that commit-pinned permalinks resolve. Do not audit a local-only or unpushed commit. -- If the requested or current audit target is not exactly `origin/main`, stop and ask the user to confirm the non-default target. Include the target ref/hash and current `origin/main` hash in the question. -- Use commit-pinned GitHub permalinks for source, docs, and API-doc line references in issues and PRs. Link to `/blob//...#L` or `#L-L`, never to moving branch names such as `main` or `origin/main`. -- Aggregate accepted findings into one issue body and one remediation PR. Do not finish with only an issue when accepted actionable findings exist. -- Create a GitHub issue before the PR when accepted findings exist, unless the user explicitly asks for a local issue body only. -- Open one remediation PR at the end after implementing a coherent fix set and running the repository-required verification that is feasible for the session. -- If the audit scope is too broad for one PR, fix the highest-severity coherent slice in the PR and leave clearly identified deferred findings in the aggregate issue and PR body. -- The PR body must be standalone. A reviewer should understand what changed, why it is correct, and what remains by reading the PR alone, without opening the issue. +Audit directly in the main agent. Subagents and cross-model reviews are optional +and require an explicit user request; they are not prerequisites for an audit. +An audit request does not by itself authorize implementation, issues or PRs. ## Workflow -1. Scope the audit. - - Run `git fetch origin`, resolve `origin/main`, and choose the audit target. Use `origin/main` unless the user explicitly requested another ref or confirms a non-`origin/main` checkout. - - Verify the chosen commit exists on GitHub, for example with `gh api repos/tensor4all/tenferro-rs/commits/` or an equivalent GitHub commit lookup. - - If the commit lookup fails, do not dispatch subagents. Ask the user whether to push that commit, switch to `origin/main`, or provide another GitHub-visible ref. - - Enumerate code with `rg --files`, including `crates/`, `docs/tutorial-code/`, `python/`, `scripts/`, examples, tests, and C API code when present. - - Record the audited commit hash and GitHub permalink base. Reuse that exact commit in every final issue/PR link. - - Summarize relevant GitHub issues with issue number, title, state, affected area, and one-line status. Prefer recent open issues plus search results for the audit scope. - - Split work by crate, language binding, or rule area so each mini subagent has a bounded file list. - -2. Dispatch initial mini subagents. - - Use `gpt-5.4-mini` when the user asks for GPT5.x mini unless a newer mini model is explicitly available and requested. - - Give each subagent exact files or directories, relevant rule excerpts, and the prompt pattern in `references/audit-prompts.md`. - - Include concise summaries of related GitHub issues, already accepted findings, and rejected false positives. Use empty summaries for the first pass if none exist yet. - - Require `possible_issue` output with `file:line`, violated rule, short evidence, impact, confidence, and a related search. Forbid final severity labels; subagents may suggest likely tests or fix sketches but do not decide user-impact severity. - -3. Main-agent triage. - - Merge candidates by root cause, not by file count. - - Verify evidence locally with minimal reads: cited lines first, then at most the nearest enclosing function or doc block if needed. - - Convert verified file/line references into commit-pinned GitHub permalinks before adding them to accepted findings, rejected summaries, issue bodies, or PR bodies. - - If evidence is insufficient, send a targeted recheck instead of exploring broadly in the main context. - - Also classify report patterns that point to rule/design defects rather than code defects. Examples: many subagents interpreting a rule differently, repeated "docs missing examples" reports that indicate unrealistic doc coverage policy, or implementation behavior not covered by `docs/design/`. - - Reject vague, ungrounded, stale, or purely stylistic candidates. - - Record rejected candidates in the false-positive summary with the original claim, cited path, rejection reason, and what evidence would make it worth revisiting. - - For every accepted finding, capture enough PR context to make the future PR standalone: current code snippet or precise behavior, proposed update sketch, expected changed files, and validation plan. - - Classify both evidence level and user-impact severity. Do not collapse repository-rule priority into bug severity. - - Evidence levels: - - Confirmed: runnable reproducer, failing test, direct public API path, measured performance cliff, or source proof of a panic/data-loss path with no plausible guard. - - Source-risk: precise source evidence shows a plausible bug or rule violation, but user-visible failure still needs a reproducer, test, measurement, or broader context. - - Policy/doc gap: documentation, coverage, oracle, checklist, or tooling drift without evidence that current runtime behavior is wrong. - - User-impact severity: - - Critical: confirmed data corruption, unsound memory behavior, severe security issue, or wrong result across normal valid public inputs. - - High: confirmed public wrong behavior, panic on valid public input, C API error loss that hides failures, silent invariant loss, or measured/unbounded dense materialization on a realistic public path. - - Medium: real repository-rule violation or plausible source-risk with broad maintenance/regression risk, but no confirmed severe user-visible failure yet. - - Low: narrow edge-case validation ordering, diagnostics quality, local docs drift, incomplete examples/tooling scope, or low-impact coverage gaps. - - Never assign High solely because a repository rule is violated. Escalate rule-compliance findings to High only when the evidence also proves a confirmed High user-impact path. - -4. Iterate until confirmed severe findings stop. - - If any Confirmed Critical/High finding is accepted, update the known-issues summary and dispatch targeted mini subagents to scan related files, sibling APIs, tests, docs, and analogous patterns. - - Pass only the short accepted-finding, false-positive, and related-issue summaries, not the full issue draft or issue bodies. - - Repeat triage and targeted scans until a full or targeted pass produces no new accepted Confirmed Critical/High findings. - - For Medium source-risks, run targeted rechecks when they could plausibly become Confirmed High; otherwise keep them as remediation backlog items. - - Do not stop merely because subagents reported nothing; the main agent must confirm coverage and that each accepted confirmed severe root cause had a related-pattern scan. - -5. Aggregate one issue. - - Keep one issue body with a concise summary, accepted findings, evidence, impact, and suggested next checks or fix sketches. - - Include a separate "Rules/Design Gaps Detected During Audit" section when the subagent reports expose ambiguity or missing design guidance. - - Include Medium/Low findings only when they are real and useful; separate them from blocking Critical/High issues. - - If no accepted findings remain, report that no issue is needed unless the user wants an audit record. - -6. Implement and open one PR. - - Choose a coherent remediation slice from the accepted findings. Prefer Critical/High findings with shared files, APIs, tests, or root cause. - - Follow the repository-local remediation or bug-fix workflow before editing. For tenferro-rs, review `ai/contribution-workflows/repository-remediation.md` for batched rule remediation and `ai/contribution-workflows/bugfix-pr.md` for a single behavior fix. - - Implement fixes, tests, docs, and work logs required by `AGENTS.md` / `REPOSITORY_RULES.md`. - - Run required verification when feasible. If full verification is too expensive or unavailable, run the tightest relevant checks and state exactly what did not run. - - Create the PR with a standalone body that includes issue links plus the PR-only context described below. - - Do not create a PR that only says "see issue". Do not include raw audit transcripts or AI-generated analysis reports as committed files. - -## Subagent Context Summaries - -Keep these summaries short enough to paste into every later subagent prompt: - -```text -Known accepted findings so far: -- K1: ; affects ; evidence ; status . -- K2: ... - -Known rejected / false-positive candidates: -- F1: ; cited ; rejected because ; revisit only if . -- F2: ... - -Related GitHub issues: -- #123 open/closed: ; affects <area/API>; status <one line>; relation <duplicate/related/superseded/follow-up>. -- #124 ... - -Do not repeat accepted or rejected items unless you find new evidence, broader affected paths, or a distinct root cause. -``` - -Update the summaries after each main-agent triage and before each recheck. Never ask a subagent to reread whole historical issue drafts or full GitHub issue bodies just to avoid duplicates. - -## Issue Body Shape - -```markdown -## Summary -<One paragraph on audit scope, audited commit, and severe stopping state.> - -## Accepted Findings -### 1. <severity> / <evidence level>: <root cause> -- Location: <file:line> -- Rule: <REPOSITORY_RULES.md / AGENTS.md rule> -- Evidence: <specific behavior with commit-pinned source/doc permalink> -- Impact: <why this matters> -- Why not higher/lower: <short severity rationale based on confirmed behavior vs source-risk/policy gap> -- Suggested next check/fix: <concrete direction, pseudocode, or short code sketch> - -## Lower-Severity Notes -<Optional.> - -## Rules/Design Gaps Detected During Audit -<Optional. Include ambiguous rules, missing design docs, inconsistent docs, or repeated false-positive patterns found by comparing subagent reports.> - -## Related GitHub Issues -<Issue-number summary of tracked, duplicate, superseded, or follow-up work considered during triage.> - -## Audit Coverage -- Initial passes: <subagent scopes> -- Recheck passes: <what was re-scanned> -- Stopping condition: no new accepted Critical/High findings after <pass details> -``` - -## PR Body Shape - -The PR body must stand on its own. Include enough evidence and remediation detail -that a reviewer can evaluate the change without opening the issue first: - -````markdown -## Summary -<What this PR fixes, which audit issue it partially or fully remediates, and why this slice is coherent.> - -## Remediated Findings -### 1. <severity> / <evidence level>: <root cause> -- Issue/audit finding: <issue number and finding id/title> -- Current behavior: <short explanation plus precise commit-pinned file:line permalink> -- Relevant current code: - ```rust - <minimal quoted snippet, only the lines needed to understand the bug> - ``` -- Change made: <what changed in this PR> -- Why this is correct: <rule, invariant, dtype/device/shape contract, or public API contract> -- Recommended pattern / pseudocode: - ```text - <small algorithm sketch or API flow that the implementation follows> - ``` -- Tests or checks: <new tests and verification commands> - -## Deferred Findings -<List accepted findings from the aggregate issue that this PR intentionally does not fix, with a short reason.> - -## Verification -<Commands run and exact pass/fail or unavailable status.> - -## Risk -<Residual risk, migration concern, or behavior that needs follow-up.> -```` - -For non-Rust files, replace the fenced language with the correct language or -`text`. Keep snippets minimal and directly tied to the changed behavior. - -## Common Mistakes - -| Mistake | Correction | -|---|---| -| Letting mini subagents decide severity | Treat their output as candidates; main verifies and assigns severity. | -| Main agent reading whole modules to understand every candidate | Read only cited lines and nearest necessary context; delegate broader inspection. | -| Treating subagent reports as isolated code bugs only | Compare reports for rule ambiguity, missing design rationale, and recurring false-positive patterns. | -| Passing full old issue text into every iteration | Pass only the known-issues summary. | -| Rewriting known issue paths while making a recheck prompt | Preserve known paths verbatim; put guessed or expanded search areas only in the separate scope. | -| Stopping after the first clean subagent response | Confirm coverage and run related-pattern scans for accepted severe findings. | -| Creating multiple issues | Maintain one aggregated issue or issue body. | -| Stopping at the aggregate issue | Implement a coherent remediation slice and open one standalone PR. | -| Writing a PR body that relies on the issue | Include current behavior, relevant snippets, fix sketch, verification, and deferred findings in the PR itself. | -| Linking to moving branch line numbers | Use commit-pinned GitHub permalinks for every source/doc line reference. | -| Treating rule violations as High bugs | Separate evidence level, user-impact severity, and remediation priority; High needs confirmed user-visible impact. | -| Accepting rule claims without source evidence | Require `file:line`, rule, impact, and local verification. | - -## Reference - -Use `references/audit-prompts.md` for subagent prompt templates and output contracts. +1. **Bound the scope.** Identify the requested repository, working state and rule + files. Read applicable rules and referenced decisions, not the entire workspace + by default. A local or uncommitted target is valid; describe it accurately. + Do not require a push or a GitHub-visible commit to inspect local work. +2. **Inspect the real path.** Read enough source to understand the contract, + callers and existing checks. Use existing API documentation when helpful; + do not build release-mode documentation as a default audit prerequisite. +3. **Verify findings.** Require a precise location, evidence, impact and smallest + useful correction. Distinguish confirmed defects, source risks and policy/docs + gaps. A rule violation alone does not prove a severe runtime bug. +4. **Check nearby instances once.** Group a confirmed problem by root cause and + check the relevant neighboring paths. Do not iterate broad scans until no + model can invent another finding. Report unresolved scope honestly. +5. **Report and stop.** Provide a ranked, concise list of findings, inspected + scope and limitations. Reuse existing issues when known. Create an issue or + implement fixes only when requested; do not automatically turn an audit into + an open-ended remediation program. + +## Rule Audits + +For each process rule, ask: +- What concrete failure does it prevent? +- Is it already enforced by CI, tools or another rule? +- Is its scope appropriate for a small fix? +- Does it force delegation, repeated approvals, duplicate records or unnecessary + build/network work? + +Prefer deleting redundant instructions or adding a clear applicability condition +rather than inventing another checklist. Preserve actual numerical, memory, +aliasing, device, data-loss and publication safety requirements. + +## Evidence and Review + +- Verify findings against actual source or a reproducer. Do not add code to + appease an unsupported review claim. +- Use repository-relative paths and the inspected revision/state. Add stable + permalinks when publishing references to an available remote commit. +- After a fix, rerun the relevant check and inspect its delta; do not restart a + design approval or full audit unless the scope materially changed. +- If an independent opinion is explicitly requested, use the optional + [bounded prompt](references/audit-prompts.md). Its output is evidence to assess, + not an automatic approval gate. diff --git a/skills/tensor4all-rules-audit/references/audit-prompts.md b/skills/tensor4all-rules-audit/references/audit-prompts.md index c775baf..f691803 100644 --- a/skills/tensor4all-rules-audit/references/audit-prompts.md +++ b/skills/tensor4all-rules-audit/references/audit-prompts.md @@ -1,114 +1,19 @@ -# Audit Prompt Templates +# Optional Independent Review Prompt -Use these templates with mini subagents. Keep prompts scoped and self-contained. - -## Initial Source Slice - -```text -You are a lightweight source-audit subagent for tensor4all-rs. - -Scope: -- Repository: /home/shinaoka/tensor4all/tensor4all-rs -- Audited commit: <full git commit hash verified to exist on GitHub> -- Audit target confirmation: <origin/main | user-confirmed non-origin/main ref/hash> -- Permalink base: https://github.com/tensor4all/tenferro-rs/blob/<full git commit hash>/ -- Files/directories: <exact list> -- Rules to check: README.md, REPOSITORY_RULES.md, AGENTS.md excerpts below. - -Context summaries: -- Related GitHub issues: - <paste concise issue-number summaries, or "none known"> -- Known accepted findings: - <paste short accepted-finding summary, or "none yet"> -- Known rejected / false-positive candidates: - <paste short false-positive summary, or "none yet"> - -Task: -Inspect only your assigned scope for possible repository-rule violations, correctness bugs, missing path coverage, stale docs/examples, hidden dense materialization, index identity mistakes, C API error-loss patterns, public API drift, or unsafe layering. -Use the context summaries to avoid rediscovering already tracked issues or already rejected false positives. Report an accepted or rejected item only if you find new evidence, broader affected paths, a refutation, or a distinct root cause. - -Output possible issues only. Do not edit files. Do not create issues. Do not assign final severity or call a candidate High/Critical. - -For each candidate: -- id: local candidate id -- file:line -- permalink: commit-pinned GitHub link for `file:line` when possible -- rule: violated rule or invariant -- evidence: concrete source/API-doc evidence with a short snippet or precise line summary -- impact: likely consequence if real -- confidence: low/medium/high -- related_search: suggested rg query or related files for the main agent -- pr_context: - - current_snippet: minimal source/API-doc snippet needed to understand the problem - - suggested_update: pseudocode, exact code shape, or concrete validation direction useful for a standalone PR body - - likely_tests: focused tests or checks that should fail before the fix and pass after it - -At the end, include a brief `rule_or_design_gap_notes` section if your scope -exposes ambiguous repository rules, missing design docs, or docs/design -inconsistencies that may cause false positives. - -If none, say "No possible issues found in assigned scope" and list the files you inspected. -``` - -## Targeted Recheck +Use only when the user explicitly requests an independent opinion. No particular +model family, number of reviewers, or follow-up round is mandatory. ```text -You are a lightweight recheck subagent for tensor4all-rs. - -Scope: -- Repository: /home/shinaoka/tensor4all/tensor4all-rs -- Audited commit: <full git commit hash verified to exist on GitHub> -- Audit target confirmation: <origin/main | user-confirmed non-origin/main ref/hash> -- Permalink base: https://github.com/tensor4all/tenferro-rs/blob/<full git commit hash>/ -- Files/directories or rg queries: <exact list> - -Context summaries: -- Related GitHub issues: - <paste concise issue-number summaries, not full issue bodies> -- Known accepted findings: - <paste short accepted-finding summary only, not the full issue draft> -- Known rejected / false-positive candidates: - <paste short false-positive summary> - -Task: -Look for new possible issues, broader affected paths, or evidence that a known finding is duplicated elsewhere. Do not repeat known findings unless you add new evidence, broader scope, or a distinct root cause. -Preserve all known-finding paths, APIs, and evidence exactly as provided. If you inspect additional likely-related paths, list them as recheck scope or new evidence, not as rewritten known facts. -Do not repeat rejected false positives unless you can point to new evidence or explain why the prior rejection no longer applies. - -Output possible issues only. Do not edit files. Do not create issues. Do not assign final severity or call a candidate High/Critical. - -For each candidate: -- id -- relation: new-root-cause | broader-scope | possible-duplicate | refutation -- file:line -- permalink: commit-pinned GitHub link for `file:line` when possible -- evidence: short snippet or precise line summary -- impact -- confidence -- related_search -- pr_context: - - current_snippet: minimal source/API-doc snippet needed to understand the problem - - suggested_update: pseudocode, exact code shape, or concrete validation direction useful for a standalone PR body - - likely_tests: focused tests or checks that should fail before the fix and pass after it +Review only <files/diff and revision or working state>, read-only. +Question: <specific correctness or policy concern>. +Relevant contract: <short rule or design reference>. +Known evidence: <tests/source facts, including rejected claims if relevant>. + +Read actual source rather than relying on summaries. Return concrete findings +with locations, short evidence and impact. Separate confirmed defects from +uncertainty and policy gaps. State what was not inspected. Do not propose new +frameworks, broaden the audit or create issues. No findings is a valid outcome. ``` -## Main-Agent Triage Checklist - -For every candidate: - -1. Open the cited source/API docs and verify the claim. -2. Check whether the claim is a duplicate of an accepted root cause. -3. Check whether the claim is already tracked by a related GitHub issue. -4. Check whether the claim matches a rejected false positive and whether new evidence changes that decision. -5. Verify or create the commit-pinned permalink for each accepted or rejected `file:line`. -6. Search related files with the candidate's `related_search` or a better `rg` query. -7. Validate or rewrite the candidate's `pr_context` from direct source/API-doc evidence. Do not preserve guessed snippets or fix sketches. -8. Decide evidence level: Confirmed, Source-risk, or Policy/doc gap. -9. Decide user-impact severity separately from remediation priority. High/Critical requires confirmed user-visible behavior, not just a broad repository-rule violation. -10. Record why the finding is not higher or lower. -11. Update the accepted-finding, false-positive, and related-issue summaries before the next recheck. - -Keep main-agent source reads minimal. If a candidate needs broad source reading, -send a targeted recheck subagent instead of expanding the main context. -Also compare candidate reports for meta-problems in rules or design docs, not -just code defects. +The main agent assesses the evidence. An inaccurate claim is rejected with a +source explanation; it does not require a code change or another review round.