D65 — EstatePushing is an active org ruleset with zero rules

[hyperpolymath]

Evidence: F24. Surfaced while measuring the metadatastician ruleset stack for the Marid assessment (D54). Org-wide, outside Marid scope — filed here rather than on marid for that reason.

The org carries four active rulesets:

ruleset	target	scope	rules
Estate Baseline	repository	~ALL	visibility, delete, transfer
EstateBranching	branch	~DEFAULT_BRANCH / ~ALL repos	required_signatures, pull_request, code_scanning, copilot_code_review
EstateTagging	tag	~ALL	required_signatures, workflows, linear history, non-fast-forward, creation, update, deletion
EstatePushing	push	~ALL	none — zero rules

EstatePushing is active with an empty rule array. It enforces nothing while reading as protection in any listing — the same vacuous-gate pattern as the required_status_checks: [] found inside marid/.github/rulesets/Optimus-Branch.json (F25), and the pattern the estate has already ruled against.

⭐ Elegant arm: either give it rules or delete it. An empty active ruleset is strictly worse than no ruleset, because it answers "is this protected?" with a yes.

Acceptance criteria

• EstatePushing either carries rules or no longer exists
• a control that flags any active ruleset whose rules array is empty, org-wide

Filed from the Marid constellation assessment. Full evidence and the Tier 1 rows are in the decision sheet: #787 (comment)

[hyperpolymath]

D65 — EstatePushing blast radius: measured, and the premise moved

Per the owner's ruling on D65 ("Give it real push rules") and its precondition
— "Measure the blast radius before arming — scan what a size cap and an
extension block would reject today, post to standards#887, then apply" — here
is the measurement.

The headline is not the size cap. Two findings displace it, and both are
measured, not inferred.

---

🔴 Finding 1 — EstatePushing is scoped ~ALL and binds to 6 of 68 repositories

Its condition reads repository_name: {include: ["~ALL"]}, which in any listing
reads as the whole org. Measured attachment via
repos/{owner}/{repo}/rulesets?includes_parents=true:

repo visibility	sampled	EstatePushing bound
public	3	0
private	6 (all of them)	6

The org is 62 public / 6 private. So arming EstatePushing today governs
6 repositories, not 68 — and the ~ALL in its condition does not say so.

This is consistent with GitHub restricting push rulesets to private and internal
repositories. ⚠ I have not verified that against current documentation; what
is verified is the attachment measurement above, which is a clean 6/6 vs 0/3
split and not a sampling artefact.

Consequence for the ruling: arming EstatePushing is still worth doing —
it genuinely constrains those 6 repos — but it must not be recorded as
estate-wide protection. A cap that reads ~ALL and reaches 9% of the estate is
the same vacuous-gate shape D65 was opened to cure, one layer up.

---

🔴 Finding 2 — EstateTagging is active with 7 real rules and binds to ZERO repositories

Found while measuring the above. Conditions of all four org rulesets, side by side:

ruleset	target	rules	repository condition
Estate Baseline	repository	3	repository_name: ~ALL
EstateBranching	branch	5	repository_name: ~ALL
EstatePushing	push	0	repository_name: ~ALL
EstateTagging	tag	7	repository_property: {include: [], exclude: []}

EstateTagging selects by repository_property with an empty include set,
where the other three select by repository_name: ~ALL. Measured across 10
repositories (5 public, 5 private): bound on 0 of 10.

Its 7 rules are required_signatures, required_linear_history, creation,
update, deletion, non_fast_forward, workflows.

