[jiaran-king]

Governing Issue and delivery slice

Refs #374

This PR delivers the read-only MindIE knowledge and candidate-evidence handoff. A user enables one synced domain for a checkout once. In later sessions, the agent consults MindIE when an Ascend-specific question needs evidence during research, diagnosis, planning, implementation or review. Knowledge-only answers retain delivered source references; candidate work additionally associates those reads with the code and independent evaluation.

The task owner's explicit request to support unresolved Ascend questions before and beyond candidate editing is recorded in the scope confirmation. The earlier #374 candidate-stage proposal remains the starting point; this comment records the accepted scope of this delivery without closing the issue.

Workflow and architecture

When to consult MindIE

flowchart TD
    analyze["Analyze the task and available evidence"] --> need{"Unresolved Ascend-specific question?"}
    need -->|No| skip["Record the reason and proceed"]
    need -->|Yes| access{"Are project read tools available?"}
    access -->|No| skip
    access -->|Yes| search["Query using observed task conditions"]
    search --> hit{"Applicable versioned ref found?"}
    hit -->|No| skip
    hit -->|Yes| read["Explain selected refs and read delivered bodies"]
    read --> useful{"Usable guidance?"}
    useful -->|No| skip
    useful -->|Yes| apply["Use the guidance and note the exact source"]
    apply --> deliverable{"Requested deliverable"}
    skip --> deliverable
    deliverable -->|Research or diagnosis| answer["Answer with delivered sources and applicability limits"]
    deliverable -->|Candidate work| candidate["Edit and freeze the candidate"]
    candidate --> evaluate["Run independent InferRSI evaluation"]
    evaluate --> record["Record candidate, round, and run ID. Link reviewed reads when used."]

Loading

Integration architecture

flowchart LR
    agent["Codex Agent with InferRSI Skill"] --> mcp["InferRSI stdio MCP"]
    agent --> cli["InferRSI CLI"]
    mcp -->|knowledge_query / knowledge_explain| adapter["Project read adapter"]
    cli -->|mindie query / mindie explain| adapter
    grant["One-time checkout grant"] --> adapter
    adapter --> worker["MindIE Python reader"]
    worker -->|Read-only SQLite| catalog[("Synced local knowledge catalog")]
    adapter --> receipts[("Local query and explain receipts")]
    agent --> snapshot["Frozen candidate"]
    snapshot --> runner["Independent InferRSI evaluation"]
    receipts -->|campaign import-mindie| trace["Reviewed campaign trace"]
    snapshot -->|Candidate and round| trace
    runner -->|Run ID| trace

Loading

Changed artifacts and evidence

Requirement	Change	Verification
Project-scoped read access	Expose knowledge_query and knowledge_explain through the InferRSI CLI and stdio MCP. Bind approval to the checkout identity and record local call receipts.	Fresh enabled and disabled Codex sessions exposed the expected tools. Native MCP read a real body and its prerequisites. Replacing the checkout at the same path invalidated the grant.
Decide when to consult MindIE	Route unresolved Ascend questions from the research section of the generic InferRSI Skill, including knowledge-only tasks. The agent preserves existing search routes and can continue when MindIE is unavailable or inapplicable.	Two fresh Luna max sessions at the final Skill revision independently completed knowledge-only retrieval and host candidate work. See the linked fresh-session evidence below.
Tie delivered knowledge to tested code	Import the exact query and explain evidence and bind the reviewed trace to the frozen candidate, round, and independent evaluation.	The fresh optimization agent read two versioned bodies and changed host metadata/kernel declarations. Frozen independent host checks and the external candidate/knowledge record association were verified; no device result is claimed.
Keep the setup reusable	Document supported versions, project enablement and revocation, MCP queries, and candidate association. Use synthetic, operator-neutral evidence fixtures.	Plugin packaging checks passed.

Current Skill: fresh-session validation

Final tested revision: 44c2a650e57ad2b9b565ac2577e096b6678b1886. It adds the precise automatic receipt location to the Skill and guide. The bundled Skill Git blob matches the committed file.

