From 82c4a6edc9c81ddcba41ed097890e26676c8cfdf Mon Sep 17 00:00:00 2001
From: "jiashuai.shi@qq.com" <shijiashuai@bgi.com>
Date: Thu, 28 May 2026 03:36:17 +0800
Subject: [PATCH] Simplify repository maintenance surfaces

Remove AI workflow scaffolding, standardize on the retained CMake/docs workflow, and tighten benchmark/reporting behavior.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
 .claude/commands/opsx/apply.md                |  152 ---
 .claude/commands/opsx/archive.md              |  157 ---
 .claude/commands/opsx/explore.md              |  173 ---
 .claude/commands/opsx/propose.md              |  106 --
 .claude/skills/openspec-apply-change/SKILL.md |  156 ---
 .../skills/openspec-archive-change/SKILL.md   |  114 --
 .claude/skills/openspec-explore/SKILL.md      |  288 ----
 .claude/skills/openspec-propose/SKILL.md      |  110 --
 .editorconfig                                 |    3 -
 .githooks/pre-commit                          |   33 -
 .github/copilot-instructions.md               |   10 -
 .github/workflows/ci.yml                      |    9 -
 .github/workflows/openspec-validation.yml     |  119 --
 .github/workflows/pages.yml                   |    2 -
 .gitignore                                    |   11 -
 AGENTS.md                                     |   92 --
 CHANGELOG.md                                  |   11 +-
 CLAUDE.md                                     |   15 -
 CONTRIBUTING.md                               |   50 +-
 Makefile                                      |   87 --
 README.md                                     |   11 +-
 README.zh-CN.md                               |   11 +-
 docs/.vitepress/config.ts                     |    5 -
 docs/en/academy/learning-path.md              |    2 +-
 docs/en/architecture/system-blueprint.md      |    2 +-
 docs/en/index.md                              |    4 +-
 docs/en/overview/getting-started.md           |    2 +-
 docs/en/research/references.md                |    4 +-
 docs/en/validation/index.md                   |    6 +-
 docs/package-lock.json                        | 1171 +----------------
 docs/package.json                             |    3 +-
 docs/zh/academy/learning-path.md              |    2 +-
 docs/zh/architecture/system-blueprint.md      |    2 +-
 docs/zh/index.md                              |    4 +-
 docs/zh/overview/getting-started.md           |    2 +-
 docs/zh/research/references.md                |    4 +-
 docs/zh/validation/index.md                   |    6 +-
 openspec/AGENTS.md                            |   58 -
 openspec/README.md                            |   64 -
 .../0001-core-architecture/change.yaml        |    6 -
 .../archive/0001-core-architecture/design.md  |   82 --
 .../0001-core-architecture/proposal.md        |   16 -
 .../0002-implementation-roadmap/change.yaml   |    6 -
 .../0002-implementation-roadmap/design.md     |   56 -
 .../0002-implementation-roadmap/proposal.md   |   14 -
 .../.openspec.yaml                            |    2 -
 .../design.md                                 |  116 --
 .../proposal.md                               |   30 -
 .../specs/architecture/spec.md                |   15 -
 .../specs/project-presentation/spec.md        |   22 -
 .../specs/repository-governance/spec.md       |   29 -
 .../specs/testing/spec.md                     |   15 -
 .../tasks.md                                  |   29 -
 .../2026-04-23-initial-migration/proposal.md  |   34 -
 .../2026-04-23-initial-migration/tasks.md     |   23 -
 .../change.yaml                               |    5 -
 .../design.md                                 |  256 ----
 .../proposal.md                               |   76 --
 .../specs/project-presentation/spec.md        |   94 --
 .../tasks.md                                  |  104 --
 .../.openspec.yaml                            |    2 -
 .../design.md                                 |   92 --
 .../proposal.md                               |   29 -
 .../specs/project-presentation/spec.md        |   85 --
 .../tasks.md                                  |   24 -
 .../rebuild-pages-whitepaper/.openspec.yaml   |    2 -
 .../rebuild-pages-whitepaper/design.md        |   60 -
 .../rebuild-pages-whitepaper/proposal.md      |   28 -
 .../specs/project-presentation/spec.md        |   40 -
 .../specs/testing/spec.md                     |   13 -
 .../changes/rebuild-pages-whitepaper/tasks.md |   21 -
 .../revamp-public-presentation/.openspec.yaml |    2 -
 .../revamp-public-presentation/design.md      |   85 --
 .../revamp-public-presentation/proposal.md    |   28 -
 .../specs/project-presentation/spec.md        |   60 -
 .../revamp-public-presentation/tasks.md       |   24 -
 openspec/config.yaml                          |   55 -
 openspec/specs/architecture/spec.md           |  296 -----
 openspec/specs/kernel/spec.md                 |  152 ---
 openspec/specs/project-presentation/spec.md   |  119 --
 openspec/specs/repository-governance/spec.md  |   44 -
 openspec/specs/testing/spec.md                |  200 ---
 scripts/install-hooks.sh                      |    6 -
 specs.md                                      |   71 -
 src/benchmark_runner.cuh                      |   25 +-
 src/main.cu                                   |    4 +-
 src/utils/benchmark.cuh                       |    1 +
 src/utils/benchmark_metrics.cuh               |   47 +-
 tests/test_performance.cu                     |  115 +-
 89 files changed, 92 insertions(+), 5729 deletions(-)
 delete mode 100644 .claude/commands/opsx/apply.md
 delete mode 100644 .claude/commands/opsx/archive.md
 delete mode 100644 .claude/commands/opsx/explore.md
 delete mode 100644 .claude/commands/opsx/propose.md
 delete mode 100644 .claude/skills/openspec-apply-change/SKILL.md
 delete mode 100644 .claude/skills/openspec-archive-change/SKILL.md
 delete mode 100644 .claude/skills/openspec-explore/SKILL.md
 delete mode 100644 .claude/skills/openspec-propose/SKILL.md
 delete mode 100755 .githooks/pre-commit
 delete mode 100644 .github/copilot-instructions.md
 delete mode 100644 .github/workflows/openspec-validation.yml
 delete mode 100644 AGENTS.md
 delete mode 100644 CLAUDE.md
 delete mode 100644 Makefile
 delete mode 100644 openspec/AGENTS.md
 delete mode 100644 openspec/README.md
 delete mode 100644 openspec/changes/archive/0001-core-architecture/change.yaml
 delete mode 100644 openspec/changes/archive/0001-core-architecture/design.md
 delete mode 100644 openspec/changes/archive/0001-core-architecture/proposal.md
 delete mode 100644 openspec/changes/archive/0002-implementation-roadmap/change.yaml
 delete mode 100644 openspec/changes/archive/0002-implementation-roadmap/design.md
 delete mode 100644 openspec/changes/archive/0002-implementation-roadmap/proposal.md
 delete mode 100644 openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/.openspec.yaml
 delete mode 100644 openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/design.md
 delete mode 100644 openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/proposal.md
 delete mode 100644 openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/specs/architecture/spec.md
 delete mode 100644 openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/specs/project-presentation/spec.md
 delete mode 100644 openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/specs/repository-governance/spec.md
 delete mode 100644 openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/specs/testing/spec.md
 delete mode 100644 openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/tasks.md
 delete mode 100644 openspec/changes/archive/2026-04-23-initial-migration/proposal.md
 delete mode 100644 openspec/changes/archive/2026-04-23-initial-migration/tasks.md
 delete mode 100644 openspec/changes/archive/2026-04-29-bilingual-docs-closeout/change.yaml
 delete mode 100644 openspec/changes/archive/2026-04-29-bilingual-docs-closeout/design.md
 delete mode 100644 openspec/changes/archive/2026-04-29-bilingual-docs-closeout/proposal.md
 delete mode 100644 openspec/changes/archive/2026-04-29-bilingual-docs-closeout/specs/project-presentation/spec.md
 delete mode 100644 openspec/changes/archive/2026-04-29-bilingual-docs-closeout/tasks.md
 delete mode 100644 openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/.openspec.yaml
 delete mode 100644 openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/design.md
 delete mode 100644 openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/proposal.md
 delete mode 100644 openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/specs/project-presentation/spec.md
 delete mode 100644 openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/tasks.md
 delete mode 100644 openspec/changes/rebuild-pages-whitepaper/.openspec.yaml
 delete mode 100644 openspec/changes/rebuild-pages-whitepaper/design.md
 delete mode 100644 openspec/changes/rebuild-pages-whitepaper/proposal.md
 delete mode 100644 openspec/changes/rebuild-pages-whitepaper/specs/project-presentation/spec.md
 delete mode 100644 openspec/changes/rebuild-pages-whitepaper/specs/testing/spec.md
 delete mode 100644 openspec/changes/rebuild-pages-whitepaper/tasks.md
 delete mode 100644 openspec/changes/revamp-public-presentation/.openspec.yaml
 delete mode 100644 openspec/changes/revamp-public-presentation/design.md
 delete mode 100644 openspec/changes/revamp-public-presentation/proposal.md
 delete mode 100644 openspec/changes/revamp-public-presentation/specs/project-presentation/spec.md
 delete mode 100644 openspec/changes/revamp-public-presentation/tasks.md
 delete mode 100644 openspec/config.yaml
 delete mode 100644 openspec/specs/architecture/spec.md
 delete mode 100644 openspec/specs/kernel/spec.md
 delete mode 100644 openspec/specs/project-presentation/spec.md
 delete mode 100644 openspec/specs/repository-governance/spec.md
 delete mode 100644 openspec/specs/testing/spec.md
 delete mode 100755 scripts/install-hooks.sh
 delete mode 100644 specs.md

