chore: file three managed-repository reports and fix the main review wording

.abcd/work/decisions/dcn-2610180914543900-the-go-public-report-from-a-managed.md

@@ -0,0 +1,6 @@
+---
+id: dcn-2610180914543900
+slug: the-go-public-report-from-a-managed
+date: 2026-10-18
+---
+2026-10-18 — The go-public report from a managed repository (iss-2610180913363115) is filed at minor, not at the sender's major: it asks for a capability abcd lacks, a staged go-public flow, and reports no defect in what abcd does. Major and critical records are what the release cut holds on, and that guard exists for confirmed defects, so a feature request at major would hold every cut until a multi-day feature ships. Decided by the technical facilitator on the product thinker's delegation, while the product thinker is away.

.abcd/work/issues/open/iss-2610180913363115-abcd-should-automate-taking-a-managed.md

@@ -0,0 +1,69 @@
+---
+schema_version: 1
+id: "iss-2610180913363115"
+slug: "abcd-should-automate-taking-a-managed"
+severity: "minor"
+category: "process"
+source: "managed-repo"
+found_during: "abcd inbox report rpt-2610121549070006 from a managed repository (root commit c372ff6b8fc387ffdf1acf7c51bffe469b70b2e0)"
+origin: researcher-authored
+production_mode: hand-written
+found_at: "proposed: abcd launch public (or abcd ahoy public), building on abcd banlist, abcd lint, abcd launch --dry-run"
+remedy: "A staged, resumable go-public flow: prepare a fresh-history public repository from a private sandbox, run the gates, stop for the person to switch visibility, then apply and verify the public-only settings."
+---
+
+abcd should automate taking a managed repository public: prepare, gate, hand over the visibility switch, then apply settings
+
+## What happened
+
+On 2026-10-12 a private abcd-managed sandbox was turned into a public product repository (intentdriven/PG-Engine). It took one long session of manual steps, several of them easy to get wrong, and the person stepped in four times: a scope refresh, two banlist decisions, and a force-push. abcd has the pieces (banlist layers, lint, ahoy, launch --dry-run), but nothing chains them.
+
+The steps, in order:
+
+1. **Fresh history.** Create the target repository private, then copy the sandbox's working tree, uncommitted record edits included, and the machine-local tier (the private banlist) as one new root commit. The sandbox stays as it is.
+2. **Rename.** The product name changed, so the project name was replaced everywhere: config `project_name`, brief, ADRs, intents, notes and README.
+3. **Banlist move.** Moving every third-party pattern from the public layer to the private one meant:
+   - converting PCRE to the guard's ERE dialect by hand;
+   - verifying each converted pattern against a corpus (91 keys, 12,753 line hits, 0 mismatches);
+   - parking the case-sensitive entries the private layer cannot express (rpt-2610121532502681);
+   - finding that abcd's own scaffolded hook text ("a link can point") trips a case-insensitive entry.
+4. **Truth edits.** The brief's naming rule was rewritten to the new state, in present tense.
+5. **Pre-public files.**
+   - The licence holder was corrected (it read "abcd").
+   - `repo.visibility` was set to public.
+   - A CI workflow was added: pinned gitleaks and zizmor, copied from a sibling repository.
+   - A CODEOWNERS file was added over the publish surface.
+6. **Gates.** `abcd lint`; gitleaks over the tree and the history; the original patterns run over every file and path; a check that the private repository's name appears nowhere.
+7. **Commit hygiene.** The first commit's message named the private sandbox, against the PII rule. Fixing it meant amending the root commit and a person-run force-push, because the guard rightly refuses force-pushes from agents. It also meant deleting the first CI run, which would have exposed the old commit's hash and message once public. The orphaned commit stays reachable by hash until GitHub collects it.
+8. **ahoy** was run in the new checkout (setup version, gitignore fence, development README).
+9. **Visibility switch**, done by the person.
+10. **Post-public settings**, which the Free plan blocks on private repositories:
+    - secret scanning, push protection and Dependabot;
+    - rulesets copied from intentdriven/abcd, with the required checks re-pointed at the jobs this repository actually has;
+    - release-tag protection;
+    - a check of the effective branch rules and of CODEOWNERS.
+
+## Proposal
+
+A staged, resumable flow. Each stage prints what it will do, applies nothing without a yes, and records its progress in the local tier, so the flow survives the pause while the person switches visibility.
+
+- **prepare:** a fresh-history copy from a source checkout; an optional rename across the record; the banlist migration, converting dialects and proving equivalence per key, and parking or refusing what the private layer cannot express; the minimal CI and CODEOWNERS; the licence holder; the declared visibility.
+- **gate:** lint, a secret scan of the tree and the history, the source's original banlist over the new tree, the private source's name absent from files and commit messages, and the Assisted-by trailer present.
+- **handover:** stops and asks the person to switch visibility (never done by abcd), naming what will be visible: Actions runs, commit hashes, issues.
+- **settle:** applies and verifies the public-only settings (the audit and apply step proposed in rpt-2610121533020069), deletes CI runs that reference rewritten commits, and reports anything left over, such as an orphaned commit only GitHub Support can purge.
+
+## Acceptance
+
+- Run against a private sandbox, the flow produces a public repository whose history, CI runs and files never name the sandbox or any banned term, and the person acts only at the handover and on each yes.
+- A second run against the same target finds nothing to do.
+
+Remedy the reporter proposes: A staged, resumable go-public flow: prepare a fresh-history public repository from a private sandbox, run the gates, stop for the person to switch visibility, then apply and verify the public-only settings.
+
+Reported by a managed repository (root commit c372ff6b8fc387ffdf1acf7c51bffe469b70b2e0) through the abcd inbox as rpt-2610121549070006, a enhancement against abcd v0.13.4, surface proposed: abcd launch public (or abcd ahoy public), building on abcd banlist, abcd lint, abcd launch --dry-run.
+
+Evidence:
+
+- rpt-2610121549070006 (the report, kept in the inbox)
+- https://github.com/intentdriven/PG-Engine
+- rpt-2610121533020069
+- rpt-2610121532502681

