@kernaut/kernaut-resources 0.1.17-beta.1 → 0.1.18

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/docs/mcp-usage.md

@@ -1,345 +0,0 @@
-# KernelWiki MCP 功能与用法
-
-KernelWiki MCP 是面向 **算子优化 / kernel 优化 / GPU-NPU 性能调优** 的知识库查询服务。它把仓库中的 wiki、PR 记录、代码 artifact、source excerpts 暴露给 MCP 客户端，例如 Codex、Claude Code 或其他支持 MCP 的 agent。
-
-AI agent 可以通过这个 MCP：
-
-- 查询 CUDA / PTX / Triton / CuTe / AscendC 算子优化经验
-- 查询 NVIDIA SM90 / SM100、Ascend 910B / 910C 的硬件相关技巧
-- 查询 CUTLASS、sglang、vLLM、FlashInfer、PyTorch、DeepGEMM 等项目的 PR 记录
-- 获取 PR 相关代码、diff、kernel source、benchmark 片段
-- 搜索性能症状，例如 memory-bound、register pressure、low SM utilization、pipeline stalls
-- 做 operator routing、kernel migration、API definition、code walkthrough 等检索
-
-## 1. 服务形态
-
-当前 MCP 支持两种启动方式。
-
-### 1.1 本地 stdio MCP
-
-适合本机 Codex / Claude Code 直接拉起：
-
-```bash
-python3 scripts/mcp_server.py
-```
-
-Codex 配置示例：
-
-```bash
-codex mcp add kernelwiki -- python3 scripts/mcp_server.py
-```
-
-### 1.2 远程 HTTP MCP
-
-适合部署到一台机器，然后其他机器通过 HTTP 访问：
-
-```bash
-BLACKWELL_WIKI_ROOT="$PWD" MCP_LOG_FILE=/tmp/kernelwiki-mcp.log \
-  python3 scripts/mcp_http_server.py --host 127.0.0.1 --port 8765
-```
-
-如果要绑定公网或内网地址，建议开启 token 鉴权：
-
-```bash
-MCP_TOKEN_DB=data/mcp_tokens.sqlite3 \
-MCP_ADMIN_TOKEN='replace-with-a-long-random-admin-token' \
-python3 scripts/mcp_http_server.py --host 0.0.0.0 --port 8765
-```
-
-客户端注册：
-
-```bash
-codex mcp add kernelwiki-http --url http://SERVER_HOST:8765/mcp
-```
-
-带 bearer token：
-
-```bash
-export KERNELWIKI_MCP_TOKEN='<client-token>'
-codex mcp add kernelwiki-http \
-  --url http://SERVER_HOST:8765/mcp \
-  --bearer-token-env-var KERNELWIKI_MCP_TOKEN
-```
-
-## 2. MCP 工具列表
-
-### 2.1 `wiki_query`
-
-用途：按关键词和过滤条件查询 KernelWiki。
-
-适合场景：
-
-- 查某个算子、kernel、API 或技术关键词
-- 查某个仓库的 PR
-- 查有代码 artifact 的页面
-- 查某个架构、语言、性能症状相关内容
-
-常用参数：
-
-| 参数 | 说明 | 示例 |
-|---|---|---|
-| `query` | 关键词数组 | `["flash attention"]`, `["tcgen05"]` |
-| `vendor` | **检索范围，见下方「vendor 是必须解析出来的」** | `nvidia`, `ascend`, `generic`, `biren`, `all` |
-| `type` | 页面类型 | `pr`, `kernel`, `technique`, `hardware`, `pattern` |
-| `repo` | 来源仓库 | `cutlass`, `sglang`, `vllm`, `flashinfer` |
-| `language` | 语言 / DSL | `cuda-cpp`, `ptx`, `triton`, `cute-dsl`, `ascendc` |
-| `architecture` | 架构，按族折叠 | `sm90`, `sm100`, `ascend910b`, `ascend910c` |
-| `symptom` | 性能症状 | `memory-bound`, `register-pressure`, `pipeline-stalls` |
-| `has_code` | 只返回带代码 artifact 的页面 | `true` |
-| `limit` | 返回数量 | `10` |
-| `compact` | 紧凑输出 | `true` |
-
-HTTP 示例：
-
-```bash
-curl -sS http://127.0.0.1:8765/mcp \
-  -H 'Content-Type: application/json' \
-  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"wiki_query","arguments":{"query":["tcgen05"],"vendor":"nvidia","limit":5,"compact":true}}}'
-```
-
-#### vendor 是必须解析出来的
-
-这个 wiki 是一个横跨多个厂商的语料库，不带 vendor 的检索会把 NVIDIA 的条目
-返回进一个 Ascend 的任务里，而且是静默发生的。所以 `wiki_query` 和 `wiki_grep`
-都会先解析 vendor，解析不出来就拒绝，而不是放宽成全库搜索：
-
-- 显式传 `vendor` 最直接。
-- 不传时，服务端会尝试从 `architecture`、`language` 或某个厂商特有的关键词
-  （如 `B200`、`ascendc`）推断。推断成功时响应里带
-  `"vendor_auto_detected": true`。
-- 推断不出单一 vendor 时，返回 `VENDOR_REQUIRED` 错误，而不是结果。
-- 确实要搜全库，显式传 `vendor: "all"`。
-
-#### 排序与 CLI 一致
-
-`wiki_query` 的排序、过滤和 vendor 规则与 `scripts/query.py` 共用同一份实现
-（`scripts/_retrieval.py`），同样的参数在两条路径上返回同样的页、同样的顺序。
-排序用字段加权 BM25（BM25F），标题命中权重高于标签、元数据和正文，并带 IDF
-和长度归一化。中文查询按字和二元组切分，所以「精度误差」「归约」这类词也能命中。
-
-`architecture` 按族折叠：`ascend910c` 能查到 `ascend910b` 的语料，`sm90` 能查到
-`sm90a` 的页面。die 级别的身份记在 `soc:` 里，它是标注，不参与检索。
-
-### 2.2 `wiki_get_page`
-
-用途：根据 page id 或相对路径获取页面详情。
-
-适合场景：
-
-- 打开 `wiki_query` 查到的页面
-- 查看 PR 页面完整内容
-- 获取页面关联代码 artifact
-- 获取引用 source excerpts
-
-常用参数：
-
-| 参数 | 说明 |
-|---|---|
-| `lookup` | page id 或相对路径，必填 |
-| `body_only` | 只返回 markdown body |
-| `frontmatter_only` | 只返回 YAML frontmatter |
-| `include_code` | 返回关联代码 artifact |
-| `follow_sources` | 返回引用 source excerpts |
-
-HTTP 示例：
-
-```bash
-curl -sS http://127.0.0.1:8765/mcp \
-  -H 'Content-Type: application/json' \
-  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"wiki_get_page","arguments":{"lookup":"pr-cutlass-3130","include_code":true,"follow_sources":true}}}'
-```
-
-### 2.3 `wiki_grep`
-
-用途：在 wiki、source references、code artifacts 中做正则搜索。
-
-适合场景：
-
-- 查某个 API、函数名、kernel 名
-- 搜索 PR 代码实现细节
-- 搜索 CUDA / PTX / Triton / AscendC 特定写法
-- 搜索性能关键词或硬件指令
-
-常用参数：
-
-| 参数 | 说明 | 示例 |
-|---|---|---|
-| `patterns` | 正则表达式数组，必填 | `["tcgen05"]`, `["wgmma", "sm90"]` |
-| `vendor` | **检索范围，规则同 `wiki_query`** | `nvidia`, `ascend`, `generic`, `biren`, `all` |
-| `scope` | 搜索范围 | `wiki`, `sources`, `artifacts`, `all` |
-| `language` | 语言 / DSL | `cuda-cpp`, `ptx`, `ascendc`, `triton-ascend` |
-| `architecture` | 架构，按族折叠 | `sm90`, `sm100`, `ascend910b`, `ascend910c` |
-| `context` | 上下文行数 | `1`, `2`, `3` |
-| `any_match` | 是否任意 pattern 命中即可 | `true` / `false` |
-| `limit` | 返回文件数量 | `20` |
-| `ext` | 限制扩展名 | `cu,cuh,py,cpp,h` |
-
-`wiki_grep` 的三轴过滤与 `scripts/grep_wiki.py` 共用 `_axes.axis_match`。被
-vendor / language / architecture 排除掉的命中文件数会放在响应的 `notes` 里，
-所以结果变少时能看出是过滤掉的还是本来就没有。
-
-HTTP 示例：
-
-```bash
-curl -sS http://127.0.0.1:8765/mcp \
-  -H 'Content-Type: application/json' \
-  -d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"wiki_grep","arguments":{"patterns":["tcgen05"],"vendor":"nvidia","scope":"all","context":2,"limit":20,"ext":"md,cu,cuh,py,cpp,h"}}}'
-```
-
-注意：为了防止批量导出语料，`wiki_grep` 会拒绝 `.`、`.*`、`^` 等 catch-all 正则。请使用具体关键词或通过 `wiki_query` 按 tag/type/repo 查询。
-
-## 3. 算子优化推荐工作流
-
-### 工作流 A：查一个算子的优化资料
-
-1. 用 `wiki_query` 搜索算子或算法名：
-
-```json
-{"name":"wiki_query","arguments":{"query":["flash attention"],"type":"kernel","vendor":"nvidia","limit":10}}
-```
-
-2. 用 `wiki_get_page` 打开候选页面：
-
-```json
-{"name":"wiki_get_page","arguments":{"lookup":"kernel-flash-attention-4","include_code":true,"follow_sources":true}}
-```
-
-3. 用 `wiki_grep` 搜索实现细节：
-
-```json
-{"name":"wiki_grep","arguments":{"patterns":["flash", "attention"],"vendor":"nvidia","scope":"artifacts","context":2,"ext":"cu,cuh,py"}}
-```
-
-### 工作流 B：查 PR 和 PR 相关代码
-
-1. 查某个 PR：
-
-```json
-{"name":"wiki_query","arguments":{"query":["3130"],"type":"pr","repo":"cutlass","vendor":"nvidia","limit":5}}
-```
-
-2. 打开 PR 页面并带代码：
-
-```json
-{"name":"wiki_get_page","arguments":{"lookup":"pr-cutlass-3130","include_code":true,"follow_sources":true}}
-```
-
-3. 在 artifact 里搜关键 API：
-
-```json
-{"name":"wiki_grep","arguments":{"patterns":["tcgen05"],"vendor":"nvidia","scope":"artifacts","context":2,"ext":"cu,cuh,cpp,h"}}
-```
-
-### 工作流 C：按性能症状找优化模式
-
-查 memory-bound 相关模式：
-
-```json
-{"name":"wiki_query","arguments":{"symptom":"memory-bound","type":"pattern","vendor":"nvidia","limit":10}}
-```
-
-查 register pressure：
-
-```json
-{"name":"wiki_query","arguments":{"symptom":"register-pressure","vendor":"nvidia","limit":10}}
-```
-
-查 pipeline stalls：
-
-```json
-{"name":"wiki_query","arguments":{"symptom":"pipeline-stalls","vendor":"nvidia","limit":10}}
-```
-
-### 工作流 D：按硬件架构找实现参考
-
-查 Blackwell / SM100：
-
-```json
-{"name":"wiki_query","arguments":{"architecture":"sm100","has_code":true,"limit":10}}
-```
-
-查 Hopper / SM90：
-
-```json
-{"name":"wiki_query","arguments":{"architecture":"sm90","has_code":true,"limit":10}}
-```
-
-查 Ascend 910B：
-
-```json
-{"name":"wiki_query","arguments":{"architecture":"ascend910b","language":"ascendc","limit":10}}
-```
-
-## 4. 自然语言使用示例
-
-在 Codex / Claude 里可以直接这样问：
-
-```text
-用 KernelWiki MCP 查 cutlass 里 tcgen05 相关 PR，并打开最相关的页面，包含代码 artifact。
-```
-
-```text
-我在优化一个 Triton attention kernel，请用 KernelWiki 查相关优化模式、PR 和代码参考。
-```
-
-```text
-帮我找 AscendC 上 matmul / attention 算子的优化经验，优先返回带代码的页面。
-```
-
-```text
-在 KernelWiki 的 PR 和代码 artifact 里 grep wgmma.mma_async，显示上下文。
-```
-
-```text
-查 low SM utilization 相关 pattern，然后给我可能的优化方向和参考代码页面。
-```
-
-## 5. Token 管理
-
-远程 HTTP MCP 推荐使用 SQLite token DB。token 增删改查见：
-
-- [`docs/mcp-token-management.md`](mcp-token-management.md)
-
-常用命令：
-
-```bash
-python3 scripts/mcp_token_admin.py --db data/mcp_tokens.sqlite3 add laptop
-python3 scripts/mcp_token_admin.py --db data/mcp_tokens.sqlite3 list
-python3 scripts/mcp_token_admin.py --db data/mcp_tokens.sqlite3 disable 1
-python3 scripts/mcp_token_admin.py --db data/mcp_tokens.sqlite3 rotate 1
-python3 scripts/mcp_token_admin.py --db data/mcp_tokens.sqlite3 delete 1 -y
-```
-
-## 6. 验证 MCP 是否可用
-
-健康检查：
-
-```bash
-curl -sS http://127.0.0.1:8765/healthz
-```
-
-查看工具列表：
-
-```bash
-curl -sS http://127.0.0.1:8765/mcp \
-  -H 'Content-Type: application/json' \
-  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'
-```
-
-stdio smoke test：
-
-```bash
-bash scripts/test_mcp_smoke.sh
-```
-
-HTTP smoke test：
-
-```bash
-bash scripts/test_mcp_http_smoke.sh
-```
-
-## 7. 相关文档
-
-- [`docs/mcp-client-config.md`](mcp-client-config.md)：客户端配置、HTTP 部署、systemd/nginx 示例
-- [`docs/mcp-token-management.md`](mcp-token-management.md)：token 增删改查
-- [MCP validation](operations/mcp-validation.md)：验证清单

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/docs/operations/mcp-validation.md

