[codex] Bootstrap public TelosZero main docs

.github/CODEOWNERS

@@ -0,0 +1 @@
+* @telosnetwork/telos-core-devs

CONTRIBUTING.md

@@ -0,0 +1,39 @@
+# Contributing
+
+Contributions should go through pull requests against `main` or a documented
+release branch.
+
+## Development Rules
+
+- Keep changes narrowly scoped.
+- Preserve upstream attribution when incorporating external patches.
+- Do not make consensus or storage-format changes without a design note.
+- Keep `nodeos`, `cleos`, and `keosd` compatibility unless a release plan says
+  otherwise.
+- Update packaging and operator docs when behavior affects installation,
+  upgrades, or runtime configuration.
+
+## Commit And PR Expectations
+
+Pull requests should include:
+
+- a short summary
+- compatibility impact
+- tests run
+- upstream or Community Edition references, if any
+
+For backports or incorporated upstream patches, include the source commit or PR
+URL in the PR description.
+
+## Local Verification
+
+At minimum, run syntax checks before opening a PR when touching the relevant
+files:
+
+```bash
+bash -n tools/tweak-deb.sh
+sh -n scripts/postinst
+sh -n scripts/prerm
+perl -c tools/pinned.pl
+python3 -m py_compile tests/TestHarness/Node.py tests/TestHarness/queries.py tests/TestHarness/testUtils.py tests/cli_test.py
+```

GOVERNANCE.md

@@ -0,0 +1,51 @@
+# Governance
+
+TelosZero Core is maintained under the TelosNetwork GitHub organization.
+
+## Project Stewardship
+
+Maintainers should prioritize:
+
+- preserving upstream history and attribution
+- keeping runtime behavior compatible unless a change is explicitly reviewed as
+  a protocol change
+- documenting licensing, patch, build, and release provenance
+- replacing inherited CI, release, and signing infrastructure with Telos-owned
+  equivalents
+- publishing clear operator guidance for every production release
+
+## Maintainer Authority
+
+Maintainers are responsible for reviewing code, release artifacts, security
+updates, and public communications. No single maintainer should be the only
+person able to merge, release, or administer the repository.
+
+The initial code owner team is `@telosnetwork/telos-core-devs`.
+
+## Branch Policy
+
+`main` is the development branch and should not be used directly in production.
+
+Production release branches use the `release/*-teloszero` naming pattern.
+Release branches require:
+
+- a documented release plan
+- passing CI for build and test targets selected for that release
+- maintainer approval
+- documented artifact integrity checks
+- upgrade and rollback notes for node operators
+
+## Protocol Changes
+
+Consensus, serialization, database format, protocol feature, and network
+compatibility changes require an explicit design note before implementation.
+The design note should state expected compatibility, activation requirements,
+test coverage, and operator impact.
+
+## Upstream And Community Edition Changes
+
+`AntelopeIO/spring` is tracked as `upstream`. Spring Community Edition may be
+tracked as `ce` as a reference source for legal/process cues and useful
+patches. Changes from either source should be reviewed and merged
+intentionally; bulk imports should be avoided unless they are part of a
+documented release sync.

LEGAL.md

@@ -0,0 +1,45 @@
+# Legal And Licensing Notes
+
+This repository is the TelosNetwork-maintained continuation of
+`AntelopeIO/spring`.
+
+## License Provenance
+
+The repository includes the upstream Spring `main` license update commit that
+changed Spring to MIT terms:
+
+```text
+e6a99f68b67abc4d89fe716755b2e1394a4991f7
+```
+
+Existing upstream copyright notices are preserved.
+
+## Stable 1.2 Release Line
+
+The TelosZero stable 1.2 release branch is based on upstream Spring `v1.2.2`:
+
+```text
+04bdb089edc790507d96ff52f41cc781fb3fa0f3
+```
+
+That branch carries TelosZero release packaging, Telos genesis materials, and a
+documented set of selected post-1.2.2 Spring fixes.
+
+## Older Branches And Tags
+
+Historical Spring branches and tags are preserved for auditability. Some older
+release branches and tags may contain different license terms. TelosZero
+production binaries should be published only from branches whose base and
+license provenance are documented.
+
+## Community Edition
+
+Spring Community Edition may be used as a reference source for process cues and
+candidate patches. TelosZero Core does not inherit Community Edition package
+renames or release tags unless maintainers explicitly merge those changes.
+
+## Trademarks
+
+TelosZero maintainers should avoid implying endorsement by upstream Spring,
+AntelopeIO, EOS Network Foundation, Vaulta Foundation, or other projects unless
+that endorsement has been explicitly granted.

MAINTAINERS.md

@@ -0,0 +1,30 @@
+# Maintainers
+
+Initial code ownership is assigned to:
+
+- `@telosnetwork/telos-core-devs`
+
+## Maintainer Expectations
+
+Maintainers should:
+
+- review protocol-affecting changes with extra care
+- preserve attribution when incorporating upstream Spring or Community Edition
+  work
+- keep package and release provenance clear
+- avoid force-pushing shared branches
+- use pull requests for changes intended for `main` or release branches
+- keep branch protection, release access, and security reporting monitored
+
+## Release Roles
+
+Each production release should identify:
+
+- release owner
+- build/reproducibility verifier
+- test verifier
+- security reviewer
+- operator communications owner
+
+Release signing keys and recovery procedures should be documented before
+TelosZero release artifacts are described as signed.

PATCHES.md

@@ -0,0 +1,26 @@
+# Patch Provenance
+
+This file records notable upstream Spring or Spring Community Edition patches
+incorporated by TelosZero maintainers outside of normal upstream merges.
+
+## Stable 1.2 Release Line
+
+The TelosZero `release/1.2-teloszero` branch incorporates selected post-1.2.2
+Spring fixes for reproducibility, build compatibility, test stability, and
+runtime stability. The release branch remains the authoritative source for the
+exact commits included in the `teloszero-v1.2.2` release.
+
+Meaningful upstream patch sources for that release include:
+
+- AntelopeIO/spring#1742 - initialize the atomic `timer_state_t`
+- AntelopeIO/spring#1841 - validate the pinned Debian package repository
+- AntelopeIO/spring#1845 - validate LLVM and CMake tarball hashes
+- AntelopeIO/spring#1873 - improve block/producer-round test logic
+- AntelopeIO/spring#1875 - avoid undefined behavior in WASM injection
+- AntelopeIO/spring#1876 - wait for block 2 in CLI tests
+- AntelopeIO/spring#1877 - support multi-threaded subprocess log writes
+- AntelopeIO/spring#1879 - signal block processing if sync is interrupted
+- AntelopeIO/spring#1881 - avoid OC interrupts during replay
+
+Larger behavior changes should be reviewed in their own TelosZero pull requests
+before landing on `main` or a release branch.