This section contains material that affects collaboration, version interpretation, and delivery decisions but does not belong to one runtime module. Governance documents define how completion is proven; they do not replace source truth, module runbooks, or release artifacts.
Choose by task
- 01/05
Code Submission Guidelines
BitzOrcas.Modern team code submission standards — branch naming, commit message format, code review checklist, and the complete PR workflow from fork to merge.
- 02/05
Changelog
Major capability and documentation changes that affect developers, adapter authors, and commercial delivery.
- 03/05
Recently updated
Automatically lists manual pages whose lastUpdated date falls in the last 30 days. Do not keep a handwritten ledger.
- 04/05
Delivery status and roadmap
Separate shipped capability, deployment-specific evidence gaps, and future investment without presenting plans as current behavior.
- 05/05
Documentation maintenance and fact calibration
Maintain the bilingual developer manual from source, tests, and delivery evidence so paths, modules, behavior, and release semantics do not drift.
| Page | Purpose |
|---|---|
| Code submission | Branches, commits, pull requests, review, and secret handling |
| Recently updated | Pages whose lastUpdated date falls in the last 30 days |
| Changelog | Major delivery changes backed by evidence |
| Roadmap | Shipped capability, evidence gaps, and future investment |
| Documentation maintenance | Sources of truth, bilingual parity, links, and prose quality |
A roadmap is not a date commitment, and a changelog does not replace Git history or release artifacts. Customer compatibility and delivery promises must be backed by versioned packages, signed artifacts, and GA evidence.
Do not mix five kinds of fact
| Information | Question answered | Primary evidence |
|---|---|---|
| Submission guide | How does a change enter main? | repository rules, branch protection, CI |
| Recently updated | Which manual pages moved lately? | page lastUpdated, build output |
| Changelog | What changed in a released version? | tag, package manifest, SBOM, provenance |
| Roadmap | Why is a future investment worthwhile? | risk, user value, gap inventory |
| Documentation maintenance | How is manual drift prevented? | source sweeps, locale verification, static build |
Verify facts before editing
# Inspect repository rules and current state before treating a plan as fact.sed -n '1,220p' AGENTS.mdgit status --shortgit log -5 --onelineWhen a page names types, configuration keys, or runtime order, locate both declaration and composition in product source. Finding an interface alone does not prove that a production adapter is registered.
Leave reproducible evidence
# Minimum governance loop for the manual repository.npm run verify:docsnpm run verify:docs-sourcenpm run verify:docs-depthnpm run buildgit diff --checkAttach results to the PR or release evidence rather than writing only “tested.” Do not evade failure by lowering page status, deleting links, or relabeling current behavior as a plan.
Escalate the right decision
When source and prose disagree, decide whether the page overstates behavior, implementation is defective, or capability remains planned. Correct overstatement immediately. Record implementation gaps in the knowledge-base architecture backlog with an owner. Use an ADR or formal architecture record for compatibility, data-model, or cross-module boundary decisions.
Definition of done
A governance page is complete only when locales agree, evidence is explicit, examples are copyable, links resolve, and unshipped boundaries are visible. External release still requires Consumer Contract and Commercial GA gates; governance prose is not itself a release certificate.