Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
b987e2e62f |
@@ -138,31 +138,6 @@ curl -fsS -X PATCH "<gitea-base-url>/api/v1/repos/Octopus/octopus/issues/comment
|
||||
|
||||
单评论聚合不变量(工件索引、当前状态表等)的执行手段。
|
||||
|
||||
## Pattern 7: move-issue-to-column
|
||||
|
||||
看板列迁移(Todo → In Progress → Review → Done)。projects/columns
|
||||
发现用 REST;「把工单移到列」的操作端点语义复杂,经 swagger 查询后
|
||||
调用,不臆造路径:
|
||||
|
||||
```bash
|
||||
# 列出 repo 级 projects(projects 仅 repo 级,无 org/user 级端点)
|
||||
curl -fsS -H "Authorization: token <token>" \
|
||||
"<gitea-base-url>/api/v1/repos/Octopus/octopus/projects"
|
||||
# 列某 project 的 columns
|
||||
curl -fsS -H "Authorization: token <token>" \
|
||||
"<gitea-base-url>/api/v1/repos/Octopus/octopus/projects/{project_id}/columns"
|
||||
# 移动工单到列:先经 swagger.v1.json 查询 projects 相关端点后调用
|
||||
curl -s <gitea-base-url>/swagger.v1.json -o /tmp/gitea-sw.json
|
||||
jq -r '.paths | keys[]' /tmp/gitea-sw.json | grep projects
|
||||
```
|
||||
|
||||
## Pattern 7.5: move-issue-to-pipeline-stage
|
||||
|
||||
管线阶段板列(Pipeline Stages board column)承载阶段迁移——阶段转移
|
||||
落到板列,**不落** `## 当前状态` 行(该表只承载 PR / 评审 / CI 行与
|
||||
非阶段阻塞项)。列序列按管线阶段定义;移动与 Pattern 7 同款
|
||||
(projects/columns 经 REST + swagger 发现,同上)。
|
||||
|
||||
## Pattern 8: post-commit-status
|
||||
|
||||
commit status 直发 REST(评审综合的 Tier-2 落点):
|
||||
@@ -183,22 +158,6 @@ context 公式:`pipeline/review-{stage}`(`code` / `review-dag` /
|
||||
`audit-process`)。token 从实例配置读取(此处 `<token>` 占位)。
|
||||
merge 前读回验证:`GET /commits/{PR_SHA}/status`。
|
||||
|
||||
## Pattern 9: create-iteration-board
|
||||
|
||||
```bash
|
||||
# 建 project(board):先经 swagger 查询 create 端点契约
|
||||
curl -s <gitea-base-url>/swagger.v1.json -o /tmp/gitea-sw.json
|
||||
jq '.paths["/repos/{owner}/{repo}/projects"].post' /tmp/gitea-sw.json
|
||||
# 随后 POST 建板(title="{slug} — Iteration {N}", description="…")
|
||||
# 再对每列(Todo / In Progress / Review / Done):
|
||||
jq '.paths["/repos/{owner}/{repo}/projects/{project_id}/columns"].post' /tmp/gitea-sw.json
|
||||
# 随后 POST 建列
|
||||
```
|
||||
|
||||
projects 仅 repo 级。DAG 聚合 agent 在单门 PASS 后建板;工单正文模板带
|
||||
`## Node Reference`(指向 `{epic-slug}/dag`)、`## Acceptance Criteria`、
|
||||
`## Parent`。
|
||||
|
||||
## Pattern 10: artifact-index(工单 ↔ 工件索引)
|
||||
|
||||
技能发布工件后,在源工单维护 **`## 工件索引` 评论**——单一原位编辑的
|
||||
|
||||
@@ -80,7 +80,7 @@ curl -fsS -H "Authorization: token <token>" \
|
||||
|
||||
## Pattern 4: read-project-column-issues
|
||||
|
||||
看板列工单队列。project/column 发现:
|
||||
看板列工单队列(只读)。project/column 发现:
|
||||
|
||||
```
|
||||
curl -fsS -H "Authorization: token <token>" \
|
||||
@@ -89,9 +89,7 @@ curl -fsS -H "Authorization: token <token>" \
|
||||
"<gitea-base-url>/api/v1/repos/Octopus/octopus/projects/{project_id}/columns"
|
||||
```
|
||||
|
||||
「把工单移到列」等复杂操作:经 `swagger.v1.json`
|
||||
(`jq '.paths | keys[]' | grep projects`)查询 projects 相关端点后调用,
|
||||
不要臆造具体端点路径。projects 仅 repo 级(无 org/user 级端点)。
|
||||
projects 仅 repo 级(无 org/user 级端点)。
|
||||
|
||||
## Pattern 5: read-review-status(CLI)
|
||||
|
||||
|
||||
@@ -74,3 +74,24 @@
|
||||
| 6.1 | Tagged commit 可构建 | ☐ | ☐ | |
|
||||
| 6.2 | 测试全部通过 | ☐ | ☐ | |
|
||||
| 6.3 | 回到了原始分支 | ☐ | ☐ | |
|
||||
|
||||
---
|
||||
|
||||
## 7. 产物发布(DIST — Artifact Distribution,octopus 项目)
|
||||
|
||||
> 对应 `.octopus/skills/release/SKILL.md` Phase 4b(#2003 退役 CI publish
|
||||
> 管线后的手工发布流程)。**主仓库 tag + release 对象 ≠ 发布完成**——CLI
|
||||
> 二进制、公开镜像、桌面 feed 三层外圈全部就位才算。本清单从磁盘读取,
|
||||
> 作为技能注入被截断时的兜底事实源(v0.25.0 发布时技能注入截断恰好切掉
|
||||
> Phase 4b,导致外圈整层遗漏——本节由此设立)。
|
||||
|
||||
| # | 检查项 | 通过 | 不通过 | 备注 |
|
||||
| --- | ---------------------------------------- | ---- | ------ | ---- |
|
||||
| 7.1 | 12 平台 CLI 二进制已构建(tag 的干净 checkout,`bun packages/octopus/script/build.ts`),全部 smoke test 输出版本号 | ☐ | ☐ | Windows 无 `python3` 命令,zip 归档需垫 shim 或手动补齐 |
|
||||
| 7.2 | 12 个归档已挂到主仓库 release(zip×6 + tar.gz×6) | ☐ | ☐ | |
|
||||
| 7.3 | (可选,Gitea-only 口径可跳过)npm/docker/AUR 外部 registry 已发或明确跳过 | ☐ | ☐ | `OCTOPUS_GITEA_ONLY=true` |
|
||||
| 7.4 | `sync-public-assets.sh` 已跑:公共镜像 `Octopus/octopus-release` 的 `v{version}` release 有 12 资产 | ☐ | ☐ | 大 POST 出站不通时经服务器 localhost 中继 |
|
||||
| 7.5 | `sync-public-install.sh` 已跑:install/install.ps1/README 同步到镜像 main(注意 cp 目标是**根 README.md**,不是 scripts/ 副本) | ☐ | ☐ | |
|
||||
| 7.6 | `verify-public-sync.sh` PASSED | ☐ | ☐ | |
|
||||
| 7.7 | Desktop feed 双平台已派发(`desktop-feed.yml` dispatch ×2:beta/prod × win/linux),`latest.yml` 与 `latest-linux.yml` 的 `version:` == CLI 版本 | ☐ | ☐ | concurrency 组已按 platform 分离;资产字节数须与 feed 声明一致 |
|
||||
| 7.8 | README 下载链接抽查(install 脚本 raw、资产直链、docs 相对链接)匿名可达 | ☐ | ☐ | v0.18 遗留 wiki 坏链由此发现 |
|
||||
|
||||
@@ -46,9 +46,9 @@ Rules:
|
||||
surfaced by checklist annotations alone — do NOT add live-status rows for
|
||||
them. PR / review / CI transitions carry BOTH a checklist annotation AND
|
||||
a live-status row.
|
||||
- **Stage rows live on the board, not here**: pipeline stage transitions are
|
||||
represented by the Pipeline Stages board column (shared write-patterns
|
||||
Pattern 7.5), NOT by `## 当前状态` rows. Keep only the
|
||||
- **No stage rows here**: pipeline stage transitions are NOT represented by
|
||||
`## 当前状态` rows — they surface through checklist annotations at skill
|
||||
exits. Keep only the
|
||||
status-sync-automated rows (PR / 代码评审 / CI) and non-stage
|
||||
blockers/deferrals.
|
||||
- Update in place (same section heading `## 当前状态`), never append a second copy.
|
||||
|
||||
@@ -31,6 +31,7 @@
|
||||
},
|
||||
"quantitative_summary": {
|
||||
"type": "object",
|
||||
"description": "Every check the reviewer executed this round (PASS and FAIL counted in total_checks; NA reported via na_count). The verdict field must follow these counts per the thresholds documented on verdict — a synthesis consumer recalculates pass_rate from passed/total_checks and treats a mismatch as a malformed artifact.",
|
||||
"required": ["total_checks", "passed", "failed", "pass_rate"],
|
||||
"properties": {
|
||||
"total_checks": { "type": "integer", "minimum": 1 },
|
||||
@@ -74,7 +75,8 @@
|
||||
},
|
||||
"severity": {
|
||||
"type": "string",
|
||||
"enum": ["BLOCKER", "MAJOR", "MINOR", "INFO"]
|
||||
"enum": ["BLOCKER", "MAJOR", "MINOR", "INFO"],
|
||||
"description": "BLOCKER: breaks an acceptance criterion, hangs/leaks, or opens an abuse channel — the artifact must not land as-is. MAJOR: a real defect on a non-blocking path, or a test/lock blind to a plausible regression (a mutation would escape). MINOR: quality/drift issue with a cheap local fix (naming, duplication, small docs gap); no behavioral risk. INFO: observation, accepted-risk note, or follow-up ticket material — no action required this round. Calibration rule: severity grades the FINDING's impact, not the reviewer's confidence; low-confidence suspicions go to INFO with the evidence, never inflated to MAJOR."
|
||||
},
|
||||
"checklist_ref": {
|
||||
"type": "string",
|
||||
|
||||
@@ -41,11 +41,6 @@ in `_shared/gitea-write-patterns.md`.
|
||||
|
||||
**Orchestrator actions**:
|
||||
|
||||
0. **Move the source issue to the `review` column** on the Pipeline Stages
|
||||
board per `_shared/gitea-write-patterns.md` Pattern 7.5. Skip if no
|
||||
source issue exists. The review stage is a single board column covering
|
||||
all review targets (DAG single gate / code review / audit-process).
|
||||
|
||||
0.5. **Initialize the review-status file** (round 1 only). The Orchestrator
|
||||
creates `<runs-root>/{slug}/reviews/{stage}/status.json` before dispatching
|
||||
round 1, with the full schema-required field set
|
||||
@@ -111,6 +106,13 @@ in `_shared/gitea-write-patterns.md`.
|
||||
`core/skills/_shared/review-orchestrator-rules.md` — Default
|
||||
Explorer Permissions).
|
||||
- Temperature: 0.1 (deterministic output).
|
||||
- StructuredOutput mount ([org-internal #5658]): pass `format: { type:
|
||||
"json_schema", schema: <the reviewer-output.schema.json contents you
|
||||
read at prompt build time> }` on the task dispatch — the reviewer's
|
||||
final emission is schema-enforced (malformed verdict/severity/summary
|
||||
args are rejected with field-path repair feedback inside the reviewer's
|
||||
own loop). The findings FILE remains the canonical Tier-1 artifact; the
|
||||
structured output mirrors it as a self-check.
|
||||
|
||||
4. Wait for all {REVIEWER_OR_AUDITOR}s to complete. Each reviewer writes its
|
||||
dimension result to the skill's configured findings sink:
|
||||
@@ -171,6 +173,11 @@ in `_shared/gitea-write-patterns.md`.
|
||||
`tier1-local` skills; `/tmp/octopus/...` for `tier2-comment` skills)
|
||||
- `permissions`: read + write + edit + bash + glob + grep (all allow)
|
||||
- `temperature`: 0.1
|
||||
- `format` ([org-internal #5658]): `{ type: "json_schema", schema: <the
|
||||
synthesis.schema.json contents you read> }` — the Synthesizer's final
|
||||
emission is schema-enforced (malformed verdict/dimension args rejected
|
||||
with field-path repair feedback in-loop). The posted fenced JSON block
|
||||
remains the canonical artifact; the structured output mirrors it.
|
||||
- Foreground (the Orchestrator waits for completion).
|
||||
|
||||
3. The Synthesizer:
|
||||
|
||||
@@ -32,6 +32,18 @@ Label: {DIMENSION_NAME}
|
||||
|
||||
## Instructions
|
||||
|
||||
### Gate records are deterministic inputs ([org-internal #5656] N-04)
|
||||
|
||||
When the work item carries gate records (`gate` tool results — metadata
|
||||
`exit_code`, `duration_ms`, `ci_run_id`), those records ARE the command
|
||||
outcomes for mechanical questions (tests/typecheck/lint): cite the exit code
|
||||
verbatim (`gate <id> (<tier>): exit_code=<n> -> green|red` — canonical block
|
||||
in `packages/octopus/src/gate/consume.ts`) and never substitute a model's
|
||||
narration of command output. A claim that disagrees with a record's
|
||||
exit_code is a finding (record wins); a mechanical claim with no record is
|
||||
unverifiable — request the citation. A green verdict-cache hit
|
||||
(`metadata.verdict_cache.key`) counts the same as a fresh run.
|
||||
|
||||
{READ_FIRST_STEPS}
|
||||
4. For each checklist item, determine whether the {ARTIFACT_NOUN} satisfies it.
|
||||
Every checklist item must receive a PASS or FAIL verdict.
|
||||
@@ -46,6 +58,21 @@ Label: {DIMENSION_NAME}
|
||||
(reviewer_count > 1), use the slot-prefixed form {DIM}R{k}-F{NNN} with your
|
||||
1-based slot k (e.g. TOPOR1-F001) so parallel slot files never collide on id.
|
||||
{CONTRADICTION_RULE}
|
||||
6b. Code graph availability (worktree sessions): if `codegraph_status` is
|
||||
unavailable or reports no index for the tree under review (typical when
|
||||
reviewing from a session worktree whose per-worktree `.codegraph/` index
|
||||
has not finished building — see `<instance-root>/rules/code-graph.md`), do NOT
|
||||
silently substitute grep+read for structural questions ("who calls /
|
||||
what depends on / where defined"). Instead:
|
||||
- For symbols on the MAIN branch side (baselines, design refs, cross-session
|
||||
frozen contracts), you MAY query the main checkout's index (path given in
|
||||
your dispatch preamble) and cite `main:<path>:<line>`.
|
||||
- If no index is reachable at all, mark the affected checklist items NA
|
||||
with reason "codegraph unavailable — structural check degraded to grep"
|
||||
and emit one INFO finding (id `{DIM}-F001`-style, in your dimension's own
|
||||
code) recording the degradation, so the Synthesizer can surface it.
|
||||
Findings derived purely from grep+read when a graph query was required are
|
||||
treated as low-confidence and may be waived in synthesis.
|
||||
7. Assign severity strictly:
|
||||
{SEVERITY_DEFINITIONS}
|
||||
8. Count every PASS and FAIL. Compute pass_rate = passed / total_checks.
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
> Core 中立版(Increment 6a 改写,原 deferHard verbatim)。编号与条目结构严格不变(C-2 不变量);实例术语按 `core/adapters/TERMINOLOGY.md` 绑定。
|
||||
# > Core 中立版(Increment 6a 改写,原 deferHard verbatim)。编号与条目结构严格不变(C-2 不变量);实例术语按 `core/adapters/TERMINOLOGY.md` 绑定。
|
||||
name: Coordinator
|
||||
purpose: >
|
||||
Pool dispatch coordinator (billing-v2 [org-internal #4041] §7, REQ-F-012): a wake-driven,
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
> Core 中立版(Increment 6a 改写,原 deferHard verbatim)。编号与条目结构严格不变(C-2 不变量);实例术语按 `core/adapters/TERMINOLOGY.md` 绑定。
|
||||
# > Core 中立版(Increment 6a 改写,原 deferHard verbatim)。编号与条目结构严格不变(C-2 不变量);实例术语按 `core/adapters/TERMINOLOGY.md` 绑定。
|
||||
name: Producer
|
||||
purpose: >
|
||||
Write production artifacts — requirements, design, plans, code, fixes,
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
> Core 中立版(Increment 6a 改写,原 deferHard verbatim)。编号与条目结构严格不变(C-2 不变量);实例术语按 `core/adapters/TERMINOLOGY.md` 绑定。
|
||||
# > Core 中立版(Increment 6a 改写,原 deferHard verbatim)。编号与条目结构严格不变(C-2 不变量);实例术语按 `core/adapters/TERMINOLOGY.md` 绑定。
|
||||
name: Reviewer
|
||||
purpose: >
|
||||
Review one dimension of an artifact against its checklist, read-only.
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
> Core 中立版(Increment 6a 改写,原 deferHard verbatim)。编号与条目结构严格不变(C-2 不变量);实例术语按 `core/adapters/TERMINOLOGY.md` 绑定。
|
||||
# > Core 中立版(Increment 6a 改写,原 deferHard verbatim)。编号与条目结构严格不变(C-2 不变量);实例术语按 `core/adapters/TERMINOLOGY.md` 绑定。
|
||||
name: Tool
|
||||
purpose: >
|
||||
Specialized tool agent for image interpretation and other vision/utility
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
> Core 中立版(Increment 6a 改写,原 deferHard verbatim)。编号与条目结构严格不变(C-2 不变量);实例术语按 `core/adapters/TERMINOLOGY.md` 绑定。
|
||||
# > Core 中立版(Increment 6a 改写,原 deferHard verbatim)。编号与条目结构严格不变(C-2 不变量);实例术语按 `core/adapters/TERMINOLOGY.md` 绑定。
|
||||
name: Verifier
|
||||
purpose: >
|
||||
Run the iteration's DoD matrix, integration tests, NFR validation, and
|
||||
|
||||
@@ -198,6 +198,14 @@
|
||||
- **Rule 4 — Aggregation, not reinterpretation**: You MUST NOT soften, rephrase,
|
||||
or downgrade reviewer findings. If a reviewer writes "BLOCKER", it stays
|
||||
"BLOCKER" in synthesis.
|
||||
|
||||
1c. **Pass-rate recalc post-check (MANDATORY, [org-internal #5658])**: for
|
||||
every dimension, recompute `pass_rate = passed / total_checks` from its
|
||||
`quantitative_summary` and compare with the reported value. On a mismatch:
|
||||
keep the raw file unchanged, use the RECOMPUTED value in the synthesis
|
||||
digest, and note the mismatch — a reviewer-output whose `pass_rate` does
|
||||
not match its own counts is a malformed artifact (the schema description
|
||||
says exactly this; this step is the enforcement).
|
||||
- **Rule 5 — Anonymous findings preservation**: If two reviewers independently
|
||||
flag the same issue from different dimensions, preserve both entries. Do not
|
||||
deduplicate by discarding one — cross-dimension agreement is itself a signal.
|
||||
@@ -209,6 +217,11 @@
|
||||
Return ONLY this summary as your final message. Do NOT include the full
|
||||
synthesis JSON — it is already posted to the pipeline PR / source issue
|
||||
comment (for audit-process runs, the wiki page `audit/{date}/round{N}/synthesis`).
|
||||
|
||||
When your dispatch carries `format` (StructuredOutput mount, [org-internal
|
||||
[org-internal #5658]]): the structured output is the MIRROR self-check of this summary (same
|
||||
schema, schema-enforced), not a second artifact — the posted fenced JSON block
|
||||
and this summary remain canonical.
|
||||
Persist this summary verbatim to
|
||||
`<runs-root>/{slug}/reviews/{stage}/round{N}/synthesis-return.md` before
|
||||
returning (step 9 above — worker-report persistence [org-internal #2847]).
|
||||
|
||||
@@ -1,33 +1,14 @@
|
||||
---
|
||||
name: codegraph-setup
|
||||
description: >
|
||||
Use ONLY when installing, configuring, initializing, or troubleshooting CodeGraph
|
||||
(@colbymchenry/codegraph — https://github.com/colbymchenry/codegraph) in the
|
||||
octopus environment. Covers global CLI install, per-project `.codegraph/`
|
||||
indexing, and maintenance commands (status, sync, upgrade, uninstall). MCP
|
||||
wiring into octopus.jsonc is handled by the kickoff pipeline
|
||||
(`octopus kickoff` or `/kickoff`). Also use when a project session reports a
|
||||
missing/stale `.codegraph/` index.
|
||||
Use ONLY when installing, configuring, initializing, or troubleshooting
|
||||
CodeGraph (@colbymchenry/codegraph) in the octopus environment.
|
||||
triggers:
|
||||
- codegraph
|
||||
- code graph
|
||||
- codegraph setup
|
||||
- codegraph install
|
||||
- codegraph init
|
||||
- .codegraph
|
||||
- codegraph_explore
|
||||
- codegraph_node
|
||||
- codegraph_callers
|
||||
- codegraph_status
|
||||
- install codegraph
|
||||
# Chinese — bare nouns for code-graph concepts. The English "codegraph" brand
|
||||
# name above already covers mixed-language phrasings; these cover pure Chinese.
|
||||
- 代码图
|
||||
- 代码图谱
|
||||
- 代码索引
|
||||
- 索引代码
|
||||
- 装代码图
|
||||
- 初始化代码图
|
||||
role: Producer
|
||||
---
|
||||
|
||||
|
||||
@@ -179,10 +179,6 @@ Available work items:
|
||||
|
||||
#### Phase 1 — Parse Context
|
||||
|
||||
> **Pipeline stage**: if the source issue exists, move it to the `implement`
|
||||
> column on the Pipeline Stages board per `_shared/gitea-write-patterns.md`
|
||||
> Pattern 7.5. Skip if no source issue exists.
|
||||
|
||||
Read the upstream artifacts to build a complete implementation context.
|
||||
Resolve inputs per the DAG-route read map (Preconditions above); standalone
|
||||
modes read the request/bug report instead:
|
||||
@@ -499,11 +495,6 @@ issue exists.
|
||||
retired — each one re-triggered the full CI surface for near-zero re-tested
|
||||
risk.
|
||||
|
||||
> **Kanban column lifecycle**: manual — move the source issue across board
|
||||
> columns explicitly as the pipeline stage changes (Pattern 7.5 in
|
||||
> `_shared/gitea-write-patterns.md`); column semantics: wiki
|
||||
> `kanban-lifecycle`.
|
||||
|
||||
---
|
||||
|
||||
#### Phase 5 — Report
|
||||
|
||||
@@ -97,10 +97,7 @@ The stage IDs remain as-is — they are used by the stage registry and auto-appr
|
||||
This skill follows the standardized parallel-review pipeline. The full mechanics are in:
|
||||
|
||||
- `<!-- inject: ../_shared/review-pipeline-phases.md -->` — Phase A through Phase E
|
||||
- **Phase A step 0**: move the source issue to the `review` column on the
|
||||
Pipeline Stages board per `_shared/gitea-write-patterns.md` Pattern 7.5
|
||||
(see `_shared/review-pipeline-phases.md` for the canonical orchestrator
|
||||
actions — step 0 is now part of the shared flow).
|
||||
(canonical orchestrator actions for the shared flow)
|
||||
- `<!-- inject: ../_shared/review-orchestrator-rules.md -->` — mandatory orchestrator rules
|
||||
- `<!-- inject: ../_shared/review-final-report-template.md -->` — final report format
|
||||
- `<!-- inject: ../_shared/review-revision-prompt.md -->` — Phase C revision prompt template
|
||||
|
||||
@@ -458,7 +458,7 @@ table).
|
||||
<!-- section:phase-a -->
|
||||
## Phase A — Parallel Review
|
||||
|
||||
> **Canonical mechanics**: `core/skills/_shared/review-pipeline-phases.md` — keep this section in sync with the canonical Phase A–E flow. This section adds review-code-specific constants (10 dimensions, severity definitions, risk tiers, output mode, standalone-bugfix mode). Step 0 (move source issue to `review` column on Pipeline Stages board per Pattern 7.5) is inherited from the shared Phase A orchestrator actions; see `_shared/review-pipeline-phases.md`.
|
||||
> **Canonical mechanics**: `core/skills/_shared/review-pipeline-phases.md` — keep this section in sync with the canonical Phase A–E flow. This section adds review-code-specific constants (10 dimensions, severity definitions, risk tiers, output mode, standalone-bugfix mode); orchestrator actions are inherited from the shared Phase A flow.
|
||||
|
||||
### Standalone Bugfix Mode — Orchestrator Dispatch
|
||||
|
||||
@@ -530,6 +530,13 @@ fallback is retired with the design pipeline, [org-internal #3072] phase 3):
|
||||
emits the reviewer's output; it does NOT touch the code under review, so
|
||||
rule #7 auditor independence holds.)
|
||||
- Temperature: 0.1 (deterministic output).
|
||||
- StructuredOutput mount ([org-internal #5658]): pass `format: { type: "json_schema",
|
||||
schema: <the reviewer-output.schema.json contents you read at prompt
|
||||
build time> }` on the Task dispatch — the reviewer's final emission is
|
||||
schema-enforced (malformed verdict/severity/summary args are rejected
|
||||
with field-path repair feedback inside the reviewer's own loop). The
|
||||
findings FILE remains the canonical Tier-1 artifact; the structured
|
||||
output mirrors it as a self-check.
|
||||
|
||||
**Worktree-path rule (mandatory)**: Every file path in the reviewer prompt
|
||||
(`{FILE_SECTIONS}`, design reference paths, artifact paths) MUST be the
|
||||
@@ -545,6 +552,21 @@ fallback is retired with the design pipeline, [org-internal #3072] phase 3):
|
||||
observed in the 2026-07 auto-approve retrospective (5-round convergence,
|
||||
67.7% rework fraction).
|
||||
|
||||
**Code-graph availability preamble (worktree sessions, [org-internal #4187])**: the main
|
||||
checkout's `.codegraph/` index does NOT cover a session worktree
|
||||
([org-internal #2561]/TD-006). Before dispatch, the Orchestrator checks the worktree's
|
||||
own index: run `codegraph_status` against the worktree root, or check for
|
||||
`<worktree-root>/.codegraph/codegraph.db` (a bare `init.log` without the
|
||||
db means the background `session-worktree.sh create` init is still running).
|
||||
Include in each reviewer's dispatch preamble: (a) the worktree index state
|
||||
(ready / building / absent), and (b) when absent or still building, the
|
||||
ABSOLUTE path of the main checkout (which has its own `.codegraph/`) so
|
||||
DGN/COR reviewers can query MAIN-side symbols (design baselines, frozen
|
||||
cross-session contracts) from the main checkout's index and cite them as
|
||||
`main:<path>:<line>`. Reviewers apply rule 6b of
|
||||
`_shared/review-reviewer-prompt.md` (NA + INFO finding) when no index is
|
||||
reachable at all — grep-only structural claims must never pass silently.
|
||||
|
||||
4. Wait for all reviewers to complete. Each reviewer writes its finding JSON to
|
||||
`<runs-root>/{slug}/reviews/code/round{N}/findings-{DIMENSION_CODE}.json`
|
||||
(Tier 1 local, validated by `core/schemas/reviewer-output.schema.json`). After all
|
||||
|
||||
@@ -196,10 +196,6 @@ each missing item.
|
||||
<!-- section:phase-1 -->
|
||||
## Phase 1 — Load Verification Context
|
||||
|
||||
> **Pipeline stage**: if the source issue exists, move it to the `verify`
|
||||
> column on the Pipeline Stages board per `_shared/gitea-write-patterns.md`
|
||||
> Pattern 7.5. Skip if no source issue exists.
|
||||
|
||||
Read the upstream artifacts. DAG task/milestone mode (the live path — see
|
||||
the DAG branch below for its read map):
|
||||
|
||||
@@ -310,6 +306,20 @@ gate fingerprint is keyed on the working tree (SHA + uncommitted state +
|
||||
untracked), so it covers pre-push/headless states the same-SHA CI clauses
|
||||
cannot.
|
||||
|
||||
### 2.0b — Gate Records as Deterministic Inputs ([org-internal #5656] N-04)
|
||||
|
||||
Mechanical checks MUST be grounded in gate records (`gate` tool result
|
||||
metadata), never in a model's transcription of command output:
|
||||
|
||||
- Cite `exit_code` verbatim — canonical block from
|
||||
`packages/octopus/src/gate/consume.ts`: `gate <id> (<tier>):
|
||||
exit_code=<n> -> green|red`, plus `duration_ms` / `ci_run_id` when present.
|
||||
- `exit_code === null` (timeout/abort) is NO verdict — rerun required; a
|
||||
pass claim cannot stand on it.
|
||||
- A green verdict-cache hit (`metadata.verdict_cache.key`) satisfies the
|
||||
check the same as a fresh run (content-addressed, same fingerprint).
|
||||
- Narration drift (claim != record) is itself a verification finding.
|
||||
|
||||
### 2.1 Full Test Suite
|
||||
|
||||
```bash
|
||||
@@ -1203,10 +1213,7 @@ If the user confirms, invoke the commit workflow per
|
||||
|
||||
An iteration is NOT Done until all code is committed in git history.
|
||||
|
||||
After the commit gate passes, move the source issue to the `done` column on
|
||||
the Pipeline Stages board per `_shared/gitea-write-patterns.md` Pattern 7.5.
|
||||
Skip if no source issue exists. `done` is a stage column marker; issue
|
||||
closing follows the lifecycle per `issue-checklist-sync.md` 归档动作.
|
||||
Issue closing follows the lifecycle per `issue-checklist-sync.md` 归档动作.
|
||||
|
||||
To notify workflow completion, call the `signal_stage_done` tool.
|
||||
|
||||
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "octopus-workflow",
|
||||
"version": "0.1.5",
|
||||
"version": "0.1.6",
|
||||
"description": "Standalone workflow core: provider-neutral agent workflow corpus (skills / rules / checklists / templates / schemas) with drift guards, extracted from the octopus agent platform.",
|
||||
"license": "MIT",
|
||||
"private": false,
|
||||
|
||||
Reference in New Issue
Block a user