chore: bootstrap mirus-tech agent workflow policy #11

Merged

jmz merged 6 commits from maximus/chore/policy-bootstrap into main 2026-05-03 17:40:52 +00:00

Conversation 2 Commits 6 Files changed 2 +105 -9

jmz commented 2026-05-03 17:03:07 +00:00

Owner

Copy link

Bootstraps the Mirus Tech multi-agent workflow policy in this repo.

Summary

• Adds docs/AGENT_WORKFLOW.md (canonical policy doc)
• Adds .forgejo/PULL_REQUEST_TEMPLATE.md and .forgejo/ISSUE_TEMPLATE/*
• Adds .forgejo/workflows/check.yml (CI scaffold)

User impact

New contributors and agents see the policy on the repo page; PR + issue templates are pre-populated; CI gate exists for self-merge.

Verification

Generated by ensure-repo-policy.py. Idempotent.

Related

Refs /srv/mirus/AGENT_WORKFLOW.md (canonical source).

Bootstraps the Mirus Tech multi-agent workflow policy in this repo. ## Summary - Adds `docs/AGENT_WORKFLOW.md` (canonical policy doc) - Adds `.forgejo/PULL_REQUEST_TEMPLATE.md` and `.forgejo/ISSUE_TEMPLATE/*` - Adds `.forgejo/workflows/check.yml` (CI scaffold) ## User impact New contributors and agents see the policy on the repo page; PR + issue templates are pre-populated; CI gate exists for self-merge. ## Verification Generated by `ensure-repo-policy.py`. Idempotent. ## Related Refs `/srv/mirus/AGENT_WORKFLOW.md` (canonical source).

jmz added the

type:chore

priority:p3

agent:maximus

labels 2026-05-03 17:03:07 +00:00

jmz added 1 commit 2026-05-03 17:03:07 +00:00

chore: bootstrap mirus-tech agent workflow policy ... e664bc8d4a

Adds docs/AGENT_WORKFLOW.md, PR + issue templates, and CI scaffold (if absent).
Generated by ensure-repo-policy.py.

jmz added 1 commit 2026-05-03 17:08:58 +00:00

ci: pin RUSTUP_INIT_SKIP_PATH_CHECK so install survives system cargo ... dd3ab3dc90

Picks up the upstream template fix (mirus-tools commit a25ba53). Without
this env var, rustup-init bails on the rpi5 runner because Debian's
cargo is at /usr/bin/cargo. The bypass lets the install proceed into
RUNNER_TEMP without touching the system or the runner user's home.

jmz added 1 commit 2026-05-03 17:16:20 +00:00

ci: hoist CARGO_HOME / RUSTUP_HOME to job-level env (mirus-tools 8a28828) 855c2c17c8

jmz added 1 commit 2026-05-03 17:19:40 +00:00

ci: switch to GITHUB_ENV for cross-step env (mirus-tools 0cc7bf7) 4e47c92c9d

jmz added 1 commit 2026-05-03 17:25:27 +00:00

ci: collapse to single rust step (mirus-tools d1445b5) 8b948b8fcc

jmz closed this pull request 2026-05-03 17:27:18 +00:00

jmz commented 2026-05-03 17:27:42 +00:00

Author

Owner

Copy link

Closing without merging. Backstory:

The intent was to swap the generic CI scaffold for the real Rust template now that mirus-tools commit dd7c4bb landed (rust template self-installs its toolchain via rustup, insulating from system rustc 1.85 vs matrix-sdk MSRV 1.88).

The chain of fixes (mirus-tools PRs #18, #19, #20, #21) each hit a different layer of the problem:

1. PR #18 — RUSTUP_INIT_SKIP_PATH_CHECK=yes to bypass rustup-init's "cannot install while Rust is installed" bail (Debian's /usr/bin/cargo on the runner host).
2. PR #19 — hoist CARGO_HOME / RUSTUP_HOME to job-level env so subsequent steps inherit them. Tripped Forgejo's YAML schema validator: Unknown Variable Access runner for ${{ runner.temp }} in declarative env values.
3. PR #20 — switch to GITHUB_ENV / GITHUB_PATH for cross-step propagation. Validator still rejected the workflow shape (failed-to-match-job).
4. PR #21 — collapse to a single combined step (no top-level env, no step-level env). mirus-tools self-CI passes; matrix-bridge runs still fail.

The matrix-bridge runner journal shows multiple CI runs landing for each push (one per on: trigger), some of which clearly use main's generic.yml ("Run Main OK") rather than the PR branch's rust.yml. Whether that's pull_request-uses-base-ref behaviour or my own runner-noise-attribution problem, more iteration without a clearer mental model of Forgejo Actions' dispatch semantics isn't productive.

State: matrix-bridge's main remains on generic.yml; full compliance preserved (check / check (pull_request) status green; branch protection FF-only-strict; full label vocab; templates committed; policy doc committed). Real Rust CI is a deferrable polish item, not a policy gap.

If revisiting later: read the Forgejo Actions YAML validator source (gitea/forgejo-runner) for the exact allowed env-block + context-expression shapes, validate offline against rust.yml, then ship one clean PR rather than iterating against the live runner.

Closing without merging. Backstory: The intent was to swap the generic CI scaffold for the real Rust template now that mirus-tools commit dd7c4bb landed (rust template self-installs its toolchain via rustup, insulating from system rustc 1.85 vs matrix-sdk MSRV 1.88). The chain of fixes (mirus-tools PRs #18, #19, #20, #21) each hit a different layer of the problem: 1. **PR #18** — `RUSTUP_INIT_SKIP_PATH_CHECK=yes` to bypass rustup-init's "cannot install while Rust is installed" bail (Debian's `/usr/bin/cargo` on the runner host). 2. **PR #19** — hoist CARGO_HOME / RUSTUP_HOME to job-level env so subsequent steps inherit them. Tripped Forgejo's YAML schema validator: `Unknown Variable Access runner` for `${{ runner.temp }}` in declarative env values. 3. **PR #20** — switch to GITHUB_ENV / GITHUB_PATH for cross-step propagation. Validator still rejected the workflow shape (failed-to-match-job). 4. **PR #21** — collapse to a single combined step (no top-level env, no step-level env). mirus-tools self-CI passes; matrix-bridge runs still fail. The matrix-bridge runner journal shows multiple CI runs landing for each push (one per `on:` trigger), some of which clearly use `main`'s generic.yml ("Run Main OK") rather than the PR branch's rust.yml. Whether that's `pull_request`-uses-base-ref behaviour or my own runner-noise-attribution problem, more iteration without a clearer mental model of Forgejo Actions' dispatch semantics isn't productive. **State**: matrix-bridge's `main` remains on generic.yml; full compliance preserved (`check / check (pull_request)` status green; branch protection FF-only-strict; full label vocab; templates committed; policy doc committed). Real Rust CI is a deferrable polish item, not a policy gap. If revisiting later: read the Forgejo Actions YAML validator source (gitea/forgejo-runner) for the *exact* allowed env-block + context-expression shapes, validate offline against rust.yml, then ship one clean PR rather than iterating against the live runner.

jmz reopened this pull request 2026-05-03 17:35:18 +00:00

jmz added 1 commit 2026-05-03 17:35:47 +00:00

ci: trigger fresh run after PR reopen 7951048ca6

jmz merged commit 7951048ca6 into main 2026-05-03 17:40:52 +00:00

jmz commented 2026-05-03 17:41:40 +00:00

Author

Owner

Copy link

Summary

matrix-bridge now uses the real Rust CI scaffold instead of generic gitleaks-only. Toolchain self-installs via rustup at job start, so CI doesn't depend on the runner host's system rustc (Debian 1.85, too old for matrix-sdk MSRVs).

Changes

• .forgejo/workflows/check.yml — single combined step "rust toolchain + cargo check + clippy". RUSTUP_INIT_SKIP_PATH_CHECK=yes lets rustup-init coexist with the runner's /usr/bin/cargo. CARGO_HOME / RUSTUP_HOME scoped to RUNNER_TEMP.
• docs/AGENT_WORKFLOW.md — refreshed from the canonical /srv/mirus/AGENT_WORKFLOW.md.

User impact

PRs against matrix-bridge now run a real cargo check --all + cargo clippy --all on every push. End-to-end run took 3m51s (rustup install + matrix-sdk dep tree + check) on the rpi5 runner.

Verification

• forgejo-runner validate --workflow --path .forgejo/workflows/check.yml → OK (offline schema validator).
• TASK-1244 (Forgejo run #10) dispatched cleanly, all steps succeeded.
• check / check (pull_request) status check green.

Trade-off

Clippy regressions surface as the combined "rust" step failing rather than a distinct cargo-clippy step. Acceptable; clippy output is still emitted to the job log.

Process notes

• Earlier attempts (PR branch's commit history) iterated against the live runner before realising forgejo-runner validate exists — saved a memory entry so the offline-first approach is the default next time.
• Job-level env: blocks containing ${{ runner.* }} context expressions trigger the schema validator's "Unknown Variable Access runner" / "Unknown Property env" errors. The minimal single-step pattern dodges this entirely.

## Summary matrix-bridge now uses the real Rust CI scaffold instead of generic gitleaks-only. Toolchain self-installs via rustup at job start, so CI doesn't depend on the runner host's system rustc (Debian 1.85, too old for matrix-sdk MSRVs). ## Changes - `.forgejo/workflows/check.yml` — single combined step "rust toolchain + cargo check + clippy". `RUSTUP_INIT_SKIP_PATH_CHECK=yes` lets rustup-init coexist with the runner's `/usr/bin/cargo`. CARGO_HOME / RUSTUP_HOME scoped to `RUNNER_TEMP`. - `docs/AGENT_WORKFLOW.md` — refreshed from the canonical `/srv/mirus/AGENT_WORKFLOW.md`. ## User impact PRs against matrix-bridge now run a real `cargo check --all` + `cargo clippy --all` on every push. End-to-end run took 3m51s (rustup install + matrix-sdk dep tree + check) on the rpi5 runner. ## Verification - `forgejo-runner validate --workflow --path .forgejo/workflows/check.yml` → OK (offline schema validator). - TASK-1244 (Forgejo run #10) dispatched cleanly, all steps succeeded. - `check / check (pull_request)` status check green. ## Trade-off Clippy regressions surface as the combined "rust" step failing rather than a distinct cargo-clippy step. Acceptable; clippy output is still emitted to the job log. ## Process notes - Earlier attempts (PR branch's commit history) iterated against the live runner before realising `forgejo-runner validate` exists — saved a memory entry so the offline-first approach is the default next time. - Job-level `env:` blocks containing `${{ runner.* }}` context expressions trigger the schema validator's "Unknown Variable Access runner" / "Unknown Property env" errors. The minimal single-step pattern dodges this entirely.

jmz referenced this pull request from a commit 2026-05-03 20:47:01 +00:00

fix(ci): pin runs-on to rpi5 + sync policy doc

jmz referenced this pull request from a commit 2026-05-03 20:47:20 +00:00

fix(ci): pin runs-on to rpi5 + sync policy doc

maximus referenced this pull request 2026-05-03 20:48:03 +00:00

fix(ci): pin runs-on to rpi5 + sync policy doc #13

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

agent:felinus

Felinus is driving

  

agent:human

A human is driving

  

agent:maximus

Maximus is driving

  

priority:p0

Drop everything; production down

  

priority:p1

Important; days

  

priority:p2

Normal; weeks

  

priority:p3

Low; whenever

  

status:blocked

Waiting on input or dependency

  

status:needs-review

Ready for human eyes

  

status:wip

Active in-progress

  

type:chore

Tooling, infra, no shipped behaviour change

  

type:docs

Documentation only

  

type:feat

New feature or capability

  

type:fix

Bug fix

  

type:perf

Performance improvement

  

type:refactor

Code restructuring with no behaviour change

  

type:test

Test additions / fixes

No labels

agent:felinus

agent:human

agent:maximus

priority:p0

priority:p1

priority:p2

priority:p3

status:blocked

status:needs-review

status:wip

type:chore

type:docs

type:feat

type:fix

type:perf

type:refactor

type:test

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

jmz/matrix-bridge!11

No description provided.