@cannbot-plugin/cannbot-harness 0.0.0-stage → 0.1.4

package/assets/ops-direct-invoke/skills/ops-design-paradigms/references/knowledge/dev-experience/regbase_programming_notes.md

@@ -0,0 +1,108 @@
+---
+title: Regbase Programming Notes
+purpose: Keep the regbase mental model stable by separating the outer shell, UB staging, and VF/reg-compute body.
+read_when:
+  - The implementation is drifting toward membase or template-default thinking.
+  - You need to restate what "regbase" means before choosing APIs or writing kernel structure.
+not_for:
+  - Exact API signatures
+  - Build, package, or install questions
+keywords:
+  - mental model
+  - spmd
+  - vec scope
+  - regtensor
+next_reads:
+  - ../regbase_development_guide.md
+  - ../patterns/regbase_kernel_dataflow_patterns.md
+  - ../pitfalls/regbase_vs_membase_confusions.md
+depth: foundation
+topic_type: dev-experience
+---
+
+# Regbase Programming Notes
+
+This note distills the project’s common programming-model reminders for `ascend950 / regbase`. It is meant to stabilize design judgment, especially when code starts drifting toward the wrong layer model.
+
+## 1. Think In SPMD First
+
+Regbase kernel work still runs in the Ascend C SPMD model:
+
+- one kernel body executes on many cores
+- each core identifies its slice by `GetBlockIdx()`
+- host-side tiling and block routing decide what each core sees
+
+If the design cannot explain the block split clearly, it is not ready for detailed API selection.
+
+## 2. Regbase Is Register-Centric At The Compute Core
+
+At the compute core, regbase centers on:
+
+- `__VEC_SCOPE__`
+- `RegTensor<T>`
+- `MaskReg`
+- `LoadDist` / `StoreDist`
+- VF-safe reg-compute chains such as `Cast`, `Add`, `Mul`, `Abs`, `Div`, usually written as `AscendC::MicroAPI::*` in open-source code and exposed as `AscendC::Reg::*` in the SDK headers
+
+Use regbase when the design is naturally expressed as a tight local compute chain over register-shaped state.
+
+## 3. Do Not Collapse The Outer Shell Into The Compute Core
+
+Real regbase kernels often still have an outer shell with:
+
+- `TPipe`
+- `TQue`
+- `GlobalTensor`
+- `LocalTensor`
+- UB-level `CopyIn -> Compute -> CopyOut`
+
+Those constructs do not automatically mean the operator has left the regbase path.
+
+The real question is: **where does the actual math happen?**
+
+- if the core math is expressed through `__VEC_SCOPE__`, `RegTensor`, `MaskReg`, and VF-safe `Reg` / `MicroAPI` calls, the design is still aligned with regbase
+- if the core math is written as a `LocalTensor`-centric compute pipeline and the VF layer disappears, the design is drifting away from the regbase writing style
+
+## 4. Know The Boundary Against Membase
+
+Re-check the branch assumption when the implementation starts depending on:
+
+- `LocalTensor` as the main compute state instead of UB staging
+- arithmetic written directly over `LocalTensor` without a VF/reg-compute body
+- queue handoff being treated as the whole compute model
+- `DataCopyPad` and queue movement becoming the center of the design instead of a staging layer
+
+That does not automatically make the design wrong, but it does mean the branch assumption should be re-checked instead of silently mixed.
+
+## 5. Half Precision Usually Implies A Wider Compute Stage
+
+For fp16 or bf16 heavy paths, the practical rule is:
+
+- load or unpack the narrow type
+- promote into a wider compute representation when the math is sensitive
+- keep summaries local in fp32 when the post-process depends on them
+- only cast back once the stable result is ready
+
+This is a design choice, not a cosmetic optimization.
+
+## 6. TilingData And TilingKey Are Part Of The Programming Model
+
+Treat tiling structures as a first-class contract:
+
+- host computes the tiling packet
+- kernel reads it explicitly
+- `TILING_KEY_IS()` selects the route
+
+Do not leave dtype route, branch route, or reduction strategy implicit if they can be expressed in `TilingKey` and a stable tiling struct.
+
+## Related Documents
+
+- [[process_memory_cards]]
+- [[requirements_analysis_patterns]]
+- [[../regbase_development_guide]]
+- [[regbase_kernel_case_notes]]
+- [[../patterns/regbase_operator_patterns]]
+- [[../patterns/regbase_kernel_dataflow_patterns]]
+- [[../patterns/kernel_design_patterns]]
+- [[../api/regbase_api_reference]]
+- [[../pitfalls/regbase_vs_membase_confusions]]

