docs(governance): adopt metadatastician-governance project binding

[hyperpolymath]

Summary

• IDApTIK is a member repo of The Metadatastician estate (metadatastician-governance), which expects each member repo to carry baseline community-health files plus a completed local project binding. IDApTIK had neither.
• Confirmed the estate-triage report's two IDApTIK entries (github:metadatastician/IDApTIK and local:meta-repos/IDApTIK) are the same repository seen by two scanners — no divergence to reconcile.
• Confirmed metadatastician-governance/ADOPTION-AND-DEVIATIONS.adoc is estate-wide/abstract with no per-repo table — adoption is recorded locally in the member repo instead, which is what this PR does.

Changes

• Adds AGENTS.md, CONTRIBUTING.adoc (DCO route), SECURITY.md (disclosure route).
• Adds the local project-binding suite from metadatastician-governance/templates/*, filled in for IDApTIK: PROJECT-GOVERNANCE-BINDING.adoc, PROJECT-ASSURANCE-PROFILE.adoc, PROJECT-CONTRIBUTION-PROFILE.adoc, .machine_readable/PROJECT-BINDING.a2ml.
• Updates 0-AI-MANIFEST.a2ml read-first list to include the new docs.

Assurance status is set to draft and review dates are flagged as placeholders (2027-01-20) since no formal review has happened yet — the maintainer should revisit these.

Also fixed, in follow-up commits: a pre-existing uncommitted local change to .github/workflows/codeql.yml (broken YAML indentation that would have failed every CodeQL run, plus an unauthenticated/unpinned/duplicated SonarCloud step) — rebuilt as its own single-instance job, plus a new sonar-project.properties.

governance-upstream-hash ambiguity resolved by maintainer (see PR comments): metadatastician-governance is the estate's governance layer, hyperpolymath/standards covers estate content standards — a separate concern. The field correctly points at metadatastician-governance's own commit (6d87eef...).

SonarCloud org: set to metadatastician — inference, needs maintainer confirmation

sonar-project.properties initially said sonar.organization=hyperpolymath / sonar.projectKey=hyperpolymath_IDApTIK, extrapolated from sibling estate repos. ed476a3 changes it to metadatastician / metadatastician_IDApTIK. This is a best inference, not a verified fact — please confirm the intended org before provisioning.

What is actually verified, against the public SonarCloud API:

• Two distinct SonarCloud organisations exist: metadatastician ("The Metadatastician") and hyperpolymath ("Jonathan D.A. Jewell", personal).
• hyperpolymath has 618 public projects and is the org used by every sonar-project.properties in the estate. metadatastician has 0 public projects.
• Neither hyperpolymath_IDApTIK nor metadatastician_IDApTIK exists. No scan works today either way, so this change breaks nothing — but it also isn't confirmed to be right.

The reasoning for metadatastician is that IDApTIK is a metadatastician-org GitHub repo, and cadastra (also metadatastician-org) carries a metadatastician_cadastra README badge. That badge is the only evidence for this direction, and it points at a project that doesn't exist.

Two readings I cannot distinguish from here:

• A — GitHub org determines SonarCloud org; the metadatastician org is intended and simply not provisioned yet. (What this PR assumes.)
• B — everything consolidates under the hyperpolymath SonarCloud org, and cadastra's badge is the aspirational mistake rather than its properties file.

Discriminating between them needs a SonarCloud token (to see private projects) or your intent. I have neither, so per this repo's own newly-adopted evidence-status honesty principle this is recorded as assumed, not verified. If the answer is B, revert ed476a3 and use hyperpolymath_IDApTIK.

(All API queries were unauthenticated, so private SonarCloud projects would not be visible.)

Test plan

• git status shows only the intended new/changed files
• .machine_readable/PROJECT-BINDING.a2ml parses as valid TOML
• New .adoc files structurally match the metadatastician-governance templates
• .github/workflows/codeql.yml parses as valid YAML after the SonarCloud fix
• governance-upstream-hash intent confirmed by maintainer — metadatastician-governance's commit, not hyperpolymath/standards'
• governance-upstream-hash 6d87eef… verified to be a real commit in metadatastician-governance, and is currently its HEAD ("sweep4: add C-A-G-M files")
• Existence of both SonarCloud orgs checked against the public API
• Maintainer to confirm the intended SonarCloud org (metadatastician vs hyperpolymath) — see above; currently an unverified inference
• Maintainer review of remaining governance-binding field values (decision authority, sensitive areas, review date)
• Maintainer to add the SONAR_TOKEN repository secret and create the project once the org is settled — no metadatastician_* project exists today, so the new job will fail until then

Note: workflow file placement

The SonarCloud scan is added as a job inside .github/workflows/codeql.yml, because that is where the broken pre-existing step lived. The estate convention elsewhere (cadastra, systemet, hermeneia) is a standalone .github/workflows/sonarqube.yml. Since alignment is the point of this PR, you may want it split out — flagging rather than reworking, as it changes nothing functionally.

🤖 Generated with Claude Code

[hyperpolymath]

Pushed a follow-up commit addressing the ultrareview findings on the pre-existing uncommitted `codeql.yml` change (broken YAML indent, unauthenticated/unpinned/duplicated SonarCloud step):

• Rebuilt SonarCloud as its own single-instance job (checkout with `fetch-depth: 0`, pinned to `SonarSource/sonarqube-scan-action@22918119...` / v8.2.1, `SONAR_TOKEN`/`GITHUB_TOKEN` wired via `env`) instead of a broken, unauthenticated step inside the per-language CodeQL matrix.
• Still needed before this job will succeed: a `SONAR_TOKEN` repo secret and a `sonar-project.properties` (or equivalent `with:` inputs) — neither exists yet. Maintainer to add.

Also corrected `governance-upstream-hash` in the project binding: it was pinned to `hyperpolymath/standards`' hash (metadatastician-governance's own upstream) instead of metadatastician-governance's own commit, which is the immediate authority layer a member-repo binding adopts per `AUTHORITY-MAP.adoc`.

Note: the original broken SonarCloud addition only existed as an uncommitted local diff on `main` (never committed) — it's superseded by this branch; safe to discard with `git checkout -- .github/workflows/codeql.yml` on main once this merges.

[hyperpolymath]

Correction to my last comment: the `governance-upstream-hash` change should not be read as a settled fix — I want to flag the ambiguity rather than claim it's resolved.

`AUTHORITY-MAP.adoc` labels the row `Upstream` as `hyperpolymath/standards` (not metadatastician-governance), and both `ADOPTION-AND-DEVIATIONS.adoc` and metadatastician-governance's own `AGENTS.md` use "upstream" the same way — pointing at `2ccc38e...`, the original value. My case for switching to metadatastician-governance's own commit (`6d87eef...`) was an interpretation of the authority-layering (binding adopts the immediate parent layer), not something the repo states outright.

IDApTIK is the first member repo to fill in this template (no existing binding elsewhere in the estate to match conventions against), so whichever value is correct here effectively sets the convention — that should be a maintainer call, not an agent guess baked in silently.

`PROJECT-GOVERNANCE-BINDING.adoc`'s prose now documents both hashes and the relationship between them either way, so nothing is lost regardless of which the maintainer prefers. But please treat `governance-upstream-hash` in `.machine_readable/PROJECT-BINDING.a2ml` (currently `6d87eef...`) as unconfirmed — confirm intent (metadatastician-governance's commit vs. hyperpolymath/standards' commit) before treating this binding as final.

[hyperpolymath]

Estate-wide SonarCloud config sweep (context for the ed476a3 org fix)

While correcting IDApTIK's sonar-project.properties I swept every sonar-project.properties under ~/developer and checked each declared key against the public SonarCloud API. This is informational — nothing outside IDApTIK is changed by this PR. Each fix below needs its own PR in its own repo.

Verified org facts

Org	Status
hyperpolymath	618 public projects — real and in active use
metadatastician	exists, 0 public projects — nothing provisioned yet

Note the asymmetry: hyperpolymath is where all 618 real projects live and what every properties file in the estate declares. metadatastician is empty. So "metadatastician-org GitHub repo ⇒ metadatastician SonarCloud org" is a hypothesis, resting on a single README badge in cadastra that points at a project which does not exist. I cannot confirm it without a token (private projects are invisible to me) or your intent. Treat the row below as "needs a decision", not "needs a fix".

Possible wrong organisation — confirm intended org first

Repo	Declared	If the metadatastician org is intended
metadatastician/cadastra	hyperpolymath / hyperpolymath_rsr-template-repo	metadatastician / metadatastician_cadastra

cadastra's README.adoc badge points at metadatastician_cadastra while its sonar-project.properties carries the template key. One of the two is wrong; which one depends on the org decision above. (Either way the template key is wrong for cadastra.) The badge target does not exist, so the badge currently renders as unknown.

Stale template key hyperpolymath_rsr-template-repo copy-pasted into unrelated repos

All of these scan into one shared project (SonarCloud display name: -REPO-), so their results are commingled:

• hyperpolymath/systemet — its own hyperpolymath_systemet project exists; findings are landing in the wrong project
• hyperpolymath/rsr-julia-library-template-repo — its own project exists; same problem
• hyperpolymath/vocarium — no dedicated project yet
• hyperpolymath/anytype — no dedicated project yet
• hyperpolymath/chronicles-of-slavia — no dedicated project yet
• hyperpolymath/rsr-template-how-to — no dedicated project yet
• hyperpolymath/-REPO- and hyperpolymath/rsr-template-repo both declare this key; the project's display name is -REPO-, so which of the two legitimately owns it is a maintainer call

Malformed key

• hyperpolymath/v3-templater declares sonar.projectKey=v3-templater (no org prefix). That key does not exist; hyperpolymath_v3-templater does. One-line fix.

Correct already (key exists and matches the repo): boj-server, boj-server-cartridges, cicd-squabbler, supernorma, hermeneia, resource-record-fluctuator, academic-workflow-suite.

Caveat: all API queries were unauthenticated, so private SonarCloud projects would not be visible. "Does not exist" here means "not publicly visible".

[hyperpolymath]

Correction to the sweep above — and the actual root cause

Two things in my sweep comment need fixing, both found by checking the CI logs rather than reasoning from the config files.

1. I said misdirected scans are "commingling" results. They are not. I inferred that from the config without checking whether the scans run. They don't:

SONAR_TOKEN:
##[warning]Running this GitHub Action without SONAR_TOKEN is not recommended
ERROR Not authorized or project not found. Please check the 'SONAR_TOKEN' environment
      variable, the 'sonar.projectKey' and 'sonar.organization' properties, ...

The scanner aborts at authentication, before submitting anything. So the wrong keys are a latent problem, not an active one. Nothing is being corrupted today.

2. The real root cause is the missing SONAR_TOKEN secret, which the key drift was masking.

Repo	SONAR_TOKEN set?	Key correct?
hyperpolymath/boj-server	yes	yes
hyperpolymath/cicd-squabbler	yes	yes
hyperpolymath/systemet	no	no
hyperpolymath/rsr-julia-library-template-repo	no	no
hyperpolymath/rsr-template-repo	no	n/a
metadatastician/cadastra	no	no

Only the two repos with working keys have tokens. Every other SonarQube workflow in the estate has been failing on every run. (hyperpolymath is a personal GitHub account, not an org, so there is no org-level secret to inherit — each repo needs its own.)

This makes the ordering matter. Adding SONAR_TOKEN to a repo that still carries the copied key would take it from "failing loudly" to "silently reporting into hyperpolymath_rsr-template-repo" — worse. Fix keys first, then add tokens.

Follow-up PRs opened for the two unambiguous cases:

• fix(sonar): point at this repo's own SonarCloud project hyperpolymath/system-et#20
• hyperpolymath/rsr-julia-library-template-repo#16

Removed from the list: hyperpolymath/v3-templater is archived — workflows are disabled, so its malformed key is moot.

Still needing a decision from you, not a patch: cadastra (blocked on the org question above), and the repos with no SonarCloud project provisioned at all (vocarium, anytype, chronicles-of-slavia, rsr-template-how-to).