docs: clarify oa l1 ownership

2026-06-14 05:15:13 +00:00
parent 438f49fef9
commit cd76411969
3 changed files with 25 additions and 8 deletions
@@ -21,6 +21,7 @@ Use this skill to keep HWLAB Cloud M1 project management centered on a stable ma
 - Do not let daily reports become the master plan. Phase reports summarize movement against the master spec; they do not define the center by themselves.
 - When a task lacks a parent direction, acceptance criteria, or original validation entry, classify it as planning/investigation before turning it into implementation work.
 - L1 directions must be capability domains that directly serve the L0 mission. Do not classify document cleanup, phase reports, project-management mechanics, board maintenance, skill maintenance, repo names, tool names, or temporary execution paths as L1 directions.
+- Treat L1 as acceptance ownership, not a loose topic tag. A cross-direction issue may list related L1s, but it must have exactly one primary L1 selected by asking which direction defines the done criteria.

 ## Canonical HWLAB Issue Anchors

@@ -42,7 +43,7 @@ Use this skill to keep HWLAB Cloud M1 project management centered on a stable ma
 Use this task tree unless the user gives a stricter one:

 - L0: Major project / master specification. Owns mission, non-goals, current center, L1 direction tree, global acceptance, and drift rules.
- L1: Direction. Owns a stable capability domain that serves L0, its scope boundary, success criteria, and L2 topic list.
+- L1: Direction. Owns a stable capability domain that serves L0, its scope boundary, success criteria, L2 topic list, and acceptance-definition authority for child work.
 - L2: Topic. Owns a concrete program of work inside one L1 direction, including deliverables, blockers, and validation plan.
 - L3: Subtopic / validation slice. Owns one bounded acceptance path, such as one CaseRun line, Web check, CLI smoke, or deployment/control-plane validation.
 - L4: Execution task / PR / CaseRun / smoke / doc closeout. Owns concrete execution and evidence collection; it cannot redefine parent scope.
@@ -122,14 +122,22 @@ Do not use any of these as L1 directions:
 - Repository names, tool names, CLI names, service names, runtime lanes, or temporary execution paths.
 - A single PR, one CaseRun, one smoke, one bug, or one migration step.

-Typical HWLAB Cloud M1 directions:
+Primary L1 rule:

- `PJ2026-0101` 云智研: cloud AI hardware-development workflow; user request, workspace, Code Agent implementation, review, collaboration, delivery.
- `PJ2026-0102` 硬验闭环: real hardware access and auditable validation loop; target device, debug probe, io probe, CaseRun, low-noise evidence.
- `PJ2026-0103` 用户计量: multi-user cloud service and commercial metering; auth, API keys, credit, usage ledger, billing, admin operations.
- `PJ2026-0104` 执行编排: execution substrate and resource orchestration; AgentRun/HWPOD/Code Agent runtime assembly, sessions, provider profiles, bundles, recovery.
- `PJ2026-0105` 能力沉淀: capability accumulation, training feedback, and quality control; harness cases, failure taxonomy, review, reusable templates, model/tool improvement.
- `PJ2026-0106` 产品协同: user product surface and collaboration experience; Web/CLI/API workflows that expose the above capabilities to users.
+- L1 is acceptance ownership, not a loose tag. Every non-trivial L2/L3/L4 issue must name exactly one primary L1.
+- Related L1s may be listed for handoff, but the primary L1 is the direction that defines the done criteria.
+- If ownership is unclear, ask which completion evidence would close the issue: AI development workflow, hardware evidence, user/billing ledger, execution runtime, reusable capability, or user-facing product surface.
+
+Typical HWLAB Cloud M1 L1 responsibility matrix:
+
+| Code | Short name | Primary responsibility | Does not own | Handoff examples |
+| --- | --- | --- | --- | --- |
+| `PJ2026-0101` | 云智研 | AI hardware-development workflow semantics: request, workspace, Code Agent coding/review/delivery loop | Web shell UX, billing, hardware pass/fail, runtime scheduling | Product UI to 产品协同; runtime/session to 执行编排; hardware evidence to 硬验闭环 |
+| `PJ2026-0102` | 硬验闭环 | Real hardware validation and evidence standards: target device, probe, CaseRun evidence, pass/fail signal | General runner infrastructure, Code Agent planning, UI display, billing | Runtime assembly to 执行编排; case learning to 能力沉淀 |
+| `PJ2026-0103` | 用户计量 | Multi-user service and commercial metering: auth, API keys, credit, usage ledger, billing, admin operations | Task UX, Code Agent behavior, hardware evidence, training quality | User-facing display to 产品协同; resource enforcement hooks to 执行编排 |
+| `PJ2026-0104` | 执行编排 | Execution substrate and resource orchestration: AgentRun/HWPOD/Code Agent runtime assembly, sessions, provider profiles, bundles, recovery | Hardware acceptance criteria, product UX, billing policy, capability taxonomy | Hardware validation to 硬验闭环; user interaction to 产品协同 |
+| `PJ2026-0105` | 能力沉淀 | Reusable capability accumulation: case library, failure taxonomy, review rules, templates, training feedback, model/tool improvement | Immediate feature delivery, runtime operations, billing, UI ownership | Consumes evidence from all L1s and returns standards/templates |
+| `PJ2026-0106` | 产品协同 | User-facing product surface and collaboration experience: Web/CLI/API workflows, history, multi-session UX, admin-facing interaction | Core Code Agent semantics, hardware pass/fail, billing ledger truth, runtime scheduling | Workflow semantics to 云智研; billing truth to 用户计量; runtime state to 执行编排 |

 ### L2 Topic

@@ -129,6 +129,12 @@ One paragraph describing the product and research objective.
 上级总项目: #1194
 总规格文档: <HWLabOA path or GitHub URL>

+## 主责边界
+
+- 主责对象:
+- 不负责:
+- 交接方向:
+
 ## 方向目标

 ...
@@ -166,6 +172,8 @@ One paragraph describing the product and research objective.
 编号: PJ2026-010N0M
 短名: <8字以内>
 上级总项目: #1194
+主责方向: PJ2026-010N <短名>
+关联方向: <可空；只列交接方向，不替代主责>
 所属方向: #...
 所属课题: #...
 规格文档: <HWLabOA path or URL>