factory-hygiene row 41 (orthogonal-axes audit) + fork-pr-workflow -1 gotcha

.claude/skills/fork-pr-workflow/SKILL.md

@@ -100,6 +100,59 @@ shortcut. Use an explicit `git push upstream` only when
 the action is intended (for example, force-pushing a
 tag you own).
 
+### Gotcha: `gh repo fork` suffixed my fork with `-1`
+
+GitHub will create your fork at `<you>/<repo>-1` (or
+`-2`, etc.) instead of `<you>/<repo>` when your
+personal namespace already has a **redirect record**
+for that repo name. This happens most often when you
+previously owned a repo named `<repo>` and transferred
+it elsewhere — the transfer leaves a 301 redirect
+record at the old name that reserves the slot. A fresh
+fork can't land on that exact name while the redirect
+lives.
+
+Detect:
+
+```bash
+# A redirect record looks like this:
+curl -sI https://github.com/<you>/<repo> | head -5
+# HTTP/2 301
+# location: https://github.com/<actual-owner>/<repo>
+```
+
+Or after the fork:
+
+```bash
+gh api /repos/<you>/<repo>-1 --jq '.full_name'
+# "<you>/<repo>-1"   ← suffix confirms redirect blocked <repo>
+```
+
+Recover — **you own the redirect record**, so you can
+override it by renaming your own fork into the slot:
+
+```bash
+gh repo rename --repo <you>/<repo>-1 <repo>
+```
+
+After rename, update any local remote URL that pointed
+at `-1`:
+
+```bash
+git remote set-url origin https://github.com/<you>/<repo>.git
+```
+
+An existing cross-repo PR you opened before the rename
+continues to work because GitHub tracks PR head
+references by repo ID (not name). Verify with
+`gh pr view <n> --repo <upstream> --json headRepositoryOwner,headRefName`.
+
+Prevention: if the canonical repo moved out of your
+namespace recently and you plan to fork it back, do
+the rename in the same session as the fork so
+contributors reading `git remote -v` never see the
+`-1` form.
+
 ## Daily loop — per-change upstream PR (default)
 
 The default rhythm is **one upstream PR per change**:

docs/BACKLOG.md

@@ -847,6 +847,38 @@ within each priority tier.
 
 ## P1 — Factory / static-analysis / tooling (round-33 surface)
 
+- [ ] **Orthogonal-axes cadenced audit — make the factory's
+  axis set an orthogonal basis (round 44 absorb)** — Aaron
+  2026-04-22: *"also we need to make sure all our axises are
+  orthogaonal to the others so therre is not overlap, like
+  fully ... When all your axes are orthogonal basis covered
+  (meaning they are mutually perpendicular), the set of axes
+  is called an orthogonal basis"* + *"i guess this is a
+  cadence thing"* + *"backlog"*. The factory classifies
+  artefacts along many axes (skill-category, hygiene-scope,
+  persona-surface, cadence-bucket, memory-type, review-target,
+  trust-tier, …). For the axis set to form a proper basis
+  (linear-algebra sense), every pair must be independent —
+  an axis's values must carry information no other axis
+  carries. Distinct from the row-22 symmetry audit: symmetry
+  asks *"is A paired with its mirror B?"*; orthogonality asks
+  *"do axes A and B have zero overlap?"* Landed this round:
+  `docs/FACTORY-HYGIENE.md` row #41 (cadence, owner TBD,
+  scope factory). Durable rule in
+  `memory/feedback_orthogonal_axes_factory_hygiene.md`. **Work
+  queued here:** (a) first audit pass — enumerate current
+  factory axes, build pairwise overlap matrix, flag per-pair
+  verdicts (collapse / keep-and-document / split); (b)
+  decide owner — dedicated capability skill
+  `orthogonal-axes-auditor` vs. fold into skill-tune-up as
+  criterion #8 (parallels the scope-auditor option-a/option-b
+  debate in the sibling P1 row below); (c) seed the first
+  overlap matrix into `docs/research/` so subsequent rounds
+  have a delta surface. Effort: M for option (a); add S for
+  option (b) skill-tune-up extension, L for option (c) new
+  capability skill via `skill-creator`. Reviewer: Architect
+  (Kenji); Daya (AX) weighs in if axes touch agent-experience.
+
 - [ ] **Gap 3 closure — memory-file tampering cross-check at
   session start (round 44 trust-infra thread)** — Aaron
   2026-04-20 research question: *"can AI trust humans didn't

