Release V1.0.1 hardening

.github/workflows/ci.yml

@@ -30,6 +30,15 @@ jobs:
         run: python -m unittest discover -s tests -p 'test_*.py'
       - name: Installed-skill tests
         run: python -m unittest discover -s skills/cuda-kernel-optimizer/tests -p 'test_*.py'
+      - name: Staged installation smoke
+        run: |
+          stage="$(mktemp -d)"
+          cp -R skills/cuda-kernel-optimizer "$stage/cuda-kernel-optimizer"
+          cd "$stage/cuda-kernel-optimizer"
+          test -f LICENSE
+          test -f NOTICE
+          python -m unittest discover -s tests -p 'test_*.py'
+          python scripts/self_check.py
       - name: Compile Python sources
         run: python -m compileall -q skills/cuda-kernel-optimizer/scripts tests
       - name: Skill self-check

README.md

@@ -49,7 +49,9 @@ recommendations unless the user separately authorizes them.
 Installation is performed by Codex. Ask Codex to install or update
 `skills/cuda-kernel-optimizer` from
 [troycheng/cuda-kernel-optimizer](https://github.com/troycheng/cuda-kernel-optimizer),
-then start a new session so the instructions are reloaded.
+using the latest published release tag. Use the moving `main` branch only when
+deliberately testing unreleased changes. Start a new session after installation
+so the instructions are reloaded.
 
 Provide a runnable target, correctness reference, target environment,
 performance goal, constraints, and allowed modification scope. A real workload must be supplied by the user; the skill does not download or invent one. When a
@@ -127,7 +129,7 @@ fast number cannot repair an invalid experiment. The installed `self_check` is
 CPU/static only and does not validate a GPU environment.
 
 See [Evidence & Safety](docs/evidence-and-safety.md), the
-[formal V2.5 reference](skills/cuda-kernel-optimizer/references/evidence_automation.md),
+[pre-V1 protocol 2.5 reference](skills/cuda-kernel-optimizer/references/evidence_automation.md),
 and the [long-run control reference](skills/cuda-kernel-optimizer/references/long_running_control.md).
 
 ## Validation status
@@ -139,6 +141,13 @@ separate. Neither page predicts the speedup of a new project.
 
 ## Release notes
 
+### V1.0.1
+
+- Include `LICENSE` and `NOTICE` in the installable skill artifact.
+- Make the physical GPU lane configurable instead of binding it to maintainer paths.
+- Apply the hard deadline and durable elapsed-time accounting to `open-iter`.
+- Separate standalone release numbers from retained pre-V1 protocol identities.
+
 ### V1.0.0
 
 The first standalone release combines environment readiness, active diagnosis,

README.zh-CN.md

@@ -41,7 +41,8 @@ Skill 不会自动修改宿主机配置。驱动、counter 权限、频率、功
 
 安装由 Codex 完成。让 Codex 从
 [troycheng/cuda-kernel-optimizer](https://github.com/troycheng/cuda-kernel-optimizer)
-安装或更新 `skills/cuda-kernel-optimizer`，然后开启新会话，让新指令生效。
+按最新发布标签安装或更新 `skills/cuda-kernel-optimizer`。只有需要试用尚未发布的修改时，
+才使用持续变化的 `main` 分支。安装完成后开启新会话，让新指令生效。
 
 请提供可运行目标、正确性 reference、目标环境、性能目标、约束和允许修改的范围。
 真实 workload 必须由用户提供；skill 不会自行下载或编造。缺少基础条件时，它会先说明
@@ -123,6 +124,13 @@ workload 结果。两者都不承诺新项目能获得相同提速。
 
 ## 版本记录
 
+### V1.0.1
+
+- 安装后的 skill 现在包含 `LICENSE` 与 `NOTICE`。
+- 物理 GPU 验收路径改为参数配置，不再绑定维护者目录。
+- `open-iter` 统一使用 hard deadline，并持久记录实际耗时。
+- 明确区分独立项目版本和保留的 pre-V1 协议标识。
+
 ### V1.0.0
 
 首个独立公开版本整合了环境准备、主动诊断、限定范围的代码修改、分阶段的

VERSION

@@ -1 +1 @@
-1.0.0
+1.0.1

docs/compatibility.md

@@ -1,7 +1,13 @@
 # Compatibility
 
-Kernel optimization needs Python 3.10+, a working CUDA GPU and driver, and the
-toolchain required by the target implementation.
+The CPU/static suite is tested with Python 3.10 and 3.12 on Linux CI. Core
+Controller scripts use POSIX facilities such as file locks, resource limits,
+signals, and process groups. Linux is the supported GPU execution environment;
+macOS can run CPU/static checks, while native Windows is not supported. Windows
+users should use a Linux or WSL environment.
+
+Kernel optimization also needs a working CUDA GPU and driver and the toolchain
+required by the target implementation.
 
 | Path | Requirement | Boundary |
 |---|---|---|
@@ -29,3 +35,12 @@ routing, and primary upstream sources are maintained in the
 
 The physical GPU fixture and opt-in commands are documented in the
 [RTX 5090 test guide](https://github.com/troycheng/cuda-kernel-optimizer/blob/main/tests/gpu/sm120/README.md).
+
+## Schema identities
+
+New unversioned schemas use the standalone repository namespace. Existing
+versioned pre-V1 schema IDs under the archived `cuda-optimized-skill/schema/v*` and
+`cuda-optimized-skill/schemas/v*` namespaces remain unchanged because they are
+stable protocol identifiers, not installation URLs. Future incompatible schemas
+must use a new versioned namespace in this repository instead of rewriting those
+legacy IDs.

docs/getting-started.md

@@ -4,8 +4,10 @@
 
 Installation is performed by Codex. Ask Codex to install or update
 `skills/cuda-kernel-optimizer` from
-[troycheng/cuda-optimized-skill](https://github.com/troycheng/cuda-kernel-optimizer),
-then start a new session so Codex reloads the skill instructions.
+[troycheng/cuda-kernel-optimizer](https://github.com/troycheng/cuda-kernel-optimizer)
+at the latest published release tag. Use the moving `main` branch only when
+deliberately testing unreleased changes. Start a new session after installation
+so Codex reloads the skill instructions.
 
 ## Prepare the task
 

docs/knowledge-and-research.md

@@ -24,7 +24,7 @@ Each card names counter-signals, required gates, verification steps, and stop
 conditions. A hard UTF-8 byte budget limits the loaded playbooks; the complete
 catalog never enters the Planner context.
 
-During V3.1 active diagnosis, a smaller routing catalog supplies at most three
+During active diagnosis, a smaller routing catalog supplies at most three
 diagnostic cards for the current layer and bottleneck. The cards name likely signals,
 counter-signals, and the next evidence family; they contain no commands and have
 `promotion_authority: none`. They help the model read the context without loading the

docs/long-running-optimization.md

@@ -1,8 +1,13 @@
 # Long-running optimization
 
-Version 3.0 is designed for optimization work that may take hours, cross many
-candidates, or resume after interruption. The AI still analyzes profiles and
-writes code, but it does not control the rules of the experiment.
+The long-running Controller is designed for optimization work that may take
+hours, cross many candidates, or resume after interruption. The AI still
+analyzes profiles and writes code, but it does not control the rules of the
+experiment.
+
+The project release starts at V1.0.0. Labels such as 2.5, 3.0, and 3.1 in
+schemas and validation records identify pre-V1 protocol generations retained
+for compatibility; they are not project release versions.
 
 ## The control loop
 
@@ -38,8 +43,8 @@ match exact architecture, task, observed signals, and available evidence before
 loading a playbook. A card can suggest what to try and how to disprove it; it
 cannot authorize execution or promotion.
 
-V3.1 adds the active-diagnosis loop between the first global scan and candidate
-admission. The Controller freezes user-owned evidence adapters, obtains available
+Protocol generation 3.1 introduced the active-diagnosis loop between the first
+global scan and candidate admission. The Controller freezes user-owned evidence adapters, obtains available
 capabilities from the current readiness report, and deterministically chooses one
 request from the AI's competing hypotheses. The selected outcome has predefined
 support and opposition effects. Those effects, the artifact digest, equivalent-request

docs/validation.md

@@ -5,9 +5,10 @@ predict the speedup of a new workload.
 
 ## Automated checks
 
-The local CPU/static suite ran 1,111 tests on 2026-07-21: 1,102 passed, nine physical RTX 5090 opt-in tests were skipped, and none failed. It covers input
+The local CPU/static suite ran 1,122 tests on 2026-07-21: 1,113 passed, nine physical RTX 5090 opt-in tests were skipped, and none failed. It covers input
 validation, state recovery, evidence binding, shared-host guards, timeouts, restoration, capability retrieval,
-stability calibration, audit cadence, and deterministic decision logic. V3.1 adds
+stability calibration, audit cadence, and deterministic decision logic. Pre-V1
+protocol generation 3.1 added
 closed-loop adapter execution, outcome-bound support/opposition, cross-round request
 history, content-based project identity, frozen launcher identity, result and artifact
 tamper detection, interruption handling, concurrent start/resume, readiness-capability
@@ -16,15 +17,15 @@ validate the reader's CUDA environment.
 
 ## Physical GPU lane
 
-The final V3.1 completion lane passed 20 of 20 checks in 58.876 seconds on a physical
+The final protocol-generation 3.1 completion lane passed 20 of 20 checks in 58.876 seconds on a physical
 RTX 5090 on 2026-07-20. It used immutable image
 `sha256:a2d9d89bc4394eab3fadc62c6b5b3f739b6494c1f64c56f5ba5e6c008252a0e5`.
 The new active-diagnosis test executed a real PyTorch CPU/CUDA profile action,
 sealed its 14,341-byte Chrome trace and observed outcome, bound the outcome's
 support/opposition effects, and returned to the next hypothesis round. No host
 setting or package was changed.
 
-The V3.1 readiness lane completed 18 of 18 checks in 52.141 seconds
+The protocol-generation 3.1 readiness lane completed 18 of 18 checks in 52.141 seconds
 on 2026-07-20 with the same immutable image listed below. Readiness itself took
 8.793 seconds; the first baseline artifact appeared 9.297 seconds after the run
 started. CUDA 13.3 target compilation, SM120 execution and SASS, Compute
@@ -33,9 +34,9 @@ recorded as diagnostic degradation. A real NCU target range returned
 `ERR_NVGPUCTRPERM`, so the report requested user action without changing host
 policy. All required capabilities passed and the baseline ran afterward.
 
-The historical V3.0 controller produced its first baseline artifact in about
+The historical protocol-generation 3.0 Controller produced its first baseline artifact in about
 0.014 seconds because it had no readiness stage. The added 9-second startup cost
-is not evidence that V3.1 finds a useful direction faster. That claim still
+is not evidence that protocol generation 3.1 finds a useful direction faster. That claim still
 requires a long user workload showing fewer tool repairs, repeated probes, and
 unproductive profiling rounds.
 

skills/cuda-kernel-optimizer/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 aa24aa
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

skills/cuda-kernel-optimizer/NOTICE

@@ -0,0 +1,20 @@
+CUDA Kernel Optimizer is distributed under the MIT License in this repository.
+
+The project began from KernelFlow-ops/cuda-optimized-skill and was developed
+through the historical repositories below before its standalone V1.0.0 release:
+
+- https://github.com/KernelFlow-ops/cuda-optimized-skill
+- https://github.com/troycheng/cuda-optimized-skill
+- https://git.yukework.com/mlsys/cuda-optimized-skill
+
+The historical repositories remain the source for pre-V1 development history.
+
+Acknowledgements
+
+CUDA Kernel Optimizer builds on the original cuda-optimized-skill created and
+published by KernelFlow-ops. We thank Mark Liu and all upstream contributors
+for the validation, benchmarking, profiling, and iterative optimization work
+that provided the foundation for this standalone project.
+
+- KernelFlow-ops: https://github.com/KernelFlow-ops
+- Mark Liu: https://github.com/mark-liu

skills/cuda-kernel-optimizer/examples/walkthrough.md

@@ -1,8 +1,8 @@
-# V2.2 dual-loop walkthrough
+# Dual-loop walkthrough
 
 This example optimizes `gemm.cu` against `ref.py` and then validates the
 shortlisted kernel on a user-provided inference workload. Values are illustrative;
-the verdict rules and artifact names match V2.2.
+the verdict rules and artifact names follow the retained pre-V1 protocol.
 
 Commands run from the installed skill root:
 

skills/cuda-kernel-optimizer/examples/workload-controller.md

@@ -1,6 +1,8 @@
 # Workload Controller example
 
-This page shows what the AI and Controller exchange during a V3.1 workload run.
+This page shows what the AI and Controller exchange during an active-diagnosis
+workload run. The underlying 3.1 label is a pre-V1 protocol generation, not the
+project release version.
 It is not a command list for the user. The user supplies the runnable workload,
 reference, target environment, objective, constraints, and allowed project paths;
 the AI prepares and operates the contracts.

skills/cuda-kernel-optimizer/references/compatibility.md

@@ -12,7 +12,7 @@ Probe the installed environment before selecting an optimization path.
 
 ## Observed RTX 5090 lanes
 
-Both isolated lanes passed the same V2.2 SM120 acceptance matrix on 2026-07-17:
+Both isolated lanes passed the same pre-V1 SM120 acceptance matrix on 2026-07-17:
 seven safety/helper tests and four real-GPU tests for Triton, native CUDA,
 CUTLASS, randomized identical paired timing, the production outer-workload
 evaluator, and target-bounded NCU.
@@ -48,10 +48,9 @@ degradation. The adapter compared prebuilt baseline/optimized binaries; the
 captured dispatch headers were byte-identical, so the result is binary A/B
 evidence rather than source-level promotion proof. No source tree was modified.
 
-Durable evidence is under
-`/data/tcheng/cuda-skill-e2e/v2.2/artifacts/{current,compatibility,real}`. The
-real run directory is
-`real/orchestrator/run_20260717_043610_569950525`.
+The validation records were captured in an isolated artifact lane. Maintainer
+filesystem paths are intentionally omitted because they are not part of the
+portable evidence contract.
 
 ## Architecture capability rules