⚠ This retires a live estate premise. D54's "sequencing trap 3" was
"EstateTagging requires signed tags", and marid's Justfile was changed
git tag -a → git tag -s on that basis (PR #27). The fix is correct on its
own merits and should stay — but tag signing is not currently enforced
anywhere in the org, and any record saying it is should be corrected.

EstatePushing (0 rules, binds to 6) and EstateTagging (7 rules, binds to 0)
are the same defect in mirror image: one has scope without teeth, the other
teeth without scope.

---

The measurement itself

repo⟨TAB⟩size⟨TAB⟩path over every blob at origin/main, deduped by slug and
aggregated by MAX rev-list --count so a stale clone cannot win.

Coverage is complete: 68/68 repos, 17,113 blobs. The two repos that
previously resisted measurement were closed via the git tree API — .github has
35 blobs (max 34,523 B, LICENSES/AGPL-3.0-or-later.txt) and contributes
nothing; proglanging-languages is an empty repo (size=0KB, /commits →
HTTP 409 "Git Repository is empty."). No caveat remains.

A. In scope — the 6 private repos EstatePushing actually reaches

1,489 blobs across 5 non-empty repos (bowtie-workbench 469, common-signal
497, pong-ping 470, dosovoi 44, reflexive-ai-studio 9; proglanging-languages
empty).

dimension	tightest value tested	rejected today
max_file_size	1 MB	0
max_file_path_length	100	0
file_path_restriction (pattern * *)	—	0
file_extension_restriction (44 binary/artefact extensions)	—	0

Largest in-scope blob: 0.10 MB (common-signal :: docs/prototypes/preview.html).
Longest in-scope path: 66 chars
(.machine_readable/self-validating/examples/project-metadata.k9.ncl).
Zero paths contain a space. The in-scope extension profile is entirely text and
source — adoc 431, a2ml 370, sh 118, ncl 81, yml 74, (none) 43,
toml 37, md 36, txt 36, json 32, idr 30 — with no binary or
artefact extension present at all.

Every dimension rejects zero at the tightest threshold tested. Any arm in
this space is free today.

B. Whole estate — the upper bound if coverage ever widened

max_file_size	rejects		max_file_path_length	rejects
100 / 50 / 25 / 10 MB	0		256 / 200	0
5 MB	1		150 / 128	2
1 MB	2		100	7

Blobs over 1 MB, estate-wide — both in public repos, i.e. out of scope today:

8.09 MB  _pathroot            docs/_pathroot for morons.docx
1.36 MB  f19-stealth-glider   assets/f19-hero-banner.png

Longest paths are 153 chars, two stapeln OCI-layout blobs
(verified-container-spec/vectors/runtime-integration/valid-bundle/oci-layout/blobs/sha256/…).
Exactly one path estate-wide contains a space (the _pathroot .docx above).

file_extension_restriction, probed across 44 binary/artefact extensions
(exe dll so dylib jar war class o a lib bin zip tar gz tgz bz2 xz 7z rar iso dmg pkg msi deb rpm docx doc xlsx xls pptx ppt pdf mp4 mov avi mkv mp3 wav psd ai sketch db sqlite sqlite3 pyc pyo node wasm) — four blobs total,
estate-wide, all public:

.docx   1   _pathroot
.pdf    2   chronicles-of-slavia
.wasm   1   progblocks   (progblocks/assets/tree-sitter-a2ml.wasm)

Everything else returns zero.

---

⚠ Correction — an earlier extension probe was wrong by three orders of magnitude

The first run of this probe reported 4,188 .doc files across 63 repos,
which is not a plausible shape for an AsciiDoc-heavy estate. It was a regex
artefact:

awk -F'\t' -v E=".$e" 'tolower($3) ~ (tolower(E)"$"){n++}'   # WRONG

~ is a regex match and . matches any character, so .doc also matched
.adoc. The repair splits the basename on its last literal dot, with no
regex:

awk -F'\t' '{p=$3; n=split(p,a,"/"); b=a[n];
  m=split(b,e,"."); if(m<2){x="(none)"} else {x=tolower(e[m])}
  print x"\t"$1}'

Proven by positive control carried through the fix: .adoc must come back
large and .doc small. After the repair, .adoc = 4188, .doc = 0.
Every contaminated figure collapsed — .a 77→0, .o 5→0, .pkg 51→0,
.db 59→0, .wasm 3→1. Cross-checked the .wasm case by hand: paint-type's
files are .twasm, not .wasm.

Top-20 estate extension histogram after the repair, which reads true:

adoc 4188 · a2ml 3149 · yml 1254 · sh 1000 · md 839 · ncl 643 · rs 552
json 514 · (none) 472 · toml 470 · idr 375 · txt 338 · zig 288 · ex 253
js 204 · affine 193 · res 168 · exs 152 · just 122 · jl 105

---

Push-rule semantics — why "rejects today" is an upper bound, with one exception

A push ruleset evaluates the blobs in the commits being pushed, not existing
history. Large blobs already on main are therefore not retroactively
rejected; they bite only if modified and re-pushed.

The exception matters here: a force-push of rewritten history pushes new
commits containing every file, so every blob is re-presented for evaluation.
This estate does history rewrites — D71 rewrote marid's main to 62 clean
commits and force-pushed it. So the safe framing is: a cap must clear the
largest blob in scope, not merely the largest blob in a typical diff.