diff --git a/.claude/commands/opsx/apply.md b/.claude/commands/opsx/apply.md
deleted file mode 100644
index ae14f0f..0000000
--- a/.claude/commands/opsx/apply.md
+++ /dev/null
@@ -1,152 +0,0 @@
----
-name: "OPSX: Apply"
-description: Implement tasks from an OpenSpec change (Experimental)
-category: Workflow
-tags: [workflow, artifacts, experimental]
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read every file path listed under `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! You can archive this change with `/opsx:archive`.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.claude/commands/opsx/archive.md b/.claude/commands/opsx/archive.md
deleted file mode 100644
index 5e91608..0000000
--- a/.claude/commands/opsx/archive.md
+++ /dev/null
@@ -1,157 +0,0 @@
----
-name: "OPSX: Archive"
-description: Archive a completed change in the experimental workflow
-category: Workflow
-tags: [workflow, archive, experimental]
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Spec sync status (synced / sync skipped / no delta specs)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success (No Delta Specs)**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** No delta specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success With Warnings**
-
-```
-## Archive Complete (with warnings)
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** Sync skipped (user chose to skip)
-
-**Warnings:**
-- Archived with 2 incomplete artifacts
-- Archived with 3 incomplete tasks
-- Delta spec sync was skipped (user chose to skip)
-
-Review the archive if this was not intentional.
-```
-
-**Output On Error (Archive Exists)**
-
-```
-## Archive Failed
-
-**Change:** <change-name>
-**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
-
-Target archive directory already exists.
-
-**Options:**
-1. Rename the existing archive
-2. Delete the existing archive if it's a duplicate
-3. Wait until a different date to archive
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use the Skill tool to invoke `openspec-sync-specs` (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.claude/commands/opsx/explore.md b/.claude/commands/opsx/explore.md
deleted file mode 100644
index 1757907..0000000
--- a/.claude/commands/opsx/explore.md
+++ /dev/null
@@ -1,173 +0,0 @@
----
-name: "OPSX: Explore"
-description: "Enter explore mode - think through ideas, investigate problems, clarify requirements"
-category: Workflow
-tags: [workflow, explore, experimental, thinking]
----
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
-**Input**: The argument after `/opsx:explore` is whatever the user wants to think about. Could be:
-- A vague idea: "real-time collaboration"
-- A specific problem: "the auth system is getting unwieldy"
-- A change name: "add-dark-mode" (to explore in context of that change)
-- A comparison: "postgres vs sqlite for this"
-- Nothing (just enter explore mode)
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│      ┌────────┐         ┌────────┐      │
-│      │ State  │────────▶│ State  │      │
-│      │   A    │         │   B    │      │
-│      └────────┘         └────────┘      │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-If the user mentioned a specific change name, read its artifacts for context.
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-    | Insight Type               | Where to Capture               |
-    |----------------------------|--------------------------------|
-    | New requirement discovered | `specs/<capability>/spec.md` |
-    | Requirement changed        | `specs/<capability>/spec.md` |
-    | Design decision made       | `design.md`                  |
-    | Scope changed              | `proposal.md`                |
-    | New work identified        | `tasks.md`                   |
-    | Assumption invalidated     | Relevant artifact              |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When things crystallize, you might offer a summary - but it's optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.claude/commands/opsx/propose.md b/.claude/commands/opsx/propose.md
deleted file mode 100644
index 05276f4..0000000
--- a/.claude/commands/opsx/propose.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-name: "OPSX: Propose"
-description: Propose a new change - create it and generate all artifacts in one step
-category: Workflow
-tags: [workflow, artifacts, experimental]
----
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The argument after `/opsx:propose` is the change name (kebab-case), OR a description of what the user wants to build.
-
-**Steps**
-
-1. **If no input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` to start implementing."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/.claude/skills/openspec-apply-change/SKILL.md b/.claude/skills/openspec-apply-change/SKILL.md
deleted file mode 100644
index 70fbdb8..0000000
--- a/.claude/skills/openspec-apply-change/SKILL.md
+++ /dev/null
@@ -1,156 +0,0 @@
----
-name: openspec-apply-change
-description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read every file path listed under `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! Ready to archive this change.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.claude/skills/openspec-archive-change/SKILL.md b/.claude/skills/openspec-archive-change/SKILL.md
deleted file mode 100644
index 12e2f70..0000000
--- a/.claude/skills/openspec-archive-change/SKILL.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-name: openspec-archive-change
-description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Whether specs were synced (if applicable)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
-
-All artifacts complete. All tasks complete.
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use openspec-sync-specs approach (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.claude/skills/openspec-explore/SKILL.md b/.claude/skills/openspec-explore/SKILL.md
deleted file mode 100644
index 6858d3f..0000000
--- a/.claude/skills/openspec-explore/SKILL.md
+++ /dev/null
@@ -1,288 +0,0 @@
----
-name: openspec-explore
-description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│      ┌────────┐         ┌────────┐      │
-│      │ State  │────────▶│ State  │      │
-│      │   A    │         │   B    │      │
-│      └────────┘         └────────┘      │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-    | Insight Type               | Where to Capture               |
-    |----------------------------|--------------------------------|
-    | New requirement discovered | `specs/<capability>/spec.md` |
-    | Requirement changed        | `specs/<capability>/spec.md` |
-    | Design decision made       | `design.md`                  |
-    | Scope changed              | `proposal.md`                |
-    | New work identified        | `tasks.md`                   |
-    | Assumption invalidated     | Relevant artifact              |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Handling Different Entry Points
-
-**User brings a vague idea:**
-```
-User: I'm thinking about adding real-time collaboration
-
-You: Real-time collab is a big space. Let me think about this...
-
-      COLLABORATION SPECTRUM
-      ════════════════════════════════════════════
-
-      Awareness          Coordination         Sync
-          │                   │                 │
-          ▼                   ▼                 ▼
-      ┌────────┐         ┌────────┐        ┌────────┐
-      │Presence│         │Cursors │        │  CRDT  │
-      │  "3    │         │ Multi  │        │Conflict│
-      │online" │         │ select │        │  free  │
-      └────────┘         └────────┘        └────────┘
-          │                   │                 │
-       trivial            moderate           complex
-
-      Where's your head at?
-```
-
-**User brings a specific problem:**
-```
-User: The auth system is a mess
-
-You: [reads codebase]
-
-     ┌─────────────────────────────────────────────┐
-     │              CURRENT AUTH FLOW              │
-     └─────────────────────────────────────────────┘
-                        │
-          ┌─────────────┼─────────────┐
-          ▼             ▼             ▼
-     ┌─────────┐  ┌─────────┐  ┌─────────┐
-     │ Google  │  │  GitHub │  │  Email  │
-     │  OAuth  │  │  OAuth  │  │  Magic  │
-     └────┬────┘  └────┬────┘  └────┬────┘
-          │             │             │
-          └─────────────┼─────────────┘
-                        ▼
-                  ┌───────────┐
-                  │  Session  │
-                  └─────┬─────┘
-                        │
-                        ▼
-                  ┌───────────┐
-                  │   Perms   │
-                  └───────────┘
-
-     I see three tangles. Which one's burning?
-```
-
-**User is stuck mid-implementation:**
-```
-User: /opsx:explore add-auth-system
-      The OAuth integration is more complex than expected
-
-You: [reads change artifacts]
-
-     You're on task 4: "Implement OAuth flow"
-
-     Let me trace what's involved...
-
-     [draws diagram, explores options, suggests paths]
-
-     Want to update the design to reflect this?
-     Or add a spike task to investigate?
-```
-
-**User wants to compare options:**
-```
-User: Should we use Postgres or SQLite?
-
-You: Generic answer is boring. What's the context?
-
-User: A CLI tool that tracks local dev environments
-
-You: That changes everything.
-
-     ┌─────────────────────────────────────────────────┐
-     │          CLI TOOL DATA STORAGE                  │
-     └─────────────────────────────────────────────────┘
-
-     Key constraints:
-     • No daemon running
-     • Must work offline
-     • Single user
-
-                  SQLite          Postgres
-     Deployment   embedded ✓      needs server ✗
-     Offline      yes ✓           no ✗
-     Single file  yes ✓           no ✗
-
-     SQLite. Not even close.
-
-     Unless... is there a sync component?
-```
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When it feels like things are crystallizing, you might summarize:
-
-```
-## What We Figured Out
-
-**The problem**: [crystallized understanding]
-
-**The approach**: [if one emerged]
-
-**Open questions**: [if any remain]
-
-**Next steps** (if ready):
-- Create a change proposal
-- Keep exploring: just keep talking
-```
-
-But this summary is optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.claude/skills/openspec-propose/SKILL.md b/.claude/skills/openspec-propose/SKILL.md
deleted file mode 100644
index 4b7e204..0000000
--- a/.claude/skills/openspec-propose/SKILL.md
+++ /dev/null
@@ -1,110 +0,0 @@
----
-name: openspec-propose
-description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
-
-**Steps**
-
-1. **If no clear input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/.editorconfig b/.editorconfig
index 9a16921..c437ff4 100644
--- a/.editorconfig
+++ b/.editorconfig
@@ -16,6 +16,3 @@ indent_size = 2
 
 [*.md]
 trim_trailing_whitespace = false
-
-[Makefile]
-indent_style = tab
diff --git a/.githooks/pre-commit b/.githooks/pre-commit
deleted file mode 100755
index baf3678..0000000
--- a/.githooks/pre-commit
+++ /dev/null
@@ -1,33 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-repo_root="$(git rev-parse --show-toplevel)"
-cd "$repo_root"
-
-staged_files="$(git diff --cached --name-only --diff-filter=ACMR)"
-[ -z "$staged_files" ] && exit 0
-
-governance_glob='^(openspec/|AGENTS\.md$|CLAUDE\.md$|specs\.md$|README(\.zh-CN)?\.md$|CHANGELOG\.md$|CONTRIBUTING\.md$|index\.md$|docs/|\.github/copilot-instructions\.md$|\.github/workflows/)'
-doc_glob='^(AGENTS\.md$|CLAUDE\.md$|specs\.md$|README(\.zh-CN)?\.md$|CHANGELOG\.md$|CONTRIBUTING\.md$|index\.md$|docs/|openspec/README\.md$|openspec/AGENTS\.md$)'
-legacy_pattern='(^|[[:space:]`(])specs/(product|rfc|testing)/'
-
-if printf '%s\n' "$staged_files" | grep -Eq "$governance_glob"; then
-  echo "[pre-commit] Running OpenSpec validation..."
-  openspec validate --all >/dev/null
-fi
-
-legacy_refs=0
-while IFS= read -r file; do
-  [[ -z "$file" ]] && continue
-  if [[ "$file" =~ $doc_glob ]] && [[ -f "$file" ]]; then
-    if grep -nE "$legacy_pattern" "$file" >/dev/null; then
-      echo "[pre-commit] Legacy spec path found in $file"
-      legacy_refs=1
-    fi
-  fi
-done <<< "$staged_files"
-
-if [[ "$legacy_refs" -ne 0 ]]; then
-  echo "[pre-commit] Replace legacy spec paths with openspec/specs/* references."
-  exit 1
-fi
diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
deleted file mode 100644
index cbf0eb8..0000000
--- a/.github/copilot-instructions.md
+++ /dev/null
@@ -1,10 +0,0 @@
-# Copilot Instructions
-
-Use `AGENTS.md` for shared repository rules and `openspec/AGENTS.md` for OpenSpec workflow details. This file only records Copilot-specific deltas.
-
-## Copilot Defaults
-
-- Prefer concise, surgical changes on `master`; do not create release/version branch automation.
-- Use `gh` for repository metadata, Actions inspection, and GitHub-side maintenance.
-- Prefer CMake/OpenSpec validation commands already documented in `AGENTS.md`; do not invent extra tooling.
-- Keep generated guidance repository-specific to CUDA SGEMM, GitHub Pages, and OpenSpec closeout work.
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index d53bbdf..9c5de8e 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -1,6 +1,3 @@
-# Continuous Integration
-# Validates code formatting
-
 name: CI
 
 on:
@@ -9,17 +6,11 @@ on:
     paths-ignore:
       - '**/*.md'
       - 'docs/**'
-      - 'index.md'
-      - '_config.yml'
-      - 'openspec/**'
   pull_request:
     branches: [master]
     paths-ignore:
       - '**/*.md'
       - 'docs/**'
-      - 'index.md'
-      - '_config.yml'
-      - 'openspec/**'
   workflow_dispatch:
 
 permissions:
diff --git a/.github/workflows/openspec-validation.yml b/.github/workflows/openspec-validation.yml
deleted file mode 100644
index 2c88e77..0000000
--- a/.github/workflows/openspec-validation.yml
+++ /dev/null
@@ -1,119 +0,0 @@
-name: Repository Governance
-
-on:
-  pull_request:
-    branches: [master]
-    paths:
-      - '.github/copilot-instructions.md'
-      - '.github/workflows/openspec-validation.yml'
-      - 'AGENTS.md'
-      - 'CLAUDE.md'
-      - 'CHANGELOG.md'
-      - 'CONTRIBUTING.md'
-      - 'README.md'
-      - 'README.zh-CN.md'
-      - '_config.yml'
-      - '_includes/**'
-      - '_sass/**'
-      - 'assets/**'
-      - 'docs/**'
-      - 'index.md'
-      - 'openspec/**'
-      - 'specs.md'
-      - 'zh/**'
-  push:
-    branches: [master]
-    paths:
-      - '.github/copilot-instructions.md'
-      - '.github/workflows/openspec-validation.yml'
-      - 'AGENTS.md'
-      - 'CLAUDE.md'
-      - 'CHANGELOG.md'
-      - 'CONTRIBUTING.md'
-      - 'README.md'
-      - 'README.zh-CN.md'
-      - '_config.yml'
-      - '_includes/**'
-      - '_sass/**'
-      - 'assets/**'
-      - 'docs/**'
-      - 'index.md'
-      - 'openspec/**'
-      - 'specs.md'
-      - 'zh/**'
-  workflow_dispatch:
-
-jobs:
-  validate:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Setup Node.js
-        uses: actions/setup-node@v4
-        with:
-          node-version: '22'
-
-      - name: Install OpenSpec CLI
-        run: npm install -g @fission-ai/openspec@latest
-
-      - name: Validate required governance files
-        run: |
-          test -f AGENTS.md
-          test -f CLAUDE.md
-          test -f .github/copilot-instructions.md
-          test -f openspec/config.yaml
-          test -f specs.md
-          test -f openspec/specs/kernel/spec.md
-          test -f openspec/specs/architecture/spec.md
-          test -f openspec/specs/testing/spec.md
-
-      - name: Validate OpenSpec
-        run: openspec validate --all
-
-      - name: Check for active changes on master
-        run: |
-          changes=$(find openspec/changes -mindepth 1 -maxdepth 1 -type d ! -name "archive" 2>/dev/null || true)
-          if [ -n "$changes" ]; then
-            echo "Active change proposals found:"
-            echo "$changes"
-            echo "::warning::Unarchived changes on master"
-          fi
-
-      - name: Validate ID uniqueness
-        run: |
-          # Match complete IDs only, exclude sub-IDs like REQ-KERNEL-001.1
-          req_dups=$(grep -rhEo "REQ-[A-Z]+-[0-9]+(\\.[0-9]+)?" openspec/specs/ 2>/dev/null | grep -vE "\\.[0-9]+$" | sort | uniq -d || true)
-          dec_dups=$(grep -rhEo "DEC-[A-Z]+-[0-9]+(\\.[0-9]+)?" openspec/specs/ 2>/dev/null | grep -vE "\\.[0-9]+$" | sort | uniq -d || true)
-          con_dups=$(grep -rhEo "CON-[A-Z]+-[0-9]+(\\.[0-9]+)?" openspec/specs/ 2>/dev/null | grep -vE "\\.[0-9]+$" | sort | uniq -d || true)
-
-          test -z "$req_dups" || (echo "::error::Duplicate REQ IDs found: $req_dups" && exit 1)
-          test -z "$dec_dups" || (echo "::error::Duplicate DEC IDs found: $dec_dups" && exit 1)
-          test -z "$con_dups" || (echo "::error::Duplicate CON IDs found: $con_dups" && exit 1)
-
-      - name: Reject legacy spec path references
-        run: |
-          legacy_files=$(grep -RInE '(^|[[:space:]`(])specs/(product|rfc|testing)/' \
-            AGENTS.md CLAUDE.md CHANGELOG.md CONTRIBUTING.md README.md README.zh-CN.md \
-            specs.md zh/specs.md openspec/README.md openspec/AGENTS.md docs zh/docs .github/workflows 2>/dev/null || true)
-          if [ -n "$legacy_files" ]; then
-            echo "::error::Legacy spec path references found:"
-            echo "$legacy_files"
-            exit 1
-          fi
-
-      - name: Check nav_order conflicts in docs
-        run: |
-          nav_orders=$(grep -rh "nav_order:" docs/ 2>/dev/null | sort | uniq -d)
-          if [ -n "$nav_orders" ]; then
-            echo "::error::Duplicate nav_order values found in docs/:"
-            echo "$nav_orders"
-            exit 1
-          fi
-
-          zh_nav_orders=$(grep -rh "nav_order:" zh/docs/ 2>/dev/null | sort | uniq -d)
-          if [ -n "$zh_nav_orders" ]; then
-            echo "::error::Duplicate nav_order values found in zh/docs/:"
-            echo "$zh_nav_orders"
-            exit 1
-          fi
diff --git a/.github/workflows/pages.yml b/.github/workflows/pages.yml
index c4890ac..71b92b7 100644
--- a/.github/workflows/pages.yml
+++ b/.github/workflows/pages.yml
@@ -7,8 +7,6 @@ on:
   push:
     branches: [master]
     paths: &pages_paths
-      - 'CHANGELOG.md'
-      - 'CONTRIBUTING.md'
       - 'docs/**'
       - '.github/workflows/pages.yml'
   pull_request:
diff --git a/.gitignore b/.gitignore
index 90c8c34..6b67bc3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,7 +10,6 @@ cmake-build-*/
 CMakeCache.txt
 CMakeFiles/
 cmake_install.cmake
-Makefile
 compile_commands.json
 CMakeUserPresets.json
 
@@ -51,15 +50,5 @@ docs/.vitepress/cache/
 .DS_Store
 Thumbs.db
 
-# BMad Method V6
-_bmad/
-_bmad-output/
-
-# oh-my-claudecode (local tool config)
-.omc/
-
 # Git worktrees
 .worktrees/
-
-# Claude Code plans (AI-generated planning drafts)
-.claude/plans/
diff --git a/AGENTS.md b/AGENTS.md
deleted file mode 100644
index 694dbb4..0000000
--- a/AGENTS.md
+++ /dev/null
@@ -1,92 +0,0 @@
-# AGENTS.md
-
-Repository-wide guidance for AI agents and automated contributors.
-
-## Project Posture
-
-This repository is in a **closeout-oriented** stage.
-
-- Prefer **consolidation over expansion**
-- Prefer **one authoritative source** over duplicate explanations
-- Prefer **deleting or merging** low-value files over keeping placeholders
-- Prefer **one longer apply/autopilot session** over frequent `/fleet` fan-out
-
-## Authoritative Sources
-
-| Need | Source |
-|------|--------|
-| Stable requirements and governance | `openspec/specs/*` |
-| Active implementation plan | `openspec/changes/<change>/` |
-| OpenSpec workflow details | `openspec/README.md`, `openspec/AGENTS.md` |
-| Repository entry point | `README.md` |
-| Public landing/documentation entry | `index.md` + `docs/` |
-
-If two files say the same thing, keep one and remove the other.
-
-## Default Workflow
-
-1. `/opsx:explore` when scope or trade-offs are unclear
-2. `/opsx:propose "description"` for repo-wide or behavior-affecting changes
-3. `/opsx:apply` to execute the task list
-4. `/review` before large deletions, workflow changes, or archive
-5. `/opsx:archive` only after specs, docs, workflows, and validation agree
-
-## Branch and Worktree Policy
-
-- `master` is the only long-lived branch.
-- Short-lived local branches or worktrees are allowed only as temporary isolation for a specific task.
-- Before closeout, merge completed work back to `master`, delete temporary branches/worktrees, and ensure local and remote branch lists contain no stale task branches.
-- Do not add release/version branch automation; this repository favors a single-mainline closeout flow.
-
-## Repository Boundaries
-
-### Code
-
-- CUDA kernels live in `src/kernels/`
-- Shared utilities live in `src/utils/`
-- Entry point lives in `src/main.cu`
-- Tests live in `tests/test_sgemm.cu`
-
-### Documentation
-
-- `README.md`: concise repo entry and quick-start
-- `index.md` + `docs/`: public project presentation and deeper learning content
-- `CHANGELOG.md`: meaningful release history only
-- `CONTRIBUTING.md`: compact collaboration instructions
-- `openspec/*`: normative process and requirements
-
-Do not duplicate the same explanation across these surfaces.
-
-## Validation Baseline
-
-```bash
-cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
-cmake --build build -j$(nproc)
-ctest --test-dir build
-openspec validate --all
-```
-
-- Hosted CI is compile-time and structure validation only
-- GPU runtime verification and benchmarking are local-only
-
-## Tooling Preferences
-
-- Use `gh` for repository metadata, workflow inspection, and GitHub-side operations
-- Treat CMake-generated `compile_commands.json` plus `clangd` as the shared LSP baseline
-- Keep hooks minimal and project-specific
-- Prefer native CLI tools, OpenSpec skills, and focused reviews over heavy MCP usage
-
-## Tool Routing
-
-- Use `/review` before major deletions, workflow topology changes, or OpenSpec archive.
-- Use subagents for bounded research, log inspection, or clearly separable analysis.
-- Use native CLI plus `gh` for repository metadata, workflows, and GitHub maintenance.
-- Treat Claude, Copilot, OpenCode, and similar tools as sharing the same OpenSpec and clangd baseline; avoid tool-specific drift.
-- Add MCP or plugins only when built-in tools or skills leave a concrete gap.
-
-## Quality Rules
-
-- Keep kernel interfaces consistent with the existing template launcher pattern
-- Preserve RAII-based CUDA resource handling and exception-based error reporting
-- Avoid generic governance boilerplate; write instructions that are specific to this repository
-- When cleaning up docs or workflows, ensure retained files have a single obvious responsibility
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 7426448..a858006 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -16,15 +16,18 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) and
 ### Fixed
 - Integer overflow risk in `verify.cuh` and `tensor_core_sgemm.cuh` for large matrices (use `size_t`)
 - Command-line parsing now uses `strtol()` with proper error handling instead of `atoi()`
+- Benchmark startup now fails cleanly instead of crashing when no CUDA device is available
+- Compute-only Tensor Core benchmark results now flow through the shared summary/export path
 
 ### Changed
-- Consolidated repository governance around `openspec/specs/`, updated agent instructions, and simplified documentation roles.
-- Reworked README, GitHub Pages content, and supporting docs into clearer repository-entry and learning surfaces.
-- Began pruning redundant release-history and engineering guidance artifacts in favor of fewer authoritative files.
+- Simplified repository maintenance around README, CONTRIBUTING, root workflows, and the docs site.
+- Reworked README, GitHub Pages content, and supporting docs into clearer SGEMM-focused entry surfaces.
+- Standardized on a single CMake build path and removed duplicate maintenance surfaces.
 
 ### Removed
 - Duplicate `LICENSE` file (kept `LICENSE.md` with third-party info)
-- Legacy `_bmad/` and `_bmad-output/` directories (replaced by OpenSpec)
+- OpenSpec, Claude-specific command/skill files, and other repository-resident AI workflow scaffolding
+- Duplicate Makefile-based build path and unused performance-baseline scaffolding
 
 ### Added
 - `.clang-tidy` configuration for static analysis
diff --git a/CLAUDE.md b/CLAUDE.md
deleted file mode 100644
index a4fc85f..0000000
--- a/CLAUDE.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# CLAUDE.md
-
-Claude-specific deltas for this repository. Shared repository rules live in `AGENTS.md`; OpenSpec rules live in `openspec/AGENTS.md`.
-
-## Command Flow
-
-1. Use `/opsx:explore`, `/opsx:propose`, `/opsx:apply`, `/review`, and `/opsx:archive` for non-trivial repository-wide changes.
-2. Use `/review` before deleting multiple files, changing workflow topology, or archiving an OpenSpec change.
-3. Avoid `/fleet` unless the work is genuinely independent and will not create branch/worktree cleanup debt.
-
-## Claude Operating Notes
-
-- Keep one long-running closeout pass on `master` unless isolation is necessary; temporary worktrees must be merged and removed before completion.
-- Prefer repository-local evidence, OpenSpec artifacts, `gh`, and clangd/compile commands over remote-only research.
-- Do not duplicate `AGENTS.md` content here; update the shared guide if a rule applies to all AI tools.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 7049b03..b379175 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -7,30 +7,18 @@ permalink: /CONTRIBUTING/
 
 # Contributing
 
-Focused improvements are welcome. For this repository, the goal is clarity, correctness, and compactness rather than feature sprawl.
+Keep changes tight, evidence-based, and easy to audit. This repository favors simplification over framework layering.
 
-## When to use OpenSpec
+## Working principles
 
-Use the OpenSpec workflow for any non-trivial change that affects:
-
-- repository structure
-- documentation roles or public positioning
-- validation rules or workflows
-- kernel behavior or engineering requirements
-
-Stable specs live under `openspec/specs/`. Active changes live under `openspec/changes/<change>/`.
-
-## Recommended flow
-
-1. `/opsx:explore` for scope and trade-offs
-2. `/opsx:propose "description"` for the actual change
-3. `/opsx:apply` to execute the task list
-4. `/review` before major deletions, workflow changes, or archive
-5. `/opsx:archive` once tasks, docs, specs, and validation all agree
+- Preserve the SGEMM kernel ladder as the core teaching surface.
+- Prefer one authoritative explanation over duplicated docs.
+- Remove stale or duplicate files instead of keeping placeholders.
+- Keep public docs, README, and workflows aligned when behavior changes.
 
 ## Branch model
 
-`master` is the only long-lived branch. Use a short-lived local branch or worktree only when a task needs isolation, then merge it back to `master` and delete the temporary branch/worktree before closeout. Do not introduce release/version branch automation for routine changes.
+`master` is the only long-lived branch. Temporary local branches are fine for isolation, but merge them back quickly and delete them once the work lands.
 
 ## Validation
 
@@ -38,22 +26,16 @@ Stable specs live under `openspec/specs/`. Active changes live under `openspec/c
 cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
 cmake --build build -j$(nproc)
 ctest --test-dir build
-openspec validate --all
+npm --prefix docs test
+npm --prefix docs run build
 ```
 
-- Hosted CI covers formatting, CUDA compile validation, OpenSpec/repository checks, and Pages.
-- Runtime verification and benchmarking still require a local GPU-capable machine.
-
-## Code and doc expectations
-
-- Keep the existing kernel launcher interface shape intact unless the specs require a change.
-- Preserve RAII-based CUDA resource management and exception-style error handling.
-- Avoid adding generic governance boilerplate or duplicate docs.
-- If two files serve the same purpose, prefer one authoritative file over two partially-overlapping ones.
+- Hosted CI covers formatting and docs-site checks.
+- Local CUDA-capable machines remain the source of truth for building, runtime correctness, and benchmarking.
 
-## Tooling notes
+## Code and docs
 
-- CMake is the primary build path.
-- `clangd` plus `compile_commands.json` is the shared LSP baseline.
-- Use `gh` for repository metadata, Actions, issues, and PR operations.
-- Install the lightweight local hooks with `scripts/install-hooks.sh` if you want repository-specific guardrails before commit.
+- Keep kernel launcher interfaces consistent unless the behavior itself changes.
+- Preserve RAII-based CUDA resource management and explicit error reporting.
+- Use CMake as the supported build path.
+- Keep docs compact and repository-specific.
diff --git a/Makefile b/Makefile
deleted file mode 100644
index b8ad876..0000000
--- a/Makefile
+++ /dev/null
@@ -1,87 +0,0 @@
-# SGEMM Optimization Makefile
-# Supports CUDA compilation with cuBLAS linking
-
-# CUDA compiler
-NVCC = nvcc
-
-# Detect GPU architecture (default to sm_86 for Ampere RTX 30 series)
-GPU_ARCH ?= sm_86
-
-# Compiler flags
-NVCC_FLAGS = -O3 -std=c++17 -arch=$(GPU_ARCH) --use_fast_math
-NVCC_FLAGS += -Xcompiler -Wall,-Wextra
-NVCC_FLAGS += -I./src -I./src/kernels -I./src/utils
-
-# Libraries
-LIBS = -lcublas -lcurand
-
-# Directories
-SRC_DIR = src
-KERNEL_DIR = $(SRC_DIR)/kernels
-UTILS_DIR = $(SRC_DIR)/utils
-TEST_DIR = tests
-BUILD_DIR = build
-
-# Source files
-MAIN_SRC = $(SRC_DIR)/main.cu
-TEST_SRC = $(TEST_DIR)/test_sgemm.cu
-
-# Targets
-BIN_DIR = $(BUILD_DIR)/bin
-MAIN_TARGET = $(BIN_DIR)/sgemm_benchmark
-TEST_TARGET = $(BIN_DIR)/test_sgemm
-
-# Header files (for dependency tracking)
-HEADERS = $(wildcard $(KERNEL_DIR)/*.cuh) $(wildcard $(UTILS_DIR)/*.cuh)
-
-.PHONY: all clean test dirs benchmark
-
-all: dirs $(MAIN_TARGET)
-
-dirs:
-	@mkdir -p $(BUILD_DIR)
-	@mkdir -p $(BIN_DIR)
-	@mkdir -p $(KERNEL_DIR)
-	@mkdir -p $(UTILS_DIR)
-	@mkdir -p $(TEST_DIR)
-
-$(MAIN_TARGET): $(MAIN_SRC) $(HEADERS) | dirs
-	$(NVCC) $(NVCC_FLAGS) -o $@ $< $(LIBS)
-
-$(TEST_TARGET): $(TEST_SRC) $(HEADERS) | dirs
-	$(NVCC) $(NVCC_FLAGS) -o $@ $< $(LIBS) -lgtest -lgtest_main -lpthread
-
-test: $(TEST_TARGET)
-	./$(TEST_TARGET)
-
-benchmark: $(MAIN_TARGET)
-	./$(MAIN_TARGET)
-
-clean:
-	rm -rf $(BUILD_DIR)
-
-# Debug build
-debug: NVCC_FLAGS += -g -G -DDEBUG
-debug: all
-
-# Profile build (for nsight)
-profile: NVCC_FLAGS += -lineinfo
-profile: all
-
-# Help
-help:
-	@echo "SGEMM Optimization Build System"
-	@echo ""
-	@echo "Targets:"
-	@echo "  all       - Build main benchmark (default)"
-	@echo "  test      - Build and run tests"
-	@echo "  benchmark - Build and run benchmark"
-	@echo "  clean     - Remove build artifacts"
-	@echo "  debug     - Build with debug symbols"
-	@echo "  profile   - Build with profiling info"
-	@echo ""
-	@echo "Variables:"
-	@echo "  GPU_ARCH  - GPU architecture (default: sm_86)"
-	@echo ""
-	@echo "Example:"
-	@echo "  make GPU_ARCH=sm_80 benchmark"
diff --git a/README.md b/README.md
index 2faa578..cca67cf 100644
--- a/README.md
+++ b/README.md
@@ -29,7 +29,7 @@ cmake --build build -j$(nproc)
 ctest --test-dir build
 ```
 
-Runtime tests and benchmarks require a local CUDA-capable machine. Hosted CI covers repository integrity, documentation, OpenSpec validation, and Pages buildability.
+Runtime tests and benchmarks require a local CUDA-capable machine. Hosted CI covers formatting plus docs-site checks and Pages buildability.
 
 ## GitHub Pages entry points
 
@@ -44,16 +44,16 @@ The README is the executive summary. The long-form technical narrative lives on
 | Study the kernel ladder | [Academy](https://lessup.github.io/sgemm-optimization/en/academy/) |
 | Check what the evidence proves | [Validation](https://lessup.github.io/sgemm-optimization/en/validation/) |
 | Trace papers and related repos | [Research Desk](https://lessup.github.io/sgemm-optimization/en/research/) |
-| Read normative repository requirements | [OpenSpec Specs](openspec/specs/) |
+| Read contributor workflow and validation commands | [CONTRIBUTING.md](CONTRIBUTING.md) |
 
 ## Validation boundary
 
 | Environment | What it can prove |
 |-------------|-------------------|
-| Hosted CI | Docs structure, route integrity, OpenSpec consistency, Pages buildability |
-| Local CUDA GPU | Runtime correctness, fallback behavior, benchmark performance |
+| Hosted CI | Formatting, docs structure, route integrity, Pages buildability |
+| Local CUDA GPU | CMake build validity, runtime correctness, fallback behavior, benchmark performance |
 
-This split is deliberate. CI keeps the repository coherent, but only local GPU execution can validate runtime behavior and speed claims.
+This split is deliberate. CI keeps the repository surface coherent, but only a local CUDA environment can validate the executable, runtime behavior, and speed claims.
 
 ## Source map
 
@@ -63,7 +63,6 @@ src/utils/     CUDA RAII, verification, benchmark helpers
 src/main.cu    benchmark CLI
 tests/         Google Test coverage against cuBLAS
 docs/          VitePress whitepaper and academy, mirrored under /en and /zh
-openspec/      stable specs and change workflow
 ```
 
 ## License
diff --git a/README.zh-CN.md b/README.zh-CN.md
index a4eb3a9..04c0359 100644
--- a/README.zh-CN.md
+++ b/README.zh-CN.md
@@ -29,7 +29,7 @@ cmake --build build -j$(nproc)
 ctest --test-dir build
 ```
 
-运行时测试和 benchmark 需要本地 CUDA GPU。托管 CI 主要负责仓库完整性、文档结构、OpenSpec 校验，以及 Pages 可构建性。
+运行时测试和 benchmark 需要本地 CUDA GPU。托管 CI 主要负责格式检查、文档站点检查，以及 Pages 可构建性。
 
 ## GitHub Pages 入口
 
@@ -44,16 +44,16 @@ README 是执行摘要，长篇技术叙事在 GitHub Pages 上。
 | 系统学习 kernel 阶梯 | [学院](https://lessup.github.io/sgemm-optimization/zh/academy/) |
 | 核对证据到底证明什么 | [验证](https://lessup.github.io/sgemm-optimization/zh/validation/) |
 | 追溯论文和相关仓库 | [研究资料台](https://lessup.github.io/sgemm-optimization/zh/research/) |
-| 阅读仓库规范来源 | [OpenSpec 规范](openspec/specs/) |
+| 查看贡献流程与验证命令 | [CONTRIBUTING.md](CONTRIBUTING.md) |
 
 ## 验证边界
 
 | 环境 | 能证明什么 |
 |------|------------|
-| 托管 CI | 文档结构、路由完整性、OpenSpec 一致性、Pages 可构建性 |
-| 本地 CUDA GPU | 运行时正确性、fallback 行为、benchmark 性能 |
+| 托管 CI | 格式检查、文档结构、路由完整性、Pages 可构建性 |
+| 本地 CUDA GPU | CMake 构建有效性、运行时正确性、fallback 行为、benchmark 性能 |
 
-这种拆分是刻意设计。CI 负责让仓库保持连贯，只有本地 GPU 执行才能验证运行时行为和速度结论。
+这种拆分是刻意设计。CI 负责让仓库表面保持连贯，只有本地 CUDA 环境才能验证可执行文件、运行时行为和速度结论。
 
 ## 源码地图
 
@@ -63,7 +63,6 @@ src/utils/     CUDA RAII、验证与 benchmark 工具
 src/main.cu    benchmark CLI
 tests/         基于 cuBLAS 的 Google Test 覆盖
 docs/          VitePress 白皮书与学院，公开镜像位于 /en 和 /zh
-openspec/      稳定 specs 与变更工作流
 ```
 
 ## 许可证
diff --git a/docs/.vitepress/config.ts b/docs/.vitepress/config.ts
index ae8d200..27319bf 100644
--- a/docs/.vitepress/config.ts
+++ b/docs/.vitepress/config.ts
@@ -1,6 +1,5 @@
 import { defineConfig } from 'vitepress'
 import { withMermaid } from 'vitepress-plugin-mermaid'
-import llmstxt from 'vitepress-plugin-llms'
 
 const rawBase = process.env.VITEPRESS_BASE
 const base = rawBase
@@ -231,10 +230,6 @@ export default withMermaid(defineConfig({
     },
   },
 
-  vite: {
-    plugins: [llmstxt()],
-  },
-
   // Mermaid 配置 - 通过 withMermaid 传入
   mermaid: {
     startOnLoad: true,
diff --git a/docs/en/academy/learning-path.md b/docs/en/academy/learning-path.md
index 03963d8..21dfaa6 100644
--- a/docs/en/academy/learning-path.md
+++ b/docs/en/academy/learning-path.md
@@ -38,4 +38,4 @@ Follow the optimization ladder in the order the repository was designed to teach
 
 - Make sure your environment follows [Getting Started](/en/overview/getting-started)
 - Use the [Architecture](/en/architecture/) page if you want the repository-level map first
-- Keep the [Specifications Index](https://github.com/LessUp/sgemm-optimization/tree/master/openspec/specs/) nearby if you want the normative requirements
+- Keep [Getting Started](/en/overview/getting-started) and [Validation](/en/validation/) nearby if you want the repository-level constraints and evidence boundary
diff --git a/docs/en/architecture/system-blueprint.md b/docs/en/architecture/system-blueprint.md
index bdab49a..db2ff48 100644
--- a/docs/en/architecture/system-blueprint.md
+++ b/docs/en/architecture/system-blueprint.md
@@ -87,7 +87,7 @@ The blueprint explicitly separates compile-time-verifiable invariants from runti
 
 | Invariant class | Verifiable where |
 |---|---|
-| File structure, docs, OpenSpec alignment | Hosted CI |
+| File structure, docs, and workflow health | Hosted CI |
 | CUDA code compiles and runs on a real CUDA toolchain | Local GPU-capable machine |
 | Correctness under cuBLAS oracle | Local GPU run |
 | Benchmark numbers and speedup ratios | Local GPU run with named hardware |
diff --git a/docs/en/index.md b/docs/en/index.md
index 0ea92e4..24cf353 100644
--- a/docs/en/index.md
+++ b/docs/en/index.md
@@ -47,7 +47,7 @@ title: SGEMM Whitepaper
     <div class="signal-card">
       <div class="signal-title">Trust model</div>
       <div class="signal-value">CI is structural, GPU is empirical</div>
-      <div class="signal-note">Repository health, Pages fitness, and OpenSpec live in automation. Runtime correctness and performance still belong to real hardware.</div>
+      <div class="signal-note">Repository health, docs checks, and Pages fitness live in automation. Runtime correctness and performance still belong to real hardware.</div>
     </div>
   </div>
 </div>
@@ -119,4 +119,4 @@ title: SGEMM Whitepaper
 
 - Repository executive summary: [README](https://github.com/LessUp/sgemm-optimization/blob/master/README.md)
 - Chinese repository entry: [README.zh-CN](https://github.com/LessUp/sgemm-optimization/blob/master/README.zh-CN.md)
-- Stable requirements: [OpenSpec project presentation spec](https://github.com/LessUp/sgemm-optimization/blob/master/openspec/specs/project-presentation/spec.md)
+- Build and validation guide: [CONTRIBUTING](https://github.com/LessUp/sgemm-optimization/blob/master/CONTRIBUTING.md)
diff --git a/docs/en/overview/getting-started.md b/docs/en/overview/getting-started.md
index 48563c1..94aede5 100644
--- a/docs/en/overview/getting-started.md
+++ b/docs/en/overview/getting-started.md
@@ -43,7 +43,7 @@ ctest --test-dir build
 | Environment | What to run |
 |-------------|-------------|
 | Local GPU machine | benchmark, runtime verification, `ctest` |
-| Hosted CI | formatting, docs tests/build, OpenSpec/repository checks, Pages |
+| Hosted CI | formatting, docs tests/build, Pages |
 
 This split is intentional: GitHub-hosted runners validate repository health, while performance and CUDA runtime correctness still require a real GPU machine.
 
diff --git a/docs/en/research/references.md b/docs/en/research/references.md
index 2e970ce..3cd2c51 100644
--- a/docs/en/research/references.md
+++ b/docs/en/research/references.md
@@ -92,8 +92,8 @@ Open this shelf when the question is about proving correctness, structuring buil
   Best for understanding the local correctness harness and tolerance-oriented testing vocabulary.
 - [CMake Documentation](https://cmake.org/documentation/)  
   Best for build-system expectations, generator behavior, and reproducible local setup.
-- [OpenSpec documentation](https://openspec.dev/)  
-  Best for understanding the spec-governed documentation and change workflow used in this repository.
+- [GitHub Actions Documentation](https://docs.github.com/actions)  
+  Best for understanding the hosted automation surfaces that keep formatting, docs checks, and Pages deployment reproducible.
 
 Why this shelf matters:
 
diff --git a/docs/en/validation/index.md b/docs/en/validation/index.md
index e4b3a53..b62ee81 100644
--- a/docs/en/validation/index.md
+++ b/docs/en/validation/index.md
@@ -12,7 +12,7 @@ Optimization methodology answers: "how do we improve performance?" Validation an
 
 | Evidence surface | What it proves | What it does not prove |
 |---|---|---|
-| Hosted CI + local structural checks | Docs/spec structure, Pages fitness, formatting/governance workflows, and repository health checks | GPU runtime correctness, CUDA benchmark numbers, or hardware-specific speedups |
+| Hosted CI + local structural checks | Docs structure, Pages fitness, formatting checks, and repository health checks | GPU runtime correctness, CUDA benchmark numbers, or hardware-specific speedups |
 | Local `ctest --test-dir build` on a GPU machine | Runtime correctness against the project's cuBLAS oracle, under the project's numerical tolerance policy | Universal performance claims or GPU model independence |
 | Local benchmark execution | Performance behavior on a named GPU, under a named command and scope label | Results on other GPUs, other CUDA stacks, or unlabeled workloads |
 
@@ -28,7 +28,7 @@ Optimization methodology answers: "how do we improve performance?" Validation an
 
 ## What hosted CI proves
 
-Hosted CI is trusted to prove repository health: documentation structure, Pages buildability, formatting checks, and OpenSpec/governance alignment. It keeps the public surface coherent.
+Hosted CI is trusted to prove repository health: documentation structure, Pages buildability, formatting checks, and docs test/build health. It keeps the public surface coherent.
 
 Hosted CI is **not** trusted to prove CUDA runtime behavior or benchmark performance. Those claims require a real GPU machine.
 
@@ -67,7 +67,7 @@ Most trustworthy
   │
   ▼  [Local GPU] cuBLAS oracle + ctest correctness suite
   ▼  [Local GPU] Benchmark with named hardware, shape, and label
-  ▼  [Hosted CI] Structure, docs, build, and governance checks
+  ▼  [Hosted CI] Structure, docs, and workflow checks
   ▼  [Analytical] Performance model (roofline, cost model)
   ▼  [Qualitative] Architecture rationale and design arguments
   │
diff --git a/docs/package-lock.json b/docs/package-lock.json
index aa2b393..34ea30c 100644
--- a/docs/package-lock.json
+++ b/docs/package-lock.json
@@ -6,12 +6,12 @@
   "packages": {
     "": {
       "name": "sgemm-optimization-docs",
-      "version": "1.0.0",
       "dependencies": {
         "mermaid": "^11.12.2",
-        "vitepress": "^1.5.0",
-        "vitepress-plugin-llms": "^1.10.0",
         "vitepress-plugin-mermaid": "^2.0.17"
+      },
+      "devDependencies": {
+        "vitepress": "^1.6.4"
       }
     },
     "node_modules/@algolia/abtesting": {
@@ -1462,15 +1462,6 @@
         "@types/d3-selection": "*"
       }
     },
-    "node_modules/@types/debug": {
-      "version": "4.1.13",
-      "resolved": "https://registry.npmjs.org/@types/debug/-/debug-4.1.13.tgz",
-      "integrity": "sha512-KSVgmQmzMwPlmtljOomayoR89W4FynCAi3E8PPs7vmDVPe84hT+vGPKkJfThkmXs0x0jAaa9U8uW8bbfyS2fWw==",
-      "license": "MIT",
-      "dependencies": {
-        "@types/ms": "*"
-      }
-    },
     "node_modules/@types/estree": {
       "version": "1.0.8",
       "resolved": "https://registry.npmjs.org/@types/estree/-/estree-1.0.8.tgz",
@@ -1523,12 +1514,6 @@
       "integrity": "sha512-RGdgjQUZba5p6QEFAVx2OGb8rQDL/cPRG7GiedRzMcJ1tYnUANBncjbSB1NRGwbvjcPeikRABz2nshyPk1bhWg==",
       "license": "MIT"
     },
-    "node_modules/@types/ms": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/@types/ms/-/ms-2.1.0.tgz",
-      "integrity": "sha512-GsCCIZDE/p3i96vtEqx+7dBUGXrc7zeSK3wwPHIaRThS+9OhWIXRqzs4d6k1SVU8g91DrNRWxWUGhp5KXQb2VA==",
-      "license": "MIT"
-    },
     "node_modules/@types/trusted-types": {
       "version": "2.0.7",
       "resolved": "https://registry.npmjs.org/@types/trusted-types/-/trusted-types-2.0.7.tgz",
@@ -1849,58 +1834,6 @@
         "node": ">= 14.0.0"
       }
     },
-    "node_modules/ansi-regex": {
-      "version": "5.0.1",
-      "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
-      "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/ansi-styles": {
-      "version": "4.3.0",
-      "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz",
-      "integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==",
-      "license": "MIT",
-      "dependencies": {
-        "color-convert": "^2.0.1"
-      },
-      "engines": {
-        "node": ">=8"
-      },
-      "funding": {
-        "url": "https://github.com/chalk/ansi-styles?sponsor=1"
-      }
-    },
-    "node_modules/argparse": {
-      "version": "1.0.10",
-      "resolved": "https://registry.npmjs.org/argparse/-/argparse-1.0.10.tgz",
-      "integrity": "sha512-o5Roy6tNG4SL/FOkCAN6RzjiakZS25RLYFrcMttJqbdd8BWrnA+fGz57iN5Pb06pvBGvl5gQ0B48dJlslXvoTg==",
-      "license": "MIT",
-      "dependencies": {
-        "sprintf-js": "~1.0.2"
-      }
-    },
-    "node_modules/bail": {
-      "version": "2.0.2",
-      "resolved": "https://registry.npmjs.org/bail/-/bail-2.0.2.tgz",
-      "integrity": "sha512-0xO6mYd7JB2YesxDKplafRpsiOzPt9V02ddPCLbY1xYGPOX24NTyN50qnUxgCPcSoYMhKpAuBTjQoRZCAkUDRw==",
-      "license": "MIT",
-      "funding": {
-        "type": "github",
-        "url": "https://github.com/sponsors/wooorm"
-      }
-    },
-    "node_modules/balanced-match": {
-      "version": "4.0.4",
-      "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-4.0.4.tgz",
-      "integrity": "sha512-BLrgEcRTwX2o6gGxGOCNyMvGSp35YofuYzw9h1IMTRmKqttAZZVU67bdb9Pr2vUHA8+j3i2tJfjO6C6+4myGTA==",
-      "license": "MIT",
-      "engines": {
-        "node": "18 || 20 || >=22"
-      }
-    },
     "node_modules/birpc": {
       "version": "2.9.0",
       "resolved": "https://registry.npmjs.org/birpc/-/birpc-2.9.0.tgz",
@@ -1910,18 +1843,6 @@
         "url": "https://github.com/sponsors/antfu"
       }
     },
-    "node_modules/brace-expansion": {
-      "version": "5.0.6",
-      "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-5.0.6.tgz",
-      "integrity": "sha512-kLpxurY4Z4r9sgMsyG0Z9uzsBlgiU/EFKhj/h91/8yHu0edo7XuixOIH3VcJ8kkxs6/jPzoI6U9Vj3WqbMQ94g==",
-      "license": "MIT",
-      "dependencies": {
-        "balanced-match": "^4.0.2"
-      },
-      "engines": {
-        "node": "18 || 20 || >=22"
-      }
-    },
     "node_modules/ccount": {
       "version": "2.0.1",
       "resolved": "https://registry.npmjs.org/ccount/-/ccount-2.0.1.tgz",
@@ -1932,16 +1853,6 @@
         "url": "https://github.com/sponsors/wooorm"
       }
     },
-    "node_modules/character-entities": {
-      "version": "2.0.2",
-      "resolved": "https://registry.npmjs.org/character-entities/-/character-entities-2.0.2.tgz",
-      "integrity": "sha512-shx7oQ0Awen/BRIdkjkvz54PnEEI/EjwXDSIZp86/KKdbafHh1Df/RYGBhn4hbe2+uKC9FnT5UCEdyPz3ai9hQ==",
-      "license": "MIT",
-      "funding": {
-        "type": "github",
-        "url": "https://github.com/sponsors/wooorm"
-      }
-    },
     "node_modules/character-entities-html4": {
       "version": "2.1.0",
       "resolved": "https://registry.npmjs.org/character-entities-html4/-/character-entities-html4-2.1.0.tgz",
@@ -1962,38 +1873,6 @@
         "url": "https://github.com/sponsors/wooorm"
       }
     },
-    "node_modules/cliui": {
-      "version": "8.0.1",
-      "resolved": "https://registry.npmjs.org/cliui/-/cliui-8.0.1.tgz",
-      "integrity": "sha512-BSeNnyus75C4//NQ9gQt1/csTXyo/8Sb+afLAkzAptFuMsod9HFokGNudZpi/oQV73hnVK+sR+5PVRMd+Dr7YQ==",
-      "license": "ISC",
-      "dependencies": {
-        "string-width": "^4.2.0",
-        "strip-ansi": "^6.0.1",
-        "wrap-ansi": "^7.0.0"
-      },
-      "engines": {
-        "node": ">=12"
-      }
-    },
-    "node_modules/color-convert": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz",
-      "integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==",
-      "license": "MIT",
-      "dependencies": {
-        "color-name": "~1.1.4"
-      },
-      "engines": {
-        "node": ">=7.0.0"
-      }
-    },
-    "node_modules/color-name": {
-      "version": "1.1.4",
-      "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.4.tgz",
-      "integrity": "sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==",
-      "license": "MIT"
-    },
     "node_modules/comma-separated-tokens": {
       "version": "2.0.3",
       "resolved": "https://registry.npmjs.org/comma-separated-tokens/-/comma-separated-tokens-2.0.3.tgz",
@@ -2548,36 +2427,6 @@
       "integrity": "sha512-YbwwqR/uYpeoP4pu043q+LTDLFBLApUP6VxRihdfNTqu4ubqMlGDLd6ErXhEgsyvY0K6nCs7nggYumAN+9uEuQ==",
       "license": "MIT"
     },
-    "node_modules/debug": {
-      "version": "4.4.3",
-      "resolved": "https://registry.npmjs.org/debug/-/debug-4.4.3.tgz",
-      "integrity": "sha512-RGwwWnwQvkVfavKVt22FGLw+xYSdzARwm0ru6DhTVA3umU5hZc28V3kO4stgYryrTlLpuvgI9GiijltAjNbcqA==",
-      "license": "MIT",
-      "dependencies": {
-        "ms": "^2.1.3"
-      },
-      "engines": {
-        "node": ">=6.0"
-      },
-      "peerDependenciesMeta": {
-        "supports-color": {
-          "optional": true
-        }
-      }
-    },
-    "node_modules/decode-named-character-reference": {
-      "version": "1.3.0",
-      "resolved": "https://registry.npmjs.org/decode-named-character-reference/-/decode-named-character-reference-1.3.0.tgz",
-      "integrity": "sha512-GtpQYB283KrPp6nRw50q3U9/VfOutZOe103qlN7BPP6Ad27xYnOIWv4lPzo8HCAL+mMZofJ9KEy30fq6MfaK6Q==",
-      "license": "MIT",
-      "dependencies": {
-        "character-entities": "^2.0.0"
-      },
-      "funding": {
-        "type": "github",
-        "url": "https://github.com/sponsors/wooorm"
-      }
-    },
     "node_modules/delaunator": {
       "version": "5.1.0",
       "resolved": "https://registry.npmjs.org/delaunator/-/delaunator-5.1.0.tgz",
@@ -2618,30 +2467,12 @@
         "@types/trusted-types": "^2.0.7"
       }
     },
-    "node_modules/emoji-regex": {
-      "version": "8.0.0",
-      "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz",
-      "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==",
-      "license": "MIT"
-    },
     "node_modules/emoji-regex-xs": {
       "version": "1.0.0",
       "resolved": "https://registry.npmjs.org/emoji-regex-xs/-/emoji-regex-xs-1.0.0.tgz",
       "integrity": "sha512-LRlerrMYoIDrT6jgpeZ2YYl/L8EulRTt5hQcYjy5AInh7HWXKimpqx68aknBFpGL2+/IcogTcaydJEgaTmOpDg==",
       "license": "MIT"
     },
-    "node_modules/entities": {
-      "version": "4.5.0",
-      "resolved": "https://registry.npmjs.org/entities/-/entities-4.5.0.tgz",
-      "integrity": "sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==",
-      "license": "BSD-2-Clause",
-      "engines": {
-        "node": ">=0.12"
-      },
-      "funding": {
-        "url": "https://github.com/fb55/entities?sponsor=1"
-      }
-    },
     "node_modules/es-toolkit": {
       "version": "1.46.1",
       "resolved": "https://registry.npmjs.org/es-toolkit/-/es-toolkit-1.46.1.tgz",
@@ -2690,77 +2521,12 @@
         "@esbuild/win32-x64": "0.21.5"
       }
     },
-    "node_modules/escalade": {
-      "version": "3.2.0",
-      "resolved": "https://registry.npmjs.org/escalade/-/escalade-3.2.0.tgz",
-      "integrity": "sha512-WUj2qlxaQtO4g6Pq5c29GTcWGDyd8itL8zTlipgECz3JesAiiOKotd8JU6otB3PACgG6xkJUyVhboMS+bje/jA==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=6"
-      }
-    },
-    "node_modules/escape-string-regexp": {
-      "version": "5.0.0",
-      "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-5.0.0.tgz",
-      "integrity": "sha512-/veY75JbMK4j1yjvuUxuVsiS/hr/4iHs9FTT6cgTexxdE0Ly/glccBAkloH/DofkjRbZU3bnoj38mOmhkZ0lHw==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=12"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
-      }
-    },
-    "node_modules/esprima": {
-      "version": "4.0.1",
-      "resolved": "https://registry.npmjs.org/esprima/-/esprima-4.0.1.tgz",
-      "integrity": "sha512-eGuFFw7Upda+g4p+QHvnW0RyTX/SVeJBDM/gCtMARO0cLuT2HcEKnTPvhjV6aGeqrCB/sbNop0Kszm0jsaWU4A==",
-      "license": "BSD-2-Clause",
-      "bin": {
-        "esparse": "bin/esparse.js",
-        "esvalidate": "bin/esvalidate.js"
-      },
-      "engines": {
-        "node": ">=4"
-      }
-    },
     "node_modules/estree-walker": {
       "version": "2.0.2",
       "resolved": "https://registry.npmjs.org/estree-walker/-/estree-walker-2.0.2.tgz",
       "integrity": "sha512-Rfkk/Mp/DL7JVje3u18FxFujQlTNR2q6QfMSMB7AvCBx91NGj/ba3kCfza0f6dVDbw7YlRf/nDrn7pQrCCyQ/w==",
       "license": "MIT"
     },
-    "node_modules/extend": {
-      "version": "3.0.2",
-      "resolved": "https://registry.npmjs.org/extend/-/extend-3.0.2.tgz",
-      "integrity": "sha512-fjquC59cD7CyW6urNXK0FBufkZcoiGG80wTuPujX590cB5Ttln20E2UB4S/WARVqhXffZl2LNgS+gQdPIIim/g==",
-      "license": "MIT"
-    },
-    "node_modules/extend-shallow": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/extend-shallow/-/extend-shallow-2.0.1.tgz",
-      "integrity": "sha512-zCnTtlxNoAiDc3gqY2aYAWFx7XWWiasuF2K8Me5WbN8otHKTUKBwjPtNpRs/rbUZm7KxWAaNj7P1a/p52GbVug==",
-      "license": "MIT",
-      "dependencies": {
-        "is-extendable": "^0.1.0"
-      },
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
-    "node_modules/fault": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/fault/-/fault-2.0.1.tgz",
-      "integrity": "sha512-WtySTkS4OKev5JtpHXnib4Gxiurzh5NCGvWrFaZ34m6JehfTUhKZvn9njTfw48t6JumVQOmrKqpmGcdwxnhqBQ==",
-      "license": "MIT",
-      "dependencies": {
-        "format": "^0.2.0"
-      },
-      "funding": {
-        "type": "github",
-        "url": "https://github.com/sponsors/wooorm"
-      }
-    },
     "node_modules/focus-trap": {
       "version": "7.8.0",
       "resolved": "https://registry.npmjs.org/focus-trap/-/focus-trap-7.8.0.tgz",
@@ -2770,14 +2536,6 @@
         "tabbable": "^6.4.0"
       }
     },
-    "node_modules/format": {
-      "version": "0.2.2",
-      "resolved": "https://registry.npmjs.org/format/-/format-0.2.2.tgz",
-      "integrity": "sha512-wzsgA6WOq+09wrU1tsJ09udeR/YZRaeArL9e1wPbFg3GG2yDnC2ldKpxs4xunpFF9DgqCqOIra3bc1HWrJ37Ww==",
-      "engines": {
-        "node": ">=0.4.x"
-      }
-    },
     "node_modules/fsevents": {
       "version": "2.3.3",
       "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.3.3.tgz",
@@ -2792,30 +2550,6 @@
         "node": "^8.16.0 || ^10.6.0 || >=11.0.0"
       }
     },
-    "node_modules/get-caller-file": {
-      "version": "2.0.5",
-      "resolved": "https://registry.npmjs.org/get-caller-file/-/get-caller-file-2.0.5.tgz",
-      "integrity": "sha512-DyFP3BM/3YHTQOCUL/w0OZHR0lpKeGrxotcHWcqNEdnltqFwXVfhEBQ94eIo34AfQpo0rGki4cyIiftY06h2Fg==",
-      "license": "ISC",
-      "engines": {
-        "node": "6.* || 8.* || >= 10.*"
-      }
-    },
-    "node_modules/gray-matter": {
-      "version": "4.0.3",
-      "resolved": "https://registry.npmjs.org/gray-matter/-/gray-matter-4.0.3.tgz",
-      "integrity": "sha512-5v6yZd4JK3eMI3FqqCouswVqwugaA9r4dNZB1wwcmrD02QkV5H0y7XBQW8QwQqEaZY1pM9aqORSORhJRdNK44Q==",
-      "license": "MIT",
-      "dependencies": {
-        "js-yaml": "^3.13.1",
-        "kind-of": "^6.0.2",
-        "section-matter": "^1.0.0",
-        "strip-bom-string": "^1.0.0"
-      },
-      "engines": {
-        "node": ">=6.0"
-      }
-    },
     "node_modules/hachure-fill": {
       "version": "0.5.2",
       "resolved": "https://registry.npmjs.org/hachure-fill/-/hachure-fill-0.5.2.tgz",
@@ -2905,36 +2639,6 @@
         "node": ">=12"
       }
     },
-    "node_modules/is-extendable": {
-      "version": "0.1.1",
-      "resolved": "https://registry.npmjs.org/is-extendable/-/is-extendable-0.1.1.tgz",
-      "integrity": "sha512-5BMULNob1vgFX6EjQw5izWDxrecWK9AM72rugNr0TFldMOi0fj6Jk+zeKIt0xGj4cEfQIJth4w3OKWOJ4f+AFw==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
-    "node_modules/is-fullwidth-code-point": {
-      "version": "3.0.0",
-      "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz",
-      "integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/is-plain-obj": {
-      "version": "4.1.0",
-      "resolved": "https://registry.npmjs.org/is-plain-obj/-/is-plain-obj-4.1.0.tgz",
-      "integrity": "sha512-+Pgi+vMuUNkJyExiMBt5IlFoMyKnr5zhJ4Uspz58WOhBF5QoIZkFyNHIbBAtHwzVAgk5RtndVNsDRN61/mmDqg==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=12"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
-      }
-    },
     "node_modules/is-what": {
       "version": "5.5.0",
       "resolved": "https://registry.npmjs.org/is-what/-/is-what-5.5.0.tgz",
@@ -2947,19 +2651,6 @@
         "url": "https://github.com/sponsors/mesqueeb"
       }
     },
-    "node_modules/js-yaml": {
-      "version": "3.14.2",
-      "resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-3.14.2.tgz",
-      "integrity": "sha512-PMSmkqxr106Xa156c2M265Z+FTrPl+oxd/rgOQy2tijQeK5TxQ43psO1ZCwhVOSdnn+RzkzlRz/eY4BgJBYVpg==",
-      "license": "MIT",
-      "dependencies": {
-        "argparse": "^1.0.7",
-        "esprima": "^4.0.0"
-      },
-      "bin": {
-        "js-yaml": "bin/js-yaml.js"
-      }
-    },
     "node_modules/katex": {
       "version": "0.16.45",
       "resolved": "https://registry.npmjs.org/katex/-/katex-0.16.45.tgz",
@@ -2990,46 +2681,18 @@
       "resolved": "https://registry.npmjs.org/khroma/-/khroma-2.1.0.tgz",
       "integrity": "sha512-Ls993zuzfayK269Svk9hzpeGUKob/sIgZzyHYdjQoAdQetRKpOLj+k/QQQ/6Qi0Yz65mlROrfd+Ev+1+7dz9Kw=="
     },
-    "node_modules/kind-of": {
-      "version": "6.0.3",
-      "resolved": "https://registry.npmjs.org/kind-of/-/kind-of-6.0.3.tgz",
-      "integrity": "sha512-dcS1ul+9tmeD95T+x28/ehLgd9mENa3LsvDTtzm3vyBEO7RPptvAD+t44WVXaUjTBRcrpFeFlC8WCruUR456hw==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
     "node_modules/layout-base": {
       "version": "1.0.2",
       "resolved": "https://registry.npmjs.org/layout-base/-/layout-base-1.0.2.tgz",
       "integrity": "sha512-8h2oVEZNktL4BH2JCOI90iD1yXwL6iNW7KcCKT2QZgQJR2vbqDsldCTPRU9NifTCqHZci57XvQQ15YTu+sTYPg==",
       "license": "MIT"
     },
-    "node_modules/linkify-it": {
-      "version": "5.0.0",
-      "resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-5.0.0.tgz",
-      "integrity": "sha512-5aHCbzQRADcdP+ATqnDuhhJ/MRIqDkZX5pyjFHRRysS8vZ5AbqGEoFIb6pYHPZ+L/OC2Lc+xT8uHVVR5CAK/wQ==",
-      "license": "MIT",
-      "dependencies": {
-        "uc.micro": "^2.0.0"
-      }
-    },
     "node_modules/lodash-es": {
       "version": "4.18.1",
       "resolved": "https://registry.npmjs.org/lodash-es/-/lodash-es-4.18.1.tgz",
       "integrity": "sha512-J8xewKD/Gk22OZbhpOVSwcs60zhd95ESDwezOFuA3/099925PdHJ7OFHNTGtajL3AlZkykD32HykiMo+BIBI8A==",
       "license": "MIT"
     },
-    "node_modules/longest-streak": {
-      "version": "3.1.0",
-      "resolved": "https://registry.npmjs.org/longest-streak/-/longest-streak-3.1.0.tgz",
-      "integrity": "sha512-9Ri+o0JYgehTaVBBDoMqIl8GXtbWg711O3srftcHhZ0dqnETqLaoIK0x17fUw9rFSlK/0NlsKe0Ahhyl5pXE2g==",
-      "license": "MIT",
-      "funding": {
-        "type": "github",
-        "url": "https://github.com/sponsors/wooorm"
-      }
-    },
     "node_modules/magic-string": {
       "version": "0.30.21",
       "resolved": "https://registry.npmjs.org/magic-string/-/magic-string-0.30.21.tgz",
@@ -3045,38 +2708,6 @@
       "integrity": "sha512-1I+1qpDt4idfgLQG+BNWmrqku+7/2bi5nLf4YwF8y8zXvmfiTBY3PV3ZibfrjBueCByROpuBjLLFCajqkgYoLQ==",
       "license": "MIT"
     },
-    "node_modules/markdown-it": {
-      "version": "14.1.1",
-      "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-14.1.1.tgz",
-      "integrity": "sha512-BuU2qnTti9YKgK5N+IeMubp14ZUKUUw7yeJbkjtosvHiP0AZ5c8IAgEMk79D0eC8F23r4Ac/q8cAIFdm2FtyoA==",
-      "license": "MIT",
-      "dependencies": {
-        "argparse": "^2.0.1",
-        "entities": "^4.4.0",
-        "linkify-it": "^5.0.0",
-        "mdurl": "^2.0.0",
-        "punycode.js": "^2.3.1",
-        "uc.micro": "^2.1.0"
-      },
-      "bin": {
-        "markdown-it": "bin/markdown-it.mjs"
-      }
-    },
-    "node_modules/markdown-it/node_modules/argparse": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
-      "integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==",
-      "license": "Python-2.0"
-    },
-    "node_modules/markdown-title": {
-      "version": "1.0.2",
-      "resolved": "https://registry.npmjs.org/markdown-title/-/markdown-title-1.0.2.tgz",
-      "integrity": "sha512-MqIQVVkz+uGEHi3TsHx/czcxxCbRIL7sv5K5DnYw/tI+apY54IbPefV/cmgxp6LoJSEx/TqcHdLs/298afG5QQ==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=6"
-      }
-    },
     "node_modules/marked": {
       "version": "16.4.2",
       "resolved": "https://registry.npmjs.org/marked/-/marked-16.4.2.tgz",
@@ -3089,62 +2720,6 @@
         "node": ">= 20"
       }
     },
-    "node_modules/mdast-util-from-markdown": {
-      "version": "2.0.3",
-      "resolved": "https://registry.npmjs.org/mdast-util-from-markdown/-/mdast-util-from-markdown-2.0.3.tgz",
-      "integrity": "sha512-W4mAWTvSlKvf8L6J+VN9yLSqQ9AOAAvHuoDAmPkz4dHf553m5gVj2ejadHJhoJmcmxEnOv6Pa8XJhpxE93kb8Q==",
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0",
-        "@types/unist": "^3.0.0",
-        "decode-named-character-reference": "^1.0.0",
-        "devlop": "^1.0.0",
-        "mdast-util-to-string": "^4.0.0",
-        "micromark": "^4.0.0",
-        "micromark-util-decode-numeric-character-reference": "^2.0.0",
-        "micromark-util-decode-string": "^2.0.0",
-        "micromark-util-normalize-identifier": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0",
-        "unist-util-stringify-position": "^4.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/mdast-util-frontmatter": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/mdast-util-frontmatter/-/mdast-util-frontmatter-2.0.1.tgz",
-      "integrity": "sha512-LRqI9+wdgC25P0URIJY9vwocIzCcksduHQ9OF2joxQoyTNVduwLAFUzjoopuRJbJAReaKrNQKAZKL3uCMugWJA==",
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0",
-        "devlop": "^1.0.0",
-        "escape-string-regexp": "^5.0.0",
-        "mdast-util-from-markdown": "^2.0.0",
-        "mdast-util-to-markdown": "^2.0.0",
-        "micromark-extension-frontmatter": "^2.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/mdast-util-phrasing": {
-      "version": "4.1.0",
-      "resolved": "https://registry.npmjs.org/mdast-util-phrasing/-/mdast-util-phrasing-4.1.0.tgz",
-      "integrity": "sha512-TqICwyvJJpBwvGAMZjj4J2n0X8QWp21b9l0o7eXyVJ25YNWYbJDVIyD1bZXE6WtV6RmKJVYmQAKWa0zWOABz2w==",
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0",
-        "unist-util-is": "^6.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
     "node_modules/mdast-util-to-hast": {
       "version": "13.2.1",
       "resolved": "https://registry.npmjs.org/mdast-util-to-hast/-/mdast-util-to-hast-13.2.1.tgz",
@@ -3166,50 +2741,10 @@
         "url": "https://opencollective.com/unified"
       }
     },
-    "node_modules/mdast-util-to-markdown": {
-      "version": "2.1.2",
-      "resolved": "https://registry.npmjs.org/mdast-util-to-markdown/-/mdast-util-to-markdown-2.1.2.tgz",
-      "integrity": "sha512-xj68wMTvGXVOKonmog6LwyJKrYXZPvlwabaryTjLh9LuvovB/KAH+kvi8Gjj+7rJjsFi23nkUxRQv1KqSroMqA==",
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0",
-        "@types/unist": "^3.0.0",
-        "longest-streak": "^3.0.0",
-        "mdast-util-phrasing": "^4.0.0",
-        "mdast-util-to-string": "^4.0.0",
-        "micromark-util-classify-character": "^2.0.0",
-        "micromark-util-decode-string": "^2.0.0",
-        "unist-util-visit": "^5.0.0",
-        "zwitch": "^2.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/mdast-util-to-string": {
-      "version": "4.0.0",
-      "resolved": "https://registry.npmjs.org/mdast-util-to-string/-/mdast-util-to-string-4.0.0.tgz",
-      "integrity": "sha512-0H44vDimn51F0YwvxSJSm0eCDOJTRlmN0R1yBh4HLj9wiV1Dn0QoXGbvFAWj2hSItVTlCmBF1hqKlIyUBVFLPg==",
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/mdurl": {
-      "version": "2.0.0",
-      "resolved": "https://registry.npmjs.org/mdurl/-/mdurl-2.0.0.tgz",
-      "integrity": "sha512-Lf+9+2r+Tdp5wXDXC4PcIBjTDtq4UKjCPMQhKIuzpJNW0b96kVqSwW0bT7FhRSfmAiFYgP+SCRvdrDozfh0U5w==",
-      "license": "MIT"
-    },
-    "node_modules/mermaid": {
-      "version": "11.15.0",
-      "resolved": "https://registry.npmjs.org/mermaid/-/mermaid-11.15.0.tgz",
-      "integrity": "sha512-pTMbcf3rWdtLiYGpmoTjHEpeY8seiy6sR+9nD7LOs8KfUbHE4lOUAprTRqRAcWSQ6MQpdX+YEsxShtGsINtPtw==",
+    "node_modules/mermaid": {
+      "version": "11.15.0",
+      "resolved": "https://registry.npmjs.org/mermaid/-/mermaid-11.15.0.tgz",
+      "integrity": "sha512-pTMbcf3rWdtLiYGpmoTjHEpeY8seiy6sR+9nD7LOs8KfUbHE4lOUAprTRqRAcWSQ6MQpdX+YEsxShtGsINtPtw==",
       "license": "MIT",
       "dependencies": {
         "@braintree/sanitize-url": "^7.1.1",
@@ -3235,198 +2770,6 @@
         "uuid": "^11.1.0 || ^12 || ^13 || ^14.0.0"
       }
     },
-    "node_modules/micromark": {
-      "version": "4.0.2",
-      "resolved": "https://registry.npmjs.org/micromark/-/micromark-4.0.2.tgz",
-      "integrity": "sha512-zpe98Q6kvavpCr1NPVSCMebCKfD7CA2NqZ+rykeNhONIJBpc1tFKt9hucLGwha3jNTNI8lHpctWJWoimVF4PfA==",
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "@types/debug": "^4.0.0",
-        "debug": "^4.0.0",
-        "decode-named-character-reference": "^1.0.0",
-        "devlop": "^1.0.0",
-        "micromark-core-commonmark": "^2.0.0",
-        "micromark-factory-space": "^2.0.0",
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-chunked": "^2.0.0",
-        "micromark-util-combine-extensions": "^2.0.0",
-        "micromark-util-decode-numeric-character-reference": "^2.0.0",
-        "micromark-util-encode": "^2.0.0",
-        "micromark-util-normalize-identifier": "^2.0.0",
-        "micromark-util-resolve-all": "^2.0.0",
-        "micromark-util-sanitize-uri": "^2.0.0",
-        "micromark-util-subtokenize": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-core-commonmark": {
-      "version": "2.0.3",
-      "resolved": "https://registry.npmjs.org/micromark-core-commonmark/-/micromark-core-commonmark-2.0.3.tgz",
-      "integrity": "sha512-RDBrHEMSxVFLg6xvnXmb1Ayr2WzLAWjeSATAoxwKYJV94TeNavgoIdA0a9ytzDSVzBy2YKFK+emCPOEibLeCrg==",
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "decode-named-character-reference": "^1.0.0",
-        "devlop": "^1.0.0",
-        "micromark-factory-destination": "^2.0.0",
-        "micromark-factory-label": "^2.0.0",
-        "micromark-factory-space": "^2.0.0",
-        "micromark-factory-title": "^2.0.0",
-        "micromark-factory-whitespace": "^2.0.0",
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-chunked": "^2.0.0",
-        "micromark-util-classify-character": "^2.0.0",
-        "micromark-util-html-tag-name": "^2.0.0",
-        "micromark-util-normalize-identifier": "^2.0.0",
-        "micromark-util-resolve-all": "^2.0.0",
-        "micromark-util-subtokenize": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-extension-frontmatter": {
-      "version": "2.0.0",
-      "resolved": "https://registry.npmjs.org/micromark-extension-frontmatter/-/micromark-extension-frontmatter-2.0.0.tgz",
-      "integrity": "sha512-C4AkuM3dA58cgZha7zVnuVxBhDsbttIMiytjgsM2XbHAB2faRVaHRle40558FBN+DJcrLNCoqG5mlrpdU4cRtg==",
-      "license": "MIT",
-      "dependencies": {
-        "fault": "^2.0.0",
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/micromark-factory-destination": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-factory-destination/-/micromark-factory-destination-2.0.1.tgz",
-      "integrity": "sha512-Xe6rDdJlkmbFRExpTOmRj9N3MaWmbAgdpSrBQvCFqhezUn4AHqJHbaEnfbVYYiexVSs//tqOdY/DxhjdCiJnIA==",
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-factory-label": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-factory-label/-/micromark-factory-label-2.0.1.tgz",
-      "integrity": "sha512-VFMekyQExqIW7xIChcXn4ok29YE3rnuyveW3wZQWWqF4Nv9Wk5rgJ99KzPvHjkmPXF93FXIbBp6YdW3t71/7Vg==",
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "devlop": "^1.0.0",
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-factory-space": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-factory-space/-/micromark-factory-space-2.0.1.tgz",
-      "integrity": "sha512-zRkxjtBxxLd2Sc0d+fbnEunsTj46SWXgXciZmHq0kDYGnck/ZSGj9/wULTV95uoeYiK5hRXP2mJ98Uo4cq/LQg==",
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-factory-title": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-factory-title/-/micromark-factory-title-2.0.1.tgz",
-      "integrity": "sha512-5bZ+3CjhAd9eChYTHsjy6TGxpOFSKgKKJPJxr293jTbfry2KDoWkhBb6TcPVB4NmzaPhMs1Frm9AZH7OD4Cjzw==",
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-factory-space": "^2.0.0",
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-factory-whitespace": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-factory-whitespace/-/micromark-factory-whitespace-2.0.1.tgz",
-      "integrity": "sha512-Ob0nuZ3PKt/n0hORHyvoD9uZhr+Za8sFoP+OnMcnWK5lngSzALgQYKMr9RJVOWLqQYuyn6ulqGWSXdwf6F80lQ==",
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-factory-space": "^2.0.0",
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
     "node_modules/micromark-util-character": {
       "version": "2.1.1",
       "resolved": "https://registry.npmjs.org/micromark-util-character/-/micromark-util-character-2.1.1.tgz",
@@ -3447,107 +2790,6 @@
         "micromark-util-types": "^2.0.0"
       }
     },
-    "node_modules/micromark-util-chunked": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-util-chunked/-/micromark-util-chunked-2.0.1.tgz",
-      "integrity": "sha512-QUNFEOPELfmvv+4xiNg2sRYeS/P84pTW0TCgP5zc9FpXetHY0ab7SxKyAQCNCc1eK0459uoLI1y5oO5Vc1dbhA==",
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-util-symbol": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-util-classify-character": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-util-classify-character/-/micromark-util-classify-character-2.0.1.tgz",
-      "integrity": "sha512-K0kHzM6afW/MbeWYWLjoHQv1sgg2Q9EccHEDzSkxiP/EaagNzCm7T/WMKZ3rjMbvIpvBiZgwR3dKMygtA4mG1Q==",
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-util-combine-extensions": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-util-combine-extensions/-/micromark-util-combine-extensions-2.0.1.tgz",
-      "integrity": "sha512-OnAnH8Ujmy59JcyZw8JSbK9cGpdVY44NKgSM7E9Eh7DiLS2E9RNQf0dONaGDzEG9yjEl5hcqeIsj4hfRkLH/Bg==",
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-util-chunked": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-util-decode-numeric-character-reference": {
-      "version": "2.0.2",
-      "resolved": "https://registry.npmjs.org/micromark-util-decode-numeric-character-reference/-/micromark-util-decode-numeric-character-reference-2.0.2.tgz",
-      "integrity": "sha512-ccUbYk6CwVdkmCQMyr64dXz42EfHGkPQlBj5p7YVGzq8I7CtjXZJrubAYezf7Rp+bjPseiROqe7G6foFd+lEuw==",
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-util-symbol": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-util-decode-string": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-util-decode-string/-/micromark-util-decode-string-2.0.1.tgz",
-      "integrity": "sha512-nDV/77Fj6eH1ynwscYTOsbK7rR//Uj0bZXBwJZRfaLEJ1iGBR6kIfNmlNqaqJf649EP0F3NWNdeJi03elllNUQ==",
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "decode-named-character-reference": "^1.0.0",
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-decode-numeric-character-reference": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0"
-      }
-    },
     "node_modules/micromark-util-encode": {
       "version": "2.0.1",
       "resolved": "https://registry.npmjs.org/micromark-util-encode/-/micromark-util-encode-2.0.1.tgz",
@@ -3564,60 +2806,6 @@
       ],
       "license": "MIT"
     },
-    "node_modules/micromark-util-html-tag-name": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-util-html-tag-name/-/micromark-util-html-tag-name-2.0.1.tgz",
-      "integrity": "sha512-2cNEiYDhCWKI+Gs9T0Tiysk136SnR13hhO8yW6BGNyhOC4qYFnwF1nKfD3HFAIXA5c45RrIG1ub11GiXeYd1xA==",
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT"
-    },
-    "node_modules/micromark-util-normalize-identifier": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-util-normalize-identifier/-/micromark-util-normalize-identifier-2.0.1.tgz",
-      "integrity": "sha512-sxPqmo70LyARJs0w2UclACPUUEqltCkJ6PhKdMIDuJ3gSf/Q+/GIe3WKl0Ijb/GyH9lOpUkRAO2wp0GVkLvS9Q==",
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-util-symbol": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-util-resolve-all": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-util-resolve-all/-/micromark-util-resolve-all-2.0.1.tgz",
-      "integrity": "sha512-VdQyxFWFT2/FGJgwQnJYbe1jjQoNTS4RjglmSjTUlpUMa95Htx9NHeYW4rGDJzbjvCsl9eLjMQwGeElsqmzcHg==",
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-util-types": "^2.0.0"
-      }
-    },
     "node_modules/micromark-util-sanitize-uri": {
       "version": "2.0.1",
       "resolved": "https://registry.npmjs.org/micromark-util-sanitize-uri/-/micromark-util-sanitize-uri-2.0.1.tgz",
@@ -3639,28 +2827,6 @@
         "micromark-util-symbol": "^2.0.0"
       }
     },
-    "node_modules/micromark-util-subtokenize": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/micromark-util-subtokenize/-/micromark-util-subtokenize-2.1.0.tgz",
-      "integrity": "sha512-XQLu552iSctvnEcgXw6+Sx75GflAPNED1qx7eBJ+wydBb2KCbRZe+NwvIEEMM83uml1+2WSXpBAcp9IUCgCYWA==",
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "devlop": "^1.0.0",
-        "micromark-util-chunked": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
     "node_modules/micromark-util-symbol": {
       "version": "2.0.1",
       "resolved": "https://registry.npmjs.org/micromark-util-symbol/-/micromark-util-symbol-2.0.1.tgz",
@@ -3693,33 +2859,6 @@
       ],
       "license": "MIT"
     },
-    "node_modules/millify": {
-      "version": "6.1.0",
-      "resolved": "https://registry.npmjs.org/millify/-/millify-6.1.0.tgz",
-      "integrity": "sha512-H/E3J6t+DQs/F2YgfDhxUVZz/dF8JXPPKTLHL/yHCcLZLtCXJDUaqvhJXQwqOVBvbyNn4T0WjLpIHd7PAw7fBA==",
-      "license": "MIT",
-      "dependencies": {
-        "yargs": "^17.0.1"
-      },
-      "bin": {
-        "millify": "bin/millify"
-      }
-    },
-    "node_modules/minimatch": {
-      "version": "10.2.5",
-      "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-10.2.5.tgz",
-      "integrity": "sha512-MULkVLfKGYDFYejP07QOurDLLQpcjk7Fw+7jXS2R2czRQzR56yHRveU5NDJEOviH+hETZKSkIk5c+T23GjFUMg==",
-      "license": "BlueOak-1.0.0",
-      "dependencies": {
-        "brace-expansion": "^5.0.5"
-      },
-      "engines": {
-        "node": "18 || 20 || >=22"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/isaacs"
-      }
-    },
     "node_modules/minisearch": {
       "version": "7.2.0",
       "resolved": "https://registry.npmjs.org/minisearch/-/minisearch-7.2.0.tgz",
@@ -3732,12 +2871,6 @@
       "integrity": "sha512-vKivATfr97l2/QBCYAkXYDbrIWPM2IIKEl7YPhjCvKlG3kE2gm+uBo6nEXK3M5/Ffh/FLpKExzOQ3JJoJGFKBw==",
       "license": "MIT"
     },
-    "node_modules/ms": {
-      "version": "2.1.3",
-      "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.3.tgz",
-      "integrity": "sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==",
-      "license": "MIT"
-    },
     "node_modules/nanoid": {
       "version": "3.3.12",
       "resolved": "https://registry.npmjs.org/nanoid/-/nanoid-3.3.12.tgz",
@@ -3786,12 +2919,6 @@
       "integrity": "sha512-NOnmBpt5Y2RWbuv0LMzsayp3lVylAHLPUTut412ZA3l+C4uw4ZVkQbjShYCQ8TCpUMdPapr4YjUqLYD6v68j+w==",
       "license": "MIT"
     },
-    "node_modules/path-to-regexp": {
-      "version": "6.3.0",
-      "resolved": "https://registry.npmjs.org/path-to-regexp/-/path-to-regexp-6.3.0.tgz",
-      "integrity": "sha512-Yhpw4T9C6hPpgPeA28us07OJeqZ5EzQTkbfwuhsUg0c237RomFoETJgmp2sa3F/41gfLE6G5cqcYwznmeEeOlQ==",
-      "license": "MIT"
-    },
     "node_modules/perfect-debounce": {
       "version": "1.0.0",
       "resolved": "https://registry.npmjs.org/perfect-debounce/-/perfect-debounce-1.0.0.tgz",
@@ -3858,18 +2985,6 @@
         "url": "https://opencollective.com/preact"
       }
     },
-    "node_modules/pretty-bytes": {
-      "version": "7.1.0",
-      "resolved": "https://registry.npmjs.org/pretty-bytes/-/pretty-bytes-7.1.0.tgz",
-      "integrity": "sha512-nODzvTiYVRGRqAOvE84Vk5JDPyyxsVk0/fbA/bq7RqlnhksGpset09XTxbpvLTIjoaF7K8Z8DG8yHtKGTPSYRw==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=20"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
-      }
-    },
     "node_modules/property-information": {
       "version": "7.1.0",
       "resolved": "https://registry.npmjs.org/property-information/-/property-information-7.1.0.tgz",
@@ -3880,15 +2995,6 @@
         "url": "https://github.com/sponsors/wooorm"
       }
     },
-    "node_modules/punycode.js": {
-      "version": "2.3.1",
-      "resolved": "https://registry.npmjs.org/punycode.js/-/punycode.js-2.3.1.tgz",
-      "integrity": "sha512-uxFIHU0YlHYhDQtV4R9J6a52SLx28BCjT+4ieh7IGbgwVJWO+km431c4yRlREUAsAmt/uMjQUyQHNEPf0M39CA==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=6"
-      }
-    },
     "node_modules/regex": {
       "version": "6.1.0",
       "resolved": "https://registry.npmjs.org/regex/-/regex-6.1.0.tgz",
@@ -3913,78 +3019,6 @@
       "integrity": "sha512-8VhliFJAWRaUiVvREIiW2NXXTmHs4vMNnSzuJVhscgmGav3g9VDxLrQndI3dZZVVdp0ZO/5v0xmX516/7M9cng==",
       "license": "MIT"
     },
-    "node_modules/remark": {
-      "version": "15.0.1",
-      "resolved": "https://registry.npmjs.org/remark/-/remark-15.0.1.tgz",
-      "integrity": "sha512-Eht5w30ruCXgFmxVUSlNWQ9iiimq07URKeFS3hNc8cUWy1llX4KDWfyEDZRycMc+znsN9Ux5/tJ/BFdgdOwA3A==",
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0",
-        "remark-parse": "^11.0.0",
-        "remark-stringify": "^11.0.0",
-        "unified": "^11.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/remark-frontmatter": {
-      "version": "5.0.0",
-      "resolved": "https://registry.npmjs.org/remark-frontmatter/-/remark-frontmatter-5.0.0.tgz",
-      "integrity": "sha512-XTFYvNASMe5iPN0719nPrdItC9aU0ssC4v14mH1BCi1u0n1gAocqcujWUrByftZTbLhRtiKRyjYTSIOcr69UVQ==",
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0",
-        "mdast-util-frontmatter": "^2.0.0",
-        "micromark-extension-frontmatter": "^2.0.0",
-        "unified": "^11.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/remark-parse": {
-      "version": "11.0.0",
-      "resolved": "https://registry.npmjs.org/remark-parse/-/remark-parse-11.0.0.tgz",
-      "integrity": "sha512-FCxlKLNGknS5ba/1lmpYijMUzX2esxW5xQqjWxw2eHFfS2MSdaHVINFmhjo+qN1WhZhNimq0dZATN9pH0IDrpA==",
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0",
-        "mdast-util-from-markdown": "^2.0.0",
-        "micromark-util-types": "^2.0.0",
-        "unified": "^11.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/remark-stringify": {
-      "version": "11.0.0",
-      "resolved": "https://registry.npmjs.org/remark-stringify/-/remark-stringify-11.0.0.tgz",
-      "integrity": "sha512-1OSmLd3awB/t8qdoEOMazZkNsfVTeY4fTsgzcQFdXNq8ToTN4ZGwrMnlda4K6smTFKD+GRV6O48i6Z4iKgPPpw==",
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0",
-        "mdast-util-to-markdown": "^2.0.0",
-        "unified": "^11.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/require-directory": {
-      "version": "2.1.1",
-      "resolved": "https://registry.npmjs.org/require-directory/-/require-directory-2.1.1.tgz",
-      "integrity": "sha512-fGxEI7+wsG9xrvdjsrlmL22OMTTiHRwAMroiEeMgq8gzoLC/PQr7RsRDSTLUg/bZAZtF+TVIkHc6/4RIKrui+Q==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
     "node_modules/rfdc": {
       "version": "1.4.1",
       "resolved": "https://registry.npmjs.org/rfdc/-/rfdc-1.4.1.tgz",
@@ -4072,19 +3106,6 @@
       "license": "MIT",
       "peer": true
     },
-    "node_modules/section-matter": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/section-matter/-/section-matter-1.0.0.tgz",
-      "integrity": "sha512-vfD3pmTzGpufjScBh50YHKzEu2lxBWhVEHsNGoEXmCmn2hKGfeNLYMzCJpe8cD7gqX7TJluOVpBkAequ6dgMmA==",
-      "license": "MIT",
-      "dependencies": {
-        "extend-shallow": "^2.0.1",
-        "kind-of": "^6.0.0"
-      },
-      "engines": {
-        "node": ">=4"
-      }
-    },
     "node_modules/shiki": {
       "version": "2.5.0",
       "resolved": "https://registry.npmjs.org/shiki/-/shiki-2.5.0.tgz",
@@ -4129,26 +3150,6 @@
         "node": ">=0.10.0"
       }
     },
-    "node_modules/sprintf-js": {
-      "version": "1.0.3",
-      "resolved": "https://registry.npmjs.org/sprintf-js/-/sprintf-js-1.0.3.tgz",
-      "integrity": "sha512-D9cPgkvLlV3t3IzL0D0YLvGA9Ahk4PcvVwUbN0dSGr1aP0Nrt4AEnTUbuGvquEC0mA64Gqt1fzirlRs5ibXx8g==",
-      "license": "BSD-3-Clause"
-    },
-    "node_modules/string-width": {
-      "version": "4.2.3",
-      "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz",
-      "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==",
-      "license": "MIT",
-      "dependencies": {
-        "emoji-regex": "^8.0.0",
-        "is-fullwidth-code-point": "^3.0.0",
-        "strip-ansi": "^6.0.1"
-      },
-      "engines": {
-        "node": ">=8"
-      }
-    },
     "node_modules/stringify-entities": {
       "version": "4.0.4",
       "resolved": "https://registry.npmjs.org/stringify-entities/-/stringify-entities-4.0.4.tgz",
@@ -4163,27 +3164,6 @@
         "url": "https://github.com/sponsors/wooorm"
       }
     },
-    "node_modules/strip-ansi": {
-      "version": "6.0.1",
-      "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
-      "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
-      "license": "MIT",
-      "dependencies": {
-        "ansi-regex": "^5.0.1"
-      },
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/strip-bom-string": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/strip-bom-string/-/strip-bom-string-1.0.0.tgz",
-      "integrity": "sha512-uCC2VHvQRYu+lMh4My/sFNmF2klFymLX1wHJeXnbEJERpV/ZsVuonzerjfrGpIGF7LBVa1O7i9kjiWvJiFck8g==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
     "node_modules/stylis": {
       "version": "4.4.0",
       "resolved": "https://registry.npmjs.org/stylis/-/stylis-4.4.0.tgz",
@@ -4217,12 +3197,6 @@
         "node": ">=18"
       }
     },
-    "node_modules/tokenx": {
-      "version": "1.3.0",
-      "resolved": "https://registry.npmjs.org/tokenx/-/tokenx-1.3.0.tgz",
-      "integrity": "sha512-NLdXTEZkKiO0gZuLtMoZKjCXTREXeZZt8nnnNeyoXtNZAfG/GKGSbQtLU5STspc0rMSwcA+UJfWZkbNU01iKmQ==",
-      "license": "MIT"
-    },
     "node_modules/trim-lines": {
       "version": "3.0.1",
       "resolved": "https://registry.npmjs.org/trim-lines/-/trim-lines-3.0.1.tgz",
@@ -4233,16 +3207,6 @@
         "url": "https://github.com/sponsors/wooorm"
       }
     },
-    "node_modules/trough": {
-      "version": "2.2.0",
-      "resolved": "https://registry.npmjs.org/trough/-/trough-2.2.0.tgz",
-      "integrity": "sha512-tmMpK00BjZiUyVyvrBK7knerNgmgvcV/KLVyuma/SC+TQN167GrMRciANTz09+k3zW8L8t60jWO1GpfkZdjTaw==",
-      "license": "MIT",
-      "funding": {
-        "type": "github",
-        "url": "https://github.com/sponsors/wooorm"
-      }
-    },
     "node_modules/ts-dedent": {
       "version": "2.2.0",
       "resolved": "https://registry.npmjs.org/ts-dedent/-/ts-dedent-2.2.0.tgz",
@@ -4252,31 +3216,6 @@
         "node": ">=6.10"
       }
     },
-    "node_modules/uc.micro": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/uc.micro/-/uc.micro-2.1.0.tgz",
-      "integrity": "sha512-ARDJmphmdvUk6Glw7y9DQ2bFkKBHwQHLi2lsaH6PPmz/Ka9sFOBsBluozhDltWmnv9u/cF6Rt87znRTPV+yp/A==",
-      "license": "MIT"
-    },
-    "node_modules/unified": {
-      "version": "11.0.5",
-      "resolved": "https://registry.npmjs.org/unified/-/unified-11.0.5.tgz",
-      "integrity": "sha512-xKvGhPWw3k84Qjh8bI3ZeJjqnyadK+GEFtazSfZv/rKeTkTjOJho6mFqh2SM96iIcZokxiOpg78GazTSg8+KHA==",
-      "license": "MIT",
-      "dependencies": {
-        "@types/unist": "^3.0.0",
-        "bail": "^2.0.0",
-        "devlop": "^1.0.0",
-        "extend": "^3.0.0",
-        "is-plain-obj": "^4.0.0",
-        "trough": "^2.0.0",
-        "vfile": "^6.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
     "node_modules/unist-util-is": {
       "version": "6.0.1",
       "resolved": "https://registry.npmjs.org/unist-util-is/-/unist-util-is-6.0.1.tgz",
@@ -4303,21 +3242,6 @@
         "url": "https://opencollective.com/unified"
       }
     },
-    "node_modules/unist-util-remove": {
-      "version": "4.0.0",
-      "resolved": "https://registry.npmjs.org/unist-util-remove/-/unist-util-remove-4.0.0.tgz",
-      "integrity": "sha512-b4gokeGId57UVRX/eVKej5gXqGlc9+trkORhFJpu9raqZkZhU0zm8Doi05+HaiBsMEIJowL+2WtQ5ItjsngPXg==",
-      "license": "MIT",
-      "dependencies": {
-        "@types/unist": "^3.0.0",
-        "unist-util-is": "^6.0.0",
-        "unist-util-visit-parents": "^6.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
     "node_modules/unist-util-stringify-position": {
       "version": "4.0.0",
       "resolved": "https://registry.npmjs.org/unist-util-stringify-position/-/unist-util-stringify-position-4.0.0.tgz",
@@ -4501,34 +3425,6 @@
         }
       }
     },
-    "node_modules/vitepress-plugin-llms": {
-      "version": "1.12.2",
-      "resolved": "https://registry.npmjs.org/vitepress-plugin-llms/-/vitepress-plugin-llms-1.12.2.tgz",
-      "integrity": "sha512-hdklo7di6E2/MwlYstH7R5QgdPHX+f5G/fp8QBq6MCiw4DWi3IOKMaous0S839FIGsPjK3QHwK6KcFwCf/XzjA==",
-      "license": "MIT",
-      "dependencies": {
-        "gray-matter": "^4.0.3",
-        "markdown-it": "^14.1.0",
-        "markdown-title": "^1.0.2",
-        "mdast-util-from-markdown": "^2.0.3",
-        "millify": "^6.1.0",
-        "minimatch": "^10.2.5",
-        "path-to-regexp": "^6.3.0",
-        "picocolors": "^1.1.1",
-        "pretty-bytes": "^7.1.0",
-        "remark": "^15.0.1",
-        "remark-frontmatter": "^5.0.0",
-        "tokenx": "^1.3.0",
-        "unist-util-remove": "^4.0.0",
-        "unist-util-visit": "^5.1.0"
-      },
-      "engines": {
-        "node": ">=18.0.0"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/okineadev"
-      }
-    },
     "node_modules/vitepress-plugin-mermaid": {
       "version": "2.0.17",
       "resolved": "https://registry.npmjs.org/vitepress-plugin-mermaid/-/vitepress-plugin-mermaid-2.0.17.tgz",
@@ -4563,59 +3459,6 @@
         }
       }
     },
-    "node_modules/wrap-ansi": {
-      "version": "7.0.0",
-      "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-7.0.0.tgz",
-      "integrity": "sha512-YVGIj2kamLSTxw6NsZjoBxfSwsn0ycdesmc4p+Q21c5zPuZ1pl+NfxVdxPtdHvmNVOQ6XSYG4AUtyt/Fi7D16Q==",
-      "license": "MIT",
-      "dependencies": {
-        "ansi-styles": "^4.0.0",
-        "string-width": "^4.1.0",
-        "strip-ansi": "^6.0.0"
-      },
-      "engines": {
-        "node": ">=10"
-      },
-      "funding": {
-        "url": "https://github.com/chalk/wrap-ansi?sponsor=1"
-      }
-    },
-    "node_modules/y18n": {
-      "version": "5.0.8",
-      "resolved": "https://registry.npmjs.org/y18n/-/y18n-5.0.8.tgz",
-      "integrity": "sha512-0pfFzegeDWJHJIAmTLRP2DwHjdF5s7jo9tuztdQxAhINCdvS+3nGINqPd00AphqJR/0LhANUS6/+7SCb98YOfA==",
-      "license": "ISC",
-      "engines": {
-        "node": ">=10"
-      }
-    },
-    "node_modules/yargs": {
-      "version": "17.7.2",
-      "resolved": "https://registry.npmjs.org/yargs/-/yargs-17.7.2.tgz",
-      "integrity": "sha512-7dSzzRQ++CKnNI/krKnYRV7JKKPUXMEh61soaHKg9mrWEhzFWhFnxPxGl+69cD1Ou63C13NUPCnmIcrvqCuM6w==",
-      "license": "MIT",
-      "dependencies": {
-        "cliui": "^8.0.1",
-        "escalade": "^3.1.1",
-        "get-caller-file": "^2.0.5",
-        "require-directory": "^2.1.1",
-        "string-width": "^4.2.3",
-        "y18n": "^5.0.5",
-        "yargs-parser": "^21.1.1"
-      },
-      "engines": {
-        "node": ">=12"
-      }
-    },
-    "node_modules/yargs-parser": {
-      "version": "21.1.1",
-      "resolved": "https://registry.npmjs.org/yargs-parser/-/yargs-parser-21.1.1.tgz",
-      "integrity": "sha512-tVpsJW7DdjecAiFpbIB1e3qxIQsE6NoPc5/eTdrbbIC4h0LVsWhnoa3g+m2HclBIujHzsxZ4VJVA+GUuc2/LBw==",
-      "license": "ISC",
-      "engines": {
-        "node": ">=12"
-      }
-    },
     "node_modules/zwitch": {
       "version": "2.0.4",
       "resolved": "https://registry.npmjs.org/zwitch/-/zwitch-2.0.4.tgz",
diff --git a/docs/package.json b/docs/package.json
index 629bb1f..bd3925a 100644
--- a/docs/package.json
+++ b/docs/package.json
@@ -12,8 +12,7 @@
     "vitepress": "^1.6.4"
   },
   "dependencies": {
-    "vitepress-plugin-mermaid": "^2.0.17",
     "mermaid": "^11.12.2",
-    "vitepress-plugin-llms": "^1.10.0"
+    "vitepress-plugin-mermaid": "^2.0.17"
   }
 }
diff --git a/docs/zh/academy/learning-path.md b/docs/zh/academy/learning-path.md
index a5da0c9..3d913f8 100644
--- a/docs/zh/academy/learning-path.md
+++ b/docs/zh/academy/learning-path.md
@@ -38,4 +38,4 @@ title: 学习路径
 
 - 确保环境符合 [快速上手](/zh/overview/getting-started)
 - 如需先了解仓库级地图，查看 [架构概览](/zh/architecture/)
-- 如需规范需求，参考 [规范索引](https://github.com/LessUp/sgemm-optimization/tree/master/openspec/specs/)
+- 如需仓库级约束与证据边界，配合阅读 [快速上手](/zh/overview/getting-started) 与 [验证](/zh/validation/)
diff --git a/docs/zh/architecture/system-blueprint.md b/docs/zh/architecture/system-blueprint.md
index e16e103..e96e353 100644
--- a/docs/zh/architecture/system-blueprint.md
+++ b/docs/zh/architecture/system-blueprint.md
@@ -87,7 +87,7 @@ Tensor Core 变体在提交 WMMA 计算之前检查设备能力和 shape 整除
 
 | 约束类别 | 可验证环境 |
 |---|---|
-| 文件结构、文档、OpenSpec 对齐 | 托管 CI |
+| 文件结构、文档与工作流健康度 | 托管 CI |
 | CUDA 代码在真实 CUDA 工具链上完成编译与运行 | 本地 GPU 机器 |
 | cuBLAS oracle 正确性 | 本地 GPU 运行 |
 | Benchmark 数字和加速比 | 带命名硬件的本地 GPU 运行 |
diff --git a/docs/zh/index.md b/docs/zh/index.md
index 286516f..05e8e23 100644
--- a/docs/zh/index.md
+++ b/docs/zh/index.md
@@ -46,7 +46,7 @@ title: SGEMM 白皮书
     <div class="signal-card">
       <div class="signal-title">信任模型</div>
       <div class="signal-value">CI 负责结构，GPU 负责证据</div>
-      <div class="signal-note">自动化负责仓库健康、Pages 构建与规范一致性，运行时正确性和性能仍然属于真实 GPU。</div>
+      <div class="signal-note">自动化负责仓库健康、文档检查与 Pages 构建，运行时正确性和性能仍然属于真实 GPU。</div>
     </div>
   </div>
 </div>
@@ -118,4 +118,4 @@ title: SGEMM 白皮书
 
 - 英文仓库摘要： [README](https://github.com/LessUp/sgemm-optimization/blob/master/README.md)
 - 中文仓库入口： [README.zh-CN](https://github.com/LessUp/sgemm-optimization/blob/master/README.zh-CN.md)
-- 稳定需求来源： [OpenSpec 项目呈现规范](https://github.com/LessUp/sgemm-optimization/blob/master/openspec/specs/project-presentation/spec.md)
+- 构建与验证说明： [CONTRIBUTING](https://github.com/LessUp/sgemm-optimization/blob/master/CONTRIBUTING.md)
diff --git a/docs/zh/overview/getting-started.md b/docs/zh/overview/getting-started.md
index 1d66774..c3bbc6e 100644
--- a/docs/zh/overview/getting-started.md
+++ b/docs/zh/overview/getting-started.md
@@ -43,7 +43,7 @@ ctest --test-dir build
 | 环境 | 运行什么 |
 |------|----------|
 | 本地 GPU 机器 | benchmark、运行时验证、`ctest` |
-| 托管 CI | 格式化、文档测试/构建、OpenSpec/仓库检查、Pages |
+| 托管 CI | 格式检查、文档测试/构建、Pages |
 
 这种划分是刻意的：GitHub 托管 runner 验证仓库健康，而性能和 CUDA 运行时正确性仍需真正的 GPU 机器。
 
diff --git a/docs/zh/research/references.md b/docs/zh/research/references.md
index f1dc0d7..af05c3a 100644
--- a/docs/zh/research/references.md
+++ b/docs/zh/research/references.md
@@ -92,8 +92,8 @@ title: 参考资料清单
   对理解本地正确性 harness 与容差测试话语体系最有帮助。
 - [CMake Documentation](https://cmake.org/documentation/)  
   对构建系统预期、generator 行为和可复现本地环境最有帮助。
-- [OpenSpec documentation](https://openspec.dev/)  
-  对理解本仓库采用的 spec 驱动文档与变更流程最有帮助。
+- [GitHub Actions Documentation](https://docs.github.com/actions)  
+  对理解托管自动化如何稳定执行格式检查、文档检查和 Pages 部署最有帮助。
 
 为什么这组重要：
 
diff --git a/docs/zh/validation/index.md b/docs/zh/validation/index.md
index 247754d..bccf96c 100644
--- a/docs/zh/validation/index.md
+++ b/docs/zh/validation/index.md
@@ -12,7 +12,7 @@ title: 验证
 
 | 证据层次 | 能证明什么 | 不能证明什么 |
 |---|---|---|
-| 托管 CI + 本地结构检查 | 文档与规范结构、Pages 可构建性、格式/治理工作流、仓库健康检查 | GPU 运行时正确性、CUDA benchmark 数字或特定硬件加速比 |
+| 托管 CI + 本地结构检查 | 文档结构、Pages 可构建性、格式检查与仓库健康检查 | GPU 运行时正确性、CUDA benchmark 数字或特定硬件加速比 |
 | GPU 机器上的本地 `ctest --test-dir build` | 在项目数值容差策略下，相对 cuBLAS oracle 的运行时正确性 | 普遍性的性能主张或 GPU 型号无关性 |
 | 本地 benchmark 执行 | 在命名 GPU 上、使用命名命令和范围标签下的性能行为 | 其他 GPU、其他 CUDA 版本，或无标签工作负载的结果 |
 
@@ -28,7 +28,7 @@ title: 验证
 
 ## 托管 CI 能证明什么
 
-托管 CI 被信任来证明仓库健康：文档结构、Pages 可构建性、格式检查以及 OpenSpec/治理对齐。它保持公共界面的一致性。
+托管 CI 被信任来证明仓库健康：文档结构、Pages 可构建性、格式检查以及文档测试/构建健康度。它保持公共界面的一致性。
 
 托管 CI **不被信任**来证明 CUDA 运行时行为或 benchmark 性能。这些主张需要真实的 GPU 机器。
 
@@ -67,7 +67,7 @@ title: 验证
   │
   ▼  [本地 GPU] cuBLAS oracle + ctest 正确性套件
   ▼  [本地 GPU] 带命名硬件、shape 和标签的 benchmark
-  ▼  [托管 CI] 结构、文档、构建与治理检查
+  ▼  [托管 CI] 结构、文档与工作流检查
   ▼  [分析性] 性能模型（roofline、代价模型）
   ▼  [定性] 架构原理与设计论证
   │
diff --git a/openspec/AGENTS.md b/openspec/AGENTS.md
deleted file mode 100644
index 31f7ad1..0000000
--- a/openspec/AGENTS.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# OpenSpec Agent Guide
-
-Use this file for **OpenSpec-specific** behavior in this repository. Generic project rules live in the root [`AGENTS.md`](../AGENTS.md).
-
-## Stable Capabilities
-
-The stable authoritative specs are:
-
-- `openspec/specs/kernel/spec.md`
-- `openspec/specs/architecture/spec.md`
-- `openspec/specs/testing/spec.md`
-- `openspec/specs/repository-governance/spec.md`
-- `openspec/specs/project-presentation/spec.md`
-
-Do not treat archived changes or old root-level spec references as normative.
-
-## Change Lifecycle
-
-```text
-explore -> propose -> apply -> review -> archive
-```
-
-1. Use `/opsx:explore` when scope, cleanup aggressiveness, or trade-offs are unclear.
-2. Use `/opsx:propose` for any repo-wide change affecting structure, docs, workflow, or quality gates.
-3. Use `/opsx:apply` to work tasks in dependency order.
-4. Use `/review` before major deletions, workflow simplification, or archive.
-5. Use `/opsx:archive` only after tasks, docs, specs, and validation are aligned.
-
-## Authoring Rules for This Repository
-
-### Proposal
-
-- Frame the change around repository outcomes, not generic process language.
-- Be explicit when the goal is consolidation, deletion, or archive-readiness.
-
-### Design
-
-- Capture why one authoritative source is chosen when duplicate systems exist.
-- Call out validation boundaries between local GPU checks and CI-safe checks.
-
-### Specs
-
-- Stable capability specs belong under `openspec/specs/<capability>/spec.md`.
-- Change deltas belong under `openspec/changes/<change>/specs/<capability>/spec.md`.
-- Use `ADDED`, `MODIFIED`, `REMOVED`, or `RENAMED` exactly.
-- Every requirement needs at least one `#### Scenario`.
-
-### Tasks
-
-- Group tasks by dependency and cleanup phase.
-- Use trackable checkboxes only: `- [ ]`.
-- Prefer tasks that can complete in one focused apply session.
-
-## Closeout Bias
-
-- Prefer deleting or merging low-value artifacts over preserving shells.
-- Prefer one longer apply session over `/fleet` unless the work is naturally parallel.
-- Keep the stable specs, README, Pages, and automation model synchronized at each major milestone.
diff --git a/openspec/README.md b/openspec/README.md
deleted file mode 100644
index ae86722..0000000
--- a/openspec/README.md
+++ /dev/null
@@ -1,64 +0,0 @@
-# OpenSpec Workflow for This Repository
-
-This repository is in a **closeout-oriented** phase: OpenSpec is used to keep structure, documentation, automation, and validation coherent while the project is being consolidated for long-term archival stability.
-
-## Authoritative Layout
-
-```text
-openspec/
-├── config.yaml
-├── specs/                    # Stable capability specs
-│   ├── architecture/spec.md
-│   ├── kernel/spec.md
-│   ├── project-presentation/spec.md
-│   ├── repository-governance/spec.md
-│   └── testing/spec.md
-├── changes/
-│   ├── <change>/
-│   │   ├── .openspec.yaml
-│   │   ├── proposal.md
-│   │   ├── design.md
-│   │   ├── tasks.md
-│   │   └── specs/<capability>/spec.md
-│   └── archive/
-└── AGENTS.md
-```
-
-- `openspec/specs/` is the **stable source of truth**
-- `openspec/changes/<change>/specs/` contains **delta specs for the active change**
-- Archived changes preserve reasoning; they are not the stable spec source
-
-## Default Command Flow
-
-| Stage | Command | Notes |
-|-------|---------|-------|
-| Explore | `/opsx:explore` | Clarify scope, risks, and trade-offs |
-| Propose | `/opsx:propose "description"` | Create proposal, design, tasks, and change-local specs |
-| Apply | `/opsx:apply` | Work tasks in order and update checkboxes immediately |
-| Review | `/review` | Recommended before large deletions, workflow changes, or archive |
-| Archive | `/opsx:archive` | Merge delta specs into stable specs once all tasks are complete |
-
-## Repository-Specific Expectations
-
-- Prefer **deletion or merge** over keeping redundant placeholder files.
-- Use OpenSpec for any non-trivial change affecting docs, workflow, validation, repo layout, or public positioning.
-- Prefer **one long-running apply/autopilot session** over frequent `/fleet` fan-out.
-- Keep README, Pages, governance docs, and stable specs aligned after any repo-wide cleanup.
-
-## Validation Baseline
-
-```bash
-openspec validate --all
-cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
-cmake --build build -j$(nproc)
-ctest --test-dir build
-```
-
-- Hosted CI is for formatting, compile-time validation, OpenSpec/repository checks, and Pages.
-- GPU runtime verification and benchmarking remain local-only unless a GPU-enabled runner is explicitly added.
-
-## References
-
-- Root contributor guidance: [`../AGENTS.md`](../AGENTS.md)
-- OpenSpec-specific agent guidance: [`AGENTS.md`](AGENTS.md)
-- Human-friendly spec index: [`../specs.md`](../specs.md)
diff --git a/openspec/changes/archive/0001-core-architecture/change.yaml b/openspec/changes/archive/0001-core-architecture/change.yaml
deleted file mode 100644
index 980e88a..0000000
--- a/openspec/changes/archive/0001-core-architecture/change.yaml
+++ /dev/null
@@ -1,6 +0,0 @@
-schema: spec-driven
-created: 2026-04-16
-archived: 2026-04-23
-status: archived
-title: Core Architecture
-description: Three-layer architecture with unified kernel interface
diff --git a/openspec/changes/archive/0001-core-architecture/design.md b/openspec/changes/archive/0001-core-architecture/design.md
deleted file mode 100644
index 7f6b770..0000000
--- a/openspec/changes/archive/0001-core-architecture/design.md
+++ /dev/null
@@ -1,82 +0,0 @@
-## Context
-
-The project serves as an educational and demonstrative implementation of core GPU optimization techniques in the HPC domain. The architecture must support five distinct kernel implementations while maintaining a clean, testable, and benchmarkable codebase.
-
-## Goals / Non-Goals
-
-### Goals
-- Support progressive optimization from naive to Tensor Core
-- Maintain consistent kernel interface across all implementations
-- Enable accurate performance benchmarking
-- Ensure numerical correctness verification
-
-### Non-Goals
-- Production-grade library (educational focus)
-- Multi-GPU support
-- Other GEMM variants (DGEMM, CGEMM)
-
-## Decisions
-
-### Three-Layer Architecture
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│                         main.cu                                  │
-│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐              │
-│  │  Benchmark  │  │   Verify    │  │  CLI Parser │              │
-│  └──────┬──────┘  └──────┬──────┘  └─────────────┘              │
-└─────────┼────────────────┼──────────────────────────────────────┘
-          │                │
-          ▼                ▼
-┌─────────────────────────────────────────────────────────────────┐
-│                    Kernel Implementations                        │
-│  ┌────────┐ ┌────────┐ ┌────────────┐ ┌─────────────┐ ┌───────┐ │
-│  │ Naive  │ │ Tiled  │ │ Bank-Free  │ │ Dbl-Buffer  │ │ TC    │ │
-│  └────────┘ └────────┘ └────────────┘ └─────────────┘ └───────┘ │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-### Unified Kernel Interface
-
-All kernels conform to a unified template interface:
-
-```cpp
-template<int TILE_SIZE = 32>
-void launch_xxx_sgemm(
-    const float* A,      // M×K input matrix
-    const float* B,      // K×N input matrix
-    float* C,            // M×N output matrix
-    int M, int K, int N,
-    cudaStream_t stream = 0
-);
-```
-
-### Exception-Based Error Handling
-
-```cpp
-struct CudaError : std::runtime_error {
-    explicit CudaError(const std::string& msg) : std::runtime_error(msg) {}
-};
-
-#define CUDA_CHECK(call) \
-    do { \
-        cudaError_t err = call; \
-        if (err != cudaSuccess) { \
-            throw CudaError(cudaGetErrorString(err)); \
-        } \
-    } while(0)
-```
-
-### Verification Tolerances
-
-| Kernel Type | rtol | atol |
-|-------------|------|------|
-| Standard FP32 | 1e-3 | 1e-4 |
-| Tensor Core | 5e-2 | 1e-2 |
-
-## Risks / Trade-offs
-
-| Risk | Mitigation |
-|------|------------|
-| Kernel interface changes would require updating all implementations | Interface is stable; use delta specs for any changes |
-| Error handling exceptions may impact performance in hot paths | Exceptions only on setup/teardown, not kernel execution |
diff --git a/openspec/changes/archive/0001-core-architecture/proposal.md b/openspec/changes/archive/0001-core-architecture/proposal.md
deleted file mode 100644
index dcf159a..0000000
--- a/openspec/changes/archive/0001-core-architecture/proposal.md
+++ /dev/null
@@ -1,16 +0,0 @@
-## Motivation
-
-Establish a foundational architecture for the CUDA SGEMM Optimization project that supports progressive kernel optimization techniques while maintaining code quality, testability, and benchmarking capabilities.
-
-## Changes
-
-### New Capabilities
-- **core-architecture**: Three-layer architecture (Application, Kernel, Utility)
-- **kernel-interface**: Unified template interface for all SGEMM kernels
-- **error-handling**: Exception-based error handling with RAII cleanup
-- **testing-architecture**: Google Test framework with property-based testing
-- **build-system**: Dual build support (CMake + Makefile)
-
-## Impact
-
-This RFC established the architectural foundation for all subsequent kernel implementations and testing infrastructure. It defined the kernel interface contract that all five implementations follow, enabling consistent benchmarking and verification.
diff --git a/openspec/changes/archive/0002-implementation-roadmap/change.yaml b/openspec/changes/archive/0002-implementation-roadmap/change.yaml
deleted file mode 100644
index 95c1af6..0000000
--- a/openspec/changes/archive/0002-implementation-roadmap/change.yaml
+++ /dev/null
@@ -1,6 +0,0 @@
-schema: spec-driven
-created: 2026-04-16
-archived: 2026-04-23
-status: archived
-title: Implementation Roadmap
-description: Seven-phase development roadmap from infrastructure to documentation
diff --git a/openspec/changes/archive/0002-implementation-roadmap/design.md b/openspec/changes/archive/0002-implementation-roadmap/design.md
deleted file mode 100644
index b5cd296..0000000
--- a/openspec/changes/archive/0002-implementation-roadmap/design.md
+++ /dev/null
@@ -1,56 +0,0 @@
-## Context
-
-The SGEMM Optimization project needed a structured approach to implement five progressive kernel optimizations while building supporting infrastructure for testing, benchmarking, and documentation.
-
-## Goals / Non-Goals
-
-### Goals
-- Deliver five kernel implementations with progressive optimization
-- Build comprehensive test coverage
-- Establish CI/CD automation
-- Create bilingual documentation
-
-### Non-Goals
-- Production deployment
-- Performance optimization beyond Tensor Core
-- Multi-GPU support
-
-## Decisions
-
-### Seven-Phase Implementation
-
-| Phase | Focus | Status |
-|-------|-------|--------|
-| 1 | Project Infrastructure | ✅ Complete |
-| 2 | Kernel Implementation (5 kernels) | ✅ Complete |
-| 3 | Utility Infrastructure | ✅ Complete |
-| 4 | Testing Suite | ✅ Complete |
-| 5 | Build System & CI/CD | ✅ Complete |
-| 6 | Documentation | ✅ Complete |
-| 7 | Code Quality & Refinement | ✅ Complete |
-
-### Kernel Development Sequence
-
-1. **Naive** - Baseline triple-loop implementation
-2. **Tiled** - Shared memory blocking
-3. **Bank-Free** - Bank conflict elimination
-4. **Double-Buffer** - Compute/memory overlap
-5. **Tensor Core** - WMMA API acceleration
-
-### Version Milestones
-
-| Version | Milestone |
-|---------|-----------|
-| 1.0.0 | Project Initialization |
-| 2.0.0-rc.1 | Memory Leak Fixes (RAII) |
-| 2.0.0-rc.2 | GitHub Pages |
-| 2.0.0 | Stable Release |
-| 2.1.0 | Documentation & Code Cleanup |
-
-## Risks / Trade-offs
-
-| Risk | Mitigation |
-|------|------------|
-| Scope creep with additional optimizations | Defined clear 5-kernel scope |
-| Documentation falling behind | Dedicated Phase 6 for documentation |
-| Code quality issues | Phase 7 for RAII refactoring and dead code cleanup |
diff --git a/openspec/changes/archive/0002-implementation-roadmap/proposal.md b/openspec/changes/archive/0002-implementation-roadmap/proposal.md
deleted file mode 100644
index ce363d0..0000000
--- a/openspec/changes/archive/0002-implementation-roadmap/proposal.md
+++ /dev/null
@@ -1,14 +0,0 @@
-## Motivation
-
-Define a clear implementation roadmap with phases, milestones, and deliverables to guide the development of the SGEMM Optimization project from initialization to stable release.
-
-## Changes
-
-### New Capabilities
-- **implementation-phases**: Seven development phases from infrastructure to documentation
-- **milestone-tracking**: Version-based milestone timeline
-- **deliverables**: Clear deliverables for each phase
-
-## Impact
-
-All seven phases were completed successfully, resulting in a comprehensive demonstration of GPU optimization techniques with complete test coverage, CI/CD automation, and bilingual documentation.
diff --git a/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/.openspec.yaml b/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/.openspec.yaml
deleted file mode 100644
index 8b394c6..0000000
--- a/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-04-23
diff --git a/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/design.md b/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/design.md
deleted file mode 100644
index 7f2b6f4..0000000
--- a/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/design.md
+++ /dev/null
@@ -1,116 +0,0 @@
-## Context
-
-This repository is functionally rich enough to close out, but it is not yet governable in a clean way. The core SGEMM code layout is reasonable, yet the surrounding repository has drifted:
-
-- `openspec/specs/*` is acting as the practical source of truth, while `openspec/config.yaml`, `specs.md`, and `openspec/README.md` still describe older paths and conventions.
-- Guidance is split between root `AGENTS.md`, `openspec/AGENTS.md`, generated `.claude/` assets, and missing project-level `CLAUDE.md` / Copilot-specific instructions.
-- README, Pages, docs, changelog, and release notes overlap heavily, which weakens both maintainability and project presentation.
-- Workflow triggers are not fully aligned with the current default branch or with the desired archive-ready maintenance posture.
-- The repository already has GitHub metadata and Pages enabled, so the work is not greenfield; it is a consolidation and correction pass.
-
-The chosen operating mode for this closeout is **strict pruning**: when two artifacts serve the same purpose, the repository should keep one authoritative version and remove the rest.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Make OpenSpec the single authoritative governance and requirements system for repository-level decisions.
-- Collapse redundant instructions, release-history files, and documentation surfaces into a small, high-signal set of maintained artifacts.
-- Redesign the GitHub-facing surfaces (README, Pages, metadata) so the project is legible and attractive to new users.
-- Keep automation and tooling intentionally small: only workflows, hooks, and configs that materially improve correctness or contributor throughput should remain.
-- Establish a shared project baseline for clangd/LSP, hooks, and AI-assistant usage that works across Claude/Codex/Copilot style tools with minimal duplication.
-- Produce an implementation sequence that is safe to execute in a long-running autopilot session without relying on `/fleet` as the default mode.
-
-**Non-Goals:**
-
-- Adding new SGEMM kernels, new benchmark features, or new end-user product scope.
-- Replacing the CUDA/CMake/Google Test stack.
-- Building a large multi-runner CI platform or adding heavyweight external services.
-- Preserving redundant historical files solely as placeholders once their content is safely represented elsewhere.
-
-## Decisions
-
-### 1. `openspec/specs/` becomes the only authoritative stable spec location
-
-**Decision:** Repository documentation and configuration will be aligned so that `openspec/specs/<capability>/spec.md` is the sole stable-spec source, while change-specific deltas continue to live under `openspec/changes/<change>/specs/`.
-
-**Why this choice:** The repository already stores the living capability specs in `openspec/specs/*`. Keeping that structure avoids another migration and lets `specs.md` become a documentation entry point instead of a second spec system.
-
-**Alternatives considered:**
-
-- **Reintroduce root `specs/` as stable specs**: rejected because it would re-expand the same duplication problem that already caused drift.
-- **Keep both paths and explain the difference better**: rejected because two normative sources would continue to confuse both humans and AI agents.
-
-### 2. Governance documents will be split by responsibility, not by tool vanity
-
-**Decision:** Root `AGENTS.md` will carry concise cross-tool project rules, `CLAUDE.md` will carry only Claude-specific operational guidance, and any Copilot instruction file will be added only if it contains project-specific guidance that does not merely restate the other files.
-
-**Why this choice:** The problem is not the absence of documents; it is duplicated, generic documents with fuzzy ownership. Clear boundaries make the docs maintainable and easier for automation to trust.
-
-**Alternatives considered:**
-
-- **One giant governance file for every tool**: rejected because it becomes verbose and hard to keep accurate.
-- **Separate fully independent instructions for every tool**: rejected because it maximizes drift.
-
-### 3. Documentation will follow a three-surface model
-
-**Decision:** The repository will treat documentation as three surfaces:
-
-1. **README**: compact repository entry point and quick-start
-2. **GitHub Pages + `docs/`**: presentation and guided technical learning
-3. **OpenSpec**: normative requirements, process, and engineering governance
-
-`CHANGELOG.md` stays only for meaningful version changes. `RELEASE_NOTES.md` will be removed unless it retains unique user-facing information after consolidation.
-
-**Why this choice:** Each surface serves a different audience. Mixing them causes duplication and weakens both onboarding and maintenance.
-
-**Alternatives considered:**
-
-- **Keep long-form README and mirror it into Pages**: rejected because it duplicates content while satisfying neither repository entry nor landing-page goals well.
-- **Move all docs into OpenSpec**: rejected because OpenSpec should govern the system, not replace tutorial or presentation content.
-
-### 4. Automation must reflect archive-ready maintenance, not expansion
-
-**Decision:** Workflows will be trimmed to a minimal set of high-signal checks: formatting/style, CI-safe compile/build validation, OpenSpec/repository-structure validation, and Pages deployment. Triggers will be aligned with the default branch and pull requests, with no redundant workflow fan-out.
-
-**Why this choice:** The project is entering a finishing phase. Noise in CI is a maintenance liability, not a feature.
-
-**Alternatives considered:**
-
-- **Add more workflows for more coverage**: rejected because runtime GPU coverage is not available in GitHub-hosted CI and extra workflows would mostly increase noise.
-- **Collapse everything into one mega-workflow**: rejected because Pages deployment and repository validation have different trigger patterns and failure modes.
-
-### 5. Shared tooling baseline will prefer portable foundations over tool-specific magic
-
-**Decision:** The project-wide developer tooling baseline will center on CMake-generated `compile_commands.json`, `clangd`, minimal `.githooks`, and native CLI/skill usage. MCP integrations will be treated as optional and added only where they clearly outperform built-in tools or skills.
-
-**Why this choice:** LSP fundamentals are largely tool-agnostic. Building the shared foundation once yields value across Claude/Codex/Copilot workflows without committing the repository to heavy context-consuming integrations.
-
-**Alternatives considered:**
-
-- **Tool-specific IDE/plugin configurations first**: rejected because they solve the thinnest layer while leaving the common foundation inconsistent.
-- **Broad MCP adoption**: rejected because the repository size and user preference do not justify the extra context and operational cost.
-
-## Risks / Trade-offs
-
-- **Aggressive pruning may remove historical breadcrumbs users still read** → Mitigation: keep genuinely useful historical context in Git history, archived OpenSpec changes, and a smaller but higher-quality changelog.
-- **Dirty worktree increases merge risk during cleanup** → Mitigation: inspect affected files carefully, avoid destructive resets, and converge existing edits instead of overwriting them blindly.
-- **GitHub metadata and Pages changes require authenticated `gh` access and repo permissions** → Mitigation: validate access early and stage metadata updates after the content model is settled.
-- **No GPU runtime in CI means closeout validation cannot rely on hosted runners for full correctness** → Mitigation: make the boundary explicit in specs and keep CI focused on compile-time and repository-structure guarantees.
-- **Cross-tool instruction files can drift again later** → Mitigation: centralize generic rules in one authoritative document and keep tool-specific files intentionally thin.
-
-## Migration Plan
-
-1. Normalize OpenSpec config, spec paths, and governance document ownership.
-2. Consolidate README, docs, changelog/release-notes, and Pages information architecture under the new authoritative model.
-3. Simplify workflows and engineering configs to match the closeout-state repository.
-4. Add or refine shared tooling/hook/LSP guidance and only the thinnest necessary tool-specific instructions.
-5. Sync GitHub metadata after the presentation layer is finalized.
-6. Run a bug and consistency sweep across code, docs, specs, and automation before archiving the change.
-
-Rollback is straightforward at the repository level because the cleanup is file- and config-oriented; each phase can be reverted via Git if a consolidation decision proves too aggressive.
-
-## Open Questions
-
-- None for the repository structure itself.
-- Full CUDA configure/build/test reruns still require a host with the CUDA toolkit and `nvcc` available; the governance and OpenSpec validation baseline can run without that dependency.
diff --git a/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/proposal.md b/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/proposal.md
deleted file mode 100644
index 4727e72..0000000
--- a/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/proposal.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## Why
-
-The repository has reached a closeout stage where the main risk is no longer missing features, but drift: OpenSpec structure and config disagree with the actual repo layout, project guidance is split across overlapping documents, GitHub Pages is not acting as a strong project entry point, and workflows/tooling are noisier than the maintenance goal requires. This change is needed now to aggressively consolidate the repository into one authoritative, archive-ready shape that is easier to trust, maintain, and eventually freeze.
-
-## What Changes
-
-- Normalize OpenSpec structure, configuration, and project instructions so the repo follows one authoritative spec-driven workflow.
-- Rewrite governance documents (`AGENTS.md`, `CLAUDE.md`, and Copilot guidance) around a concise closeout-oriented development loop.
-- Aggressively consolidate or remove low-value documentation, including duplicate landing content and redundant release-history material.
-- Redesign GitHub Pages as a project presentation and documentation entry point instead of a README mirror.
-- Prune GitHub workflows and engineering configuration to keep only high-signal automation aligned with the default branch and archive-ready maintenance goals.
-- Standardize project-specific developer tooling guidance for hooks, clangd/LSP, Claude/Copilot/OpenCode usage, and minimal-MCP tradeoffs.
-- Sync repository metadata (description, homepage, topics) with the cleaned project positioning using `gh`.
-- Sweep and fix repository bugs and inconsistencies discovered during the closeout pass.
-
-## Capabilities
-
-### New Capabilities
-- `repository-governance`: Defines the authoritative OpenSpec layout, project governance documents, automation policy, developer tooling conventions, and archive-ready maintenance workflow.
-- `project-presentation`: Defines how README, GitHub Pages, and repository metadata present the project to new users and route them to the right technical content.
-
-### Modified Capabilities
-- `architecture`: Refine architectural and engineering decisions so repository structure, build/CI expectations, and documentation boundaries match the real closeout-state system.
-- `testing`: Refine validation expectations to distinguish local GPU verification, CI-safe checks, and repository-structure/spec validation during the cleanup.
-
-## Impact
-
-- Affected code and configuration: `openspec/**`, root governance docs, documentation files, GitHub Pages files, `.github/workflows/*`, developer tooling config, and GitHub repository metadata.
-- No intended public API expansion; the main impact is repository structure, quality gates, documentation clarity, and maintenance workflow.
-- May remove or merge existing files whose content is redundant, outdated, or no longer authoritative.
diff --git a/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/specs/architecture/spec.md b/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/specs/architecture/spec.md
deleted file mode 100644
index 7fa9035..0000000
--- a/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/specs/architecture/spec.md
+++ /dev/null
@@ -1,15 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Published architecture matches the real repository structure
-The repository architecture guidance MUST describe only the directory structure, documentation boundaries, and engineering surfaces that actually exist and are maintained.
-
-#### Scenario: Contributor consults architecture guidance
-- **WHEN** a contributor reads architecture-facing documentation or specifications
-- **THEN** all referenced repository paths, layers, and responsibilities MUST correspond to the real maintained layout and MUST NOT reference stale or superseded structures as authoritative
-
-### Requirement: Engineering boundaries are explicit
-The repository architecture MUST make local-only and CI-safe responsibilities explicit so maintainers can reason correctly about build, test, and validation coverage.
-
-#### Scenario: Contributor decides how to validate a change
-- **WHEN** a contributor evaluates required validation steps for code, docs, specs, or workflow changes
-- **THEN** the architecture guidance MUST clearly distinguish local GPU-dependent verification from CI-safe compile, structure, and publication checks
diff --git a/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/specs/project-presentation/spec.md b/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/specs/project-presentation/spec.md
deleted file mode 100644
index 3853824..0000000
--- a/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/specs/project-presentation/spec.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Repository entry points have distinct roles
-The project MUST present itself through distinct entry surfaces so that each one serves a clear audience and does not duplicate another surface unnecessarily.
-
-#### Scenario: New visitor lands on the repository or project site
-- **WHEN** a user opens `README.md` or the GitHub Pages site
-- **THEN** the repository MUST provide a concise explanation of the project's value, core technical highlights, and clear navigation to deeper documentation without mirroring the same long-form content across both surfaces
-
-### Requirement: Documentation inventory is intentionally consolidated
-The project MUST aggressively merge or remove stale, low-value, or overlapping documentation so that each retained document has a single clear responsibility.
-
-#### Scenario: Maintainer audits repository documents
-- **WHEN** a maintainer reviews root docs, Pages content, and supporting documentation
-- **THEN** duplicate release-history material, overlapping landing pages, and non-authoritative explanatory files MUST be merged or removed until each retained document has a clear purpose and ownership
-
-### Requirement: GitHub metadata matches project positioning
-The public repository metadata MUST reinforce the same positioning used by the cleaned documentation and Pages experience.
-
-#### Scenario: Visitor views the GitHub repository summary
-- **WHEN** a visitor sees the repository About panel, homepage URL, or topic tags
-- **THEN** the description, homepage, and topics MUST accurately reflect the project's CUDA SGEMM optimization focus and link users toward the maintained project entry points
diff --git a/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/specs/repository-governance/spec.md b/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/specs/repository-governance/spec.md
deleted file mode 100644
index c723ba1..0000000
--- a/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/specs/repository-governance/spec.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## ADDED Requirements
-
-### Requirement: OpenSpec is the authoritative governance system
-The repository MUST use OpenSpec as the single authoritative system for repository requirements, workflow rules, and closeout-state governance decisions.
-
-#### Scenario: Contributor needs the normative source of truth
-- **WHEN** a contributor or AI agent needs project requirements, workflow rules, or repository governance guidance
-- **THEN** the authoritative source MUST be the stable capability specs under `openspec/specs/` together with active change artifacts under `openspec/changes/`
-
-### Requirement: Governance instructions have clear ownership
-The repository MUST keep governance instructions concise, non-redundant, and separated by responsibility rather than by repetitive tool-specific restatement.
-
-#### Scenario: Contributor reads repository instruction files
-- **WHEN** a contributor opens root governance files such as `AGENTS.md`, `CLAUDE.md`, or any project-level Copilot instruction file
-- **THEN** each file MUST have a distinct responsibility, avoid generic duplicated boilerplate, and defer to the authoritative OpenSpec workflow where normative process rules apply
-
-### Requirement: Automation is archive-ready and high-signal
-The repository MUST keep only automation that materially improves closeout-state quality, consistency, or publication.
-
-#### Scenario: Repository change triggers automation
-- **WHEN** a pull request or push matches the repository automation rules
-- **THEN** workflows MUST be limited to high-signal validation or publishing tasks, align with the default branch strategy, and avoid redundant or low-value executions
-
-### Requirement: Shared developer tooling is lightweight and portable
-The repository MUST provide a project-level tooling baseline that works across multiple AI and editor environments without depending on heavy, context-expensive integrations.
-
-#### Scenario: Contributor sets up local tooling
-- **WHEN** a contributor enables hooks, language tooling, or AI-assisted workflow features for the repository
-- **THEN** the primary baseline MUST rely on shared project foundations such as CMake-generated compile commands, clangd-compatible configuration, minimal hooks, and native CLI or skill-driven workflows before optional MCP-style integrations are considered
diff --git a/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/specs/testing/spec.md b/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/specs/testing/spec.md
deleted file mode 100644
index d4b1c6f..0000000
--- a/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/specs/testing/spec.md
+++ /dev/null
@@ -1,15 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Repository validation includes governance integrity
-The repository test and validation model MUST cover not only code correctness but also the integrity of governance, specification, and documentation structure.
-
-#### Scenario: Governance-related files change
-- **WHEN** OpenSpec files, workflow files, governance documents, or documentation structure are modified
-- **THEN** the repository MUST provide CI-safe validation that checks the relevant specification and structural invariants before those changes are treated as complete
-
-### Requirement: Validation expectations are split by execution environment
-The repository MUST document which checks are expected to run in hosted CI and which checks require a local GPU-capable environment.
-
-#### Scenario: Contributor reads validation guidance
-- **WHEN** a contributor prepares to validate repository changes
-- **THEN** the documented workflow MUST separate CI-safe checks such as formatting, compilation, OpenSpec validation, or Pages buildability from GPU-required runtime verification and benchmarking
diff --git a/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/tasks.md b/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/tasks.md
deleted file mode 100644
index b80d5ed..0000000
--- a/openspec/changes/archive/2026-04-23-archive-ready-governance-cleanup/tasks.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## 1. OpenSpec foundation
-
-- [x] 1.1 Normalize `openspec/config.yaml`, `specs.md`, and OpenSpec guidance docs so `openspec/specs/*` is the only authoritative stable spec path.
-- [x] 1.2 Rewrite `AGENTS.md`, `openspec/AGENTS.md`, and create `CLAUDE.md` with clear ownership and a concise closeout-oriented OpenSpec workflow.
-- [x] 1.3 Add only the thinnest necessary project-level Copilot/AI instruction files and remove or avoid redundant governance surfaces.
-
-## 2. Documentation consolidation
-
-- [x] 2.1 Rewrite `README.md` and `README.zh-CN.md` into concise repository entry points aligned with the cleaned project positioning.
-- [x] 2.2 Redesign `index.md`, `_config.yml`, and key `docs/*.md` pages so GitHub Pages becomes a real project landing/documentation experience instead of a README mirror.
-- [x] 2.3 Consolidate or remove redundant documentation artifacts such as low-value landing pages, duplicated architecture/process writeups, and `RELEASE_NOTES.md` if its content is fully absorbed elsewhere.
-- [x] 2.4 Clean `CHANGELOG.md` and `CONTRIBUTING.md` so they keep only high-signal release and collaboration information.
-
-## 3. Automation and tooling
-
-- [x] 3.1 Prune `.github/workflows/*` to a minimal high-signal set and align triggers with the repository default branch and closeout-state maintenance policy.
-- [x] 3.2 Add a minimal hook strategy and shared clangd/LSP baseline (`compile_commands.json` workflow, optional `.clangd`, hook install path) that works across Claude/Codex/Copilot style environments.
-- [x] 3.3 Document the preferred usage boundaries for `/review`, subagents, OpenSpec commands, native CLI tools, and minimal MCP/plugin adoption.
-
-## 4. Repository consistency and metadata
-
-- [x] 4.1 Sweep repository bugs and inconsistencies across code, docs, specs, workflows, and configuration; fix the confirmed closeout-blocking issues.
-- [x] 4.2 Run the relevant validation commands for formatting, buildability, tests, and OpenSpec/workflow integrity; adjust files until the closeout baseline is coherent.
-- [x] 4.3 Use `gh` to update repository description, homepage/about link, and curated topics so the public metadata matches the cleaned Pages and README positioning.
-
-## 5. Closeout readiness
-
-- [x] 5.1 Do a final pass to ensure retained files have a single clear responsibility and removed files no longer leave broken references.
-- [x] 5.2 Update the change artifacts as needed so the closeout cleanup is ready to archive once implementation is complete.
diff --git a/openspec/changes/archive/2026-04-23-initial-migration/proposal.md b/openspec/changes/archive/2026-04-23-initial-migration/proposal.md
deleted file mode 100644
index bc29fee..0000000
--- a/openspec/changes/archive/2026-04-23-initial-migration/proposal.md
+++ /dev/null
@@ -1,34 +0,0 @@
-# Proposal: Initial Migration to OpenSpec
-
-## Summary
-
-Migrate existing SDD specification structure to OpenSpec framework.
-
-## Motivation
-
-Standardize on OpenSpec for improved change tracking and AI assistant integration. The OpenSpec framework provides:
-
-- Formalized change proposal workflow (`/opsx:propose`, `/opsx:apply`, `/opsx:archive`)
-- Domain-organized specs with delta specs for incremental changes
-- Built-in AI assistant integration via slash commands
-- Archival system for preserving change history
-
-## Scope
-
-- All existing specs in `specs/` directory
-- Current AGENTS.md instructions
-- RFC and product documentation
-
-## Approach
-
-1. Created OpenSpec directory structure under `openspec/`
-2. Transformed existing specs to OpenSpec domain format:
-   - `specs/product/` → `openspec/specs/kernel/`
-   - `specs/rfc/` → `openspec/specs/architecture/`
-   - `specs/testing/` → `openspec/specs/testing/`
-3. Updated AGENTS.md to reference OpenSpec workflow
-4. Removed legacy `specs/` directory
-
-## Status: Completed
-
-Migration completed on 2026-04-23.
diff --git a/openspec/changes/archive/2026-04-23-initial-migration/tasks.md b/openspec/changes/archive/2026-04-23-initial-migration/tasks.md
deleted file mode 100644
index 214dd80..0000000
--- a/openspec/changes/archive/2026-04-23-initial-migration/tasks.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Migration Tasks
-
-## Implementation
-
-- [x] Install OpenSpec CLI
-- [x] Initialize openspec/ directory
-- [x] Create domain structure (kernel, architecture, testing)
-- [x] Migrate kernel specs to `openspec/specs/kernel/spec.md`
-- [x] Migrate architecture specs to `openspec/specs/architecture/spec.md`
-- [x] Migrate testing specs to `openspec/specs/testing/spec.md`
-
-## Documentation
-
-- [x] Create initial archive entry
-- [x] Update root AGENTS.md for OpenSpec workflow
-- [x] Create openspec/AGENTS.md with detailed instructions
-- [x] Update CONTRIBUTING.md
-
-## Validation
-
-- [x] Verify OpenSpec structure is valid
-- [x] Verify project still builds
-- [x] Remove old specs/ directory
diff --git a/openspec/changes/archive/2026-04-29-bilingual-docs-closeout/change.yaml b/openspec/changes/archive/2026-04-29-bilingual-docs-closeout/change.yaml
deleted file mode 100644
index f8a6c1d..0000000
--- a/openspec/changes/archive/2026-04-29-bilingual-docs-closeout/change.yaml
+++ /dev/null
@@ -1,5 +0,0 @@
-schema: spec-driven
-created: 2026-04-27
-status: active
-title: Bilingual Documentation and Pages Closeout
-description: Refresh bilingual READMEs, add language switcher to Pages, mirror tutorials, audit completion
diff --git a/openspec/changes/archive/2026-04-29-bilingual-docs-closeout/design.md b/openspec/changes/archive/2026-04-29-bilingual-docs-closeout/design.md
deleted file mode 100644
index c2f4b47..0000000
--- a/openspec/changes/archive/2026-04-29-bilingual-docs-closeout/design.md
+++ /dev/null
@@ -1,256 +0,0 @@
-# Design: Bilingual Documentation and Pages Closeout
-
-## Architecture Overview
-
-Keep one GitHub Pages deployment with mirrored English and Chinese routes:
-
-```
-/                    → English home
-/zh/                 → Chinese home
-/docs/*              → English tutorials
-/zh/docs/*           → Chinese tutorials
-/specs               → English specs landing
-/zh/specs            → Chinese specs landing
-```
-
-## Content Model
-
-### Public Surface Policy
-
-```yaml
-public_surface_policy:
-  normative_source: openspec/specs/*
-  bilingual_public_surfaces:
-    - README.md
-    - README.zh-CN.md
-    - index.md
-    - specs.md
-    - docs/*
-    - zh/index.md
-    - zh/specs.md
-    - zh/docs/*
-  route_model:
-    english_root: /
-    chinese_root: /zh/
-  page_pairing_keys:
-    - lang          # "en" or "zh-CN"
-    - page_key      # unique identifier for the content
-    - lang_ref      # page_key of the counterpart page
-```
-
-### Page Front Matter Template
-
-English page:
-```yaml
----
-lang: en
-page_key: kernel-naive
-lang_ref: zh-kernel-naive
-permalink: /docs/kernel-naive/
----
-```
-
-Chinese counterpart:
-```yaml
----
-lang: zh-CN
-page_key: zh-kernel-naive
-lang_ref: kernel-naive
-permalink: /zh/docs/kernel-naive/
----
-```
-
-## Components
-
-### 1. Language Switcher Include
-
-Location: `_includes/nav_footer_custom.html`
-
-```html
-<div class="language-switcher" 
-     data-page-key="{{ page.page_key }}" 
-     data-lang="{{ page.lang }}" 
-     data-lang-ref="{{ page.lang_ref }}">
-  <button type="button" data-lang-choice="en" 
-          class="{% if page.lang == 'en' %}is-active{% endif %}">
-    English
-  </button>
-  <button type="button" data-lang-choice="zh-CN"
-          class="{% if page.lang == 'zh-CN' %}is-active{% endif %}">
-    简体中文
-  </button>
-</div>
-```
-
-### 2. Route Switching Logic
-
-Location: `assets/js/language-toggle.js`
-
-Responsibilities:
-- Read current page metadata from DOM
-- On language button click, find paired page path
-- Store preference in localStorage
-- Redirect to counterpart or language home
-
-```js
-// Route mapping for page pairs
-const pagePairs = {
-  'home': { en: '/', 'zh-CN': '/zh/' },
-  'specs': { en: '/specs/', 'zh-CN': '/zh/specs/' },
-  'getting-started': { en: '/docs/getting-started/', 'zh-CN': '/zh/docs/getting-started/' },
-  // ... additional mappings
-};
-
-function findPairedPath(pageKey, targetLang) {
-  const pair = pagePairs[pageKey];
-  if (pair && pair[targetLang]) {
-    return pair[targetLang];
-  }
-  // Fallback to language home
-  return targetLang === 'zh-CN' ? '/zh/' : '/';
-}
-```
-
-### 3. SCSS Styling
-
-Location: `_sass/custom/custom.scss`
-
-```scss
-.language-switcher {
-  display: flex;
-  gap: 0.5rem;
-  margin: 0.5rem 0;
-}
-
-.language-switcher button {
-  padding: 0.25rem 0.75rem;
-  border: 1px solid var(--border-color, #ddd);
-  border-radius: 4px;
-  background: transparent;
-  cursor: pointer;
-  font-size: 0.875rem;
-}
-
-.language-switcher button.is-active {
-  border-color: var(--nvidia-green, #76b900);
-  color: var(--nvidia-green, #76b900);
-  font-weight: 500;
-}
-```
-
-## Navigation Strategy
-
-### Sidebar Organization
-
-The just-the-docs sidebar uses `nav_order` for sequencing. We have two options:
-
-**Option A: Language-filtered navigation (preferred)**
-- Use front matter `lang` to filter sidebar via custom include
-- Each language sees only its own pages in navigation
-
-**Option B: Unified navigation with language sections**
-- Group pages by language with section headers
-- Simpler to implement but mixes languages in sidebar
-
-Default to Option B for simplicity unless Option A proves necessary.
-
-### Cross-Language Linking
-
-Each page's switcher provides the primary cross-language link. Additionally:
-- README files cross-link to each other
-- Home pages mention the alternate language version
-- Tutorial pages include "Also available in: X" notes
-
-## File Layout
-
-### New Directories
-
-```
-zh/
-├── index.md
-├── specs.md
-└── docs/
-    ├── getting-started.md
-    ├── learning-path.md
-    ├── architecture.md
-    ├── benchmark-results.md
-    ├── kernel-naive.md
-    ├── kernel-tiled.md
-    ├── kernel-bank-free.md
-    ├── kernel-double-buffer.md
-    └── kernel-tensor-core.md
-```
-
-### New Includes
-
-```
-_includes/
-├── head_custom.html      # Load language-toggle.js
-└── nav_footer_custom.html # Switcher markup
-
-assets/js/
-└── language-toggle.js    # Switching logic
-```
-
-## README Structure
-
-Both READMEs follow identical outline:
-
-1. **Value Proposition** — One-sentence project description
-2. **Optimization Ladder** — Brief table of kernel progression
-3. **Quick Start** — Minimal commands to build and run
-4. **Learning Route** — Table mapping goals to entry points
-5. **Validation Boundary** — What's tested, what requires CUDA
-6. **Repository Layout** — Directory overview
-7. **Project Status** — Archive/completion notes
-
-## Metadata Alignment
-
-### GitHub Repository
-
-```bash
-gh repo edit LessUp/sgemm-optimization \
-  --description "Bilingual CUDA SGEMM optimization tutorial and reference implementation, from naive kernels to Tensor Core WMMA." \
-  --homepage "https://lessup.github.io/sgemm-optimization/"
-```
-
-### _config.yml
-
-```yaml
-title: SGEMM Optimization
-description: >-
-  Bilingual CUDA SGEMM optimization tutorial and reference implementation,
-  from naive kernels to Tensor Core WMMA.
-aux_links:
-  "GitHub":
-    - "//github.com/LessUp/sgemm-optimization"
-  "English README":
-    - "//github.com/LessUp/sgemm-optimization/blob/master/README.md"
-  "中文 README":
-    - "//github.com/LessUp/sgemm-optimization/blob/master/README.zh-CN.md"
-```
-
-## Edge Cases
-
-### Pages Without Counterparts
-
-If a page exists in one language only:
-- Still render switcher but show "Not available in [lang]" for missing language
-- Or redirect to language home with a notice
-
-### Search Behavior
-
-Just-the-docs search indexes all pages. This is acceptable — readers can find content in either language.
-
-### Mobile View
-
-Switcher should remain accessible in mobile sidebar; test at common breakpoints.
-
-## Rollback Plan
-
-All changes are additive (new files, new includes, new directory). Rollback is straightforward:
-1. Remove `zh/` directory
-2. Remove `_includes/*.html` and `assets/js/language-toggle.js`
-3. Revert modifications to `index.md`, `specs.md`, `docs/*.md`, `_config.yml`, `_sass/custom/custom.scss`
-
-No code changes required — this is documentation and presentation work only.
diff --git a/openspec/changes/archive/2026-04-29-bilingual-docs-closeout/proposal.md b/openspec/changes/archive/2026-04-29-bilingual-docs-closeout/proposal.md
deleted file mode 100644
index 79b8a22..0000000
--- a/openspec/changes/archive/2026-04-29-bilingual-docs-closeout/proposal.md
+++ /dev/null
@@ -1,76 +0,0 @@
-# Proposal: Bilingual Documentation and Pages Closeout
-
-## Summary
-
-Turn the repository into an archive-ready bilingual project surface by refreshing both READMEs, adding a real English/Chinese switch to the GitHub Pages site, expanding the tutorial experience, and auditing overall project completion.
-
-## Motivation
-
-The repository has reached a stable implementation state. All kernel implementations are complete, tests pass, and OpenSpec validation succeeds. However, the public-facing documentation surfaces are not yet ready for archival:
-
-1. **README parity gap**: English and Chinese READMEs exist but have drifted in structure and content
-2. **No language switching**: GitHub Pages lacks a functional way to switch between English and Chinese
-3. **Missing Chinese tutorials**: The docs/ directory has detailed English tutorials but no Chinese counterparts
-4. **Incomplete public navigation**: specs.md and the public-facing spec landing need bilingual exposure
-
-## Deliverables
-
-### 1. README Refresh and Parity
-
-- Restructure both READMEs to share the same outline
-- Add explicit "where to start" navigation tables
-- Align badges, links, and terminology across languages
-- Update GitHub repository metadata to match bilingual positioning
-
-### 2. GitHub Pages Theme/Navigation Improvements
-
-- Make homepage bilingual-aware with hero, CTA, and learning entry cards
-- Polish theme details (hero spacing, CTA hierarchy, table/card contrast)
-- Preserve existing dark/light mode support
-
-### 3. English/Chinese Switching for Public Teaching Surfaces
-
-- Define page-pair metadata model (`lang`, `page_key`, `lang_ref`)
-- Create lightweight switcher include for sidebar/footer
-- Implement route switching with preference persistence
-- Style switcher to match NVIDIA-inspired theme
-
-### 4. Repository Completion Audit and Closeout Polish
-
-- Audit CHANGELOG.md, CONTRIBUTING.md for bilingual exposure needs
-- Verify workflow triggers cover new file layout
-- Record and resolve remaining presentation gaps
-- Archive the OpenSpec change when truly complete
-
-## Scope
-
-### In Scope
-
-- Root README pair (`README.md`, `README.zh-CN.md`)
-- GitHub Pages home (`index.md`, `zh/index.md`)
-- All tutorial pages (`docs/*.md`, `zh/docs/*.md`)
-- Public specs landing (`specs.md`, `zh/specs.md`)
-- Language switcher infrastructure
-- GitHub repository metadata
-
-### Out of Scope
-
-- Full mirror of normative OpenSpec specs (governance files remain English-only)
-- Separate site deployments or complex frontend frameworks
-- New kernel implementations or code changes
-
-## Success Criteria
-
-1. OpenSpec validation passes for all stable specs plus the new change
-2. Both READMEs share the same structure with aligned content
-3. GitHub Pages has functional language switching on all public pages
-4. Every English tutorial page has a Chinese counterpart
-5. GitHub metadata matches the refreshed positioning
-6. Repository feels complete as a public teaching project
-
-## Dependencies
-
-- Existing `just-the-docs` theme and custom SCSS
-- OpenSpec validation tooling
-- GitHub Actions Pages workflow
-- `gh` CLI for metadata updates
diff --git a/openspec/changes/archive/2026-04-29-bilingual-docs-closeout/specs/project-presentation/spec.md b/openspec/changes/archive/2026-04-29-bilingual-docs-closeout/specs/project-presentation/spec.md
deleted file mode 100644
index f411ba1..0000000
--- a/openspec/changes/archive/2026-04-29-bilingual-docs-closeout/specs/project-presentation/spec.md
+++ /dev/null
@@ -1,94 +0,0 @@
-# Spec: Project Presentation (Delta)
-
-> This spec captures the bilingual presentation requirements for the closeout phase.
-
-## ADDED Requirements
-
-### Requirement: Repository entry surfaces support bilingual navigation
-
-The repository MUST provide clear entry points for both English and Chinese readers with consistent structure across both README files.
-
-#### Scenario: Bilingual Repository Entry
-
-- **WHEN** a visitor lands on the GitHub repository root
-- **THEN** the repository MUST present `README.md` as the default English entry
-- **AND** the repository MUST show a prominent link to `README.zh-CN.md` for Chinese readers
-- **AND** both files MUST have consistent structure and navigation tables
-
-### Requirement: All public pages offer language switching
-
-Every public documentation page MUST provide a way to switch to its counterpart in the other language.
-
-#### Scenario: Language Switching Between Paired Pages
-
-- **WHEN** a visitor reading a tutorial page in English clicks the language switcher for Chinese
-- **THEN** the system MUST redirect to the Chinese counterpart page
-- **AND** the Chinese page MUST offer a switch back to English
-
-#### Scenario: Switcher Remembers Preference
-
-- **WHEN** a visitor who previously switched to Chinese visits another English page
-- **THEN** the switcher MUST still show Chinese as active
-- **AND** clicking the switcher MUST return them to Chinese content
-
-#### Scenario: Switcher Mobile Accessible
-
-- **WHEN** a visitor on a mobile device opens the sidebar
-- **THEN** the language switcher MUST be visible and functional
-- **AND** buttons MUST be large enough for touch interaction
-
-### Requirement: Tutorial pages have mirrored counterparts
-
-Every tutorial page in English MUST have a Chinese counterpart with equivalent content structure.
-
-#### Scenario: Tutorial Pages Stay Mirrored
-
-- **WHEN** a tutorial page exists in English at `/docs/kernel-naive/` with a Chinese counterpart at `/zh/docs/kernel-naive/`
-- **THEN** both pages MUST have identical section structure
-- **AND** both pages MUST have equivalent technical content
-- **AND** both pages MUST have cross-references to the same related pages
-- **AND** both pages MUST have matching front matter (except `lang`, `page_key`, `lang_ref`)
-
-### Requirement: GitHub metadata aligns with bilingual positioning
-
-Repository metadata on GitHub MUST reflect the bilingual nature of the project.
-
-#### Scenario: Public Metadata Stays Aligned
-
-- **WHEN** the READMEs are updated with bilingual content
-- **THEN** the GitHub description and homepage MUST match the bilingual positioning
-- **AND** topics MUST remain relevant to both language audiences
-
-### Requirement: All public surfaces are reviewed before archive
-
-The closeout audit MUST verify all bilingual surfaces are complete and consistent.
-
-#### Scenario: All Public Surfaces Reviewed
-
-- **WHEN** the closeout audit runs after bilingual implementation is complete
-- **THEN** README pair MUST be verified
-- **AND** Pages home pair MUST be verified
-- **AND** all tutorial page pairs MUST be verified
-- **AND** specs landing pair MUST be verified
-- **AND** GitHub metadata MUST be verified
-
-### Requirement: Workflow triggers cover new file layout
-
-The GitHub Pages workflow MUST rebuild when any bilingual content changes.
-
-#### Scenario: Workflow Triggers Updated
-
-- **WHEN** any `zh/**/*.md` file changes
-- **THEN** the GitHub Pages workflow MUST trigger a rebuild
-- **AND** the published site MUST reflect changes
-
-### Requirement: No orphaned content exists after archive
-
-All linked content MUST resolve correctly with no missing counterparts.
-
-#### Scenario: No Orphaned Content
-
-- **WHEN** someone browses the archived site
-- **THEN** every linked page MUST exist
-- **AND** no page MUST reference a missing counterpart
-- **AND** all cross-references MUST resolve correctly
\ No newline at end of file
diff --git a/openspec/changes/archive/2026-04-29-bilingual-docs-closeout/tasks.md b/openspec/changes/archive/2026-04-29-bilingual-docs-closeout/tasks.md
deleted file mode 100644
index 20c7e37..0000000
--- a/openspec/changes/archive/2026-04-29-bilingual-docs-closeout/tasks.md
+++ /dev/null
@@ -1,104 +0,0 @@
-# Tasks: Bilingual Documentation and Pages Closeout
-
-## Task 1: OpenSpec Change and Completion Baseline
-
-- [x] Create change directory: `openspec/changes/bilingual-docs-closeout/`
-- [x] Write proposal.md covering four deliverables
-- [x] Write design.md with route model and component specs
-- [x] Add project-presentation delta scenarios
-- [x] Run `openspec validate --all` to verify
-
-## Task 2: Bilingual Information Architecture and Switcher Contract
-
-- [x] Add page-pair metadata (`lang`, `page_key`, `lang_ref`) to index.md and specs.md
-- [x] Update `_config.yml` for bilingual labels and navigation
-- [x] Create `_includes/nav_footer_custom.html` with switcher markup
-- [x] Create `assets/js/language-toggle.js` for route switching
-- [x] Add switcher styles to `_sass/custom/custom.scss`
-- [x] Create `_includes/head_custom.html` to load JS
-
-## Task 3: README Pair Refresh and Repository Metadata Alignment
-
-- [x] Restructure both READMEs to identical outline
-- [x] Add "where to start" navigation tables
-- [x] Align badges, links, and terminology
-- [x] Update GitHub repository metadata via `gh repo edit`
-
-## Task 4: Pages Home and Theme Refresh
-
-- [x] Update index.md with bilingual-aware hero and CTAs
-- [x] Create zh/index.md as Chinese counterpart
-- [x] Polish theme details (spacing, hierarchy, contrast)
-- [x] Verify dark/light mode support preserved
-
-## Task 5: Mirror and Enrich Tutorial Set
-
-- [x] Normalize front matter for all docs/*.md pages
-- [x] Expand onboarding pages (getting-started, learning-path, architecture)
-- [x] Add reader guidance to kernel pages
-- [x] Create all zh/docs/*.md counterparts with content parity
-- [x] Create optional pages only if they close real gaps (not needed)
-
-## Task 6: Public Spec/Navigation Surfaces and Closeout Audit
-
-- [x] Create zh/specs.md as bilingual specs landing
-- [x] Audit CHANGELOG.md and CONTRIBUTING.md for bilingual needs (decided: keep as-is, low-frequency files)
-- [x] Verify workflow triggers cover new file layout
-- [x] Record and resolve remaining closeout gaps
-
-## Task 7: Validation and Final Polish
-
-- [x] Run `openspec validate --all` — PASSED
-- [x] Run available repository baseline checks (OpenSpec passed; CUDA build/runtime blocked in this environment because `nvcc` is unavailable)
-- [x] Review published-surface checklist
-- [x] Archive OpenSpec change when complete
-
----
-
-## Progress Tracking
-
-| Task | Status | Notes |
-|------|--------|-------|
-| 1. OpenSpec Change | ✅ complete | |
-| 2. IA & Switcher | ✅ complete | |
-| 3. README Refresh | ✅ complete | |
-| 4. Pages Home | ✅ complete | |
-| 5. Tutorial Mirror | ✅ complete | |
-| 6. Specs & Audit | ✅ complete | |
-| 7. Validation | ✅ complete | OpenSpec validated; CUDA tests require GPU env |
-
----
-
-## Remaining Closeout Items
-
-After merge to master:
-1. Verify Pages build succeeds on CI
-2. Test language switcher on deployed site
-
-## Files Created/Modified Summary
-
-### New Files
-- `_includes/head_custom.html`
-- `_includes/nav_footer_custom.html`
-- `assets/js/language-toggle.js`
-- `zh/index.md`
-- `zh/specs.md`
-- `zh/docs/getting-started.md`
-- `zh/docs/learning-path.md`
-- `zh/docs/architecture.md`
-- `zh/docs/benchmark-results.md`
-- `zh/docs/kernel-naive.md`
-- `zh/docs/kernel-tiled.md`
-- `zh/docs/kernel-bank-free.md`
-- `zh/docs/kernel-double-buffer.md`
-- `zh/docs/kernel-tensor-core.md`
-
-### Modified Files
-- `README.md` — restructured with unified outline
-- `README.zh-CN.md` — restructured with unified outline
-- `_config.yml` — bilingual description and aux_links
-- `_sass/custom/custom.scss` — language switcher styles
-- `index.md` — page-pair metadata
-- `specs.md` — page-pair metadata
-- `docs/*.md` (9 files) — page-pair metadata
-- `.github/workflows/pages.yml` — added zh/** and _includes/** triggers
diff --git a/openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/.openspec.yaml b/openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/.openspec.yaml
deleted file mode 100644
index ab7f13b..0000000
--- a/openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-05-16
diff --git a/openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/design.md b/openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/design.md
deleted file mode 100644
index fce127d..0000000
--- a/openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/design.md
+++ /dev/null
@@ -1,92 +0,0 @@
-## Context
-
-The repository already uses VitePress and has recently improved its public presentation, but the current site still behaves like a good project manual rather than a top-tier architecture whitepaper. The strongest content is present, yet it is distributed across route groups that do not fully match the intended reader journey: first orientation, then system framing, then optimization study, then validation, then research lineage.
-
-The local `kimi-cli` docs stack is the desired engineering baseline. It uses the same VitePress generation family already present here, but with a cleaner config posture: centralized locale navigation, simpler theme bootstrapping, and clearer separation between content structure and styling. This repository should adopt that baseline where it improves maintainability, while still keeping SGEMM-specific visual language, bilingual mirroring, and closeout-oriented consolidation.
-
-The current visual risk is concentrated in technical figures. Most diagrams are Mermaid-first and tuned through runtime theme re-initialization, while SVG/icon assets remain sparse. That keeps iteration easy, but it also makes the site look less curated and causes weak light/dark mode parity. The redesign therefore needs both structural and visual changes: route architecture, reusable presentation primitives, and a theme-safe figure strategy.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Rebuild the Pages site into a bilingual whitepaper-and-academy experience with a clearer progression from project thesis to deep kernel study.
-- Align the docs engineering baseline with the `kimi-cli` VitePress setup where that improves config clarity, navigation consistency, and future maintainability.
-- Introduce a production-ready visual system for cards, metrics, figures, citations, and diagrams that remains legible in both light and dark themes.
-- Strengthen technical depth through new or expanded modules for architectural walkthroughs, related projects, references, and evolution analysis.
-- Keep README, README.zh-CN, and Pages entry routes aligned so repository visitors see one consistent public narrative.
-
-**Non-Goals:**
-
-- No changes to CUDA kernel logic, benchmark harnesses, validation tolerances, or GPU runtime behavior.
-- No hosted GPU execution changes, workflow topology expansion, or new deployment platform.
-- No obligation to preserve the current route hierarchy or internal content grouping when a cleaner information architecture is better.
-- No attempt to mimic `kimi-cli` branding or content; only its engineering posture and documentation-site baseline are reused.
-
-## Decisions
-
-### Decision 1: Adopt the `kimi-cli` docs baseline for configuration and theme entry
-
-- **Choice**: Keep VitePress and the current plugin family, but refactor `docs/package.json`, `.vitepress/config.ts`, and `.vitepress/theme/index.ts` toward the cleaner `kimi-cli` baseline: centralized locale definitions, simple theme extension, and minimal runtime logic in the theme bootstrap.
-- **Why**: The current stack already shares the same major dependencies, so the highest-return change is not a framework swap but a convergence toward a cleaner baseline that is easier to reason about during closeout.
-- **Alternative considered**: Preserve the current docs configuration and only rewrite page content.
-- **Rejected because**: The existing route layout, runtime Mermaid theme handling, and ad hoc theme responsibilities would continue to constrain the redesign and make future consolidation harder.
-
-### Decision 2: Replace the current route taxonomy with a whitepaper-and-academy map
-
-- **Choice**: Reorganize bilingual docs into mirrored route groups with a clearer reader journey: overview/orientation, architecture, academy, validation, and research.
-- **Why**: The target audience is not browsing randomly; it is evaluating the project as an engineering artifact. The route map therefore needs to behave like a curated reading sequence rather than a loose collection of topical pages.
-- **Alternative considered**: Keep the existing `architecture`, `methodology`, `resources`, `validation`, and `support` groups and only improve page copy.
-- **Rejected because**: That model is informative but not forceful enough for a whitepaper-grade presentation, and it hides the “academy” progression the user explicitly wants.
-
-### Decision 3: Use a theme-safe figure system instead of Mermaid-only presentation
-
-- **Choice**: Reserve Mermaid for simple process diagrams, but move homepage-grade and architecture-grade figures to curated SVG assets and structured figure wrappers that use explicit design tokens for light/dark mode.
-- **Why**: High-signal diagrams need better composition control, better typography, and deterministic theme behavior. SVG assets also solve the current “dark mode unreadable / light mode washed out” failure mode more directly than repeated runtime Mermaid reconfiguration.
-- **Alternative considered**: Keep all diagrams in Mermaid and continue improving theme variables.
-- **Rejected because**: Mermaid is efficient for documentation flowcharts, but it is not the right default for polished whitepaper hero figures, comparison diagrams, or dual-theme visual art direction.
-
-### Decision 4: Expand public content with explicit citation, comparison, and evolution surfaces
-
-- **Choice**: Add or strengthen pages for references, related open-source projects, and architectural evolution analysis, and connect them directly from the main navigation.
-- **Why**: Whitepaper-grade credibility depends on traceable lineage. Advanced readers and interviewers need to see not only what the project implements, but also what ideas it inherits, where it differs, and how its design choices evolved.
-- **Alternative considered**: Keep a single references page as a terminal appendix.
-- **Rejected because**: A lone references appendix is easy to ignore and does not create the academic depth or comparative framing required by the target positioning.
-
-### Decision 5: Treat README as the executive summary and Pages as the deep document
-
-- **Choice**: Keep `README.md` and `README.zh-CN.md` concise, evidence-first, and navigational, while moving the long-form architecture and academy narrative into Pages.
-- **Why**: This preserves distinct roles across entry surfaces and avoids duplicating long-form content across GitHub and Pages.
-- **Alternative considered**: Promote the README into a near-full whitepaper mirror.
-- **Rejected because**: That would violate the repository’s consolidation posture and make bilingual maintenance harder.
-
-## Risks / Trade-offs
-
-- **[Risk]** Aggressive route restructuring can create broken internal links or route-test drift.  
-  **Mitigation**: Update route tests together with nav/sidebar changes and run the docs build after each large content batch.
-
-- **[Risk]** A larger visual system can become brittle if it relies on page-specific styling.  
-  **Mitigation**: Build around shared tokens, a small reusable component set, and a documented figure/card vocabulary.
-
-- **[Risk]** Bilingual parity can regress when pages are renamed or split.  
-  **Mitigation**: Mirror route trees exactly and move English/Chinese pages in paired edits.
-
-- **[Risk]** Replacing diagrams with SVGs can create manual-asset maintenance overhead.  
-  **Mitigation**: Limit custom SVG work to high-value figures and keep diagram subjects stable and reusable across pages.
-
-- **[Risk]** The site may become more ambitious than the repository’s closeout posture allows.  
-  **Mitigation**: Prefer consolidation and strong entry pages over expanding into a large number of low-value new leaves.
-
-## Migration Plan
-
-1. Refactor docs configuration and route tests to the new mirrored navigation model.
-2. Introduce the shared visual primitives and theme-safe figure assets required by the new homepage and architecture surfaces.
-3. Migrate content into the new bilingual route map, rewriting pages in pairs and removing superseded structures.
-4. Align README entry surfaces and public metadata-facing copy with the new Pages narrative.
-5. Validate docs tests, docs build, and OpenSpec consistency before finalizing the change.
-
-Rollback strategy: revert the docs route map, theme changes, and content moves together so the site returns to the previous route architecture in one step.
-
-## Open Questions
-
-- None blocking. The user’s preference for an aggressive, non-backward-compatible rebuild resolves the main scope ambiguity.
diff --git a/openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/proposal.md b/openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/proposal.md
deleted file mode 100644
index 448b580..0000000
--- a/openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/proposal.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## Why
-
-The current Pages site already has solid technical content, but it still reads like a polished documentation set rather than a decisive whitepaper-grade project narrative. This change rebuilds the public docs experience so interviewers and advanced GitHub readers can immediately see the repository as a rigorously argued CUDA SGEMM case study, with stronger information architecture, clearer visual hierarchy, and traceable evidence.
-
-## What Changes
-
-- Rebuild the bilingual GitHub Pages information architecture around a whitepaper-and-academy model, with clearer progression from executive orientation to deep technical study.
-- Realign the VitePress docs stack and shared site structure with the `kimi-cli` docs baseline where that baseline improves maintainability, navigation consistency, and long-term clarity.
-- Replace the current theme treatment with a more deliberate visual system that improves typography, spacing, contrast, and dark/light parity without depending on fragile one-off styling.
-- Rework homepage and major entry pages so architecture, methodology, validation, and learning routes read as one coherent technical argument rather than adjacent sections.
-- Upgrade diagrams, citations, and reference surfaces so visual assets remain legible in both themes and the content presents stronger academic and comparative context.
-- Tighten README-to-Pages alignment so repository entry points, Pages navigation, and evidence framing tell the same public story.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `project-presentation`: Strengthen requirements for whitepaper-grade Pages structure, mirrored bilingual academy navigation, theme-safe technical visuals, and evidence-backed public references.
-
-## Impact
-
-- Affected docs stack: `docs/package.json`, `docs/.vitepress/**/*`, `docs/public/**/*`
-- Affected public content: `docs/en/**/*`, `docs/zh/**/*`, `README.md`, `README.zh-CN.md`
-- Affected governance: `openspec/changes/rebuild-pages-whitepaper/specs/project-presentation/spec.md`
-- Validation impact: docs route tests, docs build, and `openspec validate --all` remain required for completion
diff --git a/openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/specs/project-presentation/spec.md b/openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/specs/project-presentation/spec.md
deleted file mode 100644
index ccb09e8..0000000
--- a/openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/specs/project-presentation/spec.md
+++ /dev/null
@@ -1,85 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Public whitepaper information architecture is curated by reader depth
-The GitHub Pages site MUST present the project through a mirrored bilingual information architecture that guides readers from orientation to deep technical study instead of exposing an unstructured set of topical pages.
-
-#### Scenario: Reader lands on the home page without repository context
-- **WHEN** a visitor opens the English or Chinese home page
-- **THEN** the page MUST summarize the project thesis, the optimization ladder, and the validation model
-- **AND** the page MUST provide direct paths into deeper architecture, academy, validation, and research sections
-
-#### Scenario: Reader follows the intended learning path
-- **WHEN** a visitor uses top-level navigation or homepage entry cards
-- **THEN** the documentation structure MUST separate high-level orientation from deep kernel-study pages
-- **AND** the route groups MUST be mirrored between English and Chinese
-
-### Requirement: Technical figures remain legible across themes
-All high-signal public technical figures MUST remain readable, visually coherent, and semantically equivalent in both light mode and dark mode.
-
-#### Scenario: Visitor switches between light and dark mode
-- **WHEN** the site theme changes
-- **THEN** diagrams, SVG illustrations, icons, and figure labels MUST preserve sufficient contrast for text, boundaries, and emphasis
-- **AND** no critical visual element MUST become effectively invisible in either theme
-
-#### Scenario: Architecture page uses a custom figure
-- **WHEN** a page renders a curated architecture or flow figure
-- **THEN** the figure MUST use the site’s shared visual tokens or paired theme-safe assets
-- **AND** the figure MUST remain understandable without relying on a theme-specific background assumption
-
-### Requirement: Public research context is explicit and traceable
-The documentation site MUST provide academic-style context that links project claims to references, related open-source implementations, and architectural evolution notes.
-
-#### Scenario: Reader investigates technical lineage
-- **WHEN** a reader opens the research-oriented section from site navigation
-- **THEN** the site MUST include structured references grouped by purpose
-- **AND** the site MUST include at least one related-project or comparative-analysis surface
-- **AND** the site MUST include at least one evolution-oriented explanation of why the project architecture is organized as it is
-
-## MODIFIED Requirements
-
-### Requirement: Repository entry points have distinct roles
-The project MUST present itself through distinct entry surfaces so that each one serves a clear audience and does not duplicate another surface unnecessarily.
-
-#### Scenario: New visitor lands on the repository or project site
-- **WHEN** a user opens `README.md` or the GitHub Pages site
-- **THEN** the repository MUST provide a concise explanation of the project's value, core technical highlights, and clear navigation to deeper documentation without mirroring the same long-form content across both surfaces
-- **AND** the Pages home experience MUST behave as the long-form whitepaper entry point rather than as a second copy of the README
-- **AND** the Pages home experience MUST emphasize project thesis, architectural differentiation, and evidence framing before deep implementation detail
-
-### Requirement: Documentation inventory is intentionally consolidated
-The project MUST aggressively merge or remove stale, low-value, or overlapping documentation so that each retained document has a single clear responsibility.
-
-#### Scenario: Maintainer audits repository documents
-- **WHEN** a maintainer reviews root docs, Pages content, and supporting documentation
-- **THEN** duplicate release-history material, overlapping landing pages, and non-authoritative explanatory files MUST be merged or removed until each retained document has a clear purpose and ownership
-- **AND** the public Pages structure MUST avoid parallel sections that explain the same concept with only cosmetic differences
-
-### Requirement: Repository entry surfaces support bilingual navigation
-The repository MUST provide clear entry points for both English and Chinese readers with consistent structure across both README files.
-
-#### Scenario: Bilingual Repository Entry
-- **WHEN** a visitor lands on the GitHub repository root
-- **THEN** the repository MUST present `README.md` as the default English entry
-- **AND** the repository MUST show a prominent link to `README.zh-CN.md` for Chinese readers
-- **AND** both files MUST have consistent structure and navigation tables
-- **AND** both files MUST link to equivalent English and Chinese documentation routes on the published site
-
-### Requirement: Tutorial pages have mirrored counterparts
-Every public academy or tutorial page in English MUST have a Chinese counterpart with equivalent content structure.
-
-#### Scenario: Academy Pages Stay Mirrored
-- **WHEN** a public learning or deep-dive page exists in English under the published documentation tree
-- **THEN** a Chinese counterpart MUST exist at the mirrored route
-- **AND** both pages MUST have equivalent technical content structure
-- **AND** both pages MUST have cross-references to the same related pages
-- **AND** both pages MUST have matching front matter except for language-pair metadata
-
-### Requirement: No orphaned public content exists after closeout
-All linked public content MUST resolve correctly with no missing counterparts.
-
-#### Scenario: No Orphaned Content
-- **WHEN** someone browses the closed-out site
-- **THEN** every linked public page MUST exist
-- **AND** no page MUST reference a missing counterpart
-- **AND** all cross-references MUST resolve correctly
-- **AND** every linked English public route that belongs to the mirrored documentation tree MUST have a Chinese counterpart and vice versa
diff --git a/openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/tasks.md b/openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/tasks.md
deleted file mode 100644
index 6fe0868..0000000
--- a/openspec/changes/archive/2026-05-18-rebuild-pages-whitepaper/tasks.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## 1. Docs infrastructure realignment
-
-- [x] 1.1 Align `docs/package.json`, `docs/.vitepress/config.ts`, and `docs/.vitepress/theme/index.ts` with the cleaner `kimi-cli` VitePress baseline while preserving SGEMM-specific plugins and deployment base handling
-- [x] 1.2 Replace the current public route taxonomy with a mirrored bilingual whitepaper-and-academy navigation model and update any route tests that encode the old structure
-- [x] 1.3 Introduce the shared presentation primitives, tokens, and stylesheet structure needed for the rebuilt home, architecture, academy, validation, and research surfaces
-
-## 2. Theme-safe figures and assets
-
-- [x] 2.1 Create curated SVG or equivalent theme-safe figure assets for homepage-grade and architecture-grade visuals
-- [x] 2.2 Replace fragile light/dark rendering behavior for technical visuals so diagrams, labels, and icons remain legible in both themes
-- [x] 2.3 Apply the new figure system to the highest-signal pages before removing superseded visual treatments
-
-## 3. Content architecture rebuild
-
-- [x] 3.1 Rewrite the bilingual home pages to present the project as an evidence-backed whitepaper entry instead of a generic documentation landing page
-- [x] 3.2 Reorganize existing architecture, methodology, learning, and validation content into the new mirrored route groups and add any missing academy transition pages
-- [x] 3.3 Add or expand bilingual research-oriented pages for references, related open-source projects, and architectural evolution analysis
-- [x] 3.4 Remove or merge superseded pages and update internal cross-links so the retained document set has one clear responsibility per page
-
-## 4. Repository entry alignment and validation
-
-- [x] 4.1 Rewrite `README.md` and `README.zh-CN.md` so they operate as concise executive summaries aligned with the rebuilt Pages structure
-- [x] 4.2 Run docs route tests, docs build, and `openspec validate --all`, fixing any broken links, route drift, or spec inconsistencies
-- [x] 4.3 Review the finished change for bilingual parity, closeout-stage consolidation, and public narrative coherence before handoff
diff --git a/openspec/changes/rebuild-pages-whitepaper/.openspec.yaml b/openspec/changes/rebuild-pages-whitepaper/.openspec.yaml
deleted file mode 100644
index 231e3ab..0000000
--- a/openspec/changes/rebuild-pages-whitepaper/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-05-18
diff --git a/openspec/changes/rebuild-pages-whitepaper/design.md b/openspec/changes/rebuild-pages-whitepaper/design.md
deleted file mode 100644
index 4ed6102..0000000
--- a/openspec/changes/rebuild-pages-whitepaper/design.md
+++ /dev/null
@@ -1,60 +0,0 @@
-## Context
-
-The repository already has a bilingual VitePress site with clear technical intent, but the current presentation still relies on an incremental layer of cards, ad hoc figure embedding, and route names inherited from earlier iterations. Two issues are coupled: the information architecture does not yet present the public story as a tightly defended whitepaper, and the high-signal SVG figures rely on `prefers-color-scheme` asset swapping, which can drift from the site’s manual theme toggle.
-
-The rebuild is intentionally aggressive. Backward compatibility is not a design goal. The project posture favors long-term clarity, one authoritative public story, and stronger differentiation over preserving previous route naming or visual patterns.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Make the Pages home and section indexes read like a coherent technical whitepaper for advanced readers.
-- Rebuild the visual system so the site feels deliberate, high-signal, and theme-safe in both light and dark mode.
-- Introduce a shared figure component that swaps paired SVG assets from VitePress theme state instead of browser media preference alone.
-- Expand the public content with deeper system-blueprint, performance-model, and reference-oriented wayfinding pages in both languages.
-- Encode the new IA and figure rules in docs tests so future edits do not regress silently.
-
-**Non-Goals:**
-
-- Rewriting the CUDA kernel implementation or benchmark engine itself.
-- Adding a second docs framework, client-side visualization stack, or hosted runtime dependency.
-- Preserving old visual patterns, route names, or page emphasis when they conflict with the rebuilt whitepaper direction.
-
-## Decisions
-
-### 1. Keep the existing VitePress stack and rebuild inside it
-
-The site already has mirrored locales, tested routing, and a working GitHub Pages pipeline. Replacing the framework would create migration noise without improving the core problem. The better trade-off is to keep VitePress and rebuild the theme, shared components, and curated content surfaces inside the existing pipeline.
-
-**Alternative considered:** migrate to a different static-site framework. Rejected because the current need is stronger IA and design discipline, not framework capability.
-
-### 2. Replace `<picture media="prefers-color-scheme">` with a shared theme-aware figure component
-
-The current paired SVG approach is valid, but the switching mechanism is wrong for a manual site theme toggle. A shared component registered in the VitePress theme can read `isDark` from site state and select the correct asset explicitly. This keeps the paired-asset model, which is good for high-craft SVGs, while fixing the manual-toggle bug.
-
-**Alternative considered:** merge both themes into a single SVG that depends on CSS inheritance. Rejected because the current figures are curated illustrations, and paired assets give more control over palette and contrast.
-
-### 3. Reframe the public IA as a whitepaper reading spine, not a loose doc tree
-
-The top-level navigation and section landing pages will guide readers through five jobs: orientation, system design, algorithm ladder, evidence boundary, and reference context. Existing deep-dive pages remain valuable, but section indexes become stronger editorial surfaces that route readers by intent and depth.
-
-**Alternative considered:** keep current section emphasis and only polish the homepage. Rejected because the weakness is structural, not only cosmetic.
-
-### 4. Prefer a technical publication visual language over generic doc-card patterns
-
-The redesign will use stronger contrast, more deliberate spacing rhythm, shared whitepaper panels, and fewer template-like cards or side-stripe callouts. This aligns the site with a “lab-grade whitepaper” voice and avoids the current middle ground between docs theme defaults and a custom publication surface.
-
-**Alternative considered:** stay close to the default VitePress look with light token tweaks. Rejected because it would not produce the step-change the public positioning now needs.
-
-### 5. Treat docs tests as structural contracts for the public story
-
-The existing Node test already guards route conventions. The rebuild will extend it to assert mirrored new routes, shared figure component usage, and the absence of theme-fragile `<picture>` usage on curated whitepaper figures. That gives a low-cost CI-safe contract for presentation integrity.
-
-**Alternative considered:** rely only on manual preview checks. Rejected because the site is now part of the public technical claim and needs repeatable safeguards.
-
-## Risks / Trade-offs
-
-- **Large docs diff** → Mitigation: keep all changes inside the existing docs stack, limit new primitives to a small shared component set, and mirror EN/ZH changes together.
-- **Route and nav churn** → Mitigation: update config, section indexes, and tests in the same pass so the new IA is internally consistent.
-- **Visual overreach could harm readability** → Mitigation: keep prose measure conservative, use paired SVG assets for contrast control, and preserve semantic VitePress content flows.
-- **Bilingual drift** → Mitigation: add mirrored pages in the same change and keep sidebars symmetric across locales.
diff --git a/openspec/changes/rebuild-pages-whitepaper/proposal.md b/openspec/changes/rebuild-pages-whitepaper/proposal.md
deleted file mode 100644
index e8b2c15..0000000
--- a/openspec/changes/rebuild-pages-whitepaper/proposal.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## Why
-
-The current Pages site is structurally sound, but it still reads like an incremental documentation polish instead of a decisive technical whitepaper. The repository now needs a more opinionated public surface that upgrades the reading path, fixes theme-fragile figures, and strengthens the academic and comparative framing expected by senior GitHub readers.
-
-## What Changes
-
-- Rebuild the bilingual Pages information architecture around a stronger whitepaper flow: guide, system, algorithm ladder, evidence, and references.
-- Replace theme-fragile light/dark figure handling with a site-aware shared figure system that follows manual theme switching reliably.
-- Redesign the public theme, homepage, and section index pages to feel more deliberate, technical, and publication-grade.
-- Add deeper whitepaper surfaces for system blueprint, performance framing, and reference-driven reading paths.
-- Tighten docs validation so route structure and theme-aware figure usage are checked in CI-safe tests.
-
-## Capabilities
-
-### New Capabilities
-
-None.
-
-### Modified Capabilities
-
-- `project-presentation`: strengthen the public Pages information architecture, whitepaper hierarchy, theme-safe figure behavior, and research framing.
-- `testing`: extend CI-safe documentation validation to cover the new mirrored routes and theme-aware figure conventions.
-
-## Impact
-
-- Affected code: `docs/.vitepress/*`, `docs/en/**`, `docs/zh/**`, `docs/public/figures/*`, and `docs/tests/*`
-- Affected systems: GitHub Pages build, local docs test/build workflow, OpenSpec alignment for public presentation
-- Breaking surface changes: public navigation labels, section emphasis, and some public route inventory will be reorganized for the rebuilt whitepaper flow
diff --git a/openspec/changes/rebuild-pages-whitepaper/specs/project-presentation/spec.md b/openspec/changes/rebuild-pages-whitepaper/specs/project-presentation/spec.md
deleted file mode 100644
index cec6f5c..0000000
--- a/openspec/changes/rebuild-pages-whitepaper/specs/project-presentation/spec.md
+++ /dev/null
@@ -1,40 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Public whitepaper information architecture is curated by reader depth
-The GitHub Pages site MUST present the project through a mirrored bilingual information architecture that guides readers from orientation to system design, optimization study, evidence review, and research context instead of exposing a loosely grouped set of topical pages.
-
-#### Scenario: Reader lands on the home page without repository context
-- **WHEN** a visitor opens the English or Chinese home page
-- **THEN** the page MUST summarize the project thesis, system blueprint, optimization ladder, and evidence model
-- **AND** the page MUST provide direct paths into deeper guide, architecture, academy, validation, and research sections
-
-#### Scenario: Reader follows the intended reading spine
-- **WHEN** a visitor uses top-level navigation, sidebars, or section landing pages
-- **THEN** the documentation structure MUST separate orientation, system architecture, algorithm-study surfaces, evidence framing, and reference context into distinct mirrored route groups
-- **AND** each section landing page MUST clarify who it is for, what it answers, and what page should be opened next
-
-### Requirement: Technical figures remain legible across themes
-All high-signal public technical figures MUST remain readable, visually coherent, and semantically equivalent in both light mode and dark mode, including when the visitor changes theme from the site’s manual theme switcher.
-
-#### Scenario: Visitor switches between light and dark mode
-- **WHEN** the site theme changes through system preference or the VitePress theme toggle
-- **THEN** diagrams, SVG illustrations, icons, and figure labels MUST preserve sufficient contrast for text, boundaries, and emphasis
-- **AND** the rendered figure variant MUST follow the active site theme instead of relying only on browser-level `prefers-color-scheme`
-
-#### Scenario: Architecture page uses a curated figure
-- **WHEN** a page renders a custom architecture or whitepaper figure
-- **THEN** the figure MUST use a shared site component or equivalent shared convention for paired theme-safe assets
-- **AND** the figure MUST remain understandable without assuming one background color or one contrast profile
-
-### Requirement: Public research context is explicit and traceable
-The documentation site MUST provide academic-style context that links project claims to references, related open-source implementations, comparative reading paths, and architectural evolution notes.
-
-#### Scenario: Reader investigates technical lineage
-- **WHEN** a reader opens the research-oriented section from site navigation
-- **THEN** the site MUST include structured references grouped by purpose
-- **AND** the site MUST include at least one related-project or comparative-analysis surface
-- **AND** the site MUST include at least one evolution-oriented explanation of why the project architecture is organized as it is
-
-#### Scenario: Reader wants a guided reference path
-- **WHEN** a reader approaches the research section from the home page or a section index
-- **THEN** the site MUST provide a curated path that distinguishes canonical references, comparative open-source context, and further reading routes
diff --git a/openspec/changes/rebuild-pages-whitepaper/specs/testing/spec.md b/openspec/changes/rebuild-pages-whitepaper/specs/testing/spec.md
deleted file mode 100644
index 4b98c52..0000000
--- a/openspec/changes/rebuild-pages-whitepaper/specs/testing/spec.md
+++ /dev/null
@@ -1,13 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Repository validation includes governance integrity
-The repository test and validation model MUST cover not only code correctness but also the integrity of governance, documentation structure, mirrored public routes, and theme-aware figure conventions.
-
-#### Scenario: Governance-related files change
-- **WHEN** OpenSpec files, workflow files, governance documents, or documentation structure are modified
-- **THEN** the repository MUST provide CI-safe validation that checks the relevant specification and structural invariants before those changes are treated as complete
-
-#### Scenario: Whitepaper presentation surfaces are reorganized
-- **WHEN** Pages navigation, mirrored route inventory, or curated figure embedding changes
-- **THEN** CI-safe docs tests MUST verify that the mirrored public routes still exist
-- **AND** those tests MUST verify that curated whitepaper figures use the shared theme-aware convention instead of theme-fragile ad hoc markup
diff --git a/openspec/changes/rebuild-pages-whitepaper/tasks.md b/openspec/changes/rebuild-pages-whitepaper/tasks.md
deleted file mode 100644
index 141a222..0000000
--- a/openspec/changes/rebuild-pages-whitepaper/tasks.md
+++ /dev/null
@@ -1,21 +0,0 @@
-## 1. Validation-first setup
-
-- [ ] 1.1 Extend docs tests to fail until the rebuilt IA routes and shared figure convention exist
-- [ ] 1.2 Create the new mirrored route files and wire them into the VitePress sidebar structure
-
-## 2. Theme and figure system
-
-- [ ] 2.1 Add a shared theme-aware figure component and register it in the VitePress theme
-- [ ] 2.2 Rebuild the docs CSS tokens and publication layout for the new whitepaper visual language
-- [ ] 2.3 Refresh the paired SVG figure assets for both themes
-
-## 3. Public content rebuild
-
-- [ ] 3.1 Rewrite the English and Chinese home pages around the new whitepaper reading spine
-- [ ] 3.2 Rewrite the guide, architecture, academy, validation, and research landing pages in both languages
-- [ ] 3.3 Add the new mirrored deep-link pages for system blueprint, performance model, and reference-oriented reading
-
-## 4. Closeout validation
-
-- [ ] 4.1 Run docs tests and docs build
-- [ ] 4.2 Run OpenSpec validation and review the final git diff for consistency
diff --git a/openspec/changes/revamp-public-presentation/.openspec.yaml b/openspec/changes/revamp-public-presentation/.openspec.yaml
deleted file mode 100644
index 93831bd..0000000
--- a/openspec/changes/revamp-public-presentation/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-05-13
diff --git a/openspec/changes/revamp-public-presentation/design.md b/openspec/changes/revamp-public-presentation/design.md
deleted file mode 100644
index 7bbade9..0000000
--- a/openspec/changes/revamp-public-presentation/design.md
+++ /dev/null
@@ -1,85 +0,0 @@
-## Context
-
-The repository is in closeout mode, which means public quality now depends more on coherence than on adding new kernel features. Current docs already cover the technical ladder, but entry surfaces are still distributed across generic pages that do not explicitly answer two high-value questions:
-
-1. Why this project is different from many SGEMM learning repos.
-2. How a candidate should present this work in interview settings with evidence.
-
-At the same time, OpenSpec requires bilingual mirroring and single-source responsibilities, so the redesign must improve impact without introducing duplicated, drifting documentation.
-
-## Goals / Non-Goals
-
-**Goals:**
-
-- Build an interview-grade public narrative that starts from proof (benchmarks, verification, constraints) rather than slogans.
-- Introduce explicit citation and repository-reference structure so readers can trace each major claim to authoritative sources.
-- Keep English/Chinese pages mirrored by structure and intent, while allowing language-native wording.
-- Keep visual style recognizably technical with light NVIDIA-inspired cues (green accents, structured cards, metric blocks) without over-branding.
-- Align README and Pages so users get one consistent story regardless of entry point.
-
-**Non-Goals:**
-
-- No changes to CUDA kernels, benchmark logic, or test tolerances.
-- No replacement of VitePress stack or workflow topology.
-- No attempt to clone NVIDIA brand assets, typography, or proprietary visual materials.
-- No broad governance rewrite outside project-presentation deltas required by this change.
-
-## Decisions
-
-### Decision 1: Add three presentation rails as first-class pages
-
-- **Choice**: Add `project-highlights`, `interview-playbook`, and `references` in both languages.
-- **Why**: Existing pages teach optimization steps well but do not package the project as a differentiated engineering artifact.
-- **Alternative considered**: Embedding all content into home page sections.
-- **Rejected because**: Home page would become too long, and high-value interview/reference content would be harder to discover and maintain.
-
-### Decision 2: Keep mirrored bilingual architecture at the navigation level
-
-- **Choice**: Update navbar/sidebar so EN and ZH contain one-to-one page counterparts.
-- **Why**: This directly satisfies the stable bilingual requirements and prevents orphaned content.
-- **Alternative considered**: EN-first structure with selective ZH translation.
-- **Rejected because**: Violates current project-presentation expectations for mirrored public surfaces.
-
-### Decision 3: Use “evidence-first” storytelling blocks on homepage
-
-- **Choice**: Home page structure emphasizes benchmark context, correctness boundary, and optimization progression.
-- **Why**: Interviewers and advanced readers trust evidence framing more than generic feature claims.
-- **Alternative considered**: Marketing-style hero with minimal technical details.
-- **Rejected because**: Undermines the project’s engineering credibility.
-
-### Decision 4: Lightly evolve existing theme rather than replace it
-
-- **Choice**: Refine current CSS variable system and components; introduce stronger hierarchy, card polish, and mobile-friendly readability.
-- **Why**: Lower risk and faster convergence while preserving existing VitePress compatibility.
-- **Alternative considered**: Full theme rewrite with custom Vue components.
-- **Rejected because**: Higher maintenance and unnecessary complexity for closeout-stage goals.
-
-## Risks / Trade-offs
-
-- **[Risk]** More pages can increase maintenance burden for bilingual parity.  
-  **Mitigation**: Keep each page scoped with single responsibility and mirrored sections.
-
-- **[Risk]** Stronger visual styling might reduce content density.  
-  **Mitigation**: Keep typography conservative in article pages; concentrate visual emphasis on home and summary cards.
-
-- **[Risk]** Spec delta and implementation may drift if done in separate passes.  
-  **Mitigation**: Implement documentation and spec delta in one apply session, then run `openspec validate --all`.
-
-- **[Risk]** External reference links may break over time.  
-  **Mitigation**: Prefer canonical URLs (NVIDIA docs, official papers, mature repos) and keep links grouped for periodic audits.
-
-## Migration Plan
-
-1. Update VitePress config for new nav/sidebar architecture.
-2. Add mirrored EN/ZH pages (highlights/interview/references).
-3. Rewrite EN/ZH home pages to evidence-first layout.
-4. Refresh theme styles for light NVIDIA-inspired visual consistency.
-5. Update README and README.zh-CN to match new entry narrative and corrected internal links.
-6. Add OpenSpec project-presentation delta for new normative expectations.
-7. Validate with docs build and OpenSpec checks before final handoff.
-
-Rollback strategy: revert documentation and OpenSpec delta files in a single commit if build/validation cannot be stabilized.
-
-## Open Questions
-
-- None blocking. The requested style level (“light inspiration”) and scope (“whole-repo aligned redesign”) are explicit.
diff --git a/openspec/changes/revamp-public-presentation/proposal.md b/openspec/changes/revamp-public-presentation/proposal.md
deleted file mode 100644
index 9c67f82..0000000
--- a/openspec/changes/revamp-public-presentation/proposal.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## Why
-
-The project already has solid CUDA implementation depth, but its public presentation still undersells that depth for two key audiences: interviewers and advanced community readers. The repository and Pages surfaces also need tighter narrative alignment so visitors can quickly understand both technical value and engineering rigor.
-
-## What Changes
-
-- Restructure GitHub Pages information architecture around three high-signal tracks: project highlights, interview playbook, and references.
-- Rewrite bilingual home pages to combine visual clarity, benchmark credibility, and direct learning paths.
-- Add mirrored English/Chinese pages for highlights, interview storytelling, and paper/repo references.
-- Refresh VitePress theme styling with a lighter NVIDIA-inspired visual language while preserving readability and mobile usability.
-- Align README and README.zh-CN with the new Pages narrative and fix stale documentation links.
-- Add an OpenSpec delta to capture interview-readiness and citation-quality expectations in project presentation requirements.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `project-presentation`: Tighten requirements so README, Pages structure, bilingual mirrors, interview-readiness, and public references remain consistent and evidence-backed.
-
-## Impact
-
-- Affected documentation surfaces: `docs/.vitepress/*`, `docs/en/*`, `docs/zh/*`, `README.md`, `README.zh-CN.md`
-- Affected governance artifacts: `openspec/changes/revamp-public-presentation/specs/project-presentation/spec.md`
-- Validation impact: `npm --prefix docs run build` and `openspec validate --all` become mandatory closeout checks for this change.
diff --git a/openspec/changes/revamp-public-presentation/specs/project-presentation/spec.md b/openspec/changes/revamp-public-presentation/specs/project-presentation/spec.md
deleted file mode 100644
index 9d3af3b..0000000
--- a/openspec/changes/revamp-public-presentation/specs/project-presentation/spec.md
+++ /dev/null
@@ -1,60 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Public project narrative is interview-ready and evidence-backed
-Public entry surfaces MUST communicate the project as an engineering case study that can be defended in technical interviews with concrete evidence.
-
-#### Scenario: Interviewer scans repository entry quickly
-- **WHEN** an interviewer reads `README.md` or `README.zh-CN.md`
-- **THEN** the entry MUST summarize the optimization ladder, correctness boundary, and validation model in concise technical language
-- **AND** the entry MUST provide direct links to Pages sections that contain deeper proof and implementation context
-
-#### Scenario: Visitor asks how claims are substantiated
-- **WHEN** a visitor follows public documentation links from README or home pages
-- **THEN** the linked pages MUST include benchmark framing, verification constraints, and explicit scope notes
-- **AND** performance claims MUST avoid implying universal guarantees across all hardware and workloads
-
-### Requirement: Public references are structured and traceable
-The documentation site MUST provide a dedicated references surface that maps project ideas to authoritative papers, official documentation, and high-signal open-source repositories.
-
-#### Scenario: Reader validates technical lineage
-- **WHEN** a reader opens the references page from navigation
-- **THEN** references MUST be grouped by purpose (for example: architecture background, kernel optimization practice, Tensor Core programming)
-- **AND** each group MUST include at least one canonical source URL
-- **AND** references MUST be presented in both English and Chinese public surfaces
-
-## MODIFIED Requirements
-
-### Requirement: Repository entry points have distinct roles
-The project MUST present itself through distinct entry surfaces so that each one serves a clear audience and does not duplicate another surface unnecessarily.
-
-#### Scenario: New visitor lands on the repository or project site
-- **WHEN** a user opens `README.md` or the GitHub Pages site
-- **THEN** the repository MUST provide a concise explanation of the project's value, core technical highlights, and clear navigation to deeper documentation without mirroring the same long-form content across both surfaces
-- **AND** the Pages home experience MUST prioritize quick orientation, evidence summary, and clear paths to detailed technical pages
-
-### Requirement: Repository entry surfaces support bilingual navigation
-The repository MUST provide clear entry points for both English and Chinese readers with consistent structure across both README files.
-
-#### Scenario: Bilingual Repository Entry
-- **WHEN** a visitor lands on the GitHub repository root
-- **THEN** the repository MUST present `README.md` as the default English entry
-- **AND** the repository MUST show a prominent link to `README.zh-CN.md` for Chinese readers
-- **AND** both files MUST have consistent structure and navigation tables
-- **AND** both files MUST link to equivalent English and Chinese documentation routes on the published site
-
-### Requirement: Tutorial pages have mirrored counterparts
-Every tutorial page in English MUST have a Chinese counterpart with equivalent content structure.
-
-#### Scenario: Tutorial Pages Stay Mirrored
-- **WHEN** a tutorial page exists in English at `/en/kernel-naive` with a Chinese counterpart at `/zh/kernel-naive`
-- **THEN** both pages MUST have equivalent technical content
-- **AND** both pages MUST have cross-references to the same related pages
-- **AND** both pages MUST have matching front matter except for language-pair metadata
-
-### Requirement: Workflow triggers cover bilingual public surfaces
-The GitHub Pages workflow MUST rebuild when public bilingual content changes.
-
-#### Scenario: Workflow Triggers Updated
-- **WHEN** any `docs/**`, `zh/**`, `_includes/**`, `_sass/**`, `assets/**`, root landing page, or specs landing file changes
-- **THEN** the GitHub Pages workflow MUST trigger a rebuild
-- **AND** the published site MUST reflect changes
diff --git a/openspec/changes/revamp-public-presentation/tasks.md b/openspec/changes/revamp-public-presentation/tasks.md
deleted file mode 100644
index 5425bc0..0000000
--- a/openspec/changes/revamp-public-presentation/tasks.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## 1. Information Architecture and Theme Baseline
-
-- [x] 1.1 Update VitePress locale nav and sidebar to include mirrored EN/ZH routes for highlights, interview playbook, and references.
-- [x] 1.2 Refresh shared theme styling with light NVIDIA-inspired visual hierarchy while preserving readability and mobile usability.
-- [x] 1.3 Verify that all newly linked routes exist in both language trees before content rewrites.
-
-## 2. Bilingual Content Rewrite and New Public Pages
-
-- [x] 2.1 Rewrite `docs/en/index.md` and `docs/zh/index.md` to an evidence-first home layout with benchmark, correctness, and learning-path entry blocks.
-- [x] 2.2 Add mirrored `project-highlights` pages in English and Chinese with differentiated project strengths and engineering conventions.
-- [x] 2.3 Add mirrored `interview-playbook` pages in English and Chinese with presentation storyline, deep-dive questions, and answer framing.
-- [x] 2.4 Add mirrored `references` pages in English and Chinese with structured paper/doc/repo citations tied to project decisions.
-
-## 3. Repository Entry Alignment
-
-- [x] 3.1 Rewrite `README.md` as an entry surface aligned with the new Pages architecture and corrected internal links.
-- [x] 3.2 Rewrite `README.zh-CN.md` with the same structure, mirrored navigation, and corrected Chinese link targets.
-- [x] 3.3 Ensure README and Pages claims use consistent wording for validation boundaries and benchmark scope.
-
-## 4. Validation and OpenSpec Consistency
-
-- [x] 4.1 Run `npm --prefix docs run build` and fix broken links, missing pages, or front-matter inconsistencies.
-- [x] 4.2 Run `openspec validate --all` and resolve any spec-format or delta-merge issues.
-- [x] 4.3 Mark all completed tasks and produce a concise change summary with affected files and verification outputs.
diff --git a/openspec/config.yaml b/openspec/config.yaml
deleted file mode 100644
index e12fa38..0000000
--- a/openspec/config.yaml
+++ /dev/null
@@ -1,55 +0,0 @@
-schema: spec-driven
-
-project:
-  name: SGEMM Optimization
-  description: Closeout-stage CUDA SGEMM tutorial and optimization reference
-  version: 2.1.0
-
-spec_dirs:
-  stable: openspec/specs/
-  delta: openspec/changes/
-
-conventions:
-  id_prefixes:
-    requirement: "REQ-"
-    decision: "DEC-"
-    constraint: "CON-"
-  change_naming:
-    style: kebab-case
-  workflow:
-    prefer_single_long_apply: true
-    avoid_fleet_by_default: true
-
-context: |
-  Language: English (primary), Chinese (secondary)
-  Tech Stack: CUDA C++17, CMake, Google Test, GitHub Actions, Jekyll Pages
-  GPU Architectures: sm_70, sm_75, sm_80, sm_86, sm_89, sm_90
-
-  Project posture:
-  - Closeout-oriented: prefer consolidation over feature expansion
-  - OpenSpec is the authoritative governance and requirements system
-  - README is the repository entry point
-  - GitHub Pages is the public landing page plus documentation entry
-  - OpenSpec files define normative engineering and process rules
-
-  Code and validation:
-  - clang-format enforced
-  - RAII for all resource management
-  - Exception-based error handling (no exit() in library code)
-  - Template-based kernel interfaces with default TILE_SIZE=32
-  - Standard FP32 tolerance: rtol=1e-3, atol=1e-4
-  - Tensor Core tolerance: rtol=5e-2, atol=1e-2
-
-rules:
-  proposal:
-    - Keep proposals tightly scoped to one coherent outcome.
-    - Describe repository-facing impact and cleanup intent, not implementation detail.
-  specs:
-    - Use ADDED, MODIFIED, REMOVED, or RENAMED sections exactly.
-    - Treat openspec/specs/<capability>/spec.md as the stable authoritative location.
-  design:
-    - Explain cross-cutting technical choices and alternatives.
-    - Prefer repository architecture, process, and validation rationale over file-by-file detail.
-  tasks:
-    - Order tasks by dependency and validation path.
-    - Prefer longer serial apply sessions over fleet fan-out unless the work is naturally parallel.
diff --git a/openspec/specs/architecture/spec.md b/openspec/specs/architecture/spec.md
deleted file mode 100644
index a04165e..0000000
--- a/openspec/specs/architecture/spec.md
+++ /dev/null
@@ -1,296 +0,0 @@
-# Architecture Specification
-
-> **Version**: 2.1.0 | **Last Updated**: 2026-04-23 | **Status**: Complete
-
-## Purpose
-
-Define system architecture decisions and implementation roadmap for the SGEMM optimization project. This document consolidates RFC 0001 (Core Architecture) and RFC 0002 (Implementation Roadmap).
-
-## Requirements
-
-### Requirement: Three-Layer Architecture
-The system SHALL follow a three-layer architecture pattern for clean separation of concerns.
-
-#### Scenario: Application layer provides user interface
-- **WHEN** a user runs the benchmark or verification
-- **THEN** the application layer SHALL orchestrate benchmark, verification, and CLI parsing
-
-#### Scenario: Kernel layer provides implementations
-- **WHEN** matrix multiplication is requested
-- **THEN** the kernel layer SHALL provide five progressive optimization implementations
-
-#### Scenario: Utility layer provides infrastructure
-- **WHEN** any kernel executes
-- **THEN** the utility layer SHALL provide RAII memory management and error handling
-
-### Requirement: Unified Kernel Interface
-All kernels SHALL conform to a unified template interface for seamless swapping.
-
-#### Scenario: Consistent kernel launch signature
-- **WHEN** a kernel is invoked
-- **THEN** it SHALL accept (A, B, C, M, K, N, stream) parameters with consistent types
-
-### Requirement: Published architecture matches the real repository structure
-The repository architecture guidance MUST describe only the directory structure, documentation boundaries, and engineering surfaces that actually exist and are maintained.
-
-#### Scenario: Contributor consults architecture guidance
-- **WHEN** a contributor reads architecture-facing documentation or specifications
-- **THEN** all referenced repository paths, layers, and responsibilities MUST correspond to the real maintained layout and MUST NOT reference stale or superseded structures as authoritative
-
-### Requirement: Engineering boundaries are explicit
-The repository architecture MUST make local-only and CI-safe responsibilities explicit so maintainers can reason correctly about build, test, and validation coverage.
-
-#### Scenario: Contributor decides how to validate a change
-- **WHEN** a contributor evaluates required validation steps for code, docs, specs, or workflow changes
-- **THEN** the architecture guidance MUST clearly distinguish local GPU-dependent verification from CI-safe compile, structure, and publication checks
-
----
-
-## Design Decisions
-**Date**: 2026-04-16
-**Status**: Active
-**Source**: RFC 0001
-
-**Decision**: System follows three layers:
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│                         main.cu                                  │
-│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐              │
-│  │  Benchmark  │  │   Verify    │  │  CLI Parser │              │
-│  └──────┬──────┘  └──────┬──────┘  └─────────────┘              │
-└─────────┼────────────────┼──────────────────────────────────────┘
-          │                │
-          ▼                ▼
-┌─────────────────────────────────────────────────────────────────┐
-│                    Kernel Implementations                        │
-│  ┌────────┐ ┌────────┐ ┌────────────┐ ┌─────────────┐ ┌───────┐ │
-│  │ Naive  │ │ Tiled  │ │ Bank-Free  │ │ Dbl-Buffer  │ │ TC    │ │
-│  └────────┘ └────────┘ └────────────┘ └─────────────┘ └───────┘ │
-└─────────────────────────────────────────────────────────────────┘
-          │                │
-          ▼                ▼
-┌─────────────────────────────────────────────────────────────────┐
-│                      cuBLAS Reference                            │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-1. **Application Layer** (`main.cu`) - Benchmark, Verify, CLI
-2. **Kernel Layer** (`src/kernels/`) - 5 kernel implementations
-3. **Utility Layer** (`src/utils/`) - RAII, error handling, verification
-
-**Rationale**: Clean separation enables independent testing and benchmarking.
-
----
-
-### DEC-ARCH-002: Unified Kernel Interface
-**Date**: 2026-04-16
-**Status**: Active
-**Source**: RFC 0001
-
-**Decision**: All kernels conform to a unified template interface:
-
-```cpp
-template<int TILE_SIZE = 32>
-void launch_xxx_sgemm(
-    const float* A,      // M×K input matrix
-    const float* B,      // K×N input matrix
-    float* C,            // M×N output matrix
-    int M, int K, int N,
-    cudaStream_t stream = 0
-);
-```
-
-**Rationale**: Enables seamless kernel swapping and uniform testing.
-
----
-
-### DEC-ARCH-003: Exception-Based Error Handling
-**Date**: 2026-04-16
-**Status**: Active
-**Source**: RFC 0001
-
-**Decision**: Use exceptions, not `exit()`, for error handling.
-
-```cpp
-struct CudaError : std::runtime_error {
-    explicit CudaError(const std::string& msg) : std::runtime_error(msg) {}
-};
-
-#define CUDA_CHECK(call) \
-    do { \
-        cudaError_t err = call; \
-        if (err != cudaSuccess) { \
-            throw CudaError(cudaGetErrorString(err)); \
-        } \
-    } while(0)
-```
-
-**Rationale**: Ensures RAII cleanup correctness; destructors always run.
-
----
-
-### DEC-ARCH-004: Kernel Organization
-**Date**: 2026-04-16
-**Status**: Active
-**Source**: RFC 0001
-
-**Decision**: Each optimization level has separate kernel file:
-
-| Kernel | File | Optimization Technique |
-|--------|------|----------------------|
-| Naive | `naive_sgemm.cuh` | Basic triple-loop; baseline implementation |
-| Tiled | `tiled_sgemm.cuh` | Shared memory blocking for data reuse |
-| Bank-Free | `bank_conflict_free_sgemm.cuh` | Shared memory padding to eliminate bank conflicts |
-| Double-Buffer | `double_buffer_sgemm.cuh` | Dual buffers to overlap compute and memory transfers |
-| Tensor Core | `tensor_core_sgemm.cuh` | WMMA API for mixed-precision FP16→FP32 compute |
-
-**Rationale**: Enables incremental learning and allows performance comparison between approaches.
-
----
-
-## Implementation Roadmap
-
-### Phase Status
-
-| Phase | Description | Status |
-|-------|-------------|--------|
-| 1 | Project Infrastructure | Complete |
-| 2 | Kernel Implementation | Complete |
-| 3 | Utility Infrastructure | Complete |
-| 4 | Testing Suite | Complete |
-| 5 | Build System & CI/CD | Complete |
-| 6 | Documentation | Complete |
-| 7 | Code Quality & Refinement | Complete |
-
-**Current Version**: 2.1.0 - All phases complete.
-
----
-
-### Phase 1: Project Infrastructure ✅
-
-**Completed Tasks**:
-- [x] Project directory structure setup
-- [x] `.gitignore` configuration (CUDA/Profiling/IDE rules)
-- [x] `.editorconfig` for consistent code formatting
-- [x] MIT LICENSE file
-
-**Deliverables**: `.gitignore`, `.editorconfig`, `LICENSE`
-
----
-
-### Phase 2: Kernel Implementation ✅
-
-**Completed Tasks**:
-- [x] `naive_sgemm.cuh` — Basic triple-loop baseline implementation
-- [x] `tiled_sgemm.cuh` — Shared memory blocking for data reuse
-- [x] `bank_conflict_free_sgemm.cuh` — Shared memory padding to eliminate bank conflicts
-- [x] `double_buffer_sgemm.cuh` — Dual buffer pipeline for compute/memory overlap
-- [x] `tensor_core_sgemm.cuh` — WMMA API for mixed-precision FP16→FP32
-
-**Deliverables**: Five kernel implementations in `src/kernels/`
-
----
-
-### Phase 3: Utility Infrastructure ✅
-
-**Completed Tasks**:
-- [x] `cuda_utils.cuh` — RAII wrappers and exception-based error handling
-- [x] `verify.cuh` — Correctness verification against cuBLAS reference
-- [x] `benchmark.cuh` — Performance measurement framework using CUDA Events
-
-**Deliverables**: Three utility modules in `src/utils/`
-
----
-
-### Phase 4: Testing Suite ✅
-
-**Completed Tasks**:
-- [x] `test_sgemm.cu` — Google Test unit tests for all kernels
-- [x] Property-based tests covering 100+ random dimension combinations
-- [x] Tensor Core fallback tests for non-aligned dimensions
-- [x] Edge case tests (1×1×1, unaligned sizes)
-
-**Deliverables**: `tests/test_sgemm.cu`
-
----
-
-### Phase 5: Build System & CI/CD ✅
-
-**Completed Tasks**:
-- [x] `CMakeLists.txt` — Primary CMake build system
-- [x] `Makefile` — Quick local build alternative
-- [x] `.github/workflows/ci.yml` — Format checks and containerized CUDA compile
-- [x] `.github/workflows/pages.yml` — GitHub Pages deployment
-
-**Deliverables**: `CMakeLists.txt`, `Makefile`, CI/CD workflows
-
----
-
-### Phase 6: Documentation ✅
-
-**Completed Tasks**:
-- [x] `README.md` — English documentation
-- [x] `README.zh-CN.md` — Chinese documentation
-- [x] `CHANGELOG.md` — Version history following Keep a Changelog format
-- [x] `index.md` — GitHub Pages landing page
-- [x] `_config.yml` — Jekyll configuration
-
-**Deliverables**: All documentation files at project root
-
----
-
-### Phase 7: Code Quality & Refinement ✅
-
-**Completed Tasks**:
-- [x] **v2.0.0**: RAII refactoring across all kernels; exception-based error handling replacing `exit()` calls
-- [x] **v2.1.0**: Dead code cleanup — removed 514 lines across 7 source files
-
-**Deliverables**: Cleaner, more maintainable codebase
-
----
-
-## Milestone Timeline
-
-| Version | Date | Milestone | Key Changes |
-|---------|------|-----------|-------------|
-| 1.0.0 | 2025-02-13 | Project Initialization | MIT license, `.gitignore`, `.editorconfig`, basic README |
-| 2.0.0-rc.1 | 2026-03-09 | Memory Leak Fixes | RAII refactoring, CMake build, self-contained project |
-| 2.0.0-rc.2 | 2026-03-10 | GitHub Pages | Pages configuration, landing page, documentation enhancements |
-| 2.0.0 | 2026-03-13 | Stable Release | CPU-safe CI workflow, format checks, containerized build validation |
-| 2.1.0 | 2026-04-16 | Documentation & Code Cleanup | Dead code removal (514 lines), spec documentation reorganization |
-
----
-
-## Constraints
-
-### CON-ARCH-001: Supported GPU Architectures
-
-| GPU | Architecture | Compute Capability | Build Flag |
-|-----|-------------|-------------------|------------|
-| Tesla V100 | Volta | sm_70 | `GPU_ARCH=sm_70` |
-| RTX 2080 | Turing | sm_75 | `GPU_ARCH=sm_75` |
-| RTX 3090 / A100 | Ampere | sm_80 / sm_86 | `GPU_ARCH=sm_86` |
-| RTX 4090 / L40 | Ada Lovelace | sm_89 | `GPU_ARCH=sm_89` |
-| H100 | Hopper | sm_90 | `GPU_ARCH=sm_90` |
-
-### CON-ARCH-002: Build Commands
-
-```bash
-# CMake (recommended)
-cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
-cmake --build build -j$(nproc)
-
-# Makefile (quick local)
-make GPU_ARCH=sm_86
-make benchmark
-make test
-```
-
----
-
-## References
-
-- [CUDA C++ Programming Guide](https://docs.nvidia.com/cuda/cuda-c-programming-guide/)
-- [WMMA API Reference](https://docs.nvidia.com/cuda/cuda-c-api/group__CUDA__WMMA.html)
-- [CUTLASS](https://github.com/NVIDIA/cutlass) — NVIDIA's high-performance GEMM library
diff --git a/openspec/specs/kernel/spec.md b/openspec/specs/kernel/spec.md
deleted file mode 100644
index b5bb7da..0000000
--- a/openspec/specs/kernel/spec.md
+++ /dev/null
@@ -1,152 +0,0 @@
-# Kernel Specification
-
-> **Version**: 2.1.0 | **Last Updated**: 2026-04-16 | **Status**: Complete
-
-## Purpose
-
-Define the functional requirements for SGEMM kernel implementations covering five progressive optimization techniques from naive triple-loop to Tensor Core WMMA acceleration.
-
-## Requirements
-
-### Requirement: Kernel Implementations
-The project SHALL implement five CUDA SGEMM kernel variants with progressive optimization techniques.
-
-#### Scenario: Five kernel variants available
-- **WHEN** a user builds the project
-- **THEN** five kernel implementations SHALL be available: Naive, Tiled, Bank-Free, Double-Buffer, and Tensor Core
-
-### Requirement: Correctness Verification
-All kernels SHALL match cuBLAS reference output within specified tolerances.
-
-#### Scenario: Standard FP32 kernels correctness
-- **WHEN** any standard FP32 kernel (Naive, Tiled, Bank-Free, Double-Buffer) is executed
-- **THEN** the output SHALL match cuBLAS with rtol=1e-3, atol=1e-4
-
-#### Scenario: Tensor Core kernel correctness
-- **WHEN** the Tensor Core kernel is executed with aligned dimensions
-- **THEN** the output SHALL match cuBLAS with rtol=5e-2, atol=1e-2
-
----
-
-## Detailed Requirements
-
-### REQ-KERNEL-001: Kernel Implementations
-**Status**: Active
-**Priority**: High
-**Source**: FR-1 (Product Requirements)
-
-The project SHALL implement five CUDA SGEMM kernel variants:
-
-| ID | Requirement | Status |
-|----|-------------|--------|
-| REQ-KERNEL-001.1 | **Naive Kernel**: Basic triple-loop, one output per thread | Complete |
-| REQ-KERNEL-001.2 | **Tiled Kernel**: Shared memory blocking for data reuse | Complete |
-| REQ-KERNEL-001.3 | **Bank-Free Kernel**: Padding to eliminate bank conflicts | Complete |
-| REQ-KERNEL-001.4 | **Double-Buffer Kernel**: Dual buffers for compute/memory overlap | Complete |
-| REQ-KERNEL-001.5 | **Tensor Core Kernel**: WMMA API for FP16→FP32 | Complete |
-
-**Acceptance Criteria**:
-- [x] All 5 kernel implementations complete and functional
-- [x] Each kernel in separate file under `src/kernels/`
-
----
-
-### REQ-KERNEL-002: Correctness Verification
-**Status**: Active
-**Priority**: High
-**Source**: FR-2 (Product Requirements)
-
-All kernels must match cuBLAS reference output.
-
-**Tolerances**:
-
-| Kernel Type | Relative Tolerance (rtol) | Absolute Tolerance (atol) |
-|-------------|--------------------------|--------------------------|
-| Standard FP32 (Naive, Tiled, Bank-Free, Double-Buffer) | 1e-3 | 1e-4 |
-| Tensor Core (FP16→FP32 mixed precision) | 5e-2 | 1e-2 |
-
-**Acceptance Criteria**:
-- [x] All kernels pass cuBLAS comparison
-- [x] Property-based tests cover 100+ dimension combinations
-
----
-
-### REQ-KERNEL-003: Performance Benchmark
-**Status**: Active
-**Priority**: Medium
-**Source**: FR-3 (Product Requirements)
-
-The project shall provide benchmarking infrastructure to measure and compare kernel performance.
-
-**Acceptance Criteria**:
-- [x] CUDA Events-based timing for accurate GPU measurement
-- [x] GFLOPS calculation and reporting
-- [x] Performance comparison against cuBLAS baseline
-- [x] Roofline model data export for performance analysis
-
----
-
-### REQ-KERNEL-004: Build System Support
-**Status**: Active
-**Priority**: High
-**Source**: FR-4 (Product Requirements)
-
-**Acceptance Criteria**:
-- [x] CMake build system (primary, recommended)
-- [x] Makefile for quick local builds
-- [x] Multi-GPU architecture support: sm_70, sm_75, sm_80, sm_86, sm_89, sm_90
-
----
-
-## Constraints
-
-### CON-KERNEL-001: CUDA Compatibility
-- Target: CUDA 11.0+
-- Compute Capability: 7.0+ (Volta through Hopper)
-- Memory: Must operate within GPU memory limits
-
-### CON-KERNEL-002: Build Systems
-```bash
-# CMake (primary)
-cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
-cmake --build build -j$(nproc)
-
-# Makefile (quick)
-make GPU_ARCH=sm_86
-```
-
-### CON-KERNEL-003: Educational Focus
-- Code MUST be readable and well-commented
-- Each optimization level MUST be independently compilable
-- Progressive complexity for learning purposes
-
----
-
-## Benchmark Configuration
-
-Default benchmark matrix includes:
-
-- **Aligned square cases**: `512×512×512`, `1024×1024×1024`
-- **Aligned non-square case**: `256×384×640`
-- **Unaligned edge case**: `511×513×1025` (exercises Tensor Core fallback path)
-
----
-
-## Performance Expectations
-
-| Stage | Kernel | Technique | Expected Speedup |
-|-------|--------|-----------|------------------|
-| 1 | Naive | Baseline | 1× |
-| 2 | Tiled | Shared memory blocking | ~1.2-1.5× |
-| 3 | Bank-Free | Bank conflict elimination | ~1.1× over Tiled |
-| 4 | Double-Buffer | Compute/memory overlap | ~1.1× over Bank-Free |
-| 5 | Tensor Core | WMMA API | ~3-4× over Double-Buffer |
-
----
-
-## References
-
-- [CUDA C++ Programming Guide](https://docs.nvidia.com/cuda/cuda-c-programming-guide/)
-- [WMMA API Reference](https://docs.nvidia.com/cuda/cuda-c-api/group__CUDA__WMMA.html)
-- [CUTLASS](https://github.com/NVIDIA/cutlass) — NVIDIA's high-performance GEMM library
-- [How to Optimize a CUDA Matmul Kernel](https://siboehm.com/articles/22/CUDA-MMM) — Simon Boehm
diff --git a/openspec/specs/project-presentation/spec.md b/openspec/specs/project-presentation/spec.md
deleted file mode 100644
index 998c9a6..0000000
--- a/openspec/specs/project-presentation/spec.md
+++ /dev/null
@@ -1,119 +0,0 @@
-# Project Presentation Specification
-
-> **Version**: 1.1.0 | **Last Updated**: 2026-05-18 | **Status**: Complete
-
-## Purpose
-
-Define how the repository presents the project through README, GitHub Pages, and public repository metadata so each entry surface stays distinct, current, and aligned with the SGEMM optimization focus.
-
-## Requirements
-
-### Requirement: Repository entry points have distinct roles
-The project MUST present itself through distinct entry surfaces so that each one serves a clear audience and does not duplicate another surface unnecessarily.
-
-#### Scenario: New visitor lands on the repository or project site
-- **WHEN** a user opens `README.md` or the GitHub Pages site
-- **THEN** the repository MUST provide a concise explanation of the project's value, core technical highlights, and clear navigation to deeper documentation without mirroring the same long-form content across both surfaces
-- **AND** the Pages home experience MUST behave as the long-form whitepaper entry point rather than as a second copy of the README
-- **AND** the Pages home experience MUST emphasize project thesis, architectural differentiation, and evidence framing before deep implementation detail
-
-### Requirement: Documentation inventory is intentionally consolidated
-The project MUST aggressively merge or remove stale, low-value, or overlapping documentation so that each retained document has a single clear responsibility.
-
-#### Scenario: Maintainer audits repository documents
-- **WHEN** a maintainer reviews root docs, Pages content, and supporting documentation
-- **THEN** duplicate release-history material, overlapping landing pages, and non-authoritative explanatory files MUST be merged or removed until each retained document has a clear purpose and ownership
-- **AND** the public Pages structure MUST avoid parallel sections that explain the same concept with only cosmetic differences
-
-### Requirement: GitHub metadata matches project positioning
-The public repository metadata MUST reinforce the same positioning used by the cleaned documentation and Pages experience.
-
-#### Scenario: Visitor views the GitHub repository summary
-- **WHEN** a visitor sees the repository About panel, homepage URL, or topic tags
-- **THEN** the description, homepage, and topics MUST accurately reflect the project's CUDA SGEMM optimization focus and link users toward the maintained project entry points
-
-### Requirement: Repository entry surfaces support bilingual navigation
-The repository MUST provide clear entry points for both English and Chinese readers with consistent structure across both README files.
-
-#### Scenario: Bilingual Repository Entry
-- **WHEN** a visitor lands on the GitHub repository root
-- **THEN** the repository MUST present `README.md` as the default English entry
-- **AND** the repository MUST show a prominent link to `README.zh-CN.md` for Chinese readers
-- **AND** both files MUST have consistent structure and navigation tables
-- **AND** both files MUST link to equivalent English and Chinese documentation routes on the published site
-
-### Requirement: All public pages offer language switching
-Every public documentation page MUST provide a way to switch to its counterpart in the other language.
-
-#### Scenario: Language Switching Between Paired Pages
-- **WHEN** a visitor reading a tutorial page in English clicks the language switcher for Chinese
-- **THEN** the system MUST redirect to the Chinese counterpart page
-- **AND** the Chinese page MUST offer a switch back to English
-
-#### Scenario: Switcher Mobile Accessible
-- **WHEN** a visitor on a mobile device opens the sidebar
-- **THEN** the language switcher MUST be visible and functional
-- **AND** buttons MUST be large enough for touch interaction
-
-### Requirement: Tutorial pages have mirrored counterparts
-Every public academy or tutorial page in English MUST have a Chinese counterpart with equivalent content structure.
-
-#### Scenario: Academy Pages Stay Mirrored
-- **WHEN** a public learning or deep-dive page exists in English under the published documentation tree
-- **THEN** a Chinese counterpart MUST exist at the mirrored route
-- **AND** both pages MUST have equivalent technical content structure
-- **AND** both pages MUST have cross-references to the same related pages
-- **AND** both pages MUST have matching front matter except for language-pair metadata
-
-### Requirement: Workflow triggers cover bilingual public surfaces
-The GitHub Pages workflow MUST rebuild when public bilingual content changes.
-
-#### Scenario: Workflow Triggers Updated
-- **WHEN** any `docs/**`, `zh/**`, `_includes/**`, `_sass/**`, `assets/**`, root landing page, or specs landing file changes
-- **THEN** the GitHub Pages workflow MUST trigger a rebuild
-- **AND** the published site MUST reflect changes
-
-### Requirement: No orphaned public content exists after closeout
-All linked public content MUST resolve correctly with no missing counterparts.
-
-#### Scenario: No Orphaned Content
-- **WHEN** someone browses the closed-out site
-- **THEN** every linked public page MUST exist
-- **AND** no page MUST reference a missing counterpart
-- **AND** all cross-references MUST resolve correctly
-- **AND** every linked English public route that belongs to the mirrored documentation tree MUST have a Chinese counterpart and vice versa
-
-### Requirement: Public whitepaper information architecture is curated by reader depth
-The GitHub Pages site MUST present the project through a mirrored bilingual information architecture that guides readers from orientation to deep technical study instead of exposing an unstructured set of topical pages.
-
-#### Scenario: Reader lands on the home page without repository context
-- **WHEN** a visitor opens the English or Chinese home page
-- **THEN** the page MUST summarize the project thesis, the optimization ladder, and the validation model
-- **AND** the page MUST provide direct paths into deeper architecture, academy, validation, and research sections
-
-#### Scenario: Reader follows the intended learning path
-- **WHEN** a visitor uses top-level navigation or homepage entry cards
-- **THEN** the documentation structure MUST separate high-level orientation from deep kernel-study pages
-- **AND** the route groups MUST be mirrored between English and Chinese
-
-### Requirement: Technical figures remain legible across themes
-All high-signal public technical figures MUST remain readable, visually coherent, and semantically equivalent in both light mode and dark mode.
-
-#### Scenario: Visitor switches between light and dark mode
-- **WHEN** the site theme changes
-- **THEN** diagrams, SVG illustrations, icons, and figure labels MUST preserve sufficient contrast for text, boundaries, and emphasis
-- **AND** no critical visual element MUST become effectively invisible in either theme
-
-#### Scenario: Architecture page uses a custom figure
-- **WHEN** a page renders a curated architecture or flow figure
-- **THEN** the figure MUST use the site’s shared visual tokens or paired theme-safe assets
-- **AND** the figure MUST remain understandable without relying on a theme-specific background assumption
-
-### Requirement: Public research context is explicit and traceable
-The documentation site MUST provide academic-style context that links project claims to references, related open-source implementations, and architectural evolution notes.
-
-#### Scenario: Reader investigates technical lineage
-- **WHEN** a reader opens the research-oriented section from site navigation
-- **THEN** the site MUST include structured references grouped by purpose
-- **AND** the site MUST include at least one related-project or comparative-analysis surface
-- **AND** the site MUST include at least one evolution-oriented explanation of why the project architecture is organized as it is
diff --git a/openspec/specs/repository-governance/spec.md b/openspec/specs/repository-governance/spec.md
deleted file mode 100644
index aa4b58b..0000000
--- a/openspec/specs/repository-governance/spec.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# Repository Governance Specification
-
-> **Version**: 1.0.0 | **Last Updated**: 2026-04-23 | **Status**: Complete
-
-## Purpose
-
-Define the repository's normative governance model, including authoritative specification ownership, instruction-file responsibility boundaries, automation policy, and shared developer tooling expectations for archive-ready maintenance.
-
-## Requirements
-
-### Requirement: OpenSpec is the authoritative governance system
-The repository MUST use OpenSpec as the single authoritative system for repository requirements, workflow rules, and closeout-state governance decisions.
-
-#### Scenario: Contributor needs the normative source of truth
-- **WHEN** a contributor or AI agent needs project requirements, workflow rules, or repository governance guidance
-- **THEN** the authoritative source MUST be the stable capability specs under `openspec/specs/` together with active change artifacts under `openspec/changes/`
-
-### Requirement: Governance instructions have clear ownership
-The repository MUST keep governance instructions concise, non-redundant, and separated by responsibility rather than by repetitive tool-specific restatement.
-
-#### Scenario: Contributor reads repository instruction files
-- **WHEN** a contributor opens root governance files such as `AGENTS.md`, `CLAUDE.md`, or any project-level Copilot instruction file
-- **THEN** each file MUST have a distinct responsibility, avoid generic duplicated boilerplate, and defer to the authoritative OpenSpec workflow where normative process rules apply
-
-### Requirement: Automation is archive-ready and high-signal
-The repository MUST keep only automation that materially improves closeout-state quality, consistency, or publication.
-
-#### Scenario: Repository change triggers automation
-- **WHEN** a pull request or push matches the repository automation rules
-- **THEN** workflows MUST be limited to high-signal validation or publishing tasks, align with the default branch strategy, and avoid redundant or low-value executions
-
-### Requirement: Branch strategy is single-mainline
-The repository MUST use `master` as the only long-lived branch and avoid automated release/version branch creation for routine maintenance.
-
-#### Scenario: Maintainer finishes a task branch or worktree
-- **WHEN** a maintainer completes isolated local work
-- **THEN** the work MUST be merged back to `master`, temporary branches/worktrees MUST be removed, and remote branch state MUST remain free of stale task branches
-
-### Requirement: Shared developer tooling is lightweight and portable
-The repository MUST provide a project-level tooling baseline that works across multiple AI and editor environments without depending on heavy, context-expensive integrations.
-
-#### Scenario: Contributor sets up local tooling
-- **WHEN** a contributor enables hooks, language tooling, or AI-assisted workflow features for the repository
-- **THEN** the primary baseline MUST rely on shared project foundations such as CMake-generated compile commands, clangd-compatible configuration, minimal hooks, and native CLI or skill-driven workflows before optional MCP-style integrations are considered
diff --git a/openspec/specs/testing/spec.md b/openspec/specs/testing/spec.md
deleted file mode 100644
index b43cea3..0000000
--- a/openspec/specs/testing/spec.md
+++ /dev/null
@@ -1,200 +0,0 @@
-# Testing Specification
-
-> **Version**: 2.1.0 | **Last Updated**: 2026-04-23 | **Status**: Complete
-
-## Purpose
-
-Define BDD-style test specifications for SGEMM kernel verification against the cuBLAS reference.
-
-## Requirements
-
-### Requirement: Test Framework
-The project SHALL use Google Test for unit testing with CUDA support.
-
-#### Scenario: Tests execute via CTest
-- **WHEN** a developer runs `ctest --test-dir build`
-- **THEN** all kernel tests SHALL execute and report results
-
-### Requirement: Correctness Verification
-All kernels SHALL be verified against cuBLAS reference output.
-
-#### Scenario: Standard kernels pass correctness tests
-- **WHEN** standard FP32 kernels are tested
-- **THEN** they SHALL match cuBLAS within rtol=1e-3, atol=1e-4
-
-#### Scenario: Tensor Core passes correctness tests
-- **WHEN** Tensor Core kernel is tested with aligned dimensions
-- **THEN** it SHALL match cuBLAS within rtol=5e-2, atol=1e-2
-
-#### Scenario: Tensor Core handles unaligned dimensions
-- **WHEN** Tensor Core kernel receives non-16-aligned dimensions
-- **THEN** it SHALL safely fall back to FP32 implementation
-
-### Requirement: Repository validation includes governance integrity
-The repository test and validation model MUST cover not only code correctness but also the integrity of governance, specification, and documentation structure.
-
-#### Scenario: Governance-related files change
-- **WHEN** OpenSpec files, workflow files, governance documents, or documentation structure are modified
-- **THEN** the repository MUST provide CI-safe validation that checks the relevant specification and structural invariants before those changes are treated as complete
-
-### Requirement: Validation expectations are split by execution environment
-The repository MUST document which checks are expected to run in hosted CI and which checks require a local GPU-capable environment.
-
-#### Scenario: Contributor reads validation guidance
-- **WHEN** a contributor prepares to validate repository changes
-- **THEN** the documented workflow MUST separate CI-safe checks such as formatting, compilation, OpenSpec validation, or Pages buildability from GPU-required runtime verification and benchmarking
-
----
-
-## Test Scenarios
-
-### Scenario 1: Standard Kernel Correctness
-
-**Given** a square matrix dimension (e.g., 512×512×512, 1024×1024×1024)
-**When** each standard kernel (Naive, Tiled, Bank-Free, Double-Buffer) is executed
-**Then** the output matrix C must match cuBLAS result within tolerance `rtol=1e-3, atol=1e-4`
-
-**Test Cases**:
-- Aligned square dimensions: 512, 1024
-- Non-square dimension: 256×384×640
-- Random dimensions: 100+ property-based test iterations
-
----
-
-### Scenario 2: Tensor Core Correctness
-
-**Given** matrix dimensions that are multiples of 16 (WMMA alignment requirement)
-**When** the Tensor Core kernel is executed with FP16→FP32 mixed precision
-**Then** the output matrix C must match cuBLAS result within tolerance `rtol=5e-2, atol=1e-2`
-
-**Test Cases**:
-- 16-aligned dimensions: 512×512×512, 1024×1024×1024
-- Edge alignment: 16×16×16, 32×32×32
-
----
-
-### Scenario 3: Tensor Core Fallback
-
-**Given** matrix dimensions that are NOT multiples of 16
-**When** the Tensor Core kernel is invoked
-**Then** the kernel must safely fall back to an FP32 implementation without errors
-
-**Test Cases**:
-- Unaligned dimension: 511×513×1025
-- Prime dimensions: 17×19×23
-- Small unaligned: 15×15×15
-
----
-
-### Scenario 4: Edge Cases
-
-**Given** minimal or extreme matrix dimensions
-**When** any kernel is executed
-**Then** the kernel must complete without CUDA errors and produce correct results
-
-**Test Cases**:
-- Minimal: 1×1×1
-- Small: 2×2×2, 4×4×4
-- Non-square edge: 1×128×1, 128×1×128, 1×128×128
-
----
-
-### Scenario 5: Performance Benchmarking
-
-**Given** a set of benchmark dimensions
-**When** each kernel is benchmarked using CUDA Events
-**Then** the GFLOPS must be reported and compared against cuBLAS baseline
-
-**Benchmark Dimensions**:
-- 512×512×512
-- 1024×1024×1024
-- 2048×2048×2048
-- 256×384×640 (non-square)
-- 511×513×1025 (unaligned)
-
-**Expected Performance Progression**:
-```
-Naive < Tiled < Bank-Free < Double-Buffer < Tensor Core << cuBLAS
-```
-
----
-
-## Property-Based Testing
-
-### Property 1: Numerical Correctness
-
-**For all** valid matrix dimensions M, K, N where 1 ≤ M, K, N ≤ 2048:
-**Verify** that `allclose(kernel_output, cublas_output, rtol, atol)` returns true
-
-**Sampling Strategy**:
-- 100+ random dimension triples
-- Include squares, non-squares, and edge cases
-
----
-
-### Property 2: Kernel Monotonicity (Performance)
-
-**For all** benchmark dimensions:
-**Verify** that each successive optimization stage achieves equal or better GFLOPS than the previous stage
-
-**Expected Order**:
-```
-GFLOPS(Naive) ≤ GFLOPS(Tiled) ≤ GFLOPS(Bank-Free) ≤ GFLOPS(Double-Buffer) ≤ GFLOPS(Tensor Core)
-```
-
----
-
-### Property 3: Memory Safety
-
-**For all** kernel executions:
-**Verify** that:
-- No CUDA errors occur
-- No memory leaks (RAII validation)
-- All GPU resources are properly released
-
----
-
-## Tolerance Specifications
-
-| Kernel Category | Relative Tolerance (rtol) | Absolute Tolerance (atol) | Precision |
-|-----------------|--------------------------|--------------------------|-----------|
-| Standard FP32 Kernels (Naive, Tiled, Bank-Free, Double-Buffer) | 1e-3 | 1e-4 | FP32 |
-| Tensor Core (FP16→FP32 mixed precision) | 5e-2 | 1e-2 | FP16 input, FP32 accumulate |
-
----
-
-## Test Execution Commands
-
-```bash
-# Build and run tests via CMake
-cmake --build build --target test_sgemm
-ctest --test-dir build --verbose
-
-# Build and run tests via Make
-make test
-
-# Run specific test cases
-./build/bin/test_sgemm --gtest_filter="*Correctness*"
-./build/bin/test_sgemm --gtest_filter="*TensorCore*"
-./build/bin/test_sgemm --gtest_filter="*EdgeCase*"
-```
-
----
-
-## Acceptance Criteria
-
-All tests must pass for the following conditions:
-
-1. **Correctness**: All kernels match cuBLAS within specified tolerances
-2. **Fallback**: Tensor Core safely handles unaligned dimensions
-3. **Edge Cases**: All minimal and extreme dimensions complete successfully
-4. **Performance**: Performance progression is monotonic (non-regressing)
-5. **Memory Safety**: No leaks, no errors, clean resource management
-
----
-
-## References
-
-- [Google Test Documentation](https://google.github.io/googletest/)
-- [CUDA Testing Best Practices](https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/)
-- Property-based testing inspired by [Hypothesis](https://hypothesis.works/) methodology
diff --git a/scripts/install-hooks.sh b/scripts/install-hooks.sh
deleted file mode 100755
index 3d3c1bf..0000000
--- a/scripts/install-hooks.sh
+++ /dev/null
@@ -1,6 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-repo_root="$(git rev-parse --show-toplevel)"
-git config core.hooksPath "$repo_root/.githooks"
-echo "Configured core.hooksPath to $repo_root/.githooks"
diff --git a/specs.md b/specs.md
deleted file mode 100644
index 3bd35b4..0000000
--- a/specs.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-layout: default
-title: Specifications
-parent: Home
-nav_order: 9
-has_children: true
-permalink: /specs/
-lang: en
-page_key: specs
-lang_ref: zh-specs
----
-
-# Specifications
-{: .fs-8 }
-
-Authoritative engineering rules and requirements
-{: .fs-6 .fw-300 }
-
----
-
-## Overview
-
-This repository uses **OpenSpec** as its single authoritative system for requirements, workflow, and closeout-stage governance.
-
-- **Stable specs** live under `openspec/specs/`
-- **Active changes** live under `openspec/changes/<change>/`
-- **Archived changes** live under `openspec/changes/archive/`
-
-This page is a navigation surface for humans. The normative source of truth remains the OpenSpec files inside the repository.
-
-## Document Structure
-
-```text
-openspec/
-├── config.yaml
-├── specs/            # Stable capability specs
-├── changes/          # Active change proposals
-│   ├── <change>/     # proposal.md, design.md, tasks.md, specs/
-│   └── archive/      # Completed changes
-├── README.md         # Repository-specific OpenSpec workflow notes
-└── AGENTS.md         # OpenSpec-specific agent guidance
-```
-
-## Stable Capability Index
-
-| Capability | Purpose | Source |
-|------------|---------|--------|
-| Kernel | Kernel behaviors, tolerances, benchmark scope | [`openspec/specs/kernel/spec.md`](https://github.com/LessUp/sgemm-optimization/blob/master/openspec/specs/kernel/spec.md) |
-| Architecture | Architecture and engineering decisions | [`openspec/specs/architecture/spec.md`](https://github.com/LessUp/sgemm-optimization/blob/master/openspec/specs/architecture/spec.md) |
-| Testing | Validation scenarios and execution boundaries | [`openspec/specs/testing/spec.md`](https://github.com/LessUp/sgemm-optimization/blob/master/openspec/specs/testing/spec.md) |
-| Repository Governance | Authoritative governance, workflow ownership, automation, and tooling expectations | [`openspec/specs/repository-governance/spec.md`](https://github.com/LessUp/sgemm-optimization/blob/master/openspec/specs/repository-governance/spec.md) |
-| Project Presentation | README, Pages, and repository metadata positioning requirements | [`openspec/specs/project-presentation/spec.md`](https://github.com/LessUp/sgemm-optimization/blob/master/openspec/specs/project-presentation/spec.md) |
-
-## Change Workflow
-
-| Step | Command | Result |
-|------|---------|--------|
-| Explore | `/opsx:explore` | Clarify scope, risks, and trade-offs before creating a change |
-| Propose | `/opsx:propose "description"` | Create proposal, design, tasks, and delta specs |
-| Apply | `/opsx:apply` | Work through `tasks.md` and update checkboxes |
-| Review | `/review` | High-signal review before major consolidation or archive |
-| Archive | `/opsx:archive` | Merge delta specs into stable specs and move the change to archive |
-
-## Closeout Rules
-
-- Prefer **consolidation over expansion**. Delete or merge low-value artifacts instead of keeping placeholder files.
-- Prefer **one long apply session** over frequent `/fleet` fan-out.
-- Use OpenSpec for any change that affects repository structure, public docs, workflow, or quality gates.
-- Keep stable specs, governance docs, README, and Pages aligned after every significant cleanup pass.
-
-For repository-wide contributor guidance, see [`AGENTS.md`](https://github.com/LessUp/sgemm-optimization/blob/master/AGENTS.md). For OpenSpec-specific details, see [`openspec/README.md`](https://github.com/LessUp/sgemm-optimization/blob/master/openspec/README.md).
diff --git a/src/benchmark_runner.cuh b/src/benchmark_runner.cuh
index c789bb2..083b454 100644
--- a/src/benchmark_runner.cuh
+++ b/src/benchmark_runner.cuh
@@ -30,14 +30,22 @@ class BenchmarkRunner {
     /**
      * 运行所有配置的 benchmark
      */
-    void runAll() {
+    bool runAll() {
         printHeader();
 
+        if (!cudaDeviceAvailable()) {
+            fprintf(stderr,
+                    "No CUDA-capable device detected. Benchmark execution requires a local CUDA "
+                    "environment with a visible GPU.\n");
+            return false;
+        }
+
         for (const auto &[M, K, N] : config_.dimensions) {
             runBenchmarks(M, K, N);
         }
 
         printFooter();
+        return true;
     }
 
   private:
@@ -51,10 +59,15 @@ class BenchmarkRunner {
 
         printGPUInfo();
 
-        float peakGflops = getTheoreticalPeakGflops();
-        float peakBandwidth = getTheoreticalPeakBandwidth();
-        printf("Approximate theoretical peak FP32: %.2f GFLOPS\n", peakGflops);
-        printf("Approximate theoretical peak bandwidth: %.2f GB/s\n", peakBandwidth);
+        if (cudaDeviceAvailable()) {
+            float peakGflops = getTheoreticalPeakGflops();
+            float peakBandwidth = getTheoreticalPeakBandwidth();
+            printf("Approximate theoretical peak FP32: %.2f GFLOPS\n", peakGflops);
+            printf("Approximate theoretical peak bandwidth: %.2f GB/s\n", peakBandwidth);
+        } else {
+            printf("Approximate theoretical peak FP32: unavailable without a CUDA device\n");
+            printf("Approximate theoretical peak bandwidth: unavailable without a CUDA device\n");
+        }
         printf("\n");
     }
 
@@ -174,7 +187,7 @@ class BenchmarkRunner {
         BenchmarkResult tc_result = runTensorCoreComputeOnlyBenchmark(
             benchmark.getCublasHandle(), M, K, N, config_.warmup_runs, config_.benchmark_runs,
             kTensorCoreVerifyTolerance);
-        tc_result.print();
+        benchmark.addResult(tc_result);
     }
 
     BenchmarkConfig config_;
diff --git a/src/main.cu b/src/main.cu
index 47b5635..c6395ea 100644
--- a/src/main.cu
+++ b/src/main.cu
@@ -28,7 +28,5 @@ int main(int argc, char **argv) {
     }
 
     BenchmarkRunner runner(config);
-    runner.runAll();
-
-    return 0;
+    return runner.runAll() ? 0 : 1;
 }
diff --git a/src/utils/benchmark.cuh b/src/utils/benchmark.cuh
index f1187dc..6e044c4 100644
--- a/src/utils/benchmark.cuh
+++ b/src/utils/benchmark.cuh
@@ -217,6 +217,7 @@ class SGEMMBenchmark {
     const std::vector<BenchmarkResult> &getResults() const { return results_; }
     void clearResults() { results_.clear(); }
     cublasHandle_t getCublasHandle() const { return cublas_handle_; }
+    void addResult(const BenchmarkResult &result) { results_.push_back(result); }
 
   private:
     cublasHandle_t cublas_handle_;
diff --git a/src/utils/benchmark_metrics.cuh b/src/utils/benchmark_metrics.cuh
index 022a33f..1025073 100644
--- a/src/utils/benchmark_metrics.cuh
+++ b/src/utils/benchmark_metrics.cuh
@@ -57,6 +57,10 @@ inline PerformanceMetrics calculateSgemmMetrics(int M, int K, int N, float time_
  * - 时钟频率
  */
 inline float getTheoreticalPeakGflops() {
+    if (!cudaDeviceAvailable()) {
+        return 0.0f;
+    }
+
     DeviceInfoCache &cache = DeviceInfoCache::instance();
     const cudaDeviceProp &prop = cache.prop();
 
@@ -75,6 +79,10 @@ inline float getTheoreticalPeakGflops() {
  * - 内存总线宽度
  */
 inline float getTheoreticalPeakBandwidth() {
+    if (!cudaDeviceAvailable()) {
+        return 0.0f;
+    }
+
     const cudaDeviceProp &prop = DeviceInfoCache::instance().prop();
 
     // 内存时钟频率 (Hz -> MHz)
@@ -111,42 +119,3 @@ inline float calculateEfficiency(float actual_gflops, float peak_gflops) {
         return 0.0f;
     return (actual_gflops / peak_gflops) * 100.0f;
 }
-
-/**
- * 计算带宽利用率（相对于理论峰值的百分比）
- *
- * 注意：此函数为工具函数，供外部调用者使用。
- * 内部 benchmark 流程使用 calculateEfficiency。
- */
-[[maybe_unused]] inline float
-calculateBandwidthUtilization(float actual_bandwidth, float peak_bandwidth) {
-    if (peak_bandwidth <= 0)
-        return 0.0f;
-    return (actual_bandwidth / peak_bandwidth) * 100.0f;
-}
-
-// ============================================================================
-// 性能比较工具
-// ============================================================================
-
-/**
- * 打印性能比较报告
- *
- * 注意：此函数为工具函数，供外部调用者打印格式化报告。
- * 内部 benchmark 流程使用 SGEMMBenchmark::printSummary。
- *
- * @param kernel_name 内核名称
- * @param metrics 性能指标
- * @param baseline_gflops 基线 GFLOPS（如 cuBLAS）
- */
-[[maybe_unused]] inline void
-printPerformanceReport(const char *kernel_name, const PerformanceMetrics &metrics,
-                       float baseline_gflops = 0.0f) {
-    printf("  %-30s | %8.3f ms | %10.2f GFLOPS | %8.2f GB/s | AI: %.1f\n", kernel_name,
-           metrics.time_ms, metrics.gflops, metrics.bandwidth_gb_s, metrics.arithmetic_intensity);
-
-    if (baseline_gflops > 0.0f) {
-        float percentage = (metrics.gflops / baseline_gflops) * 100.0f;
-        printf("    -> %.1f%% of baseline (%.2f GFLOPS)\n", percentage, baseline_gflops);
-    }
-}
diff --git a/tests/test_performance.cu b/tests/test_performance.cu
index a4758b9..26c3b19 100644
--- a/tests/test_performance.cu
+++ b/tests/test_performance.cu
@@ -1,15 +1,11 @@
 /**
- * 性能回归测试框架
+ * 性能回归测试
  *
- * 为每个 SGEMM 内核记录性能基线，检测性能退化。
- * 基线数据存储在 tests/baselines/ 目录中。
+ * 使用相对于理论峰值的保守阈值检测明显退化。
  */
 
 #include <cuda_runtime.h>
-#include <fstream>
 #include <gtest/gtest.h>
-#include <memory>
-#include <sstream>
 #include <string>
 #include <unordered_map>
 #include <vector>
@@ -25,113 +21,6 @@
 #include "utils/benchmark_metrics.cuh"
 #include "utils/cuda_utils.cuh"
 
-// ============================================================================
-// 性能基线结构
-// ============================================================================
-
-struct PerformanceBaseline {
-    std::string kernel_name;
-    int M, K, N;
-    float min_gflops; // 最小可接受的 GFLOPS
-    float max_gflops; // 记录的最大 GFLOPS（参考）
-    std::string gpu_name;
-
-    std::string key() const {
-        return kernel_name + "_" + std::to_string(M) + "x" + std::to_string(K) + "x" +
-               std::to_string(N);
-    }
-};
-
-// ============================================================================
-// 基线管理器
-// ============================================================================
-
-class BaselineManager {
-  public:
-    explicit BaselineManager(const std::string &baseline_file) : baseline_file_(baseline_file) {
-        loadBaselines();
-    }
-
-    ~BaselineManager() { saveBaselines(); }
-
-    // 获取基线（如果存在）
-    bool hasBaseline(const std::string &key) const { return baselines_.count(key) > 0; }
-
-    const PerformanceBaseline &getBaseline(const std::string &key) const {
-        return baselines_.at(key);
-    }
-
-    // 更新或添加基线
-    void updateBaseline(const PerformanceBaseline &baseline) {
-        baselines_[baseline.key()] = baseline;
-    }
-
-    // 获取当前 GPU 名称
-    static std::string getCurrentGpuName() {
-        int device;
-        CUDA_CHECK(cudaGetDevice(&device));
-        cudaDeviceProp prop;
-        CUDA_CHECK(cudaGetDeviceProperties(&prop, device));
-        return prop.name;
-    }
-
-    // 计算可接受的性能范围（相对于峰值的百分比）
-    static float calculateMinGflops(float peak_gflops, float efficiency_threshold) {
-        return peak_gflops * efficiency_threshold;
-    }
-
-  private:
-    void loadBaselines() {
-        std::ifstream file(baseline_file_);
-        if (!file.is_open()) {
-            return; // 文件不存在，使用空基线
-        }
-
-        std::string line;
-        while (std::getline(file, line)) {
-            if (line.empty() || line[0] == '#') {
-                continue;
-            }
-
-            std::istringstream iss(line);
-            PerformanceBaseline baseline;
-            char delim;
-
-            // 格式: kernel_name,M,K,N,min_gflops,max_gflops,gpu_name
-            if (std::getline(iss, baseline.kernel_name, ',') &&
-                (iss >> baseline.M >> delim >> baseline.K >> delim >> baseline.N >> delim >>
-                 baseline.min_gflops >> delim >> baseline.max_gflops >> delim) &&
-                std::getline(iss, baseline.gpu_name)) {
-                baselines_[baseline.key()] = baseline;
-            }
-        }
-    }
-
-    void saveBaselines() {
-        std::ofstream file(baseline_file_);
-        if (!file.is_open()) {
-            fprintf(stderr, "Warning: Could not save baselines to %s\n", baseline_file_.c_str());
-            return;
-        }
-
-        file << "# Performance Baselines (auto-generated)\n";
-        file << "# Format: kernel_name,M,K,N,min_gflops,max_gflops,gpu_name\n";
-
-        for (const auto &[key, baseline] : baselines_) {
-            file << baseline.kernel_name << "," << baseline.M << "," << baseline.K << ","
-                 << baseline.N << "," << baseline.min_gflops << "," << baseline.max_gflops << ","
-                 << baseline.gpu_name << "\n";
-        }
-    }
-
-    std::string baseline_file_;
-    std::unordered_map<std::string, PerformanceBaseline> baselines_;
-};
-
-// ============================================================================
-// 性能回归测试
-// ============================================================================
-
 class PerformanceRegressionTest : public ::testing::Test {
   protected:
     void SetUp() override {