package/assets/ops-direct-invoke/skills/ops-design-paradigms/references/knowledge/dev-experience/requirements_analysis_patterns.md

@@ -0,0 +1,97 @@
+---
+title: Requirements Analysis Patterns
+purpose: Lock the requirements that repeatedly decide regbase route, tiling shape, precision strategy, and validation plan.
+read_when:
+  - The task definition is still ambiguous before design.
+  - Dtype, precision, scale, or shape questions are unresolved.
+not_for:
+  - Final API signature lookup
+  - Repairing an already isolated runtime bug
+keywords:
+  - requirements
+  - dtype
+  - shape
+  - precision route
+next_reads:
+  - ../regbase_development_guide.md
+  - complexity_and_route_selection.md
+  - ../patterns/regbase_operator_patterns.md
+depth: foundation
+topic_type: dev-experience
+---
+
+# Requirements Analysis Patterns
+
+This note adapts the project’s requirement-question checklist into a smaller set of questions that repeatedly prevent rework in regbase tasks. Read it before freezing a design packet.
+
+## Always Lock These First
+
+### 1. Dtypes And Precision Route
+
+Before design, clarify:
+
+- input dtypes
+- output dtypes
+- whether accumulation or post-process must stay in fp32
+- whether dtype conversion is part of the operator contract or only an implementation detail
+
+If this is vague, the API route, cast placement, and precision validation plan all stay unstable.
+
+### 2. Data Scale And UB Fit
+
+Ask whether the important working set:
+
+- always fits a comfortable local tile
+- sometimes exceeds UB and needs split execution
+- is unknown and should therefore default to a conservative split-capable route
+
+Many “simple” kernels become structurally different once the answer changes from full-load to non-full-load.
+
+### 3. Shape Semantics
+
+Clarify early whether the task is:
+
+- pure elementwise
+- reduction
+- reduction plus post-process
+- broadcasted binary op
+- shape-transform plus compute
+
+This decides the pattern family before any API discussion starts.
+
+### 4. Mixed Precision, Quantization, Or Special Numeric Contracts
+
+If the task touches quantization, fp8, bf16, or asymmetric dtype mappings, ask for the missing contract explicitly:
+
+- target numeric format
+- scale or zero-point behavior
+- block size or layout requirements
+- whether host attributes or metadata participate in the computation
+
+Do not let the implementation discover these by accident.
+
+### 5. Invalid Input And Edge Behavior
+
+For numerically sensitive operators, ask what should happen on:
+
+- divide-by-zero
+- invalid domains such as negative sqrt
+- empty or degenerate dimensions
+- tail tiles and alignment boundaries
+
+These answers belong in the design packet, not only in tests.
+
+## High-Value Defaulting Rules
+
+- If scale is unknown, assume the implementation must survive the non-full-load path.
+- If reduction axes are unclear, stop and clarify instead of assuming “last axis”.
+- If mixed precision is implied but not specified, make the cast and accumulation route explicit before coding.
+- If the task description mentions a similar open-source operator, use `[[../../reference-ops/open_source_operator_table]]` only as a hint for choosing a real reference implementation to inspect, not as proof of reuse.
+
+## Related Documents
+
+- [[process_memory_cards]]
+- [[regbase_programming_notes]]
+- [[../patterns/regbase_operator_patterns]]
+- [[../patterns/reduction_patterns]]
+- [[../pitfalls/precision_guide]]

package/assets/ops-direct-invoke/skills/ops-design-paradigms/references/knowledge/dev-experience/small_channel_transpose_notes.md

