docs: constrain oa l1 directions to capability domains
This commit is contained in:
Codex
@@ -20,12 +20,13 @@ Use this skill to keep HWLAB Cloud M1 project management centered on a stable ma
|
||||
- Treat GitHub issues as the execution control plane: hierarchy, status, discussion, cross-repo references, PR linkage, and closeout evidence.
|
||||
- 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.
|
||||
|
||||
## Canonical HWLAB Issue Anchors
|
||||
|
||||
- L0 master specification: `pikasTech/HWLAB#1194` (`HWLAB 总项目规格（L0）：云端硬件研发平台总控`).
|
||||
- Long-term navigation board: `pikasTech/HWLAB#645` (`HWLAB 长期总面板`). This is a board, not the specification.
|
||||
- Current Cloud M1 phase specification: `pikasTech/HWLAB#644` (`HWLAB Cloud SPEC / 云平台开发目标 20260601`).
|
||||
- Current Cloud M1 phase specification: `pikasTech/HWLAB#644` (`HWLAB Cloud SPEC / 云平台开发目标 20260601`). This is a phase spec, not an L1 direction.
|
||||
- When creating or updating HWLAB project-management issues, link nontrivial L1/L2/L3/L4 work back to `#1194` and keep `#645` as a navigation index only.
|
||||
|
||||
## Workflow
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
HWLAB Cloud M1 needs a project control structure that prevents local issue/PR work from drifting away from the center. Use a research-project style hierarchy:
|
||||
|
||||
- Major project: overall mission, product goal, delivery boundary.
|
||||
- Direction: stable workstream under the major project.
|
||||
- Direction: stable capability domain under the major project that directly serves the L0 mission.
|
||||
- Topic: concrete program of work inside a direction.
|
||||
- Subtopic: bounded validation slice with explicit acceptance criteria.
|
||||
- Execution task: issue, PR, CaseRun, smoke, deployment, or document closeout.
|
||||
@@ -35,7 +35,7 @@ Do not store the only copy of a stable requirement in an issue comment. If the r
|
||||
|
||||
- L0 master specification: `pikasTech/HWLAB#1194` (`HWLAB 总项目规格（L0）：云端硬件研发平台总控`).
|
||||
- Long-term board/navigation: `pikasTech/HWLAB#645` (`HWLAB 长期总面板`). Do not treat this as the specification.
|
||||
- Cloud M1 phase specification: `pikasTech/HWLAB#644` (`HWLAB Cloud SPEC / 云平台开发目标 20260601`).
|
||||
- Cloud M1 phase specification: `pikasTech/HWLAB#644` (`HWLAB Cloud SPEC / 云平台开发目标 20260601`). This is a phase spec, not an L1 direction.
|
||||
- New or updated direction/topic/execution issues should include `上级总项目: #1194` unless the user explicitly scopes the task outside HWLAB Cloud M1.
|
||||
|
||||
## Suggested HWLabOA Structure
|
||||
@@ -76,6 +76,8 @@ There should normally be one L0 GitHub issue and one L0 master spec document. Fo
|
||||
|
||||
### L1 Direction
|
||||
|
||||
L1 directions are the top-level capability domains that directly serve the L0 mission. They are not project-management artifacts.
|
||||
|
||||
Each direction must answer:
|
||||
|
||||
- Which part of the L0 goal it serves.
|
||||
@@ -84,14 +86,21 @@ Each direction must answer:
|
||||
- Which original user/runtime entry validates it.
|
||||
- Which L2 topics currently matter.
|
||||
|
||||
Do not use any of these as L1 directions:
|
||||
|
||||
- Document cleanup, stage reports, or issue/body maintenance.
|
||||
- Project-management mechanics, board maintenance, skill maintenance, or OA process work.
|
||||
- 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:
|
||||
|
||||
- Embedded cloud-development loop: ARM2D, PLC/ConStart, CaseRun.
|
||||
- Multi-user cloud platform: auth, user-billing, usage, collaboration.
|
||||
- HWPOD hardware access: specs, board-comm, device nodes, Keil/D601 bridge.
|
||||
- AgentRun execution substrate: runner/session/resource/recovery.
|
||||
- UniDesk control plane: trans, GitHub, Sub2API, YAML ops, D601/G14/PK01.
|
||||
- Cloud Web/product surface: v0.3 Vue parity, workbench, admin, usage, access.
|
||||
- Cloud AI hardware-development workflow: user request, workspace, Code Agent implementation, review, collaboration, delivery.
|
||||
- Real hardware access and auditable validation loop: target device, debug probe, io probe, CaseRun, low-noise evidence.
|
||||
- Multi-user cloud service and commercial metering: auth, API keys, credit, usage ledger, billing, admin operations.
|
||||
- Execution substrate and resource orchestration: AgentRun/HWPOD/Code Agent runtime assembly, sessions, provider profiles, bundles, recovery.
|
||||
- Capability accumulation, training feedback, and quality control: harness cases, failure taxonomy, review, reusable templates, model/tool improvement.
|
||||
- User product surface and collaboration experience: Web/CLI/API workflows that expose the above capabilities to users.
|
||||
|
||||
### L2 Topic
|
||||
|
||||
@@ -122,6 +131,7 @@ Execution tasks map to one PR, one runtime validation, one CaseRun, or one close
|
||||
Flag a task as drift-risk when:
|
||||
|
||||
- It has no L1/L2 parent.
|
||||
- It treats documentation, project management, board maintenance, or skill maintenance as the parent direction.
|
||||
- It improves tooling but does not remove a named blocker.
|
||||
- It changes a runtime/control plane without an original validation entry.
|
||||
- It expands frontend parity without tying back to Code Agent/HWPOD/user workflow.
|
||||
|
||||
@@ -23,12 +23,12 @@ One paragraph describing the product and research objective.
|
||||
|
||||
| Level | Title | GitHub issue | Spec section | Current status |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| L1 | Embedded cloud-development loop | TBD | ... | ... |
|
||||
| L1 | Multi-user cloud platform | TBD | ... | ... |
|
||||
| L1 | HWPOD hardware access | TBD | ... | ... |
|
||||
| L1 | AgentRun execution substrate | TBD | ... | ... |
|
||||
| L1 | UniDesk control plane | TBD | ... | ... |
|
||||
| L1 | Cloud Web/product surface | TBD | ... | ... |
|
||||
| L1 | Cloud AI hardware-development workflow | TBD | ... | ... |
|
||||
| L1 | Real hardware access and auditable validation loop | TBD | ... | ... |
|
||||
| L1 | Multi-user cloud service and commercial metering | TBD | ... | ... |
|
||||
| L1 | Execution substrate and resource orchestration | TBD | ... | ... |
|
||||
| L1 | Capability accumulation, training feedback, and quality control | TBD | ... | ... |
|
||||
| L1 | User product surface and collaboration experience | TBD | ... | ... |
|
||||
|
||||
## 5. Global Acceptance Criteria
|
||||
|
||||
@@ -83,6 +83,8 @@ One paragraph describing the product and research objective.
|
||||
- [ ] #... 方向B:
|
||||
- [ ] #... 方向C:
|
||||
|
||||
方向判定: L1 必须是直接服务 L0 的能力域；文档整理、项目管理、看板维护、skill 维护、仓库名、工具名和临时执行路径不得作为 L1。
|
||||
|
||||
## 全局验收
|
||||
|
||||
- ...
|
||||
|
||||
Reference in New Issue
Block a user