-
-[optional body]
-
-[optional footer]
diff --git a/GOVERNANCE.adoc b/GOVERNANCE.adoc
new file mode 100644
index 0000000..9b836fb
--- /dev/null
+++ b/GOVERNANCE.adoc
@@ -0,0 +1,60 @@
+== Governance
+
+=== Overview
+
+This project is governed by the following principles and structures to
+ensure transparent, inclusive, and effective decision-making.
+
+=== Roles and Responsibilities
+
+==== Maintainers
+
+Maintainers are responsible for: - Reviewing and merging pull requests -
+Managing releases and versioning - Ensuring code quality and standards -
+Triaging issues and bug reports - Community engagement and support
+
+==== Contributors
+
+Contributors are expected to: - Follow the code of conduct - Submit
+well-documented pull requests - Write tests for new functionality -
+Maintain existing tests - Update documentation as needed
+
+=== Decision Making
+
+==== Minor Changes
+
+* Can be made by any maintainer
+* Include bug fixes, documentation updates, dependency updates
+
+==== Major Changes
+
+* Require discussion in issues or pull requests
+* Include new features, architectural changes, API changes
+* Need approval from at least 2 maintainers
+
+==== Breaking Changes
+
+* Require RFC (Request for Comments) process
+* Need approval from majority of maintainers
+* Must include migration guide
+
+=== Code of Conduct
+
+All participants are expected to follow our Code of Conduct. Violations
+can be reported to the maintainers.
+
+=== Communication
+
+* *Issues*: For bug reports and feature requests
+* *Discussions*: For questions and general discussion
+* *Pull Requests*: For code contributions
+
+=== Licensing
+
+All contributions are made under the terms of the repository’s LICENSE
+file. By submitting a pull request, you agree to license your
+contributions accordingly.
+
+'''''
+
+_Last updated: 2026-07-18_
diff --git a/GOVERNANCE.md b/GOVERNANCE.md
deleted file mode 100644
index e27364c..0000000
--- a/GOVERNANCE.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# Governance
-
-## Overview
-
-This project is governed by the following principles and structures to ensure transparent, inclusive, and effective decision-making.
-
-## Roles and Responsibilities
-
-### Maintainers
-
-Maintainers are responsible for:
-- Reviewing and merging pull requests
-- Managing releases and versioning
-- Ensuring code quality and standards
-- Triaging issues and bug reports
-- Community engagement and support
-
-### Contributors
-
-Contributors are expected to:
-- Follow the code of conduct
-- Submit well-documented pull requests
-- Write tests for new functionality
-- Maintain existing tests
-- Update documentation as needed
-
-## Decision Making
-
-### Minor Changes
-- Can be made by any maintainer
-- Include bug fixes, documentation updates, dependency updates
-
-### Major Changes
-- Require discussion in issues or pull requests
-- Include new features, architectural changes, API changes
-- Need approval from at least 2 maintainers
-
-### Breaking Changes
-- Require RFC (Request for Comments) process
-- Need approval from majority of maintainers
-- Must include migration guide
-
-## Code of Conduct
-
-All participants are expected to follow our Code of Conduct. Violations can be reported to the maintainers.
-
-## Communication
-
-- **Issues**: For bug reports and feature requests
-- **Discussions**: For questions and general discussion
-- **Pull Requests**: For code contributions
-
-## Licensing
-
-All contributions are made under the terms of the repository's LICENSE file.
-By submitting a pull request, you agree to license your contributions accordingly.
-
----
-
-*Last updated: 2026-07-18*
diff --git a/README.adoc b/README.adoc
new file mode 100644
index 0000000..3b8aeb1
--- /dev/null
+++ b/README.adoc
@@ -0,0 +1,174 @@
+A turn from writing code to writing the rules, checks, and values that
+code must answer to — and making all three legible enough to be
+contested.
+
+== The vision
+
+For most of three decades I have worked across cognitive science,
+philosophy, and systems engineering, mostly in private. This manifesto
+marks the move into public: the deployment of the RSR 2026 (Rhodium
+Standard Repository) and the body of work that surrounds it.
+
+The thesis is simple to state and hard to live up to. Most of what
+governs software is left implicit — intent lives in prose, soundness
+lives in trust, value lives in authority. *The metaprogramming turn is
+the decision to make those governing things explicit, first-class, and
+inspectable*: to write not only the program, but the rules it must obey,
+the checks that establish it, and the values it encodes, in a form that
+both a machine and a critic can read and argue with.
+
+I can begin this. I cannot finish it alone — and a manifesto about
+making value contestable would contradict itself if it stayed a
+monologue. So from here it is _we_.
+
+We value, in the precise sense that this whole project is _about_ value:
+
+* explicit, contestable structure over implicit good faith;
+* checked certainty over fluent plausibility;
+* rigour applied wherever a problem demands it over rigour rationed to
+the problems we have agreed to call "`technical`".
+
+== The assurance turn
+
+Making rules explicit is not enough. A legible rule can still conceal
+who authorised it, erase the particular person or circumstance it
+classifies, or turn a passing check into an inflated claim. The
+assurance turn follows from the manifesto’s commitments: governing
+statements must be connected to evidence, their boundaries and
+assumptions must be visible, and the people affected by them must be
+able to contest both representation and result.
+
+Assurance here is therefore not a badge or a promise of absolute safety.
+It is a disciplined relationship among a claim, the evidence offered for
+it, the model in which that evidence has force, the residual
+uncertainty, and an authority accountable for the decision. Draft,
+designed, assumed, tested, audited, and proven work are different
+states. Fluency does not collapse them.
+
+Particularity matters because abstraction always leaves something
+behind. A type, policy category, or machine-readable record is useful
+only when its lowering remains faithful to what is materially at stake.
+Contestability is the corresponding political commitment: an affected
+person must be able to discover the rule and evidence, challenge a
+classification or automated decision, and reach a responsible human
+authority.
+
+This chapter explains the philosophical direction, not its operational
+rules. The proposed
+https://github.com/hyperpolymath/standards/tree/constitution/estate-foundation/constitution[estate
+constitution] defines authority, precedence, exceptions, assurance
+duties, and change procedure. Until adopted through review, it remains a
+proposal.
+
+== Core pillars
+
+Each pillar is a position, not a slogan. Each is meant to be disagreed
+with.
+
+=== 1. Machine-readable governance
+
+The rules an estate lives by — licensing, provenance, conventions, who
+may change what — should be encoded as machine-readable artifacts, not
+narrated in prose that quietly drifts from the code it describes. A
+human-centric README cannot be checked; governance-as-data can. The
+`+6SCM+` pattern is how this estate encodes those rules so that tooling,
+and AI agents, can verify conformance and flag drift rather than take a
+paragraph’s word for it.
+
+_What this rejects:_ the prose README as the source of truth about how a
+system is meant to behave.
+
+=== 2. Neurosymbolic verification
+
+Probabilistic generation may propose; only symbolic method may dispose.
+Where correctness matters, an unproven output from a language model is a
+hypothesis, not a result, and treating fluency as evidence is a category
+error. The discipline is to pair generation with mechanised checking so
+that the part which can be certain has the last word.
+
+_What this rejects:_ plausibility mistaken for proof. (`+hypatia+` is
+the clearest concrete instance.)
+
+=== 3. Post-disciplinary praxis
+
+The rigour we reserve for compilers belongs equally to consent, to
+policy, to accountability. The line between a "`technical`" problem that
+deserves formal treatment and a "`social`" one left to good faith is
+itself a choice — and often an alibi. Post-disciplinary means reaching
+for whatever discipline the problem needs; _praxis_ means refusing to
+separate the theory from the practice that tests it. The same instinct
+runs from labour-union policy to RISC-V SSGs.
+
+_What this rejects:_ the division of labour that keeps rigour out of the
+rooms where power actually operates. (`+avow-protocol+`,
+consent-as-code, is the most developed example.)
+
+== The wager: value made legible
+
+Underneath all three pillars is one bet. Deciding what a system _should_
+do, whether an output _counts_ as correct, who _consented_, and what
+_matters_ are all judgments of value — and they are usually smuggled in
+implicitly and backed by authority: _trust me_, _the spec says so_, _the
+model said so_. Axiology is the study of value; the metaprogramming turn
+applies it operationally. Value is not asserted, it is _structured_ —
+and structure can be inspected, checked, and argued with.
+
+This is also why the work is, at root, political as well as technical. A
+value that is explicit and inspectable can be contested by the people it
+bears on; a value backed only by authority cannot. Making value legible
+is therefore a precondition for accountability — in a compiler, in an AI
+system, and in a union. It is the point at which formal methods and
+solidarity economics turn out to want the same thing: that the rules be
+legible, and the powerful be answerable to them.
+
+It is the same instinct that runs through the technical research —
+identity defined by equivalence rather than asserted, a value justified
+by the construction that produced it rather than taken on faith. The
+manifesto only generalises that instinct, from values inside a program
+to values inside our systems and institutions.
+
+== Reading order
+
+* `+EXPLAINME.adoc+` — the canonical "`what is this`" entry-point,
+consumed by AI agents and by the `+hyperpolymath/standards+` governance
+tooling.
+* `+docs/+` — supporting essays, position papers, and ADRs that situate
+the manifesto in context.
+* `+MAINTAINERS.adoc+` — current stewards.
+
+== Status
+
+* *Licence:* MPL-2.0 (migrated from PMPL-1.0-or-later on 2026-05-26 per
+the estate licence-debt audit,
+https://github.com/hyperpolymath/standards/pull/196[hyperpolymath/standards#196]).
+* *Maturity:* a work in progress; the manifesto is a living document.
+The version number on the title line is incremented on each substantive
+revision.
+* *Audit findings:* see `+docs/tech-debt-2026-05-26.md+` if present
+(added by the 2026-05-26 estate tech-debt scan).
+
+== Engaging with this manifesto
+
+Collaboration here is not decoration; by the argument above it is
+constitutive. A manifesto that makes value contestable earns its keep
+only by being contested, adopted, and extended. Three ways in:
+
+* *Disagree* — open an Issue. Manifestos thrive on being argued with,
+and a pillar that no one challenges has not yet been tested.
+* *Adopt a thread* — fork, riff, cite. The MPL-2.0 licence makes
+derivative manifestos easy.
+* *Contribute editorially* — see CONTRIBUTING for the (intentionally
+light) editorial conventions.
+
+Whether you are a researcher, a maintainer, a journalist, or a student,
+the door is open — and the NUJ and solidarity-economics threads here
+mean I take "`we`" literally.
+
+== Companion repositories
+
+* `+hyperpolymath/standards+` — the RSR 2026 standards that the first
+pillar references.
+* `+hyperpolymath/hypatia+` — the neurosymbolic analyser that is the
+second pillar’s clearest concrete instantiation.
+* `+hyperpolymath/avow-protocol+` — the consent-as-code stack that is
+the third pillar’s most-developed example.
diff --git a/README.md b/README.md
deleted file mode 100644
index 66f015c..0000000
--- a/README.md
+++ /dev/null
@@ -1,189 +0,0 @@
-
-
-
-
-A turn from writing code to writing the rules, checks, and values that
-code must answer to — and making all three legible enough to be
-contested.
-
-
-
-# The vision
-
-For most of three decades I have worked across cognitive science,
-philosophy, and systems engineering, mostly in private. This manifesto
-marks the move into public: the deployment of the RSR 2026 (Rhodium
-Standard Repository) and the body of work that surrounds it.
-
-The thesis is simple to state and hard to live up to. Most of what
-governs software is left implicit — intent lives in prose, soundness
-lives in trust, value lives in authority. **The metaprogramming turn is
-the decision to make those governing things explicit, first-class, and
-inspectable**: to write not only the program, but the rules it must
-obey, the checks that establish it, and the values it encodes, in a form
-that both a machine and a critic can read and argue with.
-
-I can begin this. I cannot finish it alone — and a manifesto about
-making value contestable would contradict itself if it stayed a
-monologue. So from here it is *we*.
-
-We value, in the precise sense that this whole project is *about* value:
-
-- explicit, contestable structure over implicit good faith;
-
-- checked certainty over fluent plausibility;
-
-- rigour applied wherever a problem demands it over rigour rationed to
- the problems we have agreed to call "technical".
-
-# The assurance turn
-
-Making rules explicit is not enough. A legible rule can still conceal who
-authorised it, erase the particular person or circumstance it classifies, or
-turn a passing check into an inflated claim. The assurance turn follows from
-the manifesto's commitments: governing statements must be connected to
-evidence, their boundaries and assumptions must be visible, and the people
-affected by them must be able to contest both representation and result.
-
-Assurance here is therefore not a badge or a promise of absolute safety. It is
-a disciplined relationship among a claim, the evidence offered for it, the
-model in which that evidence has force, the residual uncertainty, and an
-authority accountable for the decision. Draft, designed, assumed, tested,
-audited, and proven work are different states. Fluency does not collapse them.
-
-Particularity matters because abstraction always leaves something behind. A
-type, policy category, or machine-readable record is useful only when its
-lowering remains faithful to what is materially at stake. Contestability is
-the corresponding political commitment: an affected person must be able to
-discover the rule and evidence, challenge a classification or automated
-decision, and reach a responsible human authority.
-
-This chapter explains the philosophical direction, not its operational rules.
-The proposed
-[estate constitution](https://github.com/hyperpolymath/standards/tree/constitution/estate-foundation/constitution)
-defines authority, precedence, exceptions, assurance duties, and change
-procedure. Until adopted through review, it remains a proposal.
-
-# Core pillars
-
-Each pillar is a position, not a slogan. Each is meant to be disagreed
-with.
-
-## 1. Machine-readable governance
-
-The rules an estate lives by — licensing, provenance, conventions, who
-may change what — should be encoded as machine-readable artifacts, not
-narrated in prose that quietly drifts from the code it describes. A
-human-centric README cannot be checked; governance-as-data can. The
-`6SCM` pattern is how this estate encodes those rules so that tooling,
-and AI agents, can verify conformance and flag drift rather than take a
-paragraph’s word for it.
-
-*What this rejects:* the prose README as the source of truth about how a
-system is meant to behave.
-
-## 2. Neurosymbolic verification
-
-Probabilistic generation may propose; only symbolic method may dispose.
-Where correctness matters, an unproven output from a language model is a
-hypothesis, not a result, and treating fluency as evidence is a category
-error. The discipline is to pair generation with mechanised checking so
-that the part which can be certain has the last word.
-
-*What this rejects:* plausibility mistaken for proof. (`hypatia` is the
-clearest concrete instance.)
-
-## 3. Post-disciplinary praxis
-
-The rigour we reserve for compilers belongs equally to consent, to
-policy, to accountability. The line between a "technical" problem that
-deserves formal treatment and a "social" one left to good faith is
-itself a choice — and often an alibi. Post-disciplinary means reaching
-for whatever discipline the problem needs; *praxis* means refusing to
-separate the theory from the practice that tests it. The same instinct
-runs from labour-union policy to RISC-V SSGs.
-
-*What this rejects:* the division of labour that keeps rigour out of the
-rooms where power actually operates. (`avow-protocol`, consent-as-code,
-is the most developed example.)
-
-# The wager: value made legible
-
-Underneath all three pillars is one bet. Deciding what a system *should*
-do, whether an output *counts* as correct, who *consented*, and what
-*matters* are all judgments of value — and they are usually smuggled in
-implicitly and backed by authority: *trust me*, *the spec says so*, *the
-model said so*. Axiology is the study of value; the metaprogramming turn
-applies it operationally. Value is not asserted, it is *structured* —
-and structure can be inspected, checked, and argued with.
-
-This is also why the work is, at root, political as well as technical. A
-value that is explicit and inspectable can be contested by the people it
-bears on; a value backed only by authority cannot. Making value legible
-is therefore a precondition for accountability — in a compiler, in an AI
-system, and in a union. It is the point at which formal methods and
-solidarity economics turn out to want the same thing: that the rules be
-legible, and the powerful be answerable to them.
-
-It is the same instinct that runs through the technical research —
-identity defined by equivalence rather than asserted, a value justified
-by the construction that produced it rather than taken on faith. The
-manifesto only generalises that instinct, from values inside a program
-to values inside our systems and institutions.
-
-# Reading order
-
-- `EXPLAINME.adoc` — the canonical "what is this" entry-point, consumed
- by AI agents and by the `hyperpolymath/standards` governance tooling.
-
-- `docs/` — supporting essays, position papers, and ADRs that situate
- the manifesto in context.
-
-- `MAINTAINERS.adoc` — current stewards.
-
-# Status
-
-- **Licence:** MPL-2.0 (migrated from PMPL-1.0-or-later on 2026-05-26
- per the estate licence-debt audit,
- [hyperpolymath/standards#196](https://github.com/hyperpolymath/standards/pull/196)).
-
-- **Maturity:** a work in progress; the manifesto is a living document.
- The version number on the title line is incremented on each
- substantive revision.
-
-- **Audit findings:** see `docs/tech-debt-2026-05-26.md` if present
- (added by the 2026-05-26 estate tech-debt scan).
-
-# Engaging with this manifesto
-
-Collaboration here is not decoration; by the argument above it is
-constitutive. A manifesto that makes value contestable earns its keep
-only by being contested, adopted, and extended. Three ways in:
-
-- **Disagree** — open an Issue. Manifestos thrive on being argued with,
- and a pillar that no one challenges has not yet been tested.
-
-- **Adopt a thread** — fork, riff, cite. The MPL-2.0 licence makes
- derivative manifestos easy.
-
-- **Contribute editorially** — see
- CONTRIBUTING for the
- (intentionally light) editorial conventions.
-
-Whether you are a researcher, a maintainer, a journalist, or a student,
-the door is open — and the NUJ and solidarity-economics threads here
-mean I take "we" literally.
-
-# Companion repositories
-
-- `hyperpolymath/standards` — the RSR 2026 standards that the first
- pillar references.
-
-- `hyperpolymath/hypatia` — the neurosymbolic analyser that is the
- second pillar’s clearest concrete instantiation.
-
-- `hyperpolymath/avow-protocol` — the consent-as-code stack that is the
- third pillar’s most-developed example.
diff --git a/SECURITY.adoc b/SECURITY.adoc
new file mode 100644
index 0000000..213fd9a
--- /dev/null
+++ b/SECURITY.adoc
@@ -0,0 +1,438 @@
+== Security Policy
+
+We take security seriously. We appreciate your efforts to responsibly
+disclose vulnerabilities and will make every effort to acknowledge your
+contributions.
+
+=== Table of Contents
+
+* link:#reporting-a-vulnerability[Reporting a Vulnerability]
+* link:#what-to-include[What to Include]
+* link:#response-timeline[Response Timeline]
+* link:#disclosure-policy[Disclosure Policy]
+* link:#scope[Scope]
+* link:#safe-harbour[Safe Harbour]
+* link:#recognition[Recognition]
+* link:#security-updates[Security Updates]
+* link:#security-best-practices[Security Best Practices]
+
+'''''
+
+=== Reporting a Vulnerability
+
+==== Preferred Method: GitHub Security Advisories
+
+The preferred method for reporting security vulnerabilities is through
+GitHub’s Security Advisory feature:
+
+[arabic]
+. Navigate to
+https://github.com/hyperpolymath/hyperpolymath/security/advisories/new[Report
+a Vulnerability]
+. Click *"`Report a vulnerability`"*
+. Complete the form with as much detail as possible
+. Submit — we’ll receive a private notification
+
+This method ensures:
+
+* End-to-end encryption of your report
+* Private discussion space for collaboration
+* Coordinated disclosure tooling
+* Automatic credit when the advisory is published
+
+==== Alternative: Encrypted Email
+
+If you cannot use GitHub Security Advisories, you may email us directly:
+
+[cols=",",]
+|===
+|*Email* |6759885+hyperpolymath@users.noreply.github.com
+|*Fingerprint* |`+[PGP fingerprint not set]+`
+|===
+
+____
+*⚠️ Important:* Do not report security vulnerabilities through public
+GitHub issues, pull requests, discussions, or social media.
+____
+
+'''''
+
+=== What to Include
+
+A good vulnerability report helps us understand and reproduce the issue
+quickly.
+
+==== Required Information
+
+* *Description*: Clear explanation of the vulnerability
+* *Impact*: What an attacker could achieve (confidentiality, integrity,
+availability)
+* *Affected versions*: Which versions/commits are affected
+* *Reproduction steps*: Detailed steps to reproduce the issue
+
+==== Helpful Additional Information
+
+* *Proof of concept*: Code, scripts, or screenshots demonstrating the
+vulnerability
+* *Attack scenario*: Realistic attack scenario showing exploitability
+* *CVSS score*: Your assessment of severity (use
+https://www.first.org/cvss/calculator/3.1[CVSS 3.1 Calculator])
+* *CWE ID*: Common Weakness Enumeration identifier if known
+* *Suggested fix*: If you have ideas for remediation
+* *References*: Links to related vulnerabilities, research, or
+advisories
+
+==== Example Report Structure
+
+[source,markdown]
+----
+## Summary
+[One-sentence description of the vulnerability]
+
+## Vulnerability Type
+[e.g., SQL Injection, XSS, SSRF, Path Traversal, etc.]
+
+## Affected Component
+[File path, function name, API endpoint, etc.]
+
+## Affected Versions
+[Version range or specific commits]
+
+## Severity Assessment
+- CVSS 3.1 Score: [X.X]
+- CVSS Vector: [CVSS:3.1/AV:X/AC:X/PR:X/UI:X/S:X/C:X/I:X/A:X]
+
+## Description
+[Detailed technical description]
+
+## Steps to Reproduce
+1. [First step]
+2. [Second step]
+3. [...]
+
+## Proof of Concept
+[Code, curl commands, screenshots, etc.]
+
+## Impact
+[What can an attacker achieve?]
+
+## Suggested Remediation
+[Optional: your ideas for fixing]
+
+## References
+[Links to related issues, CVEs, research]
+----
+
+'''''
+
+=== Response Timeline
+
+We commit to the following response times:
+
+[width="100%",cols="24%,35%,41%",options="header",]
+|===
+|Stage |Timeframe |Description
+|*Initial Response* |48 hours |We acknowledge receipt and confirm we’re
+investigating
+
+|*Triage* |7 days |We assess severity, confirm the vulnerability, and
+estimate timeline
+
+|*Status Update* |Every 7 days |Regular updates on remediation progress
+
+|*Resolution* |90 days |Target for fix development and release (complex
+issues may take longer)
+
+|*Disclosure* |90 days |Public disclosure after fix is available
+(coordinated with you)
+|===
+
+____
+*Note:* These are targets, not guarantees. Complex vulnerabilities may
+require more time. We’ll communicate openly about any delays.
+____
+
+'''''
+
+=== Disclosure Policy
+
+We follow *coordinated disclosure* (also known as responsible
+disclosure):
+
+[arabic]
+. *You report* the vulnerability privately
+. *We acknowledge* and begin investigation
+. *We develop* a fix and prepare a release
+. *We coordinate* disclosure timing with you
+. *We publish* security advisory and fix simultaneously
+. *You may publish* your research after disclosure
+
+==== Our Commitments
+
+* We will not take legal action against researchers who follow this
+policy
+* We will work with you to understand and resolve the issue
+* We will credit you in the security advisory (unless you prefer
+anonymity)
+* We will notify you before public disclosure
+* We will publish advisories with sufficient detail for users to assess
+risk
+
+==== Your Commitments
+
+* Report vulnerabilities promptly after discovery
+* Give us reasonable time to address the issue before disclosure
+* Do not access, modify, or delete data beyond what’s necessary to
+demonstrate the vulnerability
+* Do not degrade service availability (no DoS testing on production)
+* Do not share vulnerability details with others until coordinated
+disclosure
+
+==== Disclosure Timeline
+
+....
+Day 0 You report vulnerability
+Day 1-2 We acknowledge receipt
+Day 7 We confirm vulnerability and share initial assessment
+Day 7-90 We develop and test fix
+Day 90 Coordinated public disclosure
+ (earlier if fix is ready; later by mutual agreement)
+....
+
+If we cannot reach agreement on disclosure timing, we default to 90 days
+from your initial report.
+
+'''''
+
+=== Scope
+
+==== In Scope ✅
+
+The following are within scope for security research:
+
+* This repository (`+hyperpolymath/hyperpolymath+`) and all its code
+* Official releases and packages published from this repository
+* Documentation that could lead to security issues
+* Build and deployment configurations in this repository
+* Dependencies (report here, we’ll coordinate with upstream)
+
+==== Out of Scope ❌
+
+The following are *not* in scope:
+
+* Third-party services we integrate with (report directly to them)
+* Social engineering attacks against maintainers
+* Physical security
+* Denial of service attacks against production infrastructure
+* Spam, phishing, or other non-technical attacks
+* Issues already reported or publicly known
+* Theoretical vulnerabilities without proof of concept
+
+==== Qualifying Vulnerabilities
+
+We’re particularly interested in:
+
+* Remote code execution
+* SQL injection, command injection, code injection
+* Authentication/authorisation bypass
+* Cross-site scripting (XSS) and cross-site request forgery (CSRF)
+* Server-side request forgery (SSRF)
+* Path traversal / local file inclusion
+* Information disclosure (credentials, PII, secrets)
+* Cryptographic weaknesses
+* Deserialisation vulnerabilities
+* Memory safety issues (buffer overflows, use-after-free, etc.)
+* Supply chain vulnerabilities (dependency confusion, etc.)
+* Significant logic flaws
+
+==== Non-Qualifying Issues
+
+The following generally do not qualify as security vulnerabilities:
+
+* Missing security headers on non-sensitive pages
+* Clickjacking on pages without sensitive actions
+* Self-XSS (requires victim to paste code)
+* Missing rate limiting (unless it enables a specific attack)
+* Username/email enumeration (unless high-risk context)
+* Missing cookie flags on non-sensitive cookies
+* Software version disclosure
+* Verbose error messages (unless exposing secrets)
+* Best practice deviations without demonstrable impact
+
+'''''
+
+=== Safe Harbour
+
+We support security research conducted in good faith.
+
+==== Our Promise
+
+If you conduct security research in accordance with this policy:
+
+* ✅ We will not initiate legal action against you
+* ✅ We will not report your activity to law enforcement
+* ✅ We will work with you in good faith to resolve issues
+* ✅ We consider your research authorised under the Computer Fraud and
+Abuse Act (CFAA), UK Computer Misuse Act, and similar laws
+* ✅ We waive any potential claim against you for circumvention of
+security controls
+
+==== Good Faith Requirements
+
+To qualify for safe harbour, you must:
+
+* Comply with this security policy
+* Report vulnerabilities promptly
+* Avoid privacy violations (do not access others’ data)
+* Avoid service degradation (no destructive testing)
+* Not exploit vulnerabilities beyond proof-of-concept
+* Not use vulnerabilities for profit (beyond bug bounties where offered)
+
+____
+*⚠️ Important:* This safe harbour does not extend to third-party
+systems. Always check their policies before testing.
+____
+
+'''''
+
+=== Recognition
+
+We believe in recognising security researchers who help us improve.
+
+==== Hall of Fame
+
+Researchers who report valid vulnerabilities will be acknowledged in our
+link:SECURITY-ACKNOWLEDGMENTS.md[Security Acknowledgments] (unless they
+prefer anonymity).
+
+Recognition includes:
+
+* Your name (or chosen alias)
+* Link to your website/profile (optional)
+* Brief description of the vulnerability class
+* Date of report
+
+==== What We Offer
+
+* ✅ Public credit in security advisories
+* ✅ Acknowledgment in release notes
+* ✅ Entry in our Hall of Fame
+* ✅ Reference/recommendation letter upon request (for significant
+findings)
+
+==== What We Don’t Currently Offer
+
+* ❌ Monetary bug bounties
+* ❌ Hardware or swag
+* ❌ Paid security research contracts
+
+____
+*Note:* We’re a community project with limited resources. Your
+contributions help everyone who uses this software.
+____
+
+'''''
+
+=== Security Updates
+
+==== Receiving Updates
+
+To stay informed about security updates:
+
+* *Watch this repository*: Click "`Watch`" → "`Custom`" → Select
+"`Security alerts`"
+* *GitHub Security Advisories*: Published at
+https://github.com/hyperpolymath/hyperpolymath/security/advisories[Security
+Advisories]
+* *Release notes*: Security fixes noted in link:CHANGELOG.md[CHANGELOG]
+
+==== Update Policy
+
+[cols=",",options="header",]
+|===
+|Severity |Response
+|*Critical/High* |Patch release as soon as fix is ready
+|*Medium* |Included in next scheduled release (or earlier)
+|*Low* |Included in next scheduled release
+|===
+
+==== Supported Versions
+
+[cols=",,",options="header",]
+|===
+|Version |Supported |Notes
+|`+main+` branch |✅ Yes |Latest development
+|Latest release |✅ Yes |Current stable
+|Previous minor release |✅ Yes |Security fixes backported
+|Older versions |❌ No |Please upgrade
+|===
+
+'''''
+
+=== Security Best Practices
+
+When using Hyperpolymath, we recommend:
+
+==== General
+
+* Keep dependencies up to date
+* Use the latest stable release
+* Subscribe to security notifications
+* Review configuration against security documentation
+* Follow principle of least privilege
+
+==== For Contributors
+
+* Never commit secrets, credentials, or API keys
+* Use signed commits (`+git config commit.gpgsign true+`)
+* Review dependencies before adding them
+* Run security linters locally before pushing
+* Report any concerns about existing code
+
+'''''
+
+=== Additional Resources
+
+* https://github.com/hyperpolymath/hyperpolymath/security/advisories[Security
+Advisories]
+* link:CHANGELOG.md[Changelog]
+* link:CONTRIBUTING.md[Contributing Guidelines]
+* https://cve.mitre.org/[CVE Database]
+* https://www.first.org/cvss/calculator/3.1[CVSS Calculator]
+
+'''''
+
+=== Contact
+
+[width="100%",cols="50%,50%",options="header",]
+|===
+|Purpose |Contact
+|*Security issues*
+|https://github.com/hyperpolymath/hyperpolymath/security/advisories/new[Report
+via GitHub] or 6759885+hyperpolymath@users.noreply.github.com
+
+|*General questions*
+|https://github.com/hyperpolymath/hyperpolymath/discussions[GitHub
+Discussions]
+
+|*Other enquiries* |See link:README.md[README] for contact information
+|===
+
+'''''
+
+=== Policy Changes
+
+This security policy may be updated from time to time. Significant
+changes will be:
+
+* Committed to this repository with a clear commit message
+* Noted in the changelog
+* Announced via GitHub Discussions (for major changes)
+
+'''''
+
+_Thank you for helping keep Hyperpolymath and its users safe._ 🛡️
+
+'''''
+
+Last updated: 2026 · Policy version: 1.0.0
diff --git a/SECURITY.md b/SECURITY.md
deleted file mode 100644
index acd16f8..0000000
--- a/SECURITY.md
+++ /dev/null
@@ -1,380 +0,0 @@
-
-# Security Policy
-
-We take security seriously. We appreciate your efforts to responsibly disclose vulnerabilities and will make every effort to acknowledge your contributions.
-
-## Table of Contents
-
-- [Reporting a Vulnerability](#reporting-a-vulnerability)
-- [What to Include](#what-to-include)
-- [Response Timeline](#response-timeline)
-- [Disclosure Policy](#disclosure-policy)
-- [Scope](#scope)
-- [Safe Harbour](#safe-harbour)
-- [Recognition](#recognition)
-- [Security Updates](#security-updates)
-- [Security Best Practices](#security-best-practices)
-
----
-
-## Reporting a Vulnerability
-
-### Preferred Method: GitHub Security Advisories
-
-The preferred method for reporting security vulnerabilities is through GitHub's Security Advisory feature:
-
-1. Navigate to [Report a Vulnerability](https://github.com/hyperpolymath/hyperpolymath/security/advisories/new)
-2. Click **"Report a vulnerability"**
-3. Complete the form with as much detail as possible
-4. Submit — we'll receive a private notification
-
-This method ensures:
-
-- End-to-end encryption of your report
-- Private discussion space for collaboration
-- Coordinated disclosure tooling
-- Automatic credit when the advisory is published
-
-### Alternative: Encrypted Email
-
-If you cannot use GitHub Security Advisories, you may email us directly:
-
-| | |
-|---|---|
-| **Email** | 6759885+hyperpolymath@users.noreply.github.com |
-| **Fingerprint** | `[PGP fingerprint not set]` |
-
-
-> **⚠️ Important:** Do not report security vulnerabilities through public GitHub issues, pull requests, discussions, or social media.
-
----
-
-## What to Include
-
-A good vulnerability report helps us understand and reproduce the issue quickly.
-
-### Required Information
-
-- **Description**: Clear explanation of the vulnerability
-- **Impact**: What an attacker could achieve (confidentiality, integrity, availability)
-- **Affected versions**: Which versions/commits are affected
-- **Reproduction steps**: Detailed steps to reproduce the issue
-
-### Helpful Additional Information
-
-- **Proof of concept**: Code, scripts, or screenshots demonstrating the vulnerability
-- **Attack scenario**: Realistic attack scenario showing exploitability
-- **CVSS score**: Your assessment of severity (use [CVSS 3.1 Calculator](https://www.first.org/cvss/calculator/3.1))
-- **CWE ID**: Common Weakness Enumeration identifier if known
-- **Suggested fix**: If you have ideas for remediation
-- **References**: Links to related vulnerabilities, research, or advisories
-
-### Example Report Structure
-
-```markdown
-## Summary
-[One-sentence description of the vulnerability]
-
-## Vulnerability Type
-[e.g., SQL Injection, XSS, SSRF, Path Traversal, etc.]
-
-## Affected Component
-[File path, function name, API endpoint, etc.]
-
-## Affected Versions
-[Version range or specific commits]
-
-## Severity Assessment
-- CVSS 3.1 Score: [X.X]
-- CVSS Vector: [CVSS:3.1/AV:X/AC:X/PR:X/UI:X/S:X/C:X/I:X/A:X]
-
-## Description
-[Detailed technical description]
-
-## Steps to Reproduce
-1. [First step]
-2. [Second step]
-3. [...]
-
-## Proof of Concept
-[Code, curl commands, screenshots, etc.]
-
-## Impact
-[What can an attacker achieve?]
-
-## Suggested Remediation
-[Optional: your ideas for fixing]
-
-## References
-[Links to related issues, CVEs, research]
-```
-
----
-
-## Response Timeline
-
-We commit to the following response times:
-
-| Stage | Timeframe | Description |
-|-------|-----------|-------------|
-| **Initial Response** | 48 hours | We acknowledge receipt and confirm we're investigating |
-| **Triage** | 7 days | We assess severity, confirm the vulnerability, and estimate timeline |
-| **Status Update** | Every 7 days | Regular updates on remediation progress |
-| **Resolution** | 90 days | Target for fix development and release (complex issues may take longer) |
-| **Disclosure** | 90 days | Public disclosure after fix is available (coordinated with you) |
-
-> **Note:** These are targets, not guarantees. Complex vulnerabilities may require more time. We'll communicate openly about any delays.
-
----
-
-## Disclosure Policy
-
-We follow **coordinated disclosure** (also known as responsible disclosure):
-
-1. **You report** the vulnerability privately
-2. **We acknowledge** and begin investigation
-3. **We develop** a fix and prepare a release
-4. **We coordinate** disclosure timing with you
-5. **We publish** security advisory and fix simultaneously
-6. **You may publish** your research after disclosure
-
-### Our Commitments
-
-- We will not take legal action against researchers who follow this policy
-- We will work with you to understand and resolve the issue
-- We will credit you in the security advisory (unless you prefer anonymity)
-- We will notify you before public disclosure
-- We will publish advisories with sufficient detail for users to assess risk
-
-### Your Commitments
-
-- Report vulnerabilities promptly after discovery
-- Give us reasonable time to address the issue before disclosure
-- Do not access, modify, or delete data beyond what's necessary to demonstrate the vulnerability
-- Do not degrade service availability (no DoS testing on production)
-- Do not share vulnerability details with others until coordinated disclosure
-
-### Disclosure Timeline
-
-```
-Day 0 You report vulnerability
-Day 1-2 We acknowledge receipt
-Day 7 We confirm vulnerability and share initial assessment
-Day 7-90 We develop and test fix
-Day 90 Coordinated public disclosure
- (earlier if fix is ready; later by mutual agreement)
-```
-
-If we cannot reach agreement on disclosure timing, we default to 90 days from your initial report.
-
----
-
-## Scope
-
-### In Scope ✅
-
-The following are within scope for security research:
-
-- This repository (`hyperpolymath/hyperpolymath`) and all its code
-- Official releases and packages published from this repository
-- Documentation that could lead to security issues
-- Build and deployment configurations in this repository
-- Dependencies (report here, we'll coordinate with upstream)
-
-### Out of Scope ❌
-
-The following are **not** in scope:
-
-- Third-party services we integrate with (report directly to them)
-- Social engineering attacks against maintainers
-- Physical security
-- Denial of service attacks against production infrastructure
-- Spam, phishing, or other non-technical attacks
-- Issues already reported or publicly known
-- Theoretical vulnerabilities without proof of concept
-
-### Qualifying Vulnerabilities
-
-We're particularly interested in:
-
-- Remote code execution
-- SQL injection, command injection, code injection
-- Authentication/authorisation bypass
-- Cross-site scripting (XSS) and cross-site request forgery (CSRF)
-- Server-side request forgery (SSRF)
-- Path traversal / local file inclusion
-- Information disclosure (credentials, PII, secrets)
-- Cryptographic weaknesses
-- Deserialisation vulnerabilities
-- Memory safety issues (buffer overflows, use-after-free, etc.)
-- Supply chain vulnerabilities (dependency confusion, etc.)
-- Significant logic flaws
-
-### Non-Qualifying Issues
-
-The following generally do not qualify as security vulnerabilities:
-
-- Missing security headers on non-sensitive pages
-- Clickjacking on pages without sensitive actions
-- Self-XSS (requires victim to paste code)
-- Missing rate limiting (unless it enables a specific attack)
-- Username/email enumeration (unless high-risk context)
-- Missing cookie flags on non-sensitive cookies
-- Software version disclosure
-- Verbose error messages (unless exposing secrets)
-- Best practice deviations without demonstrable impact
-
----
-
-## Safe Harbour
-
-We support security research conducted in good faith.
-
-### Our Promise
-
-If you conduct security research in accordance with this policy:
-
-- ✅ We will not initiate legal action against you
-- ✅ We will not report your activity to law enforcement
-- ✅ We will work with you in good faith to resolve issues
-- ✅ We consider your research authorised under the Computer Fraud and Abuse Act (CFAA), UK Computer Misuse Act, and similar laws
-- ✅ We waive any potential claim against you for circumvention of security controls
-
-### Good Faith Requirements
-
-To qualify for safe harbour, you must:
-
-- Comply with this security policy
-- Report vulnerabilities promptly
-- Avoid privacy violations (do not access others' data)
-- Avoid service degradation (no destructive testing)
-- Not exploit vulnerabilities beyond proof-of-concept
-- Not use vulnerabilities for profit (beyond bug bounties where offered)
-
-> **⚠️ Important:** This safe harbour does not extend to third-party systems. Always check their policies before testing.
-
----
-
-## Recognition
-
-We believe in recognising security researchers who help us improve.
-
-### Hall of Fame
-
-Researchers who report valid vulnerabilities will be acknowledged in our [Security Acknowledgments](SECURITY-ACKNOWLEDGMENTS.md) (unless they prefer anonymity).
-
-Recognition includes:
-
-- Your name (or chosen alias)
-- Link to your website/profile (optional)
-- Brief description of the vulnerability class
-- Date of report
-
-### What We Offer
-
-- ✅ Public credit in security advisories
-- ✅ Acknowledgment in release notes
-- ✅ Entry in our Hall of Fame
-- ✅ Reference/recommendation letter upon request (for significant findings)
-
-### What We Don't Currently Offer
-
-- ❌ Monetary bug bounties
-- ❌ Hardware or swag
-- ❌ Paid security research contracts
-
-> **Note:** We're a community project with limited resources. Your contributions help everyone who uses this software.
-
----
-
-## Security Updates
-
-### Receiving Updates
-
-To stay informed about security updates:
-
-- **Watch this repository**: Click "Watch" → "Custom" → Select "Security alerts"
-- **GitHub Security Advisories**: Published at [Security Advisories](https://github.com/hyperpolymath/hyperpolymath/security/advisories)
-- **Release notes**: Security fixes noted in [CHANGELOG](CHANGELOG.md)
-
-### Update Policy
-
-| Severity | Response |
-|----------|----------|
-| **Critical/High** | Patch release as soon as fix is ready |
-| **Medium** | Included in next scheduled release (or earlier) |
-| **Low** | Included in next scheduled release |
-
-### Supported Versions
-
-
-
-| Version | Supported | Notes |
-|---------|-----------|-------|
-| `main` branch | ✅ Yes | Latest development |
-| Latest release | ✅ Yes | Current stable |
-| Previous minor release | ✅ Yes | Security fixes backported |
-| Older versions | ❌ No | Please upgrade |
-
----
-
-## Security Best Practices
-
-When using Hyperpolymath, we recommend:
-
-### General
-
-- Keep dependencies up to date
-- Use the latest stable release
-- Subscribe to security notifications
-- Review configuration against security documentation
-- Follow principle of least privilege
-
-### For Contributors
-
-- Never commit secrets, credentials, or API keys
-- Use signed commits (`git config commit.gpgsign true`)
-- Review dependencies before adding them
-- Run security linters locally before pushing
-- Report any concerns about existing code
-
----
-
-## Additional Resources
-
-- [Security Advisories](https://github.com/hyperpolymath/hyperpolymath/security/advisories)
-- [Changelog](CHANGELOG.md)
-- [Contributing Guidelines](CONTRIBUTING.md)
-- [CVE Database](https://cve.mitre.org/)
-- [CVSS Calculator](https://www.first.org/cvss/calculator/3.1)
-
----
-
-## Contact
-
-| Purpose | Contact |
-|---------|---------|
-| **Security issues** | [Report via GitHub](https://github.com/hyperpolymath/hyperpolymath/security/advisories/new) or 6759885+hyperpolymath@users.noreply.github.com |
-| **General questions** | [GitHub Discussions](https://github.com/hyperpolymath/hyperpolymath/discussions) |
-| **Other enquiries** | See [README](README.md) for contact information |
-
----
-
-## Policy Changes
-
-This security policy may be updated from time to time. Significant changes will be:
-
-- Committed to this repository with a clear commit message
-- Noted in the changelog
-- Announced via GitHub Discussions (for major changes)
-
----
-
-*Thank you for helping keep Hyperpolymath and its users safe.* 🛡️
-
----
-
-Last updated: 2026 · Policy version: 1.0.0
diff --git a/TEST-NEEDS.adoc b/TEST-NEEDS.adoc
new file mode 100644
index 0000000..401e056
--- /dev/null
+++ b/TEST-NEEDS.adoc
@@ -0,0 +1,31 @@
+== TEST-NEEDS.md — manifesto
+
+=== CRG Grade: C — ACHIEVED 2026-04-04
+
+=== Current Test State
+
+[cols=",,",options="header",]
+|===
+|Category |Count |Notes
+|Test files |0 |Current state
+|===
+
+=== What’s Covered
+
+* [ ] No test files found
+
+=== Still Missing (for CRG B+)
+
+* [ ] Add unit tests
+* [ ] Add integration tests
+* [ ] Zig FFI tests (if applicable)
+* [ ] CI/CD test automation
+* [ ] Property-based tests
+* [ ] Edge case coverage
+
+=== Run Tests
+
+[source,bash]
+----
+# Tests needed
+----
diff --git a/TEST-NEEDS.md b/TEST-NEEDS.md
deleted file mode 100644
index 6e6b5b3..0000000
--- a/TEST-NEEDS.md
+++ /dev/null
@@ -1,32 +0,0 @@
-
-# TEST-NEEDS.md — manifesto
-
-## CRG Grade: C — ACHIEVED 2026-04-04
-
-## Current Test State
-
-| Category | Count | Notes |
-|----------|-------|-------|
-| Test files | 0 | Current state |
-
-## What's Covered
-
-- [ ] No test files found
-
-## Still Missing (for CRG B+)
-
-- [ ] Add unit tests
-- [ ] Add integration tests
-- [ ] Zig FFI tests (if applicable)
-- [ ] CI/CD test automation
-- [ ] Property-based tests
-- [ ] Edge case coverage
-
-## Run Tests
-
-```bash
-# Tests needed
-```
diff --git a/TOPOLOGY.adoc b/TOPOLOGY.adoc
new file mode 100644
index 0000000..a6e385d
--- /dev/null
+++ b/TOPOLOGY.adoc
@@ -0,0 +1,36 @@
+== TOPOLOGY.md — manifesto
+
+=== Purpose
+
+Jonathan’s Manifesto documents the metaprogramming turn and governance
+philosophy for 275+ hyperpolymath repositories consolidated under the
+RSR 2026 Standard. It articulates core pillars: machine-readable
+governance, neurosymbolic verification, and post-disciplinary praxis
+rooted in axiology and cognitive science.
+
+=== Module Map
+
+....
+manifesto/
+├── docs/ # Documentation sections and supporting material
+├── contractiles/ # Contractile modules (declarative components)
+├── .machine_readable/ # SCM files (governance, state, ecosystem position)
+└── flake.nix # Nix/NixOS environment definition
+....
+
+=== Data Flow
+
+....
+[Vision Statement] ──► [Core Pillars] ──► [RSR 2026 Standard] ──► [Repository Governance]
+ ↓
+ [Axiology Framework] ──► [Value-Driven Logic]
+....
+
+=== Key Sections
+
+* *The Vision*: Metaprogramming turn and RSR consolidation (275 repos
+from 580+)
+* *Core Pillars*: Machine-readable governance, neurosymbolic
+verification, post-disciplinary praxis
+* *Legacy of Axiology*: Value systems in autonomous architecture
+* *RSR Integration*: Links to other hyperpolymath governance documents
diff --git a/TOPOLOGY.md b/TOPOLOGY.md
deleted file mode 100644
index 669eda8..0000000
--- a/TOPOLOGY.md
+++ /dev/null
@@ -1,33 +0,0 @@
-
-
-
-# TOPOLOGY.md — manifesto
-
-## Purpose
-
-Jonathan's Manifesto documents the metaprogramming turn and governance philosophy for 275+ hyperpolymath repositories consolidated under the RSR 2026 Standard. It articulates core pillars: machine-readable governance, neurosymbolic verification, and post-disciplinary praxis rooted in axiology and cognitive science.
-
-## Module Map
-
-```
-manifesto/
-├── docs/ # Documentation sections and supporting material
-├── contractiles/ # Contractile modules (declarative components)
-├── .machine_readable/ # SCM files (governance, state, ecosystem position)
-└── flake.nix # Nix/NixOS environment definition
-```
-
-## Data Flow
-
-```
-[Vision Statement] ──► [Core Pillars] ──► [RSR 2026 Standard] ──► [Repository Governance]
- ↓
- [Axiology Framework] ──► [Value-Driven Logic]
-```
-
-## Key Sections
-
-- **The Vision**: Metaprogramming turn and RSR consolidation (275 repos from 580+)
-- **Core Pillars**: Machine-readable governance, neurosymbolic verification, post-disciplinary praxis
-- **Legacy of Axiology**: Value systems in autonomous architecture
-- **RSR Integration**: Links to other hyperpolymath governance documents
diff --git a/docs/tech-debt-2026-05-26.adoc b/docs/tech-debt-2026-05-26.adoc
new file mode 100644
index 0000000..fe5ef38
--- /dev/null
+++ b/docs/tech-debt-2026-05-26.adoc
@@ -0,0 +1,69 @@
+== Tech-Debt Audit — manifesto — 2026-05-26
+
+*Source:* estate-wide automated scan 2026-05-26. *Companion:*
+https://github.com/hyperpolymath/standards/tree/main/docs/audits[`+hyperpolymath/standards+`
+2026-05-26-estate-*-debt audits]. *Combined severity:* `+HIGH+`.
+
+This file records the _raw findings_ — it does not by itself fix the
+debt. Each section ends with a '`Recommended next move`' line; closing
+the debt is follow-up work.
+
+=== 1. Proof debt
+
+No proof-bearing files (`+*.v+`, `+*.lean+`, `+*.agda+`, `+*.idr+`,
+`+*.idr2+`, `+*.fst+`, `+*.dfy+`, `+*.tla+`, `+*.ads+`, `+*.adb+`) found
+in this repo.
+
+*Recommended next move:* none.
+
+=== 2. Licence debt
+
+[cols=",",options="header",]
+|===
+|Field |Value
+|LICENSE file |`+LICENSE+`
+|SPDX header |`+MPL-2.0+`
+|Manifest licence |`+NONE+`
+|Body classifier |`+Palimp-MPL-2.0+`
+|Severity |`+ok+`
+|===
+
+*Recommended next move:* none for licence.
+
+=== 3. Documentation debt
+
+[cols=",",options="header",]
+|===
+|Field |Value
+|README lines |15
+|`+docs/+` files |1
+|`+docs/+` LoC |36
+|CHANGELOG.md |N
+|CONTRIBUTING.md |Y
+|CODE_OF_CONDUCT.md |Y
+|SECURITY.md |Y
+|Severity |`+HIGH+`
+|===
+
+*Recommended next move:* expand the stub README (currently 15 lines).
+Minimum: title, what-it-is in one paragraph, install/usage, link to
+deeper docs. Use `+hyperpolymath/rsr-template-repo+` as the reference.
+
+Additionally: *CHANGELOG.md is missing.* 65% of estate repos lack one —
+adopting a CHANGELOG (or auto-generating via `+git-cliff+`) is a
+recommended estate-wide follow-up.
+
+=== Cross-references
+
+* Estate proof-debt audit:
+`+hyperpolymath/standards/docs/audits/2026-05-26-estate-proof-debt.md+`
+* Estate licence-debt audit:
+`+hyperpolymath/standards/docs/audits/2026-05-26-estate-licence-debt.md+`
+* Estate documentation-debt audit:
+`+hyperpolymath/standards/docs/audits/2026-05-26-estate-documentation-debt.md+`
+
+'''''
+
+🤖 Generated by Claude Code estate-wide tech-debt scan (2026-05-26).
+This file is informational — closing the debt is follow-up work owned by
+the maintainer.
diff --git a/docs/tech-debt-2026-05-26.md b/docs/tech-debt-2026-05-26.md
deleted file mode 100644
index 762b28e..0000000
--- a/docs/tech-debt-2026-05-26.md
+++ /dev/null
@@ -1,57 +0,0 @@
-
-
-# Tech-Debt Audit — manifesto — 2026-05-26
-
-**Source:** estate-wide automated scan 2026-05-26.
-**Companion:** [`hyperpolymath/standards` 2026-05-26-estate-*-debt audits](https://github.com/hyperpolymath/standards/tree/main/docs/audits).
-**Combined severity:** `HIGH`.
-
-This file records the *raw findings* — it does not by itself fix the debt. Each section ends with a 'Recommended next move' line; closing the debt is follow-up work.
-
-## 1. Proof debt
-
-No proof-bearing files (`*.v`, `*.lean`, `*.agda`, `*.idr`, `*.idr2`, `*.fst`, `*.dfy`, `*.tla`, `*.ads`, `*.adb`) found in this repo.
-
-**Recommended next move:** none.
-
-## 2. Licence debt
-
-| Field | Value |
-|---|---|
-| LICENSE file | `LICENSE` |
-| SPDX header | `MPL-2.0` |
-| Manifest licence | `NONE` |
-| Body classifier | `Palimp-MPL-2.0` |
-| Severity | `ok` |
-
-**Recommended next move:** none for licence.
-
-## 3. Documentation debt
-
-| Field | Value |
-|---|---|
-| README lines | 15 |
-| `docs/` files | 1 |
-| `docs/` LoC | 36 |
-| CHANGELOG.md | N |
-| CONTRIBUTING.md | Y |
-| CODE_OF_CONDUCT.md | Y |
-| SECURITY.md | Y |
-| Severity | `HIGH` |
-
-**Recommended next move:** expand the stub README (currently 15 lines). Minimum: title, what-it-is in one paragraph, install/usage, link to deeper docs. Use `hyperpolymath/rsr-template-repo` as the reference.
-
-Additionally: **CHANGELOG.md is missing.** 65% of estate repos lack one — adopting a CHANGELOG (or auto-generating via `git-cliff`) is a recommended estate-wide follow-up.
-
-## Cross-references
-
-- Estate proof-debt audit: `hyperpolymath/standards/docs/audits/2026-05-26-estate-proof-debt.md`
-- Estate licence-debt audit: `hyperpolymath/standards/docs/audits/2026-05-26-estate-licence-debt.md`
-- Estate documentation-debt audit: `hyperpolymath/standards/docs/audits/2026-05-26-estate-documentation-debt.md`
-
----
-
-🤖 Generated by Claude Code estate-wide tech-debt scan (2026-05-26). This file is informational — closing the debt is follow-up work owned by the maintainer.
diff --git a/llm-warmup-dev.adoc b/llm-warmup-dev.adoc
new file mode 100644
index 0000000..57ecd9a
--- /dev/null
+++ b/llm-warmup-dev.adoc
@@ -0,0 +1,19 @@
+== LLM Warmup — manifesto (Developer)
+
+=== What is manifesto?
+
+See README.adoc for overview.
+
+=== Key Commands
+
+* `+just setup+` — set up development environment
+* `+just build+` — build the project
+* `+just test+` — run tests
+* `+just doctor+` — diagnose issues
+* `+just heal+` — attempt auto-repair
+
+=== Quick Context
+
+* License: MPL-2.0
+* Part of hyperpolymath ecosystem
+* See EXPLAINME.adoc for architecture
diff --git a/llm-warmup-dev.md b/llm-warmup-dev.md
deleted file mode 100644
index ac17af3..0000000
--- a/llm-warmup-dev.md
+++ /dev/null
@@ -1,20 +0,0 @@
-
-# LLM Warmup — manifesto (Developer)
-
-## What is manifesto?
-See README.adoc for overview.
-
-## Key Commands
-- `just setup` — set up development environment
-- `just build` — build the project
-- `just test` — run tests
-- `just doctor` — diagnose issues
-- `just heal` — attempt auto-repair
-
-## Quick Context
-- License: MPL-2.0
-- Part of hyperpolymath ecosystem
-- See EXPLAINME.adoc for architecture
diff --git a/llm-warmup-user.adoc b/llm-warmup-user.adoc
new file mode 100644
index 0000000..cddf850
--- /dev/null
+++ b/llm-warmup-user.adoc
@@ -0,0 +1,19 @@
+== LLM Warmup — manifesto (User)
+
+=== What is manifesto?
+
+See README.adoc for overview.
+
+=== Key Commands
+
+* `+just setup+` — set up development environment
+* `+just build+` — build the project
+* `+just test+` — run tests
+* `+just doctor+` — diagnose issues
+* `+just heal+` — attempt auto-repair
+
+=== Quick Context
+
+* License: MPL-2.0
+* Part of hyperpolymath ecosystem
+* See EXPLAINME.adoc for architecture
diff --git a/llm-warmup-user.md b/llm-warmup-user.md
deleted file mode 100644
index 90c1247..0000000
--- a/llm-warmup-user.md
+++ /dev/null
@@ -1,20 +0,0 @@
-
-# LLM Warmup — manifesto (User)
-
-## What is manifesto?
-See README.adoc for overview.
-
-## Key Commands
-- `just setup` — set up development environment
-- `just build` — build the project
-- `just test` — run tests
-- `just doctor` — diagnose issues
-- `just heal` — attempt auto-repair
-
-## Quick Context
-- License: MPL-2.0
-- Part of hyperpolymath ecosystem
-- See EXPLAINME.adoc for architecture