@@ -0,0 +1,78 @@
+---
+title: Small Channel Transpose Notes
+purpose: Preserve a proven small-channel transpose compatibility case so layout-change tasks can learn from it without mistaking it for the default regbase route.
+read_when:
+  - The task involves transpose or layout conversion with very small channel counts.
+  - You need a compatibility-side case note before deciding whether a specialized path is worth it.
+not_for:
+  - Default regbase kernel skeleton design
+  - General broadcast or reduction routing
+keywords:
+  - transpose
+  - small channel
+  - compatibility case
+  - 910b
+next_reads:
+  - complexity_and_route_selection.md
+  - ../patterns/regbase_operator_patterns.md
+  - ../pitfalls/regbase_vs_membase_confusions.md
+depth: case
+topic_type: dev-experience
+---
+
+# Small Channel Transpose Notes
+
+This note preserves a high-value compatibility case from the 910b knowledge base. The filename is neutral because the lesson is about the engineering pattern, but the original evidence and performance numbers come from a `910b / membase` implementation context.
+
+## 1. When This Case Is Useful
+
+Read this when the task involves:
+
+- NCHW to NHWC transpose
+- very small channel count
+- a question about whether a specialized path is worth it
+- evaluating a compatibility-side reference before designing a new route
+
+This is not a regbase default pattern. It is a proven compatibility experience note.
+
+## 2. The Winning Trick For Very Small `C`
+
+For very small channel counts, the practical winner in the source case was:
+
+- `vnchwconv` to interleave channels into a 16-element block
+- then `Gather` to extract only the valid channels
+
+The key lesson is that a specialized vector-friendly route can beat more “generic” transpose or per-pixel extraction paths by a large margin.
+
+## 3. What Lost And Why
+
+The losing patterns in the source case were valuable because they failed for understandable reasons:
+
+- scalar packing introduced `GetValue` / `SetValue` style overhead
+- tiny `DataCopyPad` blocks paid DMA setup costs too often
+- generic transpose APIs carried internal overhead that was too large for the shape
+
+The experience lesson is to distrust generic-looking APIs for micro-shape transpose work until the actual shape has been tested.
+
+## 4. Practical Pitfalls
+
+- `Gather` path may force an intermediate cast route depending on dtype
+- small transfer sizes can make DMA-heavy ideas look elegant but perform terribly
+- alignment behavior in UB and GM still matters even when the logical tensor is tiny
+
+## 5. How To Use This In Regbase Work
+
+Use this note as:
+
+- a compatibility reference
+- a performance intuition source
+- a reminder that small-shape transpose work may justify a special path
+
+Do not treat it as direct proof that the same implementation should be copied into the regbase branch.
+
+## Related Documents
+
+- [[complexity_and_route_selection]]
+- [[regbase_performance_practices]]
+- [[../../reference-ops/open_source_operator_table]]
+- [[../pitfalls/regbase_vs_membase_confusions]]

package/assets/ops-direct-invoke/skills/ops-design-paradigms/references/knowledge/dev-experience/tiling_review_notes.md

