feat: Wire all programs to org profile (org portability PR B)

[rubambiza]

Summary

PR B ("rewire") of the org-portability refactor. Wires all seven scanner/fixer programs to the load_org_profile() seam introduced in PR A (#43) so the suite targets any GitHub org via one committed profile file, and completes the kagenti→rossoctl rename as the first consumer.

Every program now resolves its org identity by precedence --flag > env > profile > default (ORG, FORK_OWNER, MAIN_REPO, REPOS_DIR, SOURCE_REPO, plus the transitional REMAP). No org name is hardcoded in a read or write path; the default profile (config/org.env) supplies rossoctl.

What changed

Rewire (Tasks 5–9):

• dep-bump-scanner, dep-bump-fixer, pr-review-scanner, pr-review-impact, link-health-scanner, link-health-fixer wired to the loader; --org/--fork-owner/--repos-dir/--profile flags added where missing.
• automation-health-dashboard newly sources program-lib.sh; --kagenti-dir/KAGENTI_DIR renamed to --main-repo-dir/MAIN_REPO_DIR (old flag kept as a deprecated, warning alias).
• Fixed a silent prefix bug in link-health-fixer (${repo#"$ORG/"} → ${repo##*/}): the $ORG-coupled strip failed when ORG ≠ the repo owner.

Report home (#44):

• The org main repo's docs/ now feeds the docs site and cannot host machine reports, so both standing report PRs (link-health, dashboard) write a single perpetual file under automation-health/ in this repo, overwritten in place each run. History is reconstructed from git commit history — no dated snapshots. Added automation-health/README.md documenting the convention.

Auditability:

• Report PRs are branded and carry an "Automation program" section linking back to the invoking program's standing order, via a new overridable SOURCE_REPO fact (default $ORG/automation).
• Standing orders (standing-orders/*.md) synced with the rename, report destinations, epic refs, and pr-review scope; added standing-orders/repo-sync.md for the nightly clone-sync program.

Tests/docs (Task 10):

• Portability smoke test proving a foreign-org profile yields <org>/* refs with no rossoctl/kagenti leak.
• README "Org profile" section + "Adapting for a Different Org" workflow.

Verification

• Full unit suite green (org-profile, core-repos, pr-review-integration, pr-review-impact, extract-broken-links, parse-diff-map).
• Deployed and exercised live: the link-health and dashboard report PRs (docs: Link health report (auto-updated) #45, docs: Automation health dashboard (auto-updated) #46) push to automation-health/ here with correct cross-fork wiring and standing-order links.
• Parity confirmed for the default rossoctl case (every read ref resolves to the same string as before the rewire).

Fixes #30
Closes #31

Notes for reviewers

• PR A (feat: Add org-portability seam (load_org_profile + bare core-repos) #43) is already merged; this branch is based directly on it (no rebase needed).
• The transitional REMAP (kagenti→rossoctl, kagenti-extensions→cortex) self-retires once clone dirs are renamed (chore: Rename clone dirs to canonical names and retire the remap shim #37).
• A few OpenClaw platform display strings are intentionally left (tooling name, not an org ref).

Assisted-By: Claude Code

[clawgenti]

Solid org-portability rewire — the profile-seam abstraction is clean and the ${repo##*/} prefix-strip fix (#389) is correct. 14/14 commits are DCO signed-off and CI (DCO) passes.

Findings:

suggestion scripts/link-health-scanner.sh line 59 — FORK_REMOTE is still hardcoded "clawgenti-kagenti-fork". On an existing deployment this remote already exists in .git/config pointing at github.com/clawgenti/kagenti.git (the old report target). Because the git remote get-url guard at line 649 succeeds, the new URL (clawgenti/automation.git) is never registered and pushes silently land on the wrong repo. Consider renaming the constant (e.g. "$FORK_OWNER-automation-fork") or adding a remote-URL update step after the guard.

nit scripts/automation-health-dashboard.sh line 23 — MAIN_REPO_DIR is seeded from ${KAGENTI_DIR:-} as a migration alias. If KAGENTI_DIR is still set in the environment from an old deployment it will silently shadow the profile-derived REPOS_DIR/automation path. A one-time warning (echo "WARN: KAGENTI_DIR is deprecated" >&2) here would match the pattern used by --kagenti-dir at line 185.

---

Reviewed by clawgenti using github:pr-review

[clawgenti]

suggestion: FORK_REMOTE is still hardcoded as "clawgenti-kagenti-fork". On an existing deployment this remote exists in .git/config pointing at github.com/clawgenti/kagenti.git (the old report target). The guard at the remote-add block (git remote get-url "$FORK_REMOTE") will succeed and skip re-registering the URL — pushes will land on the wrong repo. Either rename the constant to something like "$FORK_OWNER-automation-fork" (so old remotes don't collide), or add a URL-update step:

git remote set-url "$FORK_REMOTE" "https://github.com/$FORK_OWNER/${REPORT_TARGET_NAME}.git" 2>/dev/null || \
  git remote add "$FORK_REMOTE" "https://github.com/$FORK_OWNER/${REPORT_TARGET_NAME}.git"

[clawgenti]

nit: MAIN_REPO_DIR is seeded from ${KAGENTI_DIR:-} as a silent migration alias. If KAGENTI_DIR is still set in the environment from an old deployment, it will silently win over the profile-derived default, masking the new REPOS_DIR/automation path. A deprecation warning here would match the explicit one added for --kagenti-dir at line 185:

if [ -n "${KAGENTI_DIR:-}" ]; then
  echo "WARN: KAGENTI_DIR is deprecated; set MAIN_REPO_DIR instead" >&2
fi
MAIN_REPO_DIR="${MAIN_REPO_DIR:-${KAGENTI_DIR:-}}"

[rubambiza]

Thanks for the review. Both addressed in 55034e1:

suggestion (FORK_REMOTE) — dropped the hardcoded clawgenti-kagenti-fork literal; the remote name now derives from the profile ($FORK_OWNER-automation-fork). More importantly, both report writers now register the remote with git remote set-url ... || git remote add ... instead of the guard-then-skip, so a stale remote left by a prior deployment is corrected to the current target rather than silently pushing to the old repo. (Good catch — this is the same class of issue we hit during the controlled live run.)

nit (KAGENTI_DIR) — rather than warn, removed the alias entirely. The report jobs no longer pass KAGENTI_DIR (migrated to --main-repo-dir), so it only guarded a scenario that no longer exists. Both the KAGENTI_DIR env seed and the --kagenti-dir flag are gone; --main-repo-dir/MAIN_REPO_DIR is now the sole interface.

Assisted-By: Claude Code

[clawgenti]

The latest commit (55034e14) fully addresses both prior review findings: FORK_REMOTE is now derived from $FORK_OWNER-automation-fork, and both report writers use set-url || add to correct stale remotes; KAGENTI_DIR/--kagenti-dir is removed entirely (not just warned against). All 15 commits are DCO signed-off, CI passes, and no residual org literals remain in the rewired code paths.

All checks pass. Ready for human review.

---

Reviewed by clawgenti using github:pr-review

[cwiklik]

PR B of the org-portability refactor — wires all seven programs to the load_org_profile() seam and completes the kagenti→rossoctl rename. Clean, well-decomposed (15 commits), and it lands the design from #42 well.

Verified:

• Each program calls load_org_profile exactly once — the rewire is uniform (dep-bump scanner/fixer, pr-review scanner/impact, link-health scanner/fixer, health-dashboard).
• No hardcoded org identifiers remain in read/write paths — the only kagenti/rossoctl literals added are human-facing branding strings and the portability test's leak-guard.
• Clobber-safety (my note on #42): the profile uses PROFILE_*-prefixed vars, so ORG="${ORG_FLAG:-${ORG:-${PROFILE_ORG:-}}}" can't be clobbered by a sourced profile — and the smoke test explicitly asserts a testorg profile yields testorg/* with no rossoctl/kagenti leak.
• SOURCE_REPO added with the same --flag > env > PROFILE_* > default idiom and exported.

DCO green (all commits signed), no .claude/.vscode.

One non-blocking maintainer note: the behavior-changing part is the report-PR redirect (dashboard/link-health now land reports under automation-health/ in MAIN_REPO, PRs linking back to SOURCE_REPO standing orders). That's the one path the org-profile unit test doesn't cover, and these programs open real PRs against live repos — worth a --dry-run parity confirmation (per the spec's rollout step) before the first live run against rossoctl. Also minor: SOURCE_REPO is a new identity fact beyond the #42 spec's original set — worth a one-line addendum there for traceability.

LGTM.

Assisted-By: Claude Code

[evaline-ju]

lgtm, few non-blocking nits

[evaline-ju]

L86 sets this now, so this appears to be dead code

[rubambiza]

I think this guard is still valid against cases where neither MAIN_REPORT_DIR was exported when calling the script nor was REPOS_DIR set, in which case L86 may have derived nothing or garbage.

[evaline-ju]

I'm not quite understanding. From the way L86 forms variables, I don't think it can derive empty especially with the L81 fallback, and a garbage case would not fall into this branch anyway with the emptiness guard (L459)

[rubambiza]

You're right, and my earlier reply was off. REPORT_TARGET_DIR falls back to $REPOS_DIR/$REPORT_TARGET_NAME, and $REPORT_TARGET_NAME is always non-empty ("automation"), so the string is never empty — an unset REPOS_DIR would abort earlier under set -u, and a garbage path is non-empty and correctly caught by the .git check. Removed the dead -z guard in f7d006a and folded the actionable "export MAIN_REPO_DIR" hint into the surviving .git existence check. Thanks for the catch.

[evaline-ju]

same dead code due to L57

[rubambiza]

Same comment as the automation-health-dashboard script.

[rubambiza]

Same fix applied here in f7d006a — removed the unreachable -z guard, kept the .git check with the hint. (Conceding the same point as on the dashboard thread; my earlier "same comment" reply doesn't hold.)

[evaline-ju]

the SOURCE_REPO_FLAG doesn't seem to exist

[rubambiza]

Correct — I added SOURCE_REPO with the full --flag > env > PROFILE_* > default idiom to mirror the other facts, but never wired a --source-repo flag into any arg loop, so the SOURCE_REPO_FLAG tier did nothing. Dropped it in f7d006a; SOURCE_REPO now resolves via env > profile > default, which fits it being a deploy-level constant rather than a per-invocation knob. Thanks.