@@ -1,22 +0,0 @@
-# MCP validation
-
-Run these checks from the repository root. Record the checked commit, command, environment and outcome for each run. Commands listed here are procedures, not claims that the checks have passed.
-
-## Offline regression checks
-
-```sh
-python3 scripts/validate.py
-bash scripts/test_mcp_smoke.sh
-bash scripts/test_access_policy.sh
-bash scripts/test_symlink_containment.sh
-```
-
-The smoke fixtures exercise stdio protocol, queries, page retrieval, grep and error handling. The access checks protect the declared readable roots; moving documentation into history or governance must not expose those directories through knowledge tools. Record existing baseline failures separately from newly introduced failures.
-
-## HTTP and client checks
-
-Use [MCP usage](../mcp-usage.md), [client configuration](../mcp-client-config.md) and [token management](../mcp-token-management.md) for current configuration and authentication. The HTTP transport regression entry is `bash scripts/test_mcp_http_smoke.sh`; it starts local test services and is separate from the offline checks above.
-
-For an actual client, check tools/list, a vendor-scoped query, exact page retrieval, a missing page and a rejected path. Compare the served knowledge version and returned identities with the intended checkout. Client registration and a local protocol pass do not establish that a remote service was upgraded.
-
-The original [FUT-1 handoff](../history/mcp/fut-1-validation-checklist.md) remains historical evidence. Its unchecked items, commands and configuration examples describe that handoff; use the current guides above for operations. Store each new validation result with its experiment or release identity rather than editing the old handoff into a completion report.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/governance/README.md