@@ -0,0 +1,87 @@
+---
+title: Tiling Review Notes
+purpose: Turn high-frequency tiling mistakes into a review checklist for already-designed or already-written regbase kernels.
+read_when:
+  - Tiling code already exists and needs review.
+  - A design packet is close to implementation and you want to catch high-yield tiling risks.
+not_for:
+  - First operator classification
+  - Exact API whitelist questions
+keywords:
+  - tiling review
+  - storage shape
+  - tiling key
+  - host kernel contract
+next_reads:
+  - ../patterns/tiling_patterns.md
+  - regbase_performance_practices.md
+  - ../pitfalls/common_traps.md
+depth: intermediate
+topic_type: dev-experience
+---
+
+# Tiling Review Notes
+
+This note turns the 950 tiling checklist into review-oriented engineering experience. It is for catching the high-frequency mistakes that make tiling code look almost right while still being broken.
+
+## 1. Treat Includes As Part Of The Contract
+
+Many tiling failures are not algorithmic. They come from file-role confusion:
+
+- host tiling header
+- host tiling implementation
+- kernel entry
+- kernel-side struct
+- kernel implementation header
+
+The lesson is to review includes by file role, not by memory.
+
+## 2. `StorageShape` Errors Are Usually Logic Smells
+
+If a tiling implementation is confused about `StorageShape`, `OriginShape`, or where dimensions are read from, the underlying problem is often that the author has not clearly separated:
+
+- storage-level layout
+- logical operator semantics
+- runtime tiling data
+
+Fix the conceptual split, not just the method call.
+
+## 3. TilingKey Drift Breaks Otherwise Valid Routes
+
+A correct tiling decision is still broken if:
+
+- host sets one key
+- kernel branches on another
+- binary metadata advertises a third set
+
+Review TilingKey as a three-part contract: generation, dispatch, registration.
+
+## 4. Namespace Hygiene Matters More Than It Looks
+
+Tiling code often spans host and kernel boundaries. Namespace mismatches in `_struct.h`, `_tiling_arch35.*`, and `_apt.cpp` are easy to dismiss as cosmetic, but they are usually a sign that the route was assembled by copy-paste rather than by a stable mental model.
+
+## 5. `TilingPrepare` And `Tiling` Are Different Jobs
+
+Repeated failure pattern:
+
+- platform-only logic leaks into runtime shape logic
+- or runtime assumptions are incorrectly pushed into prepare-time code
+
+The stable habit is:
+
+- `TilingPrepare` captures platform facts
+- `Tiling` consumes real shape/dtype facts
+
+Review any code that blurs that boundary.
+
+## 6. Serialization Rules Need Their Own Review Pass
+
+The host side may use macros for tiling-data serialization while kernel-side code may need plain structs. When these are “almost aligned” rather than exactly aligned, the bug can hide until much later.
+
+## Related Documents
+
+- [[regbase_build_notes]]
+- [[working_vs_failed_950_cases]]
+- [[../patterns/tiling_patterns]]
+- [[../patterns/kernel_design_patterns]]
+- [[../pitfalls/common_traps]]

package/assets/ops-direct-invoke/skills/ops-design-paradigms/references/knowledge/dev-experience/working_vs_failed_950_cases.md

@@ -0,0 +1,85 @@
+---
+title: Working Vs Failed 950 Cases
+purpose: Compare stable and broken 950 implementation patterns so route choice and code review start from real success and failure evidence.
+read_when:
+  - You need concrete 950 lessons before coding.
+  - The current design feels close to a known failure mode but the exact difference is unclear.
+not_for:
+  - Exact API or header lookup
+  - Detailed runtime synchronization design
+keywords:
+  - 950 cases
+  - working vs failed
+  - route choice
+  - failure evidence
+next_reads:
+  - regbase_kernel_case_notes.md
+  - regbase_programming_notes.md
+  - ../pitfalls/common_traps.md
+depth: case
+topic_type: dev-experience
+---
+
+# Working Vs Failed 950 Cases
+
+This note turns the `knowledge_cards/kernel_code_patterns_950.md` material into a smaller set of engineering lessons. The goal is not to catalog every operator, but to show what repeatedly separates stable 950 implementations from broken ones.
+
+## 1. Simple DAG Routes Succeed When The Problem Really Is Simple
+
+Successful elementwise operators on `ascend950` tend to share these traits:
+
+- the operator is genuinely short and local
+- the route stays inside the DAG abstraction cleanly
+- dtype handling is explicit
+- tiling keys, config, and kernel branches line up
+
+The lesson is not “always use DAG”. The lesson is that DAG works well when the operator shape really matches it.
+
+## 2. Regbase Works Best When You Commit To It
+
+Successful regbase paths usually look like this:
+
+- explicit class-based kernel organization
+- direct regbase compute chain
+- deliberate buffer and dtype handling
+- no attempt to hide imperative logic under a half-DAG abstraction
+
+The common success signal is commitment. The implementation chooses regbase and then stays regbase.
+
+## 3. Mixing DAG And Regbase Is A High-Probability Failure Mode
+
+One of the most expensive 950 mistakes is hybrid code that:
+
+- borrows DAG structure
+- then injects raw MicroAPI assumptions inside it
+- or assumes a Vec wrapper and a MicroAPI primitive are interchangeable
+
+This produces code that is neither a clean DAG path nor a clean regbase path. The result is usually API mismatch, configuration mismatch, or both.
+
+## 4. Many “Kernel” Failures Are Actually Configuration Failures
+
+A large share of broken 950 work comes from:
+
+- `simplified_key.ini` not matching the route
+- TilingKey branches not matching runtime registration
+- missing or inconsistent config updates
+- operator support declarations drifting away from the code path
+
+When the math seems fine but the route still breaks, inspect config before redesigning computation.
+
+## 5. A Practical 950 Review Habit
+
+Before trusting a new 950 implementation, ask:
+
+- Is this really a DAG-shaped problem or a regbase-shaped problem?
+- Did we keep one execution family all the way through?
+- Does TilingKey routing agree with config and dtype coverage?
+- Is any “framework mixing” happening under a different name?
+
+## Related Documents
+
+- [[complexity_and_route_selection]]
+- [[regbase_programming_notes]]
+- [[regbase_performance_practices]]
+- [[tiling_review_notes]]
+- [[../patterns/regbase_operator_patterns]]