Current PR head is 1b40e2a150d33695e545ad91795b84deae5a1946. Its only change after the tested revision is plugin-guide wording that result.json is retained only when a response was received. The Skill Git blob remains a067d2977c0069929615319437b6dc7529357e51, and runtime/knowledge bytes are unchanged, so the fresh sessions exercise the exact current Skill.

Two new gpt-6-luna / max sessions used fork_turns=none, with no prior experiment history or retrieval-route hint and no follow-up instructions before completion. Evidence bundle · Review response with direct receipts.

Case	Observed result
Knowledge-only Ascend Triton question	Autonomously queried and explained three exact versioned units; the answer preserved backend/SoC limitations.
Host launch-configuration optimization	A different fresh agent read two units, changed the host key and matching kernel scalar declarations, and delivered a frozen candidate.
Independent host checks and association	All 85 assertions in the pre-existing host/source validator passed. Actual reads were imported and associated with an external candidate-validation record; dashboard loading resolved two knowledge sources and 14 source artifacts.

The downloadable evidence includes prompts, orchestration metadata, call logs, request/result files, redacted receipts, candidate sources, frozen acceptance and a runnable independent validator. Input/result bytes were checked against the original receipt hashes; all uploaded files matched the reviewed publication copy. Knowledge attribution and redaction details are included.

An unnecessary MindIE query for the ordinary PyTorch DCP control returned no applicable cards; the answer used the original DCP package. The wrong-revision read and bounded-output omission are retained. These results establish fresh-session Ascend retrieval in the tested CLI cases, not zero irrelevant calls or statistical stability. No actual Triton/NPU execution, device compile-count or performance qualification occurred; device quality is NOT_RUN and performance INCONCLUSIVE.

Earlier experiments at f6194b5 included a history-bearing follow-up after invalid CLI arguments. They remain historical observations and do not substitute for the fresh sessions above. The earlier three fixed-query comparisons found identical original-path outputs before/after a real MindIE read.

Checks and dependencies

• The receipt-wording update passed Skill validation and git diff --check. The earlier 52 plugin tests at f6194b5 are reused: the only later source-tree changes are receipt-location prose in the Skill and guide; runtime, knowledge data and test definitions are unchanged. The final bundle was exercised by both fresh sessions above.

• Earlier runtime validation at the pre-update head: 69 focused tests passed in tests/test_mindie_context.py, tests/test_mindie_project.py, and tests/test_codex_plugin.py. Ruff and git diff --check passed.

• The new workflow smokes covered host correctness and traceability. The earlier session-authorized RMSNorm A3 run verified correctness and source identity. Its performance result was INCONCLUSIVE because the identical-code control showed larger variation.

• The earlier full-suite run recorded 3,574 passed, 11 failed, and 27 skipped. Ten failures reproduced on the base, and the remaining nested-repository case passed in isolation. The earlier ready-lane workflow at f6194b5 reported action_required with zero jobs created; no fresh full-suite CI result is claimed.

• Project reads use the installed, synced mindie-knowledge 0.13.13 catalog. Setup and the optional native MCP configuration are in docs/codex-plugin.md.

Remaining work and Issue closure

Maintainers can review this read-only delivery and its evidence independently. Earlier review items 1–4 remain open: worker test/read-only behavior coverage, stdio MCP protocol coverage/error code, the permissive test exit assertion, and full CI/failure identifiers. This update addresses fresh-session evidence, scope confirmation and receipt wording. Remaining Issue requirements and goal acceptance are tracked in #374.

[amy-why-3459]

First full review at head d3ccdc49bde7ad196bf3c0528af8ab4aeeafd240, against base main @ 0da7e2f960cd4ec994ae8eddea5b71023c5379ca. I read all 11 files (+1043/−0). The PR is still a draft, and I am not approving yet. This review is static: I read the diff and the files at this head, and I did not run the tests.

What I checked