docs/FACTORY-HYGIENE.md

@@ -83,6 +83,7 @@ is never destructive; retiring one requires an ADR in
 | 38 | Harness-surface cadenced audit | Every 5-10 rounds per populated harness (same cadence as skill-tune-up and agent-QOL). Stubs don't tick. | Per populated harness: Claude owned by Architect (Kenji) **interim** until a dedicated harness-guide role is decided; plugin-provided `claude-code-guide` agent (Anthropic official plugin cache, not a local `.claude/agents/` file) is a reference resource consulted during audit, not the audit runner. Codex / Cursor / GitHub Copilot / Antigravity / Amazon Q / Kiro — TBD when populated (either dedicated guide per harness or a shared multi-harness guide). | factory | Audit each populated harness's platform surfaces for new features, cut features, behavioural changes. For Claude: model / Code CLI / Desktop app / Agent SDK / API. For Codex / Cursor / Copilot / Antigravity / Amazon Q / Kiro: per-harness equivalents inventoried at first-populated audit. Primary feature-comparison axis per harness is skill-authoring + eval-driven feedback loop (the Claude-Code feature that made it Aaron's primary choice — `memory/user_skill_creator_killer_feature_feedback_loop.md`). Update `docs/HARNESS-SURFACES.md` living inventory with adoption statuses (adopted / watched / untested / rejected / stub). When audit surfaces drift, either adopt (ADR if Tier-3), retire the workaround the new feature obsoletes, or record explicit rejection in `docs/WONT-DO.md`. Integration-point tests per harness are owned by a *different* harness per the capability-boundary rule (a harness cannot honestly self-verify its own factory integration from within itself). Triggering incidents: 2026-04-20 AutoMemory miss (Anthropic's Q1-2026 feature mis-attributed as factory-native) + 2026-04-20 multi-harness expansion (Aaron: factory supports multiple harnesses; each tests the others'). | `docs/HARNESS-SURFACES.md` audit log row per cycle per populated harness; ADRs under `docs/DECISIONS/` for Tier-3 adoptions; `docs/research/meta-wins-log.md` entry when a pre-existing factory assumption is found to have been wrong | `feedback_claude_surface_cadence_research.md` + `feedback_multi_harness_support_each_tests_own_integration.md` + `user_skill_creator_killer_feature_feedback_loop.md` + `reference_automemory_anthropic_feature.md` + `reference_autodream_feature.md` |
 | 39 | Hot-file-path detector | Round-cadence (every round close) or every 5-10 rounds — whichever catches churn drift before the next merge-tangle. Proposed 2026-04-21. | TBD — candidate capability skill `hot-file-detector` (queued in BACKLOG P1); Architect runs inline until the skill lands. | factory (ships to adopters as a command-line recipe) | `git log --since="60 days ago" --name-only --pretty=format: \| grep -v '^$' \| sort \| uniq -c \| sort -rn \| head -25` — git history *is* the index. Heuristic threshold: >20 changes in 60d on a single monolithic doc = investigate; >30 = refactor candidate (tune after 5-10 rounds). Per-file decision is one of four: `refactor-split` (per-row, per-round, per-section), `consolidate-reduce` (merge with a sibling), `accept-as-append-only` (legitimately append-only → split into per-round files rather than trimming), or `observe`. Pair with merge-tangle fingerprints from `docs/research/parallel-worktree-safety-2026-04-22.md` §9 — a hot file is worse if also in a recent conflict list. Triggering incident: PR #31 5-file merge-tangle (2026-04-21) where `docs/ROUND-HISTORY.md` at 33 changes / 60d was the #1 conflict source, and `docs/BACKLOG.md` at 26 already has an in-flight split ADR. | Audit doc per cycle listing top-N hot paths + per-file decision; BACKLOG rows for refactor-split candidates; ADRs for structural changes. | `feedback_hot_file_path_detector_hygiene.md` + `docs/DECISIONS/2026-04-22-backlog-per-row-file-restructure.md` (same pattern) |
 | 40 | GitHub-settings drift detector | Weekly (cron `17 14 * * 1`) + on any change to `tools/hygiene/github-settings.expected.json` / detector script / workflow file. Added 2026-04-21 after `AceHack/Zeta` → `Lucent-Financial-Group/Zeta` org-transfer silently flipped `secret_scanning` and `secret_scanning_push_protection` from enabled to disabled. | Automated (`.github/workflows/github-settings-drift.yml`); human resolves on drift | factory (ships to adopters as a template; repo-specific expected snapshot per adopter) | Live `gh api` snapshot vs. checked-in `tools/hygiene/github-settings.expected.json`: repo-level toggles (merge methods, security-and-analysis), rulesets + rule contents, classic branch protection on default branch, Actions permissions + variables + counts of secrets, environments + protection-rule types, Pages config, CodeQL default-setup state, webhook / deploy-key / secret counts. Script at `tools/hygiene/check-github-settings-drift.sh` exits 1 on drift and prints `diff -u` output. Resolution: intentional → re-snapshot + commit new expected with rationale; unintentional → revert in GitHub + rerun detector. | `docs/GITHUB-SETTINGS.md` + `tools/hygiene/github-settings.expected.json` + workflow run log + optional `memory/reference_github_*.md` entry if drift source is non-obvious | `feedback_github_settings_as_code_declarative_checked_in_file.md` + `feedback_blast_radius_pricing_standing_rule_alignment_signal.md` + `project_zeta_org_migration_to_lucent_financial_group.md` |
+| 41 | Orthogonal-axes audit | Every 5-10 rounds (proposed 2026-04-22) — same cadence as skill-tune-up / agent-QOL / symmetry-audit / missing-hygiene-class-gap-finder. | TBD — candidate capability skill `orthogonal-axes-auditor` (queued in BACKLOG P1); Architect (Kenji) runs inline until the skill lands. | factory | Distinct from row 22 (symmetry-opportunities) — symmetry asks "is A paired with its mirror B?"; orthogonality asks "do axes A and B have **zero overlap**?" The factory classifies artefacts along many axes: skill-category (capability / persona / hat), hygiene-scope (project / factory / both), persona-surface (author / reviewer / auditor / cadence-runner), cadence-bucket (session-open / round-open / round-close / weekly / per-event), memory-type (user / feedback / project / reference), review-target (proposed / shipped / retired), trust-tier (autonomous / advisory / binding), etc. For the axis set to form a proper basis (linear-algebra sense), every pair must be independent — an axis's values must carry information no other axis carries. Drift signs: (a) a new skill could be classified identically on two axes (collapsing them), (b) a proposed distinction in docs maps one-to-one to an existing distinction (duplicate naming), (c) a row in one taxonomy duplicates a row in another. Audit sweep = enumerate current factory axes, check pairwise for rank-reduction (could we collapse axis A into axis B without information loss?), flag overlaps to HUMAN-BACKLOG as `axis-overlap` rows. Load-bearing overlap is allowed but must be documented (e.g. hygiene-scope and review-target overlap deliberately because some projects distinguish, some don't). | Audit doc per cycle enumerating axes, overlap matrix, and per-overlap verdict (collapse / keep-and-document / split); HUMAN-BACKLOG rows for P1+ overlaps; BACKLOG row for candidate axis collapses | `feedback_orthogonal_axes_factory_hygiene.md` (to be written) + Aaron 2026-04-22 message *"also we need to make sure all our axises are orthogaonal to the others so therre is not overlap, like fully ... the set of axes is called an orthogonal basis"* + *"i guess this is a cadence thing"* |
 
 ## Ships to project-under-construction