package/assets/ops-direct-invoke/skills/ops-design-paradigms/references/knowledge/index.md

@@ -0,0 +1,30 @@
+# Knowledge Index
+
+This subtree is the top-level knowledge map for regbase development. It routes agents into the four primary knowledge branches and the few stable cross-cutting entry points that stay useful across design, implementation, repair, and reference-implementation selection.
+
+## How To Use This Index
+
+- Read this first when you need the shortest path from a regbase task into the right knowledge branch.
+- Choose the primary branch here, then read that directory's `index.md` before opening leaf notes.
+- For one subproblem, expand **at most 5 leaf documents** inside the chosen directory. If that is still not enough, split the subproblem or move to another branch.
+
+## Branch Selection Table
+
+| Need | Read First | Then |
+|---|---|---|
+| Full practical end-to-end regbase development path | [Regbase Development Guide](./regbase_development_guide.md) | follow the linked notes as the implementation deepens |
+| API constraints, VF boundaries, sync, or runtime guardrails | [API Index](./api/index.md) | pick leaf API notes by `purpose`, `read_when`, and `keywords` |
+| Kernel structure, tiling, reduction, broadcast, or sync-by-layer patterns | [Patterns Index](./patterns/index.md) | pick the smallest pattern set that closes the current design question |
+| Failure modes, precision risks, wrong-branch symptoms, or repair loops | [Pitfalls Index](./pitfalls/index.md) | branch from symptom or failure mechanism into the matching pitfall notes |
+| Engineering judgment, route selection, build habits, or reference-reading advice | [Development Experience Index](./dev-experience/index.md) | choose experience notes that fit the current execution-stage question |
+| Need at least one existing regbase implementation to inspect before coding | [Open Source Operator Table](../reference-ops/open_source_operator_table.md) | inspect the matched source implementation directly after the table |
+
+## Related Documents
+
+- [[../index]]
+- [[regbase_development_guide]]
+- [[api/index]]
+- [[patterns/index]]
+- [[pitfalls/index]]
+- [[dev-experience/index]]
+- [[../reference-ops/open_source_operator_table]]

package/assets/ops-direct-invoke/skills/ops-design-paradigms/references/knowledge/patterns/broadcast_patterns.md

