Octopus/octopus-workflow
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.1.1: Gitea transport surface de-MCP — REST+swagger sole canon (adapter recipes, terminology map, review probes)

Browse Source
This commit is contained in:
octopus
2026-09-15 09:59:04 +08:00
parent bb35e661b2
commit 18ffce5d29
15 changed files with 202 additions and 136 deletions
Download Patch File Download Diff File Expand all files Collapse all files
core/skills/_shared/review-pipeline-phases.md
+18 -14
View File
@@ -68,12 +68,13 @@ in `_shared/gitea-write-patterns.md`.
in the Orchestrator instead of letting {DIMENSION_COUNT} parallel subagents
each rediscover the gap:
- **Primary path**: confirm `gitea_wiki__*` tools are registered (the
Orchestrator checks its own tool catalog; these tools are forwarded to
reviewer subagents when registered — [org-internal #2116] raised the tool cap 50→100 so
they are present in normal runs). If available → continue to step 2.
- **Fallback path** (when `gitea_wiki__*` is NOT registered, e.g. a
cross-repo scenario [org-internal #2115]): verify the **local wiki clone** at
- **Primary path**: confirm the Gitea REST API is reachable — probe
`GET <gitea-base-url>/api/v1/repos/{owner}/{repo}/wiki/pages` with
`-H "Authorization: token <token>"` (a 200 or 403 response means
reachable; anything else — timeout, connection refused, 5xx — is
unreachable). If reachable → continue to step 2.
- **Fallback path** (when REST is unreachable, e.g. a
cross-repo scenario [org-internal #2115]): verify the **local wiki clone** at
`<wiki-clone-root>/{repo}-wiki/` is readable —
`glob(pattern="*.md", path="<wiki-clone-root>/{repo}-wiki/")`. If the clone
is readable → continue to step 2; reviewers use the local clone (see
@@ -82,13 +83,14 @@ in `_shared/gitea-write-patterns.md`.
- **Both unavailable → FAIL FAST**: post a `failure` commit status (state
`"failure"`, context `pipeline/{REVIEW_TYPE}`, description naming the
missing capability) and abort — do NOT enter parallel dispatch. Report the
gap so the environment can be fixed (register the wiki MCP server, or
populate `<wiki-clone-root>/{repo}-wiki/`).
gap so the environment can be fixed (restore Gitea REST reachability —
token validity, network route — or
populate `<wiki-clone-root>/{repo}-wiki/`).
This probe is belt-and-suspenders: RC1 (tool cap, [org-internal #2116]) already fixed the
primary cause of missing `gitea_wiki__*` in subagents. It exists so a future
environment regression fails gracefully with one clear message instead of N
silent subagent aborts.
This probe is belt-and-suspenders: it exists so a future
environment regression (REST unreachable, stale token) fails gracefully
with one clear message instead of N
silent subagent aborts.
2. Post an initial pending commit status via REST:
@@ -471,8 +473,10 @@ not the round-1 full set.
3.5. **Gitea approval timing (mandatory when the PR needs a human approval
gate)**: if the flow requests approval from a human reviewer on Gitea,
register the reviewer FIRST via `gitea_pull__add_reviewer`, wait for the
`REQUEST_REVIEW` registration to be recorded, and only THEN ask the human
register the reviewer FIRST via
`POST <gitea-base-url>/api/v1/repos/{owner}/{repo}/pulls/{index}/requested_reviewers`,
wait for the
`REQUEST_REVIEW` registration to be recorded, and only THEN ask the human
to approve. Approving before the reviewer is registered produces
`official: false` on the approval — the gate treats the PR as unapproved
and the approval must be re-done. ([org-internal #1931]: audit R2→R3 re-loop + re-approve,
core/skills/_shared/review-reviewer-prompt.md
+2 -1
View File
@@ -65,7 +65,8 @@ Label: {DIMENSION_NAME}
## What You Must NOT Do
- Do NOT fabricate results. If a tool you need (e.g. `gitea_wiki__get_page`,
- Do NOT fabricate results. If a tool you need (e.g. the Gitea REST call
`GET <gitea-base-url>/api/v1/repos/{owner}/{repo}/wiki/pages`,
`read`, `codegraph_*`) is unavailable, errors, or returns empty, report the
failure honestly — emit a finding stating the dimension could not be
reviewed due to the missing tool. NEVER invent findings, severities, or
core/skills/headless-session-ops/reference/ticket-recipe.md
+2 -2
View File
@@ -65,8 +65,8 @@ model**.
and coordinate on the issue before proceeding.
**c. Open-PR check.** List open PRs referencing `#N` —
`工单 API（见 TERMINOLOGY）search(q: "#N", type: "pulls", state: "open")` (API source)
or `gitea_pull__list` — and **ABORT** if an open PR already covers the ticket.
`GET <gitea-base-url>/api/v1/repos/issues/search?q="#N"&type=pulls&state=open`
(API source) — and **ABORT** if an open PR already covers the ticket.
**d. Remote branch check ([org-internal #2297]).** A local branch is invisible to other
sessions — check the remote too:
core/skills/implement/reference/bugfix-mode.md
+4 -4
View File
@@ -104,15 +104,15 @@ Phase 2 and Phase 4, not after the fix:
[Worker: developer] Phase 1 reproduce + Phase 2 root cause
→ write repro-notes (reproduction steps, root cause, bug path,
expected behavior)
↓ persist: wiki page `{slug}/repro-notes` (gitea_wiki__create_page)
↓ persist: wiki page `{slug}/repro-notes` (`POST .../wiki/new`, body `content_base64`)
[Worker: tester] read repro-notes → Phase 3 write failing regression test
(confirms FAIL before fix)
↓ persist: wiki page `{slug}/test-report` (gitea_wiki__create_page, failing test confirmed)
↓ persist: wiki page `{slug}/test-report` (`POST .../wiki/new`, body `content_base64`, failing test confirmed)
[Worker: developer] Phase 4 fix → run test:changed to green
→ write impl-notes (post-fix behavior contract)
↓ persist: wiki page `{slug}/impl-notes` (gitea_wiki__create_page, post-fix behavior contract)
↓ persist: wiki page `{slug}/impl-notes` (`POST .../wiki/new`, body `content_base64`, post-fix behavior contract)
[Worker: tester] supplement boundary regression tests → run test:changed
↓ persist: update wiki page `{slug}/test-report` (gitea_wiki__update_page, final)
↓ persist: update wiki page `{slug}/test-report` (`PATCH .../wiki/page/{mangled-name}`, omit `title`, body `content_base64` — final)
— consumed by the human stakeholder / next iteration planning for DoD regression-test evidence
```
core/skills/implement/reference/implement-mode.md
+2 -2
View File
@@ -499,8 +499,8 @@ issue exists.
retired — each one re-triggered the full CI surface for near-zero re-tested
risk.
> **Kanban column lifecycle**: automated (`工单 API（见 TERMINOLOGY）create` → Backlog,
> `gitea_pull__create` → Review; no manual moves). Single shared reference:
> **Kanban column lifecycle**: automated (`POST <gitea-base-url>/api/v1/repos/{owner}/{repo}/issues` → Backlog,
> `POST .../pulls` → Review; no manual moves). Single shared reference:
> `_shared/gitea-write-patterns.md` Pattern 7.5; column semantics: wiki
> `kanban-lifecycle`.
core/skills/implement/reference/refactor-mode.md
+1 -1
View File
@@ -234,7 +234,7 @@ After all steps are complete:
{If the refactoring changes the internal architecture in a way that merits an
ADR, reference the ADR. **Deprecated:** `.artifacts/{slug}/design/adr/{NNNN}-*.md`
→ ADRs now live on the Gitea wiki at page `{slug}/03-adr-{NNNN}-{title}`,
readable via `gitea_wiki__get_page`. Or "None".}
readable via `GET <gitea-base-url>/api/v1/repos/{owner}/{repo}/wiki/page/{mangled-name}`. Or "None".}
---
core/skills/review-artifact/SKILL.md
+10 -7
View File
@@ -25,19 +25,22 @@ role: Reviewer
## Tool Availability & Path Resolution
This skill's reviewers (parallel Explorer subagents) read two kinds of files.
Some runs lack the `gitea_wiki__*` MCP tools (cross-repo scenario, [org-internal #2115]); the
fallbacks below keep reviews working without them.
Some runs cannot reach the Gitea REST API (cross-repo scenario, [org-internal #2115]); the
fallbacks below keep reviews working without it.
The Orchestrator probes availability **before dispatching reviewers** (Phase A
The Orchestrator probes REST reachability **before dispatching reviewers** (Phase A
step 1, `_shared/review-pipeline-phases.md`) and fails fast if neither path is
usable, so every reviewer has a working read path by the time it runs.
### Wiki artifacts (DAG artifact / review reports)
- **Primary**: `wiki 读写 API（见 TERMINOLOGY）(owner, repo, page_name)` — use when the
tool is available. `page_name` construction is in
- **Primary**: `GET <gitea-base-url>/api/v1/repos/{owner}/{repo}/wiki/page/{mangled-name}`
— use when REST is reachable. Resolve `{mangled-name}` from
`GET .../wiki/pages` (`sub_url` — mangled name with `%2F` encoding and
possible `.-` suffix); never construct it by hand. Page-name resolution
context is in
`_shared/gitea-read-patterns.md` Pattern 1.
- **Fallback** (when `gitea_wiki__*` is unavailable): read the **local wiki
- **Fallback** (when REST is unreachable): read the **local wiki
clone** at `<wiki-clone-root>/{repo}-wiki/` — a git checkout of the wiki repo,
kept current. Wiki filenames are URL-encoded (`/` → `%2F`, with a possible
`.-` before `.md`), so resolve the file with `glob` rather than constructing
@@ -393,7 +396,7 @@ file (concurrent write race):
- `{BASELINE_SECTION}`:
```
## Baseline
The artifact under review is the DAG at wiki page `{epic-slug}/dag` (read via `gitea_wiki__get_page`). Read it first for orientation. Its `dag_metrics.review_depth` (D1–D4) sets this review's depth and round cap.
The artifact under review is the DAG at wiki page `{epic-slug}/dag` (read via `GET <gitea-base-url>/api/v1/repos/{owner}/{repo}/wiki/page/{mangled-name}`, `sub_url` resolved from `GET .../wiki/pages` first). Read it first for orientation. Its `dag_metrics.review_depth` (D1–D4) sets this review's depth and round cap.
```
- `{READ_FIRST_STEPS}`:
1. Read the DAG artifact at `{epic-slug}/dag` first for orientation.
core/skills/review-code/SKILL.md
+3 -2
View File
@@ -974,7 +974,8 @@ After the Developer completes revision:
`question` tool, passing `stage: "review-code"`:
> **Gitea approval timing (mandatory when the PR needs a human approval
> gate)**: register the reviewer FIRST via `gitea_pull__add_reviewer`,
> gate)**: register the reviewer FIRST via
> `POST <gitea-base-url>/api/v1/repos/{owner}/{repo}/pulls/{index}/requested_reviewers`,
> wait for the `REQUEST_REVIEW` registration to be recorded, and only
> THEN ask the human to approve. Approving before the reviewer is
> registered produces `official: false` on the approval — the gate
@@ -987,7 +988,7 @@ After the Developer completes revision:
Final verdict: {PASS | WARN | FAIL}
Converged: {true | false}
See full report: wiki page `{slug}/reviews/code/final/report` （DAG task mode: `{epic-slug}/reviews/code/final/report-task-{node-id}`）（via `gitea_wiki__get_page`，`_shared/gitea-read-patterns.md` Pattern 1）
See full report: wiki page `{slug}/reviews/code/final/report` （DAG task mode: `{epic-slug}/reviews/code/final/report-task-{node-id}`）（via `GET <gitea-base-url>/api/v1/repos/{owner}/{repo}/wiki/page/{mangled-name}` — `sub_url` resolved from `GET .../wiki/pages` first, `_shared/gitea-read-patterns.md` Pattern 1）
All review artifacts: ticket #{issue_number} comments + wiki pages under `{slug}/reviews/code/`（DAG task mode: under `{epic-slug}/reviews/code/`, Tier 1 round artifacts under `<runs-root>/{epic-slug}-task-{node-id}/reviews/code/`）
Inline comments（only when step 2.56 ran；omit for no-PR flows）: `inline: X posted / Y file-level / Z fallback / W failed`
core/skills/verify/SKILL.md
+14 -16
View File
@@ -732,10 +732,10 @@ originating slug in each row so the trail survives.
independent ticket THEN, carrying the reserved `TD-NNN`:
```
gitea_issue__create(owner="Octopus", repo="octopus",
title="[{origin}] Tech debt: {short description} (TD-{NNN})",
body=<promotion template below>,
labels=[tech_debt_label_id, severity_label_id])
POST <gitea-base-url>/api/v1/repos/Octopus/octopus/issues
body: {"title":"[{origin}] Tech debt: {short description} (TD-{NNN})",
"body":<promotion template below>,
"labels":[tech_debt_label_id, severity_label_id]}
```
- **Severity → label** (reuse the existing exclusive Priority set):
@@ -820,8 +820,7 @@ AND closed), per `core/rules/testing.md`** (de-duplicate BEFORE filing,
retro [org-internal #2696]). Query `baseline-failure` issues in ALL states:
```
gitea_issue__list(owner="Octopus", repo="octopus",
labels="baseline-failure", state="all")
GET <gitea-base-url>/api/v1/repos/Octopus/octopus/issues?labels=baseline-failure&state=all&page=N&limit=50
```
Match each candidate by **failure signature** — the error/assertion signature
@@ -848,10 +847,10 @@ number `#NNNN` is the tracker handle.
no existing family matches the signature:
```
gitea_issue__create(owner="Octopus", repo="octopus",
title="[{origin}] Baseline failure: {test identifier} (BF-{NNN})",
body=<issue body template below>,
labels=[baseline_failure_label_id, severity_label_id, kind_bug_label_id])
POST <gitea-base-url>/api/v1/repos/Octopus/octopus/issues
body: {"title":"[{origin}] Baseline failure: {test identifier} (BF-{NNN})",
"body":<issue body template below>,
"labels":[baseline_failure_label_id, severity_label_id, kind_bug_label_id]}
```
- **Title**: `[{origin}] Baseline failure: {signature summary} (BF-{NNN})`
@@ -965,8 +964,7 @@ AND closed), per `core/rules/testing.md`** (de-duplicate BEFORE filing,
retro [org-internal #2696]). Query `flaky-test` issues in ALL states:
```
gitea_issue__list(owner="Octopus", repo="octopus",
labels="flaky-test", state="all")
GET <gitea-base-url>/api/v1/repos/Octopus/octopus/issues?labels=flaky-test&state=all&page=N&limit=50
```
Match each candidate by **failure signature** — the flakiness mode (timeout /
@@ -991,10 +989,10 @@ incl. closed tickets). `FT-NNN` names the FAMILY.
no existing family matches the signature:
```
gitea_issue__create(owner="Octopus", repo="octopus",
title="[{origin}] Flaky test: {test identifier} (FT-{NNN})",
body=<issue body template below>,
labels=[flaky_test_label_id, severity_label_id, kind_testing_label_id])
POST <gitea-base-url>/api/v1/repos/Octopus/octopus/issues
body: {"title":"[{origin}] Flaky test: {test identifier} (FT-{NNN})",
"body":<issue body template below>,
"labels":[flaky_test_label_id, severity_label_id, kind_testing_label_id]}
```
- **Title**: `[{origin}] Flaky test: {signature summary} (FT-{NNN})` — the