@@ -1,30 +0,0 @@
-# Knowledge governance
-
-This directory is the entry point for KernelWiki's knowledge-construction constraints. KernelWiki adopts **Open Knowledge Format (OKF) v0.2**, with a KernelWiki Profile for accelerator-kernel knowledge. The reviewed upstream revision and compatibility boundary are defined in [OKF and the KernelWiki Profile](specs/okf.md).
-
-## Rules and responsibilities
-
-| Location | Responsibility | Start here |
-| --- | --- | --- |
-| `specs/` | Explain the format, content ownership, metadata, evidence and rule changes | [OKF](specs/okf.md), [paths](specs/paths.md), [frontmatter and evidence](specs/frontmatter.md), [schema and contract maintenance](specs/schemas.md) |
-| `schemas/` | Locate the authoritative machine declarations and registries | [Declaration inventory](schemas/README.md) |
-| `contracts/` | Locate shared deterministic implementations and their checks | [Implementation inventory](contracts/README.md) |
-
-[Generic admission and capacity](specs/generic-bucket-budget.md) remains an existing policy. [Production tools](../agent/README.md) own producer workflows; [provenance](../provenance/README.md) retains migration and release evidence. Governance Markdown is maintenance documentation, outside the knowledge Bundle and kernel-knowledge search.
-
-## Adoption and deployment
-
-The format decision is adopted; conversion of the deployed corpus is pending. These are separate states:
-
-| Area | Current deployment | Adopted destination |
-| --- | --- | --- |
-| Formal knowledge | `wiki/`, with legacy page types and IDs | One `knowledge/` OKF Bundle |
-| Source records | `sources/`, also searchable | Retained as separately identified source records, outside the Bundle |
-| Machine declarations | `data/` and `corpus/MANIFEST.yaml` | Reuse these authorities; relocate only with their consumers |
-| Validation and retrieval | Existing `scripts/` and producer checks | Extend shared implementations for the Profile before switching writers or readers |
-
-The new-format specifications govern migration pilots and their acceptance. Until an explicitly checked cutover, production writes must also satisfy the deployed schema; a legacy page is not converted by adding a version label. The current validator does not certify OKF or the new Profile. Do not publish an empty Bundle or silently change legacy field meanings to claim conformance.
-
-## Changing a rule
-
-Use [the change checklist](specs/schemas.md#change-checklist). Every executable rule has one declaration owner and one shared interpretation. A tightening or relocation needs consumer adaptation and relevant acceptance/rejection cases. Unresolved conflicts between legacy instructions and the adopted Profile are migration work, not permission to invent per-producer exceptions.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/governance/contracts/README.md

@@ -1,28 +0,0 @@
-# Shared contract implementations
-
-The following existing implementations execute the deployed rules. This directory supplies their common entry point; it does not wrap or fork them.
-
-| Contract | Current implementation | Current verification |
-| --- | --- | --- |
-| Legacy frontmatter, references and artifact provenance | [scripts/validate.py](../../scripts/validate.py) | Run `python3 scripts/validate.py` from the repository root |
-| Vendor/language/architecture interpretation | [scripts/_axes.py](../../scripts/_axes.py), used by [retrieval](../../scripts/_retrieval.py) | CLI/MCP fixtures and affected query regression |
-| Page lookup and source following | [scripts/wiki_page_service.py](../../scripts/wiki_page_service.py) | Existing MCP fixtures, plus old-ID/source/artifact cases for a migration batch |
-| File access and containment | [scripts/wiki_access_policy.py](../../scripts/wiki_access_policy.py) | `bash scripts/test_access_policy.sh`; `bash scripts/test_symlink_containment.sh` |
-| Generated navigation | [scripts/generate-indices.py](../../scripts/generate-indices.py) | Inspect generation in an isolated checkout; this command writes derived files |
-| Experience candidates | [Kernaut producer](../../agent/kernaut-experience-ledger/SKILL.md) and its [record tests](../../agent/kernaut-experience-ledger/tests/test_record_tools.py) | Producer-specific deterministic checks; candidate generation is not publication or independent reproduction |
-
-`bash scripts/test_mcp_smoke.sh` exercises the current retrieval/read interface. It does not establish semantic correctness or retrieval-quality improvement. Current `validate.py` checks `wiki/`, `sources/` and existing artifact contracts; it does **not** validate an OKF Bundle, Profile/index consistency or the new platform filter.
-
-## Integration boundary
-
-Before a new-format migration batch is enabled, the shared implementation must cover:
-
-- Bundle boundary, reserved navigation files, version declaration and Profile-to-type consistency;
-- structured provenance, lifecycle and actual verification events;
-- vendor/technology/platform scope without conflating product generations and architecture families;
-- old identity resolution, split/merge mappings, links and durable evidence access;
-- consistent exclusion of navigation and governance from knowledge-card results.
-
-These checks belong in the shared implementation used by producer, query and lint. Acceptance and rejection fixtures demonstrate the new behavior before release. A directory name or a prose specification is not proof that any of these checks already exists.
-
-Structural validity, source availability, technical support, independent reproduction and usefulness are distinct acceptance results. Keep the existing [machine declarations](../schemas/README.md) as their source of values; follow the [change checklist](../specs/schemas.md#change-checklist) when integrating new checks.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/governance/schemas/README.md

@@ -1,22 +0,0 @@
-# Machine declarations and registries
-
-This is the authoritative-location inventory, not a second copy of the schema. Existing consumers continue to read the following files.
-
-| Declaration | Current owner | Purpose |
-| --- | --- | --- |
-| Page schemas | [data/schemas.yaml](../../data/schemas.yaml) | Legacy source/wiki types, required fields and per-type constraints |
-| Vendor and architecture registry | [data/vendors.yaml](../../data/vendors.yaml) | Vendor ownership, compute stacks and architecture-family normalization |
-| Retrieval vocabulary | [data/tags.yaml](../../data/tags.yaml) | Controlled retrieval values |
-| Aliases | [data/aliases.yaml](../../data/aliases.yaml) | Term and hardware-name normalization declarations |
-| Tool versions | [data/tool-versions.yaml](../../data/tool-versions.yaml) | Tracked software identities and versions |
-| Version claims | [data/version-claims.yaml](../../data/version-claims.yaml) | Version-sensitive claim references |
-| Source corpus registry | [corpus/MANIFEST.yaml](../../corpus/MANIFEST.yaml) | Original source roots and identities |
-| Artifact provenance | Per-bundle `PROVENANCE.yaml` under `artifacts/`, checked by [validate.py](../../scripts/validate.py) | Code/evidence identity, manifests, hashes and derivation |
-
-[references/schema.md](../../references/schema.md) explains the deployed format. It is a human reference, not an independent machine declaration.
-
-## Pending declaration work
-
-The adopted [path Profiles](../specs/paths.md#card-profiles), OKF field shapes and vendor-scoped `platforms` need machine encoding and consumer tests during the representative migration pilot. They are not already implemented by the legacy declarations above. In particular, `architectures` cannot stand in for A2/A3 product applicability.
-
-Reuse and extend the existing authorities before moving their location. A new JSON Schema, Profile file or consolidated registry must have a declared owner, real consumers and a checked replacement plan; do not introduce an unused parallel schema merely to match another repository's filenames. See [maintenance rules](../specs/schemas.md).

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/governance/specs/frontmatter.md

@@ -1,57 +0,0 @@
-# Frontmatter, applicability and evidence
-
-These are the adopted new-format authoring requirements. The [machine-declaration inventory](../schemas/README.md) describes the deployed legacy rules; this document does not change existing files' interpretation before migration.
-
-## Common metadata
-
-We align with CANNBot's eight common authoring fields. Only `type` is universally required by OKF; the other requirements belong to our Profile.
-
-| Field | Construction requirement |
-| --- | --- |
-| `type` | Nonempty, matching the path Profile in [paths](paths.md#card-profiles) |
-| `title` | Nonblank human-readable title |
-| `description` | Nonblank concise summary usable in search and indexes |
-| `tags` | Deduplicated registered retrieval terms; preserve useful existing aliases |
-| `status` | Explicit knowledge lifecycle: `draft`, `stable` or `deprecated` |
-| `sources` | Structured provenance entries with `resource`; a stable technical claim needs traceable support |
-| `created_at` | Actual card creation time, UTC RFC 3339 |
-| `updated_at` | Latest substantive card change, UTC RFC 3339, no earlier than creation |
-
-Default new-format recommendations select `stable` cards. Draft and deprecated material remains explicitly inspectable, with lifecycle and replacement information visible. Legacy cards without knowledge lifecycle metadata need an explicit migration decision; do not treat an absent field as evidence of review.
-
-All YAML inputs must reject duplicate keys when the new Profile is enforced. Reliable Git history can establish editing times, but cannot establish verification. An original experiment date, upstream publication date and migration date are different facts. Missing history remains an explicit migration gap; do not fill all dates or evidence fields with the migration time to make lint pass.
-
-Path-derived vendor, technology and Profile form the destination's classification authority. Legacy `vendor`, `languages` and ID fields remain available through compatibility handling; any retained redundant classification must agree with the path and declared shared scope. Do not introduce a second independently editable Concept ID field.
-
-## Hardware and software boundaries
-
-`platforms` is required on every card except `Glossary`. Canonical platform values are scoped by vendor. Ascend uses `a2` for 910B, `a3` for 910C and the string `"950"` for 950.
-
-- List multiple platforms only when support is established for each.
-- `agnostic` means the claim is independent of hardware platform within its vendor/technology scope. It cannot be mixed with concrete platform values and never means unknown.
-- `[]` means applicability is unconfirmed; retain it in a draft/candidate channel rather than recommending it as compatible.
-- Multiple requested platforms mean common applicability, matching CANNBot. Query each separately when comparing differences. Matching must also honor vendor, technology and local conditions.
-
-`architectures` describes ISA/capability families; `soc` and `measured_on` identify exact parts and runs. A shared architecture family cannot prove A2/A3 product applicability. Do not infer a platform from a broad software enum, and do not expand one SKU's measurements to every generation.
-
-Keep exact software/toolchain and version-sensitive boundaries through the existing [tool-version](../../data/tool-versions.yaml) and [version-claim](../../data/version-claims.yaml) authorities. Existing `cann_version`, `scope`, workload and comparator evidence must survive migration. Hardware filtering is not a substitute for software compatibility or numerical correctness.
-
-## Provenance and verification
-
-Every source entry uses OKF's `resource`; optional `id` identifies per-claim attribution, and optional `role` distinguishes primary/supporting/example evidence. Prefer a fixed upstream revision or a declared local evidence identity. If prose uses a source footnote, its label matches that source's `id`.
-
-`sources[].resource` preserves OKF path/URI resolution: ordinary relative paths resolve from the card; paths beginning with `/` resolve from the Bundle root. Registry lookup can restore assets, but cannot silently reinterpret these as repository-root-relative paths. Convert legacy repository-relative references explicitly. A standalone Bundle must package local dependencies or publish a resolvable immutable equivalent. Bare machine-absolute paths, floating upstream branches and unavailable local logs cannot be the only reproducible evidence. Preserve license, upstream version and content hashes where recorded. [Current authorities](../schemas/README.md) remain the source and artifact registries.
-
-`verified` contains real OKF events with actor `by` and timestamp `at`; one mapping or a list is accepted. Human actors use `human:<id>`, automated checks `process:<id>`, and versioned producers `<producer>/<version>`. Derive the OKF trust tier from events rather than storing another competing tier.
-
-A legacy `confidence: verified`, a source's reputation, a lint pass or a copied upstream event does not establish a new verification event for our changed card. Confirmation applies to the content and conditions actually checked; substantive changes need reassessment. Do not fabricate an actor or timestamp. Lifecycle, evidence strength, trust and freshness describe different properties.
-
-Legacy PR `status: merged/open/closed` remains PR state in source records; it is never converted by renaming it to the knowledge lifecycle. Preserving old confidence and evidence fields as extensions must not redefine `verified`.
-
-## Experience evidence and admission
-
-An `Experience` retains workload/shape/dtype, hardware/software, baseline and candidate identities, comparator/correctness result, measurement units/procedure, direct readings, code and raw evidence references. Preserve unknowns and distinguish observed facts from causal interpretation. Existing mechanism/condition IDs connect instances to reusable knowledge without replacing either identity.
-
-A candidate becomes `stable` only after its sources, applicability and Profile-specific evidence are reviewed and relevant deterministic checks pass. Machine checks prove structure and reference consistency, not technical truth. Independent reproduction, source checking and performance benefit are distinct checks and must be recorded as such. Unverified performance assertions remain reported or draft evidence; failures and regressions remain scoped evidence.
-
-For updates, choose create/update/merge/split/deprecate/defer after locating the existing owner. Importing an upstream card or producing a local candidate does not automatically promote it. Deprecation preserves historical identity and explains the reason and replacement; `replaced_by`, when used, identifies a valid successor Concept. Detailed producer workflow remains with [production tools](../../agent/README.md), so these construction constraints do not create a second ingestion pipeline.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/governance/specs/generic-bucket-budget.md

@@ -1,63 +0,0 @@
-# `wiki/generic` — admission budget
-
-`generic` is not a fourth vendor. It means **"true for every vendor in this
-wiki"**, and that is a much stronger claim than "we have not decided which
-vendor it belongs to". A page that lands here by default rather than by
-argument makes every vendor-scoped query noisier without making any of them
-more useful, which is the failure this budget exists to prevent.
-
-## Admission test
-
-A page is admitted only if **all four** hold. The first is the one that
-actually decides:
-
-1. **Delete the vendor and the language from the page. Is there still an
-   executable action left?** Not a true statement — an *action*. "Memory
-   coalescing matters" survives deletion and is worthless; "compute
-   Δscore/Δspeedup per family before ranking work" survives deletion and tells
-   you what to do on Monday.
-2. **It has been observed on more than one vendor, or it is a property of the
-   objective function / the measurement setup rather than of the silicon.**
-   One vendor's measurement generalised by assertion is how the most expensive
-   documented mistake in this method happened (04 §4.1).
-3. **It carries a `scope`** — the conditions under which it inverts. A rule
-   with no stated inversion has not been thought through; see the worked
-   example below.
-4. **It cites the vendor-specific measurement it was distilled from.** The
-   claim is generic; the evidence never is. A generic page that cites nothing
-   is an opinion.
-
-## What fails the test
-
-- **Hardware facts.** UB size, cache line width, tensor-core shapes. These are
-  `wiki/<vendor>/hardware/` even when both vendors happen to have the feature.
-- **A technique both vendors support.** Double buffering exists on both, but
-  the *how* differs per ISA, so the page belongs to each vendor. Only the
-  *decision rule* for when to reach for it can be generic.
-- **Scoring rules of a specific benchmark or leaderboard.** Platform semantics
-  (03 §3.4). These are dropped, not relocated.
-- **Anything whose action changes when you change vendor.** If the answer to
-  "so what do I do" differs, it is two vendor pages, not one generic page.
-
-## Numeric cap
-
-**Twenty pages.** At the time of writing there is one, plus the five seeded
-below. The cap is deliberate: this bucket competes for retrieval attention
-with every vendor query, and a generic bucket that grows without an argument
-per page is indistinguishable from an unsorted inbox. Raising the cap requires
-showing that the bucket is still all-signal — not that more candidates exist.
-
-Candidates that pass the test but exceed the cap go to `data/` as a queue
-entry, not into `wiki/generic`.
-
-## Worked example of criterion 3
-
-From 03 §3.5, the rule "when the objective function weights cases equally,
-device-time share is the wrong priority" is generic — and it **inverts**:
-
-> When the objective function weights by total time (an end-to-end latency
-> SLO, say), device-time share becomes exactly the right priority.
-
-That inversion clause is what makes the page safe to retrieve. Without it the
-reader applies an equal-weight rule to a time-weighted objective and optimises
-the wrong kernel with full confidence.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/governance/specs/okf.md

@@ -1,34 +0,0 @@
-# OKF and the KernelWiki Profile
-
-KernelWiki adopts Google's [Open Knowledge Format v0.2](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/fe3268a70e8ca5110a43a8f1dfdf6d1a458cf79f/okf/SPEC.md), pinned to `fe3268a70e8ca5110a43a8f1dfdf6d1a458cf79f`. This is the same reviewed baseline used by CANNBot Knowledge. Upstream changes require an explicit compatibility review.
-
-## Format boundary
-
-The destination is one `knowledge/` Bundle. Its cards use UTF-8 Markdown and YAML frontmatter. Concept identity is the Bundle-relative path without `.md`; legacy IDs remain additional compatibility identities. Standard Markdown links connect cards; any graph is rebuilt from those links rather than edited separately.
-
-`index.md` and `log.md` are reserved, not Concepts. Our Profile requires a thin index in each materialized directory and `okf_version: "0.2"` in the root index only. Child indexes have no frontmatter. Git supplies distribution, history and review.
-
-Core fields keep OKF semantics: a nonempty `type`, structured `sources`, knowledge lifecycle `status`, and actual `verified` events. [Metadata rules](frontmatter.md) add domain requirements. General OKF readers must tolerate unknown types/fields, absent optional metadata/indexes and broken links; strict author checks are a separate Profile responsibility.
-
-## KernelWiki Profile
-
-A Profile is our additional construction contract, not a revision of OKF. We adopt CANNBot's useful conventions: one body root; responsibility-based card types; navigational indexes separated from cards; structured provenance; and shared rules for producers, readers and lint. The [path](paths.md) and [metadata](frontmatter.md) specifications define the adopted contract.
-
-The following differences address existing KernelWiki requirements:
-
-| Requirement | Profile decision |
-| --- | --- |
-| Multiple hardware vendors | Vendor namespace before technology/shared and card Profile; platform applicability remains metadata, not duplicated generation trees |
-| Existing KOP/Kernaut references | Preserve old page IDs, mechanism IDs and condition identities through an explicit compatibility mapping |
-| Scoped experimental knowledge | Add `experiences/` / `Experience`, linking exact conditions, observations, implementation and evidence to reusable methods |
-| Durable local evidence | Keep source inventories and original experiment/code bundles outside the Bundle; Git-ignored cache must never be their only surviving copy |
-| Existing retrieval vocabulary | Reuse registered tags and aliases; do not mechanically replace them with another repository's task/topic taxonomy |
-| Numerical and version-sensitive results | Preserve the exact hardware, software, workload and comparator boundaries in all relevant card types, including Runbooks |
-
-These extensions must be declared and consumed before their migration batch switches to the new format. This specification creates no new query flags, JSON schemas or verification actors.
-
-## Publication boundary
-
-The repository root, `governance/`, tools, historical records, `sources/`, `corpus/` and `artifacts/` are outside the Bundle. They are not Concepts merely because some files use Markdown. Knowledge-to-knowledge links stay within the Bundle; external evidence uses resolvable provenance references. A standalone Bundle release must include its referenced local assets or explicitly resolve them to immutable published resources.
-
-[Deployment status](../README.md#adoption-and-deployment) records the remaining legacy layout. Conformance can be claimed for an actual released Bundle only after format checks and separate Profile checks pass; neither installing these specifications nor passing the legacy validator establishes that result. A release pairs the Bundle revision with compatible schema, query and producer revisions.