@@ -0,0 +1,132 @@
+---
+name: broadcast_patterns
+description: Regbase-first 广播模式选择，覆盖维度折叠、OneDim、UB Broadcast、NDDMA Broadcast 以及标量快速路径。
+title: Broadcast Patterns
+purpose: Choose the correct broadcast route after dimensions are collapsed and the operand reuse pattern is clear.
+read_when:
+  - The task contains broadcasting and you need a concrete route such as OneDim, UB broadcast, or NDDMA broadcast.
+  - Broadcast shape handling affects the overall regbase kernel design.
+not_for:
+  - Reduction-only design
+  - Detailed synchronization debugging
+keywords:
+  - broadcast
+  - onedim
+  - nddma
+  - dimension collapse
+next_reads:
+  - regbase_operator_patterns.md
+  - regbase_kernel_dataflow_patterns.md
+  - ../pitfalls/common_traps.md
+depth: intermediate
+topic_type: pattern
+type: knowledge_card
+platform: common
+verified: false
+patterns: [broadcast, dimension_collapse, onedim, nddma, ub_broadcast]
+---
+
+# Broadcast Patterns
+
+This note captures the broadcast routes that are most useful for regbase-first direct-invoke work on Ascend 950 and adjacent compatibility contexts.
+
+## Start With Dimension Collapse
+
+Before branch selection:
+
+- left-pad smaller-rank inputs with `1`
+- compute per-axis broadcast flags
+- merge adjacent axes that share the same broadcast pattern
+- compute stride-zero axes explicitly
+
+After collapse, most tasks become one of two categories:
+
+- one-dimensional linear work
+- multi-dimensional broadcast work
+
+## Pattern 1: OneDim Fast Path
+
+Choose OneDim when collapse leaves one logical dimension.
+
+Key traits:
+
+- all data is processed linearly
+- scalar inputs are a first-class case
+- UB and block tiling can be computed from a simple linear length
+
+Fast path rule:
+
+- prefer TensorScalar forms such as `Adds` / `Muls` when one side is scalar
+- use `Duplicate` only when no scalar form exists
+
+## Pattern 2: UB Broadcast
+
+Use UB Broadcast when the task is multi-dimensional and the chosen platform path cannot or should not rely on NDDMA broadcast.
+
+Shape:
+
+1. copy the un-broadcast source tile into UB
+2. expand it in UB
+3. run the arithmetic step on the broadcasted tile
+
+Best fit:
+
+- compatibility-oriented routes
+- shapes where explicit UB-side expansion is easier to reason about than a multi-copy setup
+- cases where tmp-buffer cost is acceptable
+
+## Pattern 3: NDDMA Broadcast on Ascend 950
+
+For `ascend950 / regbase`, NDDMA broadcast is often the preferred multi-dimensional route when the shape fits its constraints.
+
+Why:
+
+- broadcast happens during GM-to-UB movement
+- no extra UB-side broadcast instruction is needed
+- destination tiles arrive already expanded
+
+Checkpoints:
+
+- only use it when the broadcasted axes can be encoded as stride-zero movement
+- respect the limited multi-dimensional copy rank
+- when an input does not actually broadcast on the split axis, let it degenerate to a normal copy
+
+## Pattern 4: Split-Axis and Loop Selection
+
+Multi-dimensional broadcast design still needs a stable split:
+
+- find the innermost product that fits UB
+- define `ubSplitAxis`, `ubFormer`, `ubOuter`, and tail behavior
+- fuse the outer product for multi-core scheduling
+
+The split axis is not just a size calculation. It determines:
+
+- the loop structure
+- the GM offset logic
+- whether the broadcast can stay inside a single copy primitive
+
+## Pattern 5: Broadcast Is Still a Dataflow Contract
+
+Even when the math is elementwise, broadcast work must record:
+
+- which input axes are broadcasted
+- whether the path is OneDim, UB Broadcast, or NDDMA Broadcast
+- whether any scalar fast path is available
+- what shape the compute stage actually sees after expansion
+
+Without this, implementation and review will silently disagree on what the kernel is doing.
+
+## Regbase-First Checks
+
+- On Ascend 950, prefer NDDMA broadcast only when its rank and stride-zero assumptions actually fit.
+- Keep scalar fast paths explicit; they often remove one buffer and one copy.
+- Use `DataCopyPad`-style safe copy behavior whenever alignment is uncertain.
+- Avoid mixing a broadcast route with an unrelated membase execution explanation.
+
+## Related Documents
+
+- [[tiling_patterns]]
+- [[regbase_operator_patterns]]
+- [[kernel_design_patterns]]
+- [[../api/index]]
+- [Precision Guide](../pitfalls/precision_guide.md)

package/assets/ops-direct-invoke/skills/ops-design-paradigms/references/knowledge/patterns/index.md