• Grant binding (mindie_project.py). The grant is keyed by checkout path. _load_grant (L72-91) also compares project_root and the .git device and inode. For worktrees it additionally compares the pointer hash and the gitdir inode. It rejects a grant file that is a symlink, has a different owner, or has group/other permission bits. The file is written with NamedTemporaryFile (0600) and then replace. disable only deletes the grant. Old receipts stay where they are.
• Argument checks (_check_arguments, L162-185). They match the MCP inputSchema: the field allow-lists, the limit/token_budget ranges, and the domain-bound mindie://<domain>/units/<id>@N refs. mindie_mcp._reply allows only the two tools, and errors come back as isError.
• Import (mindie_context.export_context). It rejects duplicate keys and non-finite values. It accepts the direct, structuredContent and single text-block payload shapes. Explain refs must be exact query hits in one domain, and delivered units must have been requested. Anything unresolved or missing marks the result partial. The id regex and is_relative_to keep writes inside mindie/<id>, and an existing directory is never overwritten.
• Import paths. The tests import inferrsi.harness.campaign_records / dashboard_data, and those still exist on main. Note that Review measured request profiles and decisions across optimization rounds #389 moves both to inferrsi.observability, so whichever PR merges second will need to update these imports.
• Packaging. The plugin runtime unpacks to runtime/inferrsi/, so _WORKER (L17) is a real file that the MindIE interpreter can execute.

Needs a change or an answer

1. The worker that actually touches MindIE has no tests. Every test monkeypatches mindie_project._worker, so _mindie_read_worker.py never runs in CI. That file holds the version pin, the domain check, the read-only overrides (observe_delivered, _rebuild_index), the use of the private _load(), and the error-masking allow-list (L62-78). Could you add a test that runs the real _worker subprocess with sys.executable and a minimal stub mindie_knowledge package placed through the interpreter's path? It should cover:

   • the version mismatch;
   • the domain mismatch;
   • a library exception whose message contains a private path, which must come back as the generic error;
   • a successful query.

   Related question: in 0.13.13, do GradedRepository.query/explain write anything besides observe_delivered, such as usage stats, feedback or a cache? With mode=ro, any such write would make every read fail with "The local MindIE catalog is unavailable", not silently write. Please confirm this against the real catalog. It would also help to link the evidence for "Native MCP read a real body and its prerequisites".

2. The serve() loop isn't tested, only _reply. Please add a small stdio round trip covering initialize, the notifications/initialized notification (no reply), tools/list, one tools/call, and one invalid line. Minor: a line that isn't valid JSON currently returns -32600 with id: null. JSON-RPC uses -32700 for parse errors.

3. tests/test_mindie_context.py L192-196 accepts exit code {0, 1} from inferrsi run. A failed run passes this assertion. Please assert the exit code you expect, or say why 1 is acceptable for this CPU fixture.

4. CI and evidence. Only declarations has run at this head, and the PR body says the full CI is still pending. The body also reports an earlier full-suite run with 11 failures: 10 reproduced on the base, plus 1 nested-repo case that passes in isolation. Please list those test IDs, or link the run, so reviewers can confirm they aren't related. The behavior claims in the table ("Two fresh Luna max agents…", the Triton launch-configuration case, "Replacing the checkout … invalidated the grant") have no linked artifacts. Please link the retained receipts, run IDs or logs that back them.

Optional

• campaign import-mindie makes the caller copy four paths and two exit codes out of the receipts by hand. Accepting --query-receipt <dir> --explain-receipt <dir> and reading input.json/result.json/receipt.json directly would remove a source of mismatched evidence.
• docs/codex-plugin.md doesn't say where receipts are kept: ~/.config/inferrsi/mindie-projects/reads/<project-hash>/. It also doesn't say that disable leaves them in place. Worth one sentence.

Accuracy and performance comparisons don't apply here. This is a read-only knowledge and evidence-import feature, and it doesn't change model numerics or claim a speedup.

Reviewed: 0da7e2f960cd4ec994ae8eddea5b71023c5379ca → d3ccdc49bde7ad196bf3c0528af8ab4aeeafd240.

[jiaran-king]

补充一次 Luna max 的实际行为验证（2026-11-11）。本轮在全新 Codex 会话中，只给出“实现昇腾 Triton RMSNorm 启动配置模块”的工程目标和交付要求，观察新版 InferRSI Skill 是否引导 Agent 按需获取知识并用于代码。

验证版本：实际运行的是 4153420，使用 mindie-knowledge 0.13.13 和公开 operators 语料。已比对当前 head d3ccdc4，项目授权、读取 worker、MCP、结果导入及 CLI 接线代码一致；Skill 的差异是移除特定 RMSNorm evaluator 说明、调整文档指引。以下是前一提交的实测结果。