.abcd/work/issues/open/iss-2610180913376757-a-abcd-design-verb-design-rounds-a.md

@@ -0,0 +1,39 @@
+---
+schema_version: 1
+id: "iss-2610180913376757"
+slug: "a-abcd-design-verb-design-rounds-a"
+severity: "minor"
+category: "future-work-seed"
+source: "managed-repo"
+found_during: "abcd inbox report rpt-2610111258569639 from a managed repository (root commit dd203ff780118159c16a4fbf48899c880e71a88e)"
+origin: researcher-authored
+production_mode: hand-written
+found_at: "new verb (design); neighbours abcd lab, abcd ideate"
+remedy: "Earn it in stages: finish the open design lab, run a second lab on a non-UI kind such as wording variants that also tests the cull-first protocol, then propose a design verb with assessment as its judging step, and decide by ADR whether the assessment page is served locally."
+---
+
+A /abcd:design verb: design rounds, a person-only assessment, and a committed design history
+
+A managed repository (Dessau) needed a visual reference for a planned intent. Agents generated ten HTML mockups in two rounds; the maintainer rejected round 1 as a whole, then judged all ten in one sitting in an HTML assessment page built in a lab, and chose a base design with amendments and borrowings. The record went into the repository as a design history (PR 206 above). The maintainer asked whether abcd should carry this as a verb.
+
+Proposed shape (maintainer's preference: one user-facing /abcd:design, not a separate assess verb, and not under ideate, which judges whether to do something rather than what form it takes):
+
+- People: /abcd:design lists runs and what each waits for; /abcd:design "<question>" starts a run linked to an intent, with criteria from abcd defaults then repo config then the run; /abcd:design assess <run> opens the judging page; /abcd:design decide files the result as a design-history entry, a dated decision line, a reference on the intent, and offers lessons for a taste file.
+- Agents only: design brief <run> renders the generation brief including the taste file and lessons from rejected rounds; design variant add records each variant's round, parent, model and brief. The generating agent never judges; any self-review is labelled weak evidence and never counted.
+
+What the lab found (protocol A: criteria first, blind overview tags, 25 pairs plus 5 side-swapped repeats, a 1-7 rubric with a reason on the top three, a Bradley-Terry ranking with bootstrap ranges): 9.5 minutes; 5 of 5 repeats agreed; no loops; top design chosen without override; all round-2 designs ranked above all round-1 designs. But pairs were judged at a glance (median 2.1 s at half-size side by side), followed looks, and did not separate the top four; the criteria step surfaced findability and phone width. The real decision was a composite (base plus amendments plus borrowings), which a single-winner result cannot hold, and the judge pointed at parts with screenshots after the session rather than pins during it.
+
+Judge's own tool debrief: sortable result columns (e.g. by mean score); a way back to each design from the result; remove the finalist swap; serve the assessment locally so the result is saved without an export. Serving locally opens a listening port, so it needs a decision record (bind address, who may write the result) before it ships.
+
+SOTA grounding gathered in the lab: Tohidi et al. CHI 2006 (designs judged alone are rated higher); Kinnear et al. 2025 (about 10 comparisons per item for comparative judgement reliability); Vitello and Bramley 2017 (adaptive reliability is inflated); LMSYS (Bradley-Terry over Elo); UK DfE design histories (keep what did not work); QOC and MADR for the record shape; Anthropic's harness article on generator self-grading.
+
+Remedy the reporter proposes: Earn it in stages: finish lab-261011111706-9fed999, run a second lab on a non-UI kind (e.g. wording variants) that also tests the cull-first protocol, then propose /abcd:design with assessment as its judging step, and decide by ADR whether the assessment page is served locally.
+
+Reported by a managed repository (root commit dd203ff780118159c16a4fbf48899c880e71a88e) through the abcd inbox as rpt-2610111258569639, a enhancement against abcd v0.13.3, surface new verb (design); neighbours abcd lab, abcd ideate.
+
+Evidence:
+
+- rpt-2610111258569639 (the report, kept in the inbox)
+- lab-261011111706-9fed999
+- https://github.com/intentdriven/Dessau/pull/206
+- https://github.com/intentdriven/Dessau/pull/205

.abcd/work/issues/resolved/iss-2610180913341869-follow-up-to-rpt-2610121533020069-the.md

@@ -0,0 +1,57 @@
+---
+schema_version: 1
+id: "iss-2610180913341869"
+slug: "follow-up-to-rpt-2610121533020069-the"
+severity: "minor"
+category: "security"
+source: "managed-repo"
+found_during: "abcd inbox report rpt-2610121624558512 from a managed repository (root commit b7297501ef3f6f39707c6c9d08ead29240ed1f0b)"
+origin: researcher-authored
+production_mode: hand-written
+found_at: "GitHub ruleset baseline copied from intentdriven/abcd (main review: pull_request rule)"
+remedy: "Say in .github/CODEOWNERS and .abcd/work/rulesets/README.md that the owner's pull requests pass this rule by the admin bypass while it binds every other writer, since GitHub's ruleset documentation requires a code owner's approval on owned paths whatever the approval count, and confirm that once with a pull request from a maintain-role account."
+resolution: "The CODEOWNERS header and the rulesets README now say what the main review rule does: GitHub's ruleset documentation requires a code owner's approval on a pull request that modifies owned content, whatever the approval count, so the rule binds every writer but a repository admin, and the owner's own pull requests pass it by the admin bypass the README already named. The report's open question, whether the rule holds anyone at all, is answered by that documentation, not by the owner's test, which only exercised the bypass."
+impact: internal
+---
+
+Follow-up to rpt-2610121533020069: the copied main review ruleset does not stop the owner's own PRs, and may not stop anyone's
+
+## Addendum to rpt-2610121533020069
+
+That report proposes a GitHub settings baseline taken from intentdriven/abcd. One of its rulesets, "main review", does less than its name suggests.
+
+## What was tested
+
+intentdriven/a managed repository has the "main review" ruleset copied from intentdriven/abcd: a pull_request rule with require_code_owner_review true and required_approving_review_count 0. Its CODEOWNERS file assigns `.github/`, `.githooks/`, the `.abcd/` config, AGENTS.md and LICENSE to the repository owner.
+
+Test PR #1 was opened as the owner and changed `.github/CODEOWNERS`, a path the owner owns. Once the two required checks (gitleaks, zizmor) passed, GitHub reported:
+
+- mergeStateStatus CLEAN, mergeable MERGEABLE;
+- reviewDecision null, and no review requested.
+
+The PR could have entered the merge queue with no approval at all. It was closed unmerged.
+
+## What it means
+
+- **For the owner's own PRs, the code-owner rule does nothing.** That includes every PR an agent or autonomous run opens under the owner's identity. Practically this is convenient: autonomous runs are not stuck waiting for a self-approval GitHub would refuse anyway. But the rule's name and the CODEOWNERS comment in intentdriven/abcd ("requires a code-owner review on any pull request touching them") promise a gate that, for the owner, does not exist.
+- **Untested: other authors.** With required_approving_review_count 0, GitHub may not require a code-owner approval from anyone, which would make the rule a no-op for every contributor. Confirming this needs a PR from a second account (another org member).
+- **intentdriven/abcd** carries the same setting, plus require_extra_approval_for_unattributed_changes. Whether that parameter changes the outcome there is also untested.
+
+## Expected
+
+The baseline either enforces what it claims (code-owner approval on the publish surface, from someone other than the author where that matters) or says plainly that it is advisory for the owner. The audit proposed in rpt-2610121533020069 should check what a rule actually does, not only that it is present.
+
+Remedy the reporter proposes: Decide what code-owner review is meant to guard, then set required_approving_review_count to at least 1 or drop the rule; make the baseline in rpt-2610121533020069 test the rule's effect, not only its presence.
+
+Reported by a managed repository (root commit b7297501ef3f6f39707c6c9d08ead29240ed1f0b) through the abcd inbox as rpt-2610121624558512, a defect against abcd v0.13.4, surface GitHub ruleset baseline copied from intentdriven/abcd (main review: pull_request rule).
+
+Evidence:
+
+- rpt-2610121624558512 (the report, kept in the inbox)
+- rpt-2610121533020069
+- https://github.com/a managed repository/pull/1
+- https://github.com/intentdriven/abcd
+
+## Grounds
+
+- pursued: a pull request from a maintain-role account that changes an owned path stays blocked until a code owner approves; a CLEAN merge state on such a pull request with no approval would show it wrong.

.abcd/work/rulesets/README.md

@@ -11,10 +11,14 @@ in the tree rather than only a web console.
   status checks (strict), and the merge queue. **No bypass actors**: nobody
   merges past a red required check.
 - `main-review.json` — the pull-request rule requiring a code-owner review on
-  changes to the publish surface (`.github/CODEOWNERS`). Repository admins may
-  bypass, which is why it is a separate ruleset: a bypass covers every rule in
-  its ruleset, so the review requirement and the required checks must never
-  share one.
+  changes to the publish surface (`.github/CODEOWNERS`). Its approval count is
+  0, and the code-owner approval is required all the same: GitHub requires a
+  code owner's approval on a pull request that modifies owned content whatever
+  the count. Repository admins may bypass, so the rule binds every other
+  writer and does not hold the owner's own pull requests, an agent's under the
+  owner's identity included. That is why it is a separate ruleset: a bypass
+  covers every rule in its ruleset, so the review requirement and the required
+  checks must never share one.
 - `reservations-protection.json` — deletion and force-push protection for
   `refs/heads/abcd-reserved/**`, the branches `abcd reserve` pushes
   (itd-2609091034175565). **No bypass actors.** It is its own ruleset because it

.github/CODEOWNERS

@@ -1,8 +1,11 @@
 # The publish surface: paths whose changes ship behaviour to installed users
 # (plugin hooks and commands, agent prompts, workflows, gates and their config)
 # or alter what the release and site builds produce. The "main review" ruleset
-# requires a code-owner review on any pull request touching them; the two
-# rulesets are mirrored into .abcd/work/rulesets/ (itd-92 owns the drift check).
+# requires a code owner's approval on any pull request touching them, whatever
+# its approval count, from every writer but a repository admin: admins pass it
+# by the ruleset's bypass, so the owner's own pull requests are not held by it.
+# The rulesets are mirrored into .abcd/work/rulesets/ (itd-92 owns the drift
+# check).
 /hooks/ @REPPL
 /commands/ @REPPL
 /agents/ @REPPL