@@ -0,0 +1,48 @@
+# Patterns Index
+
+This subtree captures the reusable implementation patterns that shape regbase-first kernel design, tiling, reduction routing, broadcast handling, and design-to-implementation decisions.
+
+## How To Use This Index
+
+- Read this index first when the task is already in the `regbase` branch and now needs a workable kernel shape.
+- For one subproblem, shortlist by `purpose`, `read_when`, and `keywords`, then expand **at most 5 leaf documents** from this directory.
+- If you still need more than 5 pattern notes, split the issue into smaller subproblems or move to `api/`, `pitfalls/`, or `dev-experience/` instead of scanning the whole subtree.
+
+## Routing Table
+
+| File | Purpose | Read When | Not For | Keywords |
+|---|---|---|---|---|
+| [Regbase Development Guide](../regbase_development_guide.md) | full practical mainline before choosing sub-patterns | you need the whole flow before drilling into one pattern | isolated API lookup | mainline, end-to-end |
+| [Regbase Operator Patterns](./regbase_operator_patterns.md) | choose overall kernel shape and fusion boundary | first design route is still open | low-level sync or build questions | kernel shape, fusion boundary |
+| [Regbase Kernel Dataflow Patterns](./regbase_kernel_dataflow_patterns.md) | separate shell, UB staging, and VF body | structuring a new kernel or reading a reference | host runtime-only questions | dataflow, VF, copyin/compute/copyout |
+| [Regbase Buffer Partitioning](./regbase_buffer_partitioning.md) | plan GM, UB, and register residency | tile buffers and scratch placement are unclear | top-level route selection | GM, UB, RegTensor |
+| [Regbase Sync Patterns](./regbase_sync_patterns.md) | choose sync by layer | handoff vs VF vs overlap boundaries are unclear | operator classification | sync, SetFlag, queue handoff |
+| [Tiling Patterns](./tiling_patterns.md) | choose block and UB split strategy | tiling route must be fixed before coding | postmortem runtime debugging | tiling, block split |
+| [Tiling Input Validation](./tiling_input_validation.md) | reject illegal dtype/format/dimension/attr/shape at tiling entry | tiling needs input validation or L2 exception cases need a rejection path | kernel-side runtime validation | validation, dtype, format, dimension, attr, shape, exception |
+| [Reduction Patterns](./reduction_patterns.md) | route reductions by shape and algorithm family | reduction, norm, with-index, or ARA choices matter | pure broadcast work | reduction, AR, Welford |
+| [Broadcast Patterns](./broadcast_patterns.md) | choose a broadcast route after dimension collapse | broadcast strategy affects the kernel shape | reduction-only design | broadcast, OneDim, NDDMA |
+| [Kernel Design Patterns](./kernel_design_patterns.md) | keep design packets and repair loops coherent | moving from design into implementation or review | exact API signatures | walkthrough, repair loop |
+| [Inplace Operator Patterns](./inplace_operator_patterns.md) | inplace 算子的 OpDef 同名规则、kernel 参数命名、冒烟测试与 TTK 用例 | 算子名含 Inplace 或需求文档声明输出复用输入地址 | 非 inplace 算子的常规开发流程 | inplace, OpDef 同名, var_out, output_inplace_indexes |
+
+## Common Paths
+
+- Need the full practical path before choosing a sub-pattern: [[../regbase_development_guide]]
+- Need the overall regbase-first kernel shape and fusion boundary: [[regbase_operator_patterns]]
+- Need the outer shell, UB flow, and VF decomposition: [[regbase_kernel_dataflow_patterns]]
+- Need GM / UB / register domain planning: [[regbase_buffer_partitioning]]
+- Need stage handoff, flags, and sync boundaries: [[regbase_sync_patterns]]
+- Need block, UB, and split-axis planning: [[tiling_patterns]]
+- Need tiling input validation (dtype/format/dimension/attr/shape): [[tiling_input_validation]]
+- Need AR / ARA / multi-axis / with-index reduction routes: [[reduction_patterns]]
+- Need OneDim / UB-broadcast / NDDMA-broadcast selection: [[broadcast_patterns]]
+- Need design packet, implementation order, and repair loop habits: [[kernel_design_patterns]]
+- Need inplace operator OpDef / kernel / test patterns: [[inplace_operator_patterns]]
+
+## Related Documents
+
+- [[../regbase_development_guide]]
+- [[../index]]
+- [[../api/index]]
+- [Precision Guide](../pitfalls/precision_guide.md)
+- [[inplace_operator_patterns]]
+- [[../../reference-ops/open_source_operator_table]]