• 自主检索：Agent 通过原生 MCP 调用了两次 knowledge_query。首次查询缺少 kernel_language，随后根据返回的适用条件补充 kernel_language=triton 并重新查询。
• 实际读取：一次 knowledge_explain 请求四个精确版本引用，成功取得三个条目的完整正文。第四个条目及相关前置条件因 SoC 未知保留在 unresolved，导入上下文标为 partial。
• 用于实现：候选将 n_cols 保持为运行时标量并加入 do_not_specialize，将 BLOCK_SIZE 保持为 tl.constexpr；启动配置支持宽度分桶和显式 tile。材料记录逐项关联了特化契约、动态标量 SOP、重编译决策树与这些代码选择。
• 检查与记录：10 项本机配置/标量参考检查及 compileall 通过。实际读取经 campaign import-mindie 导入，assemble-trace 生成候选 trace；候选源码、读取材料及检查日志通过 external record 关联。InferRSI dashboard 成功解析了 trace 和 25 个关联来源。

本轮记录标识为 rmsnorm-launch-config-20261111，候选为 rmsnorm-launch-config-v1。核对了会话中的实际 MCP 调用、读取回执、候选源码和 dashboard 解析结果。

结论：这轮已观察到预期的“按需查知识 → 读取正文 → 用于候选实现 → 留存关联记录”行为。本次范围是宿主侧行为与记录验证；Triton 设备编译、NPU 数值验证、实际编译缓存复用和性能测量仍待实机验证，记录保留 performance_verdict=INCONCLUSIVE、设备质量 NOT_RUN。

[amy-why-3459]

Incremental re-review: d3ccdc49bde7ad196bf3c0528af8ab4aeeafd240 → f6194b504de4093d3bccb09a9f0446310f425556 (one commit, "Route unresolved Ascend research questions to MindIE"). Base main @ 0da7e2f960cd4ec994ae8eddea5b71023c5379ca is unchanged. The PR is still a draft. This is a static review: I read the new diff and the files at this head, and I did not run anything.

What this commit changes
It only touches docs/codex-plugin.md (+7) and plugins/inferrsi/skills/inferrsi/SKILL.md (+52/−34). The MindIE guidance moves out of the comparison flow into a new research subsection, "Consult MindIE for unresolved Ascend questions" (SKILL.md L72-110). The comparison section (L148-157) now refers back to that subsection.

Verified at this head

• The CLI input shapes in SKILL.md L88-91 match _SEARCH_FIELDS/_EXPLAIN_FIELDS (src/inferrsi/mindie_project.py L19-20) and _check_arguments (L162-185). They have the same optional limit/include_unknown/token_budget, and refs must be non-empty for explain.
• "returns receipt_directory" (SKILL.md L94-95) matches call() (mindie_project.py L225).
• The new docs paragraph (docs/codex-plugin.md L86-91) agrees with the skill text.

Still open from my previous review (6792034283)
This commit doesn't touch src/ or tests/, so items 1-4 still stand:

1. _mindie_read_worker.py is never run by a test. All tests still monkeypatch mindie_project._worker. I also still need an answer on whether 0.13.13 query/explain write anything under mode=ro.
2. No stdio round-trip test for mindie_mcp.serve(). The parse-error code is still -32600 instead of -32700.
3. tests/test_mindie_context.py L192-196 still accepts exit code {0, 1}.
4. Only partial CI has run. There are still no linked artifacts for the behavior claims, and no test IDs for the earlier 11 failures.

New in this revision: needs an answer or a change
5. The behavior evidence predates the skill text. The Luna max validation in the comment above ran at 41534203ac93d902c01f97b6c32de5bb443d5c25. This commit rewrites when and how the agent consults MindIE. It now triggers on research, diagnosis, planning, implementation, review and knowledge-only tasks, not only before editing a candidate. So that run no longer covers the guidance being merged. Please re-run at least one fresh session at f6194b5, ideally one knowledge-only question and one optimization task, and link the receipts. Or explain why the earlier run still represents this text.
6. Scope. The trigger now includes review and knowledge-only conversations (SKILL.md L74-77, docs/codex-plugin.md L86-88). Please link the governing issue or comment that accepts this broader trigger. I couldn't tell from the PR body whether it's in scope.
7. Minor wording, SKILL.md L107-108. "Keep query and explain receipt directories outside the source checkout" reads like the agent picks where receipts go. But _record_read (mindie_project.py L188-191) always writes them under ~/.config/inferrsi/mindie-projects/reads/<project-hash>/. Consider "Don't copy receipts into the source checkout; the CLI stores them under …". This would also cover my earlier optional note that docs/codex-plugin.md doesn't say where receipts live.

