skynet/agent-runtime-framework
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(forge-credential): hatchmate working-repo key layer + 4 composite forks #3

Merged
ai_admin merged 1 commits from feat/hatchmate-per-project-fork-key into main 2026-09-18 02:05:50 +00:00
Conversation 0 Commits 1 Files Changed 7 +123 -5
ai_admin commented 2026-09-18 01:05:57 +00:00
Contributor
Copy Link

Context

M2-CRS W4 unblock. Agent jobs dispatched for the hatchmate project were failing to clone hatchmate/hatchmate-agents because the shared gitea-ssh/v1 context mounts the ai_enablement deploy key (scoped to skynet/* only). The same bug would hit every project whose working repo lives outside the skynet org.

This implements the per-org pattern the framework already uses for accelerators (gitea-ssh-accelerators/v1) and homelab (gitea-ssh-homelab/v1).

What

  • New gitea-ssh-hatchmate/v1 forge-credential context (mirrors gitea-ssh-accelerators/v1)
    • account_ref: "hatchmate.space:platform"
    • write_targets: ["gitea.oreillyit.nz/hatchmate/*"]
    • ssh alias gitea.oreillyit.nz-hatchmate → matched by the URL git@gitea.oreillyit.nz-hatchmate:hatchmate/hatchmate-agents.git
  • 4 new composite forks: code-{fable,minimax,airouter,opus}-tdd-repo-hatchmate/v1/harness.yaml
    • Compose BOTH gitea-ssh/v1 (for reference clones, skynet org) AND gitea-ssh-hatchmate/v1 (for working-repo clone + push)
  • Fix pre-existing test bug: tests/invariants/test_forge_credentials_declare_write_targets.py had xfail(strict=True) but all 4 existing layers already declare write_targets → was XPASS-ing. Removed the marker so HC-11 is now a real positive gate (5 layers instead of 4).

Verification

  • pytest tests/invariants/ → 7/7 pass
  • HC-11 test flips from XPASS(strict) to a real pass
  • W4 already has the new account provisioned (CP account 21ef21f9-..., grant bc4c3375-..., K8s Secret acct-21ef21f9 materialised)

Companion CRS change

hatchmate-crs PR will route roles to the -hatchmate composites and flip AGENT_REPO_URL to the per-org scp-form URL (git@gitea.oreillyit.nz-hatchmate:...) so SSH resolves to the right IdentityFile.

## Context M2-CRS W4 unblock. Agent jobs dispatched for the hatchmate project were failing to clone `hatchmate/hatchmate-agents` because the shared `gitea-ssh/v1` context mounts the `ai_enablement` deploy key (scoped to `skynet/*` only). The same bug would hit every project whose working repo lives outside the `skynet` org. This implements the per-org pattern the framework already uses for accelerators (`gitea-ssh-accelerators/v1`) and homelab (`gitea-ssh-homelab/v1`). ## What - New `gitea-ssh-hatchmate/v1` forge-credential context (mirrors `gitea-ssh-accelerators/v1`) - `account_ref: "hatchmate.space:platform"` - `write_targets: ["gitea.oreillyit.nz/hatchmate/*"]` - ssh alias `gitea.oreillyit.nz-hatchmate` → matched by the URL `git@gitea.oreillyit.nz-hatchmate:hatchmate/hatchmate-agents.git` - 4 new composite forks: `code-{fable,minimax,airouter,opus}-tdd-repo-hatchmate/v1/harness.yaml` - Compose BOTH `gitea-ssh/v1` (for reference clones, skynet org) AND `gitea-ssh-hatchmate/v1` (for working-repo clone + push) - Fix pre-existing test bug: `tests/invariants/test_forge_credentials_declare_write_targets.py` had `xfail(strict=True)` but all 4 existing layers already declare `write_targets` → was `XPASS`-ing. Removed the marker so HC-11 is now a real positive gate (5 layers instead of 4). ## Verification - `pytest tests/invariants/` → 7/7 pass - HC-11 test flips from `XPASS(strict)` to a real pass - W4 already has the new account provisioned (CP account `21ef21f9-...`, grant `bc4c3375-...`, K8s Secret `acct-21ef21f9` materialised) ## Companion CRS change hatchmate-crs PR will route roles to the `-hatchmate` composites and flip `AGENT_REPO_URL` to the per-org scp-form URL (`git@gitea.oreillyit.nz-hatchmate:...`) so SSH resolves to the right IdentityFile.
ai_admin added 1 commit 2026-09-18 01:05:58 +00:00
feat(forge-credential): add gitea-ssh-hatchmate/v1 layer + 4 hatchmate composite forks 59f7b9e5f8 
M2-CRS W4 unblock: dispatched agents could not clone hatchmate/hatchmate-agents
because the shared gitea-ssh/v1 context mounts the ai_enablement deploy key,
which is scoped to skynet/* only. Same bug would hit every project whose
working repo lives outside the skynet org.

This implements the per-org pattern the framework already uses for accelerators
(gitea-ssh-accelerators/v1) and homelab (gitea-ssh-homelab/v1):

- harnesses/contexts/gitea-ssh-hatchmate/v1/{init.sh,harness.yaml} — NEW
  forge-credential context mirroring accelerators, with account_ref
  'hatchmate.space:platform' and write_targets covering hatchmate/*. The
  init.sh stages the ESO-mounted private key to ~/.ssh/gitea-oreillyit-nz-hatchmate
  (matching the ssh alias declared in harness.yaml). URL host pattern
  'gitea.oreillyit.nz-hatchmate' (per-org alias) drives SSH config block
  selection — already auto-written by harness_init.py from each layer's
  ssh_hosts: declarations.

- harnesses/composites/code-*-tdd-repo-hatchmate/v1/ — NEW composites for
  fable/minimax/airouter/opus that compose BOTH gitea-ssh/v1 (for reference
  clones, skynet org) AND gitea-ssh-hatchmate/v1 (for working-repo clone +
  push, hatchmate org). Composites are unchanged for non-hatchmate projects.

- tests/invariants/test_forge_credentials_declare_write_targets.py — the
  existing xfail(strict=True) marker was wrong: the 4 existing layers all
  declare write_targets today, so the test was XPASSing. Removed the
  xfail marker so HC-11 is now a real positive gate (5 layers instead
  of 4). This was a pre-existing test bug surfaced by the 5th layer.

W4 next step: dispatcher's account_ref resolution needs the hatchmate CP
account + grant to be created (via the new scripts/provision-hatchmate-fork-key.sh
in the hatchmate app repo).
ai_admin merged commit c89cb5beab into main 2026-09-18 02:05:50 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
admin ai_enablement
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: skynet/agent-runtime-framework#3
Delete Branch "feat/hatchmate-per-project-fork-key"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?