git:20260801.c86e9a8 to git:20260907.0cfcd93

31 added, 76 removed. Audit A to A.

---
name: mathodology-dev-test-release
- description: Use when validating the Mathodology skills-only repository or preserving archived knowledge about the former development, testing, deployment, packaging, and release workflows.
+ description: Use when checking skill metadata, references or repository boundaries, or preparing an explicitly requested skills release.
---
- # Mathodology Dev Test Release Archive
-
- ## Scope
-
- This branch is skills-only. Its active validation checks are skill, metadata, link, backup, and tracked-file whitelist checks.
-
- The former application build, CI, Docker, native service, packaging, installer, and release files are not present on this branch. Treat those workflows as archived knowledge unless recovered from Git history.
-
- ## Active Workflow Validation
-
- For award-level modeling workflows, this skill owns final gates rather than application builds:
-
- - phase log exists and covers Phases 0-8
- - every prompt requirement maps to a paper section or package file
- - every reported number maps to code, data, derivation, or documented manual calculation
- - every phase has specialist handoffs, lead synthesis, and an independent critic gate
- - all blocker and high-severity critic findings are fixed before final packaging
- - model selection considers at least three routes with rejection reasons for alternatives
- - sensitivity or robustness evidence exists for important assumptions and key results
- - final paper, editable source if required, code, data notes, figures, tables, README, AI-use statement, and checklist are present
- - no local caches, secrets, raw scratch files, or unrelated artifacts are in the final package
-
- Codex should run these gates with a dedicated critic or packaging agent.
-
- Claude Code should run `mathodology-submission-packager` and then `mathodology-critic`.
-
- ## Active Validation
+ # Mathodology Repository Checks
- Shared repository validation lives in ONE place: `scripts/validate_repo.py`
- (pure standard library, no PyYAML). Do not re-inline these checks as heredocs in
- docs or other skills; add or change a gate in the script.
+ Repository maintenance checks are optional utilities; they do not run during
+ modeling by default and cannot establish mathematical or editorial quality.
- Run every maintenance gate from the repository root:
+ From a repository checkout, run:
```bash
python3 .claude/skills/mathodology-dev-test-release/scripts/validate_repo.py all
```
- Run one gate by naming it: `skills`, `metadata`, `links`, `whitelist`, `agents`,
- `sync`, `evidence`, `updater`, or `selftest`. The script prints per-check `PASS`/`FAIL` lines and exits
- non-zero on any failure.
-
- - `skills` / `metadata`: every `.claude/skills/*/SKILL.md` frontmatter (name ==
- dir, lowercase-hyphen, `Use when` description) and every `agents/openai.yaml`
- default prompt mentioning `$<dirname>`.
- - `links`: relative markdown links, inline `.claude/...` paths, and
- `mathodology-<x>` name references in tracked docs resolve.
- - `whitelist`: only skills-repository files are tracked.
- - `agents`: every `.claude/agents/*.md` frontmatter (name == stem, description,
- tools, and any `model` in opus/sonnet/haiku/inherit).
- - `sync`: each en/zh doc twin agrees on heading and code-block counts, and
- command-significant code is identical.
- - `evidence`: the project search MCP enables staged downloads; the evidence agent
- loads both discovery channels and the evidence skill; skill, agent, and workflow
- retain the combined-mode contract; manual Claude/Codex commands enable download.
- - `updater`: the transactional project updater is executable, exposes its required
- CLI and rollback contracts, and every public update surface uses one canonical
- bootstrap instead of the retired shell pipeline.
- - `selftest`: proves each checker can both pass and fail on tempdir fixtures and
- runs the updater's offline drift, rollback, and installer-cleanup tests.
-
- From a global skill install, run `scripts/validate_repo.py` from this skill's
- directory instead of the repo-relative path.
-
- ## Backup Check
-
- Create and verify a skills-only backup:
-
- ```bash
- bash .claude/skills/mathodology-whole-project/scripts/create-source-backup.sh
- ```
-
- Then check the printed backup directory:
+ The standard-library checker covers skill/role metadata, local Markdown links,
+ known skill references and allowed repository paths. Individual commands are
+ `metadata`, `links`, `boundary` and `selftest`. It supports a source export without
+ Git; in a checkout it also inspects tracked paths. It does not enforce document
+ heading counts, search wording, updater contracts or contest run schemas.
- ```bash
- shasum -a 256 -c SHA256SUMS
- tar -tzf mathodology-skills-<timestamp>.tar.gz | rg '^(AGENTS\.md|\.claude/skills/)'
- tar -tzf mathodology-skills-<timestamp>.tar.gz | rg '^(apps/|crates/|packages/|scripts/|config/|installer/|tests/|data/|\.github/)'
- ```
+ When changing a utility, exercise its actual behavior. The figure demonstration
+ script and PDF overview utility have self-tests; backup can be verified by
+ extracting the archive and checking its checksum. Read
+ [backup and installation guidance](../mathodology-whole-project/SKILL.md).
- The last command should produce no matches.
+ When changing prompts, review representative user scenarios and inspect generated
+ figures. Do not add tests that simply restate prompt sentences. Do not report
+ that a prompt guarantees consistent future model behavior.
- ## Archived Dev And Release Knowledge
+ ## Explicitly requested releases
- The former project used a multi-language application stack with service builds, contract generation, tests, deployment files, and release packaging. Those files were removed from the current branch.
+ Release work is repository maintenance, separate from the modeling guidance.
+ Inspect the current remote branch, recent releases and existing tags. Choose the
+ next version consistently with that history and describe migration requirements
+ when removing an old entry point or utility. Do not invent a package manifest,
+ application build or CI pipeline for this skills pack.
- If the user needs to rebuild or audit those workflows, first recover the relevant historical tree in a separate branch or worktree. Do not treat old commands as valid gates in the skills-only checkout.
+ Review the actual changes, run relevant checks and verify retained asset licenses.
+ Use a focused branch and pull request when that matches repository practice.
+ Respect branch protections; do not bypass required reviews or checks. Once the
+ authorized changes are merged, tag that exact commit and publish the requested
+ release with concise changes, migration notes and truthful validation results.
+ Never move an existing release tag to a different commit. Verify the published
+ tag and release point to the intended source. GitHub's source archives are enough
+ unless the user requests additional artifacts.