Accuracy and performance comparisons still don't apply. This revision is guidance and docs only.

Reviewed: d3ccdc49bde7ad196bf3c0528af8ab4aeeafd240 → f6194b504de4093d3bccb09a9f0446310f425556.

[jiaran-king]

Scope clarification for review item 6 (re-review):

The task owner explicitly requested in the implementation conversation:

我希望 agent 在昇腾相关资料不足时能主动查询 MindIE，而不只是写候选代码前。

The owner then authorized implementing that Skill change, validating it with two Luna-max agents, and updating PR #393. This comment records that updated scope in the public PR discussion. The earlier #374 proposal described the candidate-stage starting point; it did not itself establish the later knowledge-only extension.

The reason for the extension is an observed routing gap: a knowledge-only task found insufficient Ascend Triton specialization material but skipped the available MindIE path because the old guidance was framed as a step before editing a candidate. The unresolved technical question can occur during research, diagnosis, planning, implementation or review, so the trigger now follows the knowledge gap.

The accepted boundary is:

• Consult an already authorized MindIE domain when an unresolved Ascend-specific question needs evidence.
• Keep existing knowledge routes and skip additional MindIE reads when the available evidence is sufficient.
• Knowledge-only work returns source-grounded conclusions and applicability limits; candidate/run association applies when the task includes candidate work.
• The change does not enable a domain automatically or authorize remote/device execution.

Fresh-session validation against the final receipt-wording update is now running for a knowledge-only task and a host launch-configuration optimization task. The previous history-bearing follow-up remains labeled as such and will not substitute for these new sessions. This scope record does not close #374 or replace independent PR review.

[jiaran-king]

Follow-up to re-review items 5–7. Final tested Skill: 44c2a650e57ad2b9b565ac2577e096b6678b1886, including the receipt-location clarification.

Current PR head is 1b40e2a150d33695e545ad91795b84deae5a1946. Its only change after the tested revision is plugin-guide wording that result.json is retained only when a response was received. The Skill Git blob remains a067d2977c0069929615319437b6dc7529357e51, and runtime/knowledge bytes are unchanged, so the fresh sessions exercise the exact current Skill.

5. Fresh sessions and linked receipts

Two new gpt-6-luna / max sessions used fork_turns=none. They received no previous experiment history, selected knowledge refs, or instruction to use MindIE. No follow-up instructions were sent before completion. The evidence bundle includes the initial prompts, orchestration metadata, call logs, original request/result files, redacted receipts, answers, frozen candidate, and a runnable independent host validator. Gist revision: cb26c5db16dd8264a12f1231db7802b0e9a142db.

Fresh task	Actual observation	Evidence
Knowledge-only Ascend Triton question	Autonomously queried and explained three exact versioned units; the answer retained SoC/backend limitations.	Explain receipt · Delivered bodies · Answer
Host launch-configuration optimization	A different fresh agent read two units, changed the host key and matching kernel scalar declarations, and handed off the candidate.	Explain receipt · Delivered bodies · Handoff
Independent candidate check and association	All 85 frozen host/source assertions passed. Actual reads were imported through campaign import-mindie and associated with the frozen candidate's external validation record; dashboard loading resolved both knowledge sources and 14 source artifacts.	Host checks · Candidate record

The receipt manifest also includes the extra DCP query. Input/result bytes match the original receipt hashes; session identifiers and local paths are redacted where indicated. The uploaded files were compared byte-for-byte with the reviewed publication copy, and the published reconstruction/host-check procedure was exercised.