In scope that maximum is 0.10 MB, so any cap ≥ 1 MB is safe under every push
shape. Estate-wide it is 8.09 MB, so 10 MB is the value that would remain
safe if coverage ever widened to public repos.

---

Bypass actors — who an armed ruleset would not constrain

EstatePushing carries 9 bypass actors, all at bypass_mode: always:

OrganizationAdmin(null)   RepositoryRole(2)        RepositoryRole(5)
Integration(12526)        Integration(29110)       Integration(262318)
Integration(946600)       Integration(1236702)     Team(18237148)

EstateBranching by contrast uses a mix of always / pull_request /
exempt. ⚠ I am not asserting the all-always shape is a defect —
bypass_mode: pull_request may simply be meaningless for a push target, since
push rules apply to pushes rather than PRs.

What is safe to state: OrganizationAdmin bypasses always, and the owner is
the org admin, so an armed EstatePushing would not constrain the owner's own
pushes. Integration(1236702) is claude, so it would not constrain this
session's pushes either.

Resolved integration ids: 12526 → sonarqubecloud, 29110 → dependabot,
1236702 → claude. 262318 and 946600 are unresolved — they do not
appear in orgs/metadatastician/installations, but that endpoint lists
third-party installations and first-party GitHub apps do not appear there
(29110/dependabot proves exactly that). They are reported as unresolved,
not as stale entries.

---

⚠ Vocabulary — what arming would and would not earn

Per AGENTS.md §6: merging rules into EstatePushing makes it configured.
It is not deployed until a violating push is actually rejected.

That positive control cannot be run from the owner's credential while
OrganizationAdmin is on bypass — the push will simply succeed and prove
nothing. Either the owner comes off the bypass list first, or the control runs
from a non-bypass actor. A green push under bypass must not be recorded as a
passed gate.

---

Recommended arm

Given that every in-scope dimension rejects zero at the tightest threshold
tested, the constraint is free today and should be set where it stays safe if
coverage ever widens:

• max_file_size: 10 MB — rejects 0 in scope, 0 estate-wide, and 0 even
  under a full history rewrite (largest blob anywhere is 8.09 MB).
• max_file_path_length: 200 — rejects 0 in scope (longest 66) and 0
  estate-wide (longest 153).
• file_extension_restriction: the zero-count binary/artefact set only —
  rejects 0 in scope and 0 estate-wide, and does not grandfather anything.
• file_path_restriction on spaces: rejects 0 in scope, 1 estate-wide.

The two open decisions that are the owner's and not mine — the extension set,
and whether OrganizationAdmin comes off the bypass list so the gate can
actually be proven — go to the owner separately.

---

Suggested follow-ups, as issues with acceptance criteria

1. EstateTagging binds to nothing — change its condition from
   repository_property: {include: []} to repository_name: {include: ["~ALL"]}.
   Acceptance: repos/{O}/{R}/rulesets?includes_parents=true lists
   EstateTagging on a sampled public repo and a sampled private repo, with a
   positive control asserting the probe can see a bound tag ruleset at all.
2. EstatePushing scope is misleading — whatever is armed, record in the
   ruleset description that push rules reach private/internal repositories only,
   so ~ALL is never read as estate-wide again.
3. Correct the D54 record — tag signing is not enforced; marid's
   git tag -s change stands on its merits, not on EstateTagging.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WPSJ7fBhVAMcpSffCBWUDo

[hyperpolymath]

D65 — armed, verified by attachment, and three corrections to the measurement above

Following the owner's rulings (10 MB / 200 chars, zero-count binaries only, drop OrganizationAdmin, and fix the EstateTagging condition now), both org rulesets have been written and verified by attachment, not by rc=0.

What is actually armed

EstatePushing — max_file_size: 10 (MB), max_file_path_length: 200, file_extension_restriction with 45 *.ext entries. OrganizationAdmin removed from bypass (9 → 8 actors).

EstateTagging — its condition was repaired. It was selecting by repository_property with an empty include set, so despite being active with 7 real rules it bound to zero repos. It now uses repository_name: ~ALL.

⭐ Correction 1 — reach is set by the ruleset's TARGET TYPE, not by its condition string

Finding 1 above generalised from a push ruleset to rulesets in general. That was wrong. The identical condition repository_name.include = ["~ALL"] gives two different reaches. Measured after both writes via gh api repos/{O}/{R}/rulesets?includes_parents=true, filtered to source_type=="Organization":

