{
  "markdown": "# Tianheng Foundry\n\nForge declared Rust architecture prose into tested Tianheng reactions.\n\nTianheng Foundry is a portable skill collection for people adopting\n[Tianheng](https://github.com/tacticaldoll/tianheng) in their own Rust projects. It helps an agent\nturn an existing architectural claim into candidate boundary code, prove that the boundary reacts,\nand present the result for human acceptance.\n\nFoundry does not invent policy. The adopter's constitution remains the source of law.\n\n## The Thesis\n\nArchitecture guidance drifts when it exists only as prose. Tianheng makes observable structure\nreact in code; Foundry supplies the guarded reasoning needed to cross from declared prose to that\nreaction:\n\n```mermaid\nflowchart LR\n    claim[\"declared claim\"] --> intent[\"observable intent\"]\n    intent --> candidate[\"boundary candidate\"]\n    candidate --> proofs[\"violating and clean proofs\"]\n    proofs --> acceptance[\"human acceptance\"]\n    acceptance --> context[\"generated context\"]\n    context --> reaction[\"reaction during future work\"]\n```\n\nThe generated code is never accepted merely because an agent wrote it or a test passed. Human\nreview is the authority transition.\n\n## Skills\n\n### `forge-law`\n\nUse when:\n\n- a Rust project already uses Tianheng and contains a declared architecture constraint;\n- a user explicitly asks to adopt Tianheng for one declared constraint; or\n- an agent is about to add normative architecture prose that could instead become a reaction.\n\nThe skill first checks Rust and Tianheng eligibility, then classifies the claim, finds a real\nobservation source, selects a narrow public Tianheng recipe, writes a candidate, and proves both\nteeth and precision.\n\nIt declines non-Rust repositories, generic best-practice invention, subjective claims, and\nconstraints Tianheng cannot observe.\n\nInvoke it explicitly as `$forge-law`, or let a compatible host select it from its description.\n\n### `activate-law`\n\nUse before inspecting or changing code in an already governed Rust workspace. The skill reads the\nadopter's canonical law projection, forms a change envelope, and selects direct and adjacent\ndependency, semantic, runtime, and workspace boundaries into task-local context.\n\nIt is read-only. Uncovered effects remain visible without becoming invented policy, and the\npost-change Tianheng reaction remains the binding verification.\n\nInvoke it explicitly as `$activate-law`, or let a compatible host select it before governed Rust\nwork begins.\n\n### `repair-drift`\n\nUse after an accepted Tianheng boundary reacts to Rust product code. The skill reads the structured\nreaction reason-first, freezes the constitution and baseline, repairs the product code, then reruns\nthe same reaction and repository gates.\n\nIt distinguishes enforced drift from warn-only, baselined, and exit-class `2` states. It refuses\nallowlist widening, severity reduction, baseline additions, and every other attempt to make the\nreaction pass by weakening law.\n\nInvoke it explicitly as `$repair-drift`, or let a compatible host select it from Tianheng check\noutput.\n\n### `amend-law`\n\nUse only when a user explicitly requests a deliberate change to an existing accepted Tianheng\nboundary. The skill snapshots accepted behavior, classifies the change as tighten, loosen,\nretarget, reason correction, or removal, and proves the exact before/after reaction delta.\n\nIt keeps candidate authority separate from acceptance, exposes observation lost by loosening or\nremoval, and refuses vague green-CI authority.\n\nInvoke it explicitly as `$amend-law`, or let a compatible host select it from an explicit\namendment request.\n\n### `review-law`\n\nUse when a candidate diff adds or changes Tianheng boundaries, reasons, baselines, proof fixtures,\nor generated projection. The skill runs sequential authority, observability, reaction, minimality,\nprojection, and compatibility gates.\n\nIt reports findings first and returns `ACCEPT_CANDIDATE`, `REVISE`, or `REJECT`. Even\n`ACCEPT_CANDIDATE` leaves acceptance with the human or steward.\n\nInvoke it explicitly as `$review-law`, or let a compatible host select it from a Tianheng law diff.\n\n### `shape-capability`\n\nUse when an authorized structural Rust claim has no supported Tianheng observation. The skill first\nproves the gap is not an overlooked recipe, compatibility mismatch, non-structural preference, or\ncross-language concern, then shapes an observation contract and fixture matrix.\n\nIt produces upstream-ready capability pressure without writing a no-op adopter boundary or\nimplementing Tianheng.\n\nInvoke it explicitly as `$shape-capability`, or let a compatible host select it from a reported\ncapability-pressure stop.\n\n### `manage-baseline`\n\nUse for an explicitly authorized baseline adoption, refresh, stale prune, annotation update, or\nretirement. The skill compares structured `(target, rule_key, fact)` identities before every write\nand refuses to absorb newly observed drift without separate authority.\n\nIt treats a baseline as accepted-current debt that changes gate outcome, not as law or cleanliness.\n\nInvoke it explicitly as `$manage-baseline`, or let a compatible host select it from a baseline or\nstale-entry request.\n\n## Design\n\n- **Declared intent only.** Existing project prose or direct human instruction supplies authority.\n- **Observation before generation.** No observation source means no boundary.\n- **Proof before replacement.** A violating fixture must react and a clean fixture must remain\n  clean before prose can be retired.\n- **Human authority.** Generated output remains a candidate until reviewed.\n- **Forward reasons.** A boundary reason describes the structure the reaction protects, within its\n  observable perimeter.\n- **Independent repositories.** Foundry references Tianheng's public surface without vendoring it\n  or using git submodules.\n- **Progressive disclosure.** The skill keeps its control flow compact and opens reference material\n  only when the current decision needs it.\n\n## Repository\n\n```text\nskills/*/                  skill entrypoints and focused references\ntests/scenarios/           authority and eligibility policy cases\ntests/repair-scenarios/    reaction routing and law-protection cases\ntests/amendment-scenarios/ amendment authority and proof-direction cases\ntests/activation-scenarios/ task-local law selection and routing cases\ntests/review-scenarios/     adversarial acceptance-gate cases\ntests/capability-scenarios/  observation-gap classification and ownership cases\ntests/baseline-scenarios/    debt-ratchet authority and identity-diff cases\ntests/compatibility/       representative Tianheng consumer fixture\nscripts/                   network-free validation entrypoints\ndocs/                      identity, lifecycle, packaging, and compatibility\ntools/th-foundry-cli/      local multi-host deploy CLI (th-foundry)\n```\n\n`PROJECT.md` records standing decisions and non-goals. `AGENTS.md` is the authoring contract for\ncontributors.\n\n## Install\n\nFor a local Codex marketplace checkout:\n\n```bash\ncodex plugin marketplace add /path/to/tianheng-foundry\ncodex plugin add tianheng-foundry@tianheng-foundry\n```\n\nStart a new Codex thread after installing or refreshing the plugin so skill discovery uses the new\nversion. Claude, Cursor, Gemini, and generic agent distributions use the host manifests already\nchecked into the repository; see `docs/host-packaging.md`.\n\nTo deploy across every local agent host in one step (Claude, Codex, Antigravity, Gemini CLI,\nCopilot CLI, Cline, Cursor, OpenCode — whichever are installed on the machine), use the\n[`th-foundry` CLI](tools/th-foundry-cli/):\n\n```bash\nuv tool install ./tools/th-foundry-cli\nth-foundry deploy --all\n```\n\nUnlike Fornax's own CLI, `th-foundry` deploys from the local checkout rather than a tagged release\n— this project has not cut one yet. See [`tools/th-foundry-cli/README.md`](tools/th-foundry-cli/README.md)\nfor the distinction and the plain `hosts`/`status`/`doctor` commands.\n\n## Validate\n\nThe normal repository gate is:\n\n```bash\npython3 scripts/validate_skills.py\npython3 scripts/test_scenarios.py\npython3 scripts/test_repair_scenarios.py\npython3 scripts/test_amendment_scenarios.py\npython3 scripts/test_activation_scenarios.py\npython3 scripts/test_review_scenarios.py\npython3 scripts/test_capability_scenarios.py\npython3 scripts/test_baseline_scenarios.py\npython3 \"${CODEX_HOME:-$HOME/.codex}/skills/.system/skill-creator/scripts/quick_validate.py\" \\\n  skills/forge-law\npython3 \"${CODEX_HOME:-$HOME/.codex}/skills/.system/plugin-creator/scripts/validate_plugin.py\" .\n```\n\n`.githooks/pre-commit` runs the network-free part of that gate (the first eight commands)\nautomatically before every commit, but git does not wire a repository's own hook directory in by\ndefault. Enable it once per clone:\n\n```bash\ngit config core.hooksPath .githooks\n```\n\nWithout that step the hook file is inert and only CI catches a violation, after push.\n\nTo compile representative generated vocabulary against a local Tianheng checkout:\n\n```bash\nTIANHENG_SOURCE=/path/to/tianheng \\\n  python3 scripts/check_tianheng_compatibility.py\n```\n\nAll repository and scenario checks are network-free. The compatibility runner uses Cargo offline\nafter the selected Tianheng checkout has its dependencies available.\n\n`distribution.json`'s `version` field is the single release-version source. Every other manifest\nand `scripts/validate_skills.py` check against it; bump it there and nowhere else.\n\n## Status\n\nExperimental `0.1.x`. The collection currently contains `forge-law`, `activate-law`,\n`repair-drift`, `amend-law`, `review-law`, `shape-capability`, and `manage-baseline`. Every skill's\n`skill.yaml` declares `status: draft` for this release — that is deliberate, not an oversight:\nnone has yet gone through a documented promotion to `stable`. The initial supported Tianheng line\nis `>=0.5.0,<0.6.0`, with `0.5.0` as the checked representative; wider-range coverage is future\nwork, not claimed here.\n\nWhat's actually enforced, versus what still relies on a human following AGENTS.md:\n\n- **CI-enforced** (`.github/workflows/validate.yml`, on every push and pull request):\n  `scripts/validate_skills.py` (distribution structure, manifest consistency, and the full\n  `skill.yaml` schema) and the seven `scripts/test_*_scenarios.py` suites, plus a separate job that\n  compiles representative generated vocabulary against a real `tianheng@v0.5.0` checkout.\n  `.githooks/pre-commit` runs the same network-free checks locally once a clone enables it with\n  `git config core.hooksPath .githooks` (see Validate above) — CI still catches anyone who hasn't.\n- **Self-policed** (no script fails if skipped): the `skill-creator`/`plugin-creator`\n  `quick_validate.py` and `validate_plugin.py` steps listed above are not wired into CI; and, by\n  design, whether a generated `BoundaryCandidate` should become `AcceptedLaw` is a human review\n  judgment this repository never automates (see `docs/law-lifecycle.md`).\n\n## License\n\nMIT OR Apache-2.0.\n",
  "bytes": 10977,
  "sha": "0af31642d473b3cf1d674fdc58793d60a28385616877ecd800468703fbc49973",
  "repo_slug": "tacticaldoll/tianheng-foundry",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/plg_tacticaldoll_tianheng_foundry_b3a57291/readme"
}