Observed limitation: the knowledge session unnecessarily queried MindIE once for an ordinary PyTorch DCP question. It found no applicable cards and ultimately used the original DCP package. A wrong package revision and a bounded-output omission are also retained in the logs. This demonstrates fresh-session Ascend retrieval, not zero irrelevant calls or statistical stability. No Triton/NPU execution or performance qualification was performed; device quality is NOT_RUN, performance INCONCLUSIVE. These are CLI sessions, not a native MCP round-trip test.

6. Scope and confirmation

The task owner's explicit instruction and the reason for broadening the trigger are now recorded in the scope clarification. The trigger follows an unresolved Ascend-specific knowledge question, including knowledge-only work; existing read authorization and execution boundaries remain in place.

7. Receipt wording

Commit 44c2a65 states the actual automatic location in both the Skill and plugin guide: ~/.config/inferrsi/mindie-projects/reads/<project-hash>/. It tells the agent not to copy receipts into the source checkout. The fresh sessions above used this final text.

Earlier review items 1–4 remain open. This update does not claim new runtime unit coverage, a MCP protocol fix, or full CI completion.

[amy-why-3459]

Incremental re-review: f6194b504de4093d3bccb09a9f0446310f425556 → 1b40e2a150d33695e545ad91795b84deae5a1946 (two commits: 44c2a65 "Clarify automatic MindIE receipt storage" and 1b40e2a "Qualify response files in failed read receipts"). Base main @ 0da7e2f960cd4ec994ae8eddea5b71023c5379ca is unchanged, and the PR is still a draft. This is a static review: I read the new diff, the code it describes, and the two follow-up comments. I did not run anything.

What changed
Docs and guidance only: docs/codex-plugin.md (+6) and plugins/inferrsi/skills/inferrsi/SKILL.md (+3/−2). No changes under src/ or tests/.

Verified at this head

• Item 7 is resolved. The receipt location now in SKILL.md L107-109 and docs/codex-plugin.md L136-140 matches the code. _grant_path (src/inferrsi/mindie_project.py L40-42) uses ~/.config/inferrsi/mindie-projects/<sha256(root)>.json, and _record_read (L190-194) writes to the sibling reads/<sha256(root)>/. The file list is also correct: input.json and receipt.json are always written, and result.json only when response is not None (L195-199, L208). This also covers my earlier optional note.
• Item 6. The scope is now recorded in the PR discussion (6795800272). The new text only says when to consult MindIE. It doesn't enable a domain or widen read or execution authority. A maintainer still needs to confirm the broader trigger. I can't verify the owner's instruction from the PR alone.
• Item 5. Two fresh sessions are linked in the gist at revision cb26c5d. You say the Skill blob a067d297… is the same at 44c2a65 and at the head. That fits this delta, because 1b40e2a touches only docs/codex-plugin.md. I didn't re-run the gist validator.

Needs a change or an answer

1. Items 1-4 from 6792034283 are still open, as you also noted. src/ and tests/ haven't changed, so these still block approval:
   • _mindie_read_worker.py isn't run by any test. I also still need an answer on whether 0.13.13 query/explain write anything under mode=ro.
   • There's no stdio round-trip test for mindie_mcp.serve(), and the parse-error code is still -32600 instead of -32700.
   • tests/test_mindie_context.py L192-196 still accepts exit code {0, 1}.
   • Only partial CI has run.
2. Trigger precision (question / suggestion). Your evidence shows the knowledge session queried MindIE for an ordinary PyTorch DCP question, which isn't Ascend-specific. Could the trigger in SKILL.md L74-77 say explicitly that MindIE is for questions whose answer depends on Ascend hardware or software (CANN, torch_npu, vllm-ascend, Ascend Triton or SoC behavior)? It would also help to say that generic framework questions should go to the usual sources first. If you think the current wording is enough and this was a one-off, please say so.
3. Minor, optional. docs/codex-plugin.md L136-138 says the reader "returns receipt_directory on success". On failure, the receipt is still written, and its path only appears in the error message (mindie_project.py L222-225). One clause saying where failed-attempt receipts can be found would make the paragraph complete.

Accuracy and performance comparisons still don't apply. This delta is docs and guidance only.

Reviewed: f6194b504de4093d3bccb09a9f0446310f425556 → 1b40e2a150d33695e545ad91795b84deae5a1946.