visibility	sampled	org rulesets bound
public	5	Estate Baseline, EstateBranching, EstateTagging — 3
private	6 (all)	+ EstatePushing — 4

• a push ruleset at ~ALL → 6 of 68 (private/internal only)
• a tag ruleset at ~ALL → 68 of 68
• a branch ruleset at ~ALL → 68 of 68

Acceptance held on both visibilities, with EstateBranching on a public repo as a live positive control in the same run. So Finding 2's "binds to 0" was accurate when posted and is now superseded by the fix.

⭐ Correction 2 — the org holds 4 tags, not 0

The premise I put to the owner was "zero tags org-wide". That came from a 3-repo sample (marid, stapeln, MaridIR.jl). A full 68/68 census (0 errors) returns 4 tags in 4 repos: common-signal (private), burble, gossamer, phi-LAM.

The effect is benign — a ruleset does not re-evaluate refs that already exist, and org admins retain bypass — so this does not reopen the decision. But the claim was wrong and should not be repeated.

⭐ Correction 3 — I armed EstateTagging before measuring its blast radius

The D65 ruling's precondition was "measure the blast radius before arming". That doctrine applies to both rulesets; I applied the EstateTagging condition fix on a 3-repo tag sample without it. Owning the sequencing error regardless of the outcome, which is benign. The retroactive measurement:

The EstateTagging blast radius, measured

Scanned at origin/main (not the working tree — 33 of 34 clones sit on peer/WIP branches) across 67 of 68 org repos; proglanging-languages has no local clone and is the one unscannable repo. Pattern covered git tag (including lightweight and -f), git push --tags / refs/tags, gh release create|delete, actions/create-release, release-please, semantic-release, createRef, git/refs/tags. Positive control: 586 workflow files match runs-on at origin/main, so a zero would have meant a broken probe.

17 repos carry a release workflow; 18 workflows total. Every hit in all 17 is softprops/action-gh-release — zero git tag, zero git push --tags, zero gh release create, zero createRef anywhere in the estate.

17 of 18 are pure on: push: tags: consumers with no tag_name: — the tag already exists when the workflow runs, so a creation rule never fires for them. Reporting the raw intersection would have overstated the blast radius ~17×.

The one workflow passing an explicit tag_name is gossamer/.github/workflows/ci-cd.yml:322, gated on workflow_dispatch && inputs.prepare_release && github.ref == 'refs/heads/main', with draft: true, prerelease: true. Its "Create release tag" step runs no git tag and no git push — it only writes version= to $GITHUB_OUTPUT. ⚠ Whether a draft: true release creates the tag ref at draft time is not documented on GitHub's REST-releases or about-releases pages (both checked), so I am not asserting either way. If it does not, publishing the draft certainly does — under the publisher's identity, which succeeds for an admin and is rejected for anyone else.

The real behavioural change, stated plainly

This is not "zero blast radius". Across all 68 repos, any non-admin can no longer create, move or delete a tag, and tag signatures are now required. That is presumably the intended immutable-tags doctrine, but it is a real change.

Forward constraint: EstateTagging's creation rule has no Integration bypass — only OrganizationAdmin, RepositoryRole(5) and Team(18237148). Integration(15368) (github-actions) is on neither ruleset's bypass list (measured, both return 0). So no CI job anywhere in the org can create a tag ref. Any future release path that tags from CI needs that bypass added first — relevant to D59 if marid's release ever tags from CI.

⚠ This also means D54's "sequencing trap 3" is back in force. For the interval in which EstateTagging bound to nothing, tag signing was enforced nowhere; that is no longer true. marid's git tag -a → git tag -s (PR #27) is now load-bearing, not merely correct on its merits.

⚠ Vocabulary — EstatePushing is configured, NOT deployed

Per AGENTS.md §6. No violating push has been rejected, and dropping OrganizationAdmin did not make the control runnable. RepositoryRole(5) — the admin role — remains on bypass, and repos/metadatastician/dosovoi/collaborators/hyperpolymath/permission returns admin. So a push from the owner's credential still bypasses and proves nothing.

The genuinely runnable control is a CI push of an oversize blob to a scratch branch in a private repo, since Integration(15368) is on neither bypass list. Noting it as the route; not running it unprompted.

In-scope blast radius is unchanged from the measurement above: the 6 private repos hold 1,489 blobs, largest 0.10 MB, longest path 66 chars — zero rejections at every threshold.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WPSJ7fBhVAMcpSffCBWUDo