docs: finish instantiating the RSR docs skeleton (#22)

## What

This repo was minted from the RSR template and got a docs skeleton
(docs/architecture.adoc, docs/contributing.adoc, docs/usage.adoc,
docs/troubleshooting.adoc, ADR 0001) adopted wholesale in #11, but the
skeleton was never actually filled in — it still carried `<angle
bracket>` placeholder tokens and generic boilerplate describing a
built/tested software product (`just` recipes, an HTTP API, Rust
source paths) that has never existed in this repo.

`technical-notes` is, in fact, a documentation archive: short citable
technical notes, individually deposited on Zenodo with a DOI (see
README.md). No source code, build system, or test suite. This PR
rewrites the process docs to say that, plainly and minimally, instead
of describing a fictional product.

## Changes

- `docs/architecture.adoc`, `docs/contributing.adoc`, `docs/usage.adoc`,
  `docs/troubleshooting.adoc`: replaced unfilled placeholders and
  fictional software-product content with a truthful description of
  the actual publishing/citation process. Fixed the stray
  `:revdate: 2026-MM-DD` placeholders. Dropped a dead link to a
  nonexistent `SECURITY.md`.
- `ARCHITECTURE.md`, `GOVERNANCE.md`, `MAINTAINERS` (repo root): these
  were 100% unedited generic scaffold text (mentions `src/`, `tests/`,
  `scripts/`, `config/`, "public APIs", multi-maintainer RFC process)
  that never matched this repo. Rewritten to match reality: single
  maintainer, no software architecture.
- `MAINTAINERS`, `.github/CODEOWNERS`, `.github/funding.yml`: these
  pointed at `@metadatastician`, the RSR template's literal default
  owner value, never swapped for this repo's real owner. Corrected to
  `@hyperpolymath`, which matches every commit author and existing
  SPDX `FileCopyrightText` in this repo.
- `mise.toml`: trimmed from a full generic multi-language toolchain
  list (node/python/go/java/rust/…) down to what this repo actually
  needs — `git` and `typst` (for reproducing a note's rendered PDF).

## Not touched

`flake.nix`, `.tool-versions` (not present), `.editorconfig`,
`.gitattributes`, `.gitignore` — excluded per estate convention.
`README.md`'s CC-BY-4.0 licence line for note *content* was left
alone: it's consistent with `.zenodo.json` and is a separate,
intentional licence from the MPL-2.0/CC-BY-SA-4.0 covering this repo's
own tooling/process docs.

## Not applicable here

No literal `{{...}}` mustache placeholders,
`scripts/validate-template.sh`,
`tests/e2e/template_instantiation_test.sh`, `justfile`, or `.zig`
sources exist in this checkout, so those parts of the standard
instantiation cure don't apply to this repo.

## Verification

- `grep -rn '{{' .` (excluding GitHub Actions `${{ }}` expressions):
  clean.
- `grep -rn 'metadatastician'`: clean.
- `grep -rn 'MM-DD'`: clean.
- Remaining `<...>` placeholders in docs: only one intentional
  notational use (`zenodo.<version>` describing the DOI *format*, not
  an unfilled field).
- All three `.github/workflows/*.yml` files parse as valid YAML
  (`python3 -c "import yaml; yaml.safe_load(...)"`), each with at
  least one job — unchanged by this PR, verified as a regression
  check.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: hyperpolymath

.github/CODEOWNERS

@@ -1,7 +1,7 @@
 # Code Owners
 
 # Default: All contributors with write access are code owners
-* @metadatastician
+* @hyperpolymath
 
 # For specific paths, add explicit owners below
 # Example:

.github/funding.yml

@@ -1,4 +1,4 @@
 # Funding Configuration
 # See: https://docs.github.com/en/repositories/managing-your-repositorys-custom-fields/displaying-a-sponsor-button-in-your-repository
 
-github: metadatastician
+github: hyperpolymath

ARCHITECTURE.md

@@ -1,47 +1,59 @@
-# Architecture
+<!--
+SPDX-License-Identifier: CC-BY-SA-4.0
+SPDX-FileCopyrightText: 2026 Jonathan D.A. Jewell (hyperpolymath)
+-->
 
-## Overview
+# Architecture
 
-This repository follows a modular, maintainable architecture designed for clarity, scalability, and long-term sustainability.
+`technical-notes` is a documentation archive, not a software project:
+it holds short, citable technical notes (Markdown, optionally with a
+Typst source and rendered PDF) that are individually deposited on
+Zenodo with a DOI. There is no source code, no build system, and no
+runtime component.
 
-## Directory Structure
+## Layout
 
 ```
 .
-├── src/           # Source code
-├── tests/        # Test suites
-├── docs/         # Documentation
-├── scripts/      # Utility scripts
-├── config/       # Configuration files
-├── LICENSE       # License file
-├── LICENSES/     # Full license texts
-└── README.adoc   # Project documentation
+├── README.md              # index of published notes (title, date, DOI)
+├── <note-slug>.md         # note source (Markdown)
+├── <note-slug>.pdf        # rendered note (optional, Typst-produced)
+├── <note-slug>.typ        # Typst source for the PDF (optional)
+├── docs/                  # process documentation (this file's siblings)
+├── LICENSE / LICENSES/    # MPL-2.0 (repo tooling/process docs) +
+│                          #   CC-BY-SA-4.0; individual notes carry
+│                          #   their own licence at Zenodo-deposit time
+└── .github/               # CI wrappers (governance, security scan)
 ```
 
-## Design Principles
-
-- **Separation of Concerns**: Each module has a single responsibility
-- **Testability**: Code is written to be easily testable
-- **Documentation**: All public APIs are documented
-- **Configuration**: Environment-specific settings are externalized
+## The invariant
 
-## Dependencies
+Every note listed in the README resolves to a real, citable Zenodo
+record. If that link breaks, the repo has failed at its one job.
 
-- External dependencies are minimized and clearly declared
-- Version pinning is used for reproducibility
+## Publishing flow
 
-## Security Considerations
+There is no runtime to diagram; the only "flow" is authorial:
 
-- Sensitive data is never committed to the repository
-- Secrets are managed through environment variables or secure vaults
-- Regular dependency audits are performed
+```
+draft note (.md [+ .typ -> .pdf])
+        |
+        v
+   README table entry (title, date, concept DOI, version DOI)
+        |
+        v
+   Zenodo deposit (direct API today; GitHub Release once the
+   Zenodo-GitHub integration is enabled — see README § Zenodo archiving)
+```
 
-## Maintainability
+## Out of scope
 
-- Code follows consistent style guidelines
-- Pull requests require review and CI checks
-- Issues and discussions are tracked transparently
+* No source code, package, or binary is built or shipped from this repo.
+* No API, service, or CLI.
+* No automated test suite — there is no code to exercise.
 
----
+## See also
 
-*Last updated: 2026-07-18*
+* [docs/usage.adoc](docs/usage.adoc) — how to cite a note.
+* [docs/contributing.adoc](docs/contributing.adoc) — how to add a new note.
+* [docs/decisions/](docs/decisions/) — ADRs, historical record of why this shape.

GOVERNANCE.md

@@ -1,60 +1,49 @@
-# Governance
-
-## Overview
-
-This project is governed by the following principles and structures to ensure transparent, inclusive, and effective decision-making.
+<!--
+SPDX-License-Identifier: CC-BY-SA-4.0
+SPDX-FileCopyrightText: 2026 Jonathan D.A. Jewell (hyperpolymath)
+-->
 
-## Roles and Responsibilities
-
-### Maintainers
+# Governance
 
-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
+`technical-notes` is a single-maintainer repository in the
+`hyperpolymath` estate. There is no multi-maintainer or RFC process
+here; estate-wide policy lives in
+[`hyperpolymath/standards`](https://github.com/hyperpolymath/standards).
 
-### Contributors
+## Maintainer
 
-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
+See [`MAINTAINERS`](MAINTAINERS) for who currently maintains this repo.
 
-## Decision Making
+## Decision making
 
-### Minor Changes
-- Can be made by any maintainer
-- Include bug fixes, documentation updates, dependency updates
+The maintainer accepts, revises, or declines contributions directly.
+A non-trivial process change — how notes are drafted, versioned, or
+archived — is recorded as an ADR in
+[`docs/decisions/`](docs/decisions/) rather than decided ad hoc.
 
-### Major Changes
-- Require discussion in issues or pull requests
-- Include new features, architectural changes, API changes
-- Need approval from at least 2 maintainers
+## Licensing
 
-### Breaking Changes
-- Require RFC (Request for Comments) process
-- Need approval from majority of maintainers
-- Must include migration guide
+* Repository tooling and process documentation: MPL-2.0 or
+  CC-BY-SA-4.0 per the SPDX header on each file (see `LICENSE` /
+  `LICENSES/`).
+* Each published note carries its own licence, set at Zenodo-deposit
+  time and recorded in that note's Zenodo metadata (see the root
+  `README.md` § Licence).
 
-## Code of Conduct
+## CI-enforced governance
 
-All participants are expected to follow our Code of Conduct. Violations can be reported to the maintainers.
+SPDX-header presence, licence consistency, secrets scanning, and
+workflow security are enforced by the shared reusable workflow in
+`hyperpolymath/standards`; see
+[`.github/workflows/governance.yml`](.github/workflows/governance.yml)
+and
+[`.github/workflows/hypatia-scan.yml`](.github/workflows/hypatia-scan.yml).
 
 ## 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*
+* **Issues**: bugs or gaps in this repo — broken DOI links, wrong
+  citations, process gaps.
+* **Pull requests**: proposed changes; see
+  [`CONTRIBUTING.md`](CONTRIBUTING.md).
+* **Security**: follow estate policy in `hyperpolymath/standards` —
+  do not file security-relevant findings as public issues.

MAINTAINERS

@@ -1,3 +1,8 @@
+<!--
+SPDX-License-Identifier: CC-BY-SA-4.0
+SPDX-FileCopyrightText: 2026 Jonathan D.A. Jewell (hyperpolymath)
+-->
+
 # Maintainers
 
 This file lists the current maintainers of this project.
@@ -6,38 +11,15 @@ This file lists the current maintainers of this project.
 
 | Name | GitHub | Role | Since |
 |------|--------|------|-------|
-| Metadatastician | @metadatastician | Primary | Project Start |
+| Jonathan D.A. Jewell | [@hyperpolymath](https://github.com/hyperpolymath) | Primary | Project start |
 
 ## Emeritus Maintainers
 
 None at this time.
 
-## Becoming a Maintainer
-
-To become a maintainer:
-
-1. Demonstrate consistent, high-quality contributions
-2. Show understanding of the project's goals and architecture
-3. Be active in code reviews and community discussions
-4. Be nominated by an existing maintainer
-5. Be approved by consensus of existing maintainers
-
-## Maintainer Responsibilities
-
-- Reviewing and merging pull requests
-- Managing releases
-- Triaging issues
-- Enforcing code standards
-- Mentoring new contributors
-- Participating in decision-making
-
-## Maintainer Expectations
-
-- Respond to issues and PRs in a timely manner
-- Follow the code of conduct
-- Be transparent in decision-making
-- Communicate clearly and respectfully
-
----
+## Notes
 
-*Last updated: 2026-07-18*
+This is currently a single-maintainer repository, so there is no
+formal "becoming a maintainer" process. See
+[`GOVERNANCE.md`](GOVERNANCE.md) for how decisions are made and
+[`CONTRIBUTING.md`](CONTRIBUTING.md) for how to propose a change.

docs/architecture.adoc

@@ -1,78 +1,76 @@
 // SPDX-License-Identifier: CC-BY-SA-4.0
 // SPDX-FileCopyrightText: 2026 Jonathan D.A. Jewell (hyperpolymath) <6759885+hyperpolymath@users.noreply.github.com>
 = Architecture — technical-notes
-:revdate: 2026-MM-DD
+:revdate: 2026-07-27
 
 == System overview
 
-One paragraph: what this project does and what it does not do. State the
-*invariant* — the property that, if violated, would make the whole project
-pointless. Future maintainers will read this paragraph first.
+`technical-notes` is a documentation archive, not a running system. It
+holds short, citable technical notes (Markdown, optionally with a Typst
+source and rendered PDF) that are individually deposited on Zenodo with a
+DOI. The invariant that matters: every note listed in the README resolves
+to a real, citable Zenodo record. If that link breaks, the repo has
+failed at its one job.
 
 == Component diagram
 
-Replace this section with an ASCII or Mermaid diagram. Keep it under 20
-lines — anything bigger belongs in `architecture/`.
+There is no runtime component graph. The only "flow" is authorial:
 
 [source]
 ----
-+------------------+      +------------------+
-|   Component A    | ---> |   Component B    |
-+------------------+      +------------------+
-         |
-         v
-+------------------+
-|   Component C    |
-+------------------+
+draft note (.md [+ .typ -> .pdf])
+        |
+        v
+   README table entry (title, date, concept DOI, version DOI)
+        |
+        v
+   Zenodo deposit (direct API today; GitHub Release once the
+   Zenodo-GitHub integration is enabled)
 ----
 
 == Data flow
 
-For each external input, describe:
-
-* **Source**: where it comes from.
-* **Validation**: what guarantees we enforce on entry.
-* **Transformation**: high-level processing stages.
-* **Sink**: where the result goes.
+* **Source**: the maintainer's own drafting — no external input feed.
+* **Validation**: none automated beyond estate governance CI (SPDX
+  headers, licence consistency, secrets scanning — see
+  `.github/workflows/governance.yml` and
+  `.github/workflows/hypatia-scan.yml`).
+* **Transformation**: optional Typst → PDF render for notes that ship one.
+* **Sink**: Zenodo (DOI-bearing deposit) and the README index.
 
 == Key invariants
 
-Enumerate the load-bearing invariants of the system. Each should have:
-
-. A one-line statement.
-. The code location(s) that enforce it.
-. The failure mode if the invariant is violated.
-
-Example:
-
 [cols="1,2,2,2", options="header"]
 |===
 | # | Invariant | Enforced at | Failure mode
 
 | 1
-| All HTTP requests carry a valid `X-Request-ID`.
-| `src/middleware/request_id.rs`
-| Logs become unjoinable; correlation breaks.
+| Every README row has a resolvable DOI link.
+| Manual, at note-publish time.
+| Citation breaks; the note becomes unfindable via its concept DOI.
 
 | 2
-| The output buffer is always flushed before exit.
-| `src/main.rs:88-92` (Drop impl)
-| Last ~16KB of log lost on crash.
+| Every published note's licence matches its Zenodo deposit metadata.
+| `.zenodo.json` for the deposited record; manual cross-check.
+| Licence mismatch between GitHub and the archival copy.
 |===
 
 == Dependencies
 
-* **Internal**: list other hyperpolymath repos this depends on.
-* **External**: SHA-pinned (see `Cargo.lock` / `deno.lock` / etc.).
-* **Build-time**: tools required to build (just, deno, cargo, …).
+* **Internal**: none — this repo does not depend on other hyperpolymath
+  repos.
+* **External**: Zenodo (archival + DOI minting).
+* **Build-time**: none to read a note; Typst only when producing a PDF
+  rendering of a note that has one.
 
 == Out of scope
 
-Explicit non-goals. Things we deliberately do *not* do, with a one-line
-reason for each. This section saves more time than the rest combined.
+* No source code, package, or binary is built or shipped from this repo.
+* No API, service, or CLI — there is nothing to run.
+* No automated test suite — there is no code to exercise.
 
 == See also
 
-* link:./usage.adoc[Usage] — consumer perspective.
-* link:./contributing.adoc[Contributing] — developer setup.
+* link:./usage.adoc[Usage] — how to cite a note.
+* link:./contributing.adoc[Contributing] — how to add a new note.
 * link:./decisions/[ADRs] — historical record of why this shape.