Complete user-account public entry and governance boundaries

.github/workflows/community-health-invariants.yml

@@ -0,0 +1,28 @@
+name: Community Health Invariants
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    branches:
+      - main
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+jobs:
+  validate-community-health:
+    runs-on: ubuntu-24.04
+    steps:
+      - name: Checkout
+        uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262
+
+      - name: Setup Node
+        uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020
+        with:
+          node-version: '20.11.0'
+
+      - name: Validate shared community-health invariants
+        run: node scripts/validate-community-health.mjs

CONTRIBUTING.md

@@ -2,48 +2,80 @@
 
 This document describes how to contribute to Riverbraid public repositories.
 
-It is a community health surface only. It does not create governance authority, maintainer capacity, guaranteed response times, legal approval, certification, production readiness, or external validation.
+It is a community-health surface only. It does not create governance authority, maintainer capacity, guaranteed response times, legal approval, certification, production readiness, or external validation.
 
 ## Contribution posture
 
 Riverbraid prioritizes bounded, inspectable, evidence-preserving changes.
 
 Preferred contributions are:
 
-- Documentation corrections
-- Claim boundary fixes
-- Reproduction notes
-- Verification failure reports
-- Surface coherence improvements
-- Small, reviewable pull requests
-- Issues that separate observed facts from interpretation
+- documentation corrections;
+- claim-boundary fixes;
+- reproduction notes;
+- verification-failure reports;
+- surface-coherence improvements;
+- small, reviewable pull requests;
+- issues that separate observed facts from interpretation.
+
+## Read before contributing
+
+Review the shared policies that apply where the receiving repository does not provide a narrower rule:
+
+- `GOVERNANCE.md` — authority and disposition;
+- `MAINTAINERS.md` — current authority map;
+- `INBOUND_CONTRIBUTION_RIGHTS.md` — contributor rights and licensing representations;
+- `PULL_REQUEST_TEMPLATE.md` — change, evidence, and claim-boundary fields;
+- `SECURITY.md` — sensitive reporting route;
+- `SUPPORT.md` — issue routing;
+- `FORKING.md` — provenance and authority for adaptations;
+- `SUPPORTED_VERSIONS.md` — source-bound support posture;
+- `RELEASE_AND_COMPATIBILITY.md` — release, comparison, and compatibility rules.
+
+Repository-specific guidance governs within its declared scope.
 
 ## Before opening a pull request
 
 Check whether the change affects:
 
-- Protocol semantics
-- Verification commands
-- Registry entries
-- Workflow behavior
-- Hashes or seals
-- Public claims
-- Repository lifecycle status
+- protocol semantics;
+- verification commands, expected results, or verification depth;
+- registry entries, pins, manifests, or source identities;
+- workflow behavior or action identity;
+- dependencies, environments, locks, or network behavior;
+- schemas, machine contracts, or comparison contracts;
+- hashes, seals, evidence, or provenance;
+- public claims or nonclaims;
+- governance, authority, or maintainer scope;
+- security, privacy, access, or disclosure;
+- repository lifecycle, release, compatibility, or supersession status;
+- the proposed F0–F4 control package.
+
+If it touches any of those, clearly state the exact impact and required authority in the pull request body.
 
-If it touches any of those, clearly state the impact in the pull request body.
+Use `PULL_REQUEST_TEMPLATE.md` where GitHub applies the shared account default.
 
 ## Pull request scope
 
-Use small pull requests with a clear scope.
+Use small pull requests with a clear subject and boundary.
 
 A good pull request states:
 
-- What changed
-- Why it changed
-- What did not change
-- Whether code, workflow, registry, verifier, hash, seal, or protocol behavior changed
+- what changed;
+- why it changed;
+- the exact base and proposed subject;
+- what did not change;
+- tests and observations performed;
+- negative, blocked, unavailable, malformed, or degraded cases;
+- evidence not yet available;
+- supported and refused claims;
+- authority or further disposition required;
+- whether code, workflow, registry, verifier, schema, environment, hash, seal, authority, or protocol behavior changed;
+- rollback, supersession, recovery, and re-entry notes where material.
+
+Do not delete a template section merely because a result is inconvenient. Use `NOT_APPLICABLE` with a short reason when appropriate.
 
-## Suggested pull request boundary block
+## Suggested boundary block
 
 ```text
 Scope:
@@ -54,28 +86,76 @@ No registry changes.
 No verifier changes.
 No hash or seal changes.
 No protocol changes.
+No adoption or gate advancement.
 ```
 
-Adjust this block if the pull request actually changes one of those surfaces.
+Adjust the block when the pull request actually changes one of those surfaces.
+
+## Evidence rule
+
+A successful check applies only to the exact source, configuration, commands, environment, and verification depth observed.
+
+Do not present:
+
+- file presence as execution;
+- execution as correctness;
+- self-execution as independent reproduction;
+- one component pass as an integrated or account-wide pass;
+- a historical result as automatically current;
+- a merge as adoption or F0–F4 gate advancement.
+
+When a technical claim is made, preserve an attributable command, source identity, environment, result, and limitation record sufficient for review.
+
+## Inbound rights and licensing
+
+`INBOUND_CONTRIBUTION_RIGHTS.md` is the shared policy candidate for authorship, licensing, third-party material, generated content, provenance, and acceptance boundaries.
+
+Its current posture is:
+
+- no separate Contributor License Agreement is required by default;
+- no Developer Certificate of Origin sign-off is required by default;
+- contributors must have the right to submit their material;
+- accepted contributions are provided under the target repository's applicable license unless that repository declares a narrower policy;
+- third-party and materially tool-generated inputs must be disclosed where relevant;
+- submission or merge does not transfer Riverbraid governance or maintainer authority.
+
+If the target repository has no clear license, or the contribution cannot be distributed under that license, stop and open a licensing issue before submitting the change.
+
+This policy is not legal advice or a completed legal review.
 
 ## Issues
 
 Use issues for:
 
-- Reproduction failures
-- Documentation mismatch
-- Inconsistent metadata
-- Broken links
-- Verification ambiguity
-- Claim boundary problems
-- Public surface coherence issues
+- reproduction failures;
+- documentation mismatch;
+- inconsistent metadata;
+- broken links;
+- verification ambiguity;
+- claim-boundary problems;
+- public-surface coherence issues;
+- licensing or provenance uncertainty;
+- bounded compatibility or lifecycle questions;
+- requests for a private security-reporting route without sensitive details.
+
+Do not publish vulnerability details, credentials, secrets, private keys, personal data, or unredacted exploit information in public issues. Follow `SECURITY.md`.
+
+## Governance and forks
+
+A contribution does not adopt the F0–F4 control package, advance a gate, refresh the Evaluation Kit registry, establish independent review, appoint a maintainer, or transfer protocol or release authority unless the required attributable authority and evidence are present.
 
 ## Conduct
 
 Contributions should be factual, bounded, and respectful.
 
-Do not use issues or pull requests to imply unsupported maturity, adoption, certification, legal approval, production readiness, external audit, complete AI safety, absolute security, or absence of defects.
+Do not use issues or pull requests to imply unsupported maturity, adoption, certification, legal approval, production readiness, external audit, complete AI safety, absolute security, full-constellation operation, or absence of defects.
+
+## Acceptance boundary
+
+Submission does not guarantee review, acceptance, support, attribution format, or response time.
+
+A merge does not automatically appoint the contributor as a maintainer, transfer registry or protocol authority, establish independent review, or support claims beyond the evidence actually reviewed.
 
 ## Boundary
 
-This guide does not guarantee review, acceptance, support availability, response time, or maintenance capacity.
+This guide does not guarantee review, acceptance, support availability, response time, maintenance capacity, legal sufficiency, compatibility, security coverage, or future project direction.

FORKING.md

@@ -0,0 +1,78 @@
+# Forking and Adaptation Policy
+
+Riverbraid repositories may be forked and adapted under each repository's applicable license.
+
+## Core rule
+
+A fork inherits source history and license obligations. It does **not** automatically inherit Riverbraid authority, identity, registry membership, verification results, adoption state, endorsement, or evidence continuity.
+
+## Required distinctions
+
+A public fork or adaptation should state:
+
+- upstream repository and exact source commit;
+- fork or adaptation name;
+- files and behavior changed;
+- whether upstream tests were rerun;
+- whether new tests or evidence exist;
+- which upstream claims still apply unchanged;
+- which claims are no longer applicable;
+- who now owns maintenance and security response;
+- whether the fork remains compatible with any Riverbraid profile.
+
+## Naming and presentation
+
+A fork may accurately say that it is derived from Riverbraid.
+
+It must not imply that it is:
+
+- the canonical Riverbraid repository;
+- an adopted Riverbraid profile;
+- included in the Evaluation Kit registry;
+- verified by upstream results after material changes;
+- maintained, approved, endorsed, certified, or audited by Riverbraid;
+- entitled to use upstream evidence as proof of changed bytes or behavior.
+
+Materially divergent adaptations should use a distinct name and prominent provenance statement.
+
+## Evidence continuity
+
+Upstream evidence remains attributable only to the exact upstream subject it assessed.
+
+After a fork changes code, configuration, dependencies, workflows, registry entries, environment locks, expected results, schemas, hashes, seals, or claim boundaries, the fork must create new evidence for those changed surfaces.
+
+Copying an evidence file does not transfer the truth of the evidence to a new subject.
+
+## Registry and profile relationship
+
+A fork is not part of the Riverbraid Evaluation Kit registry or any future F3/F4 functional core unless an authorized process explicitly admits and pins it.
+
+Compatibility may be claimed only at the tested level and under the observed environment.
+
+## Security and support
+
+Fork maintainers are responsible for their own:
+
+- security reporting route;
+- dependency and workflow review;
+- releases and tags;
+- incident response;
+- legal and compliance decisions;
+- user support;
+- claim boundaries.
+
+Riverbraid does not guarantee support for forks or adaptations.
+
+## Contribution back upstream
+
+Changes proposed upstream should be submitted as small, reviewable pull requests that preserve provenance and disclose:
+
+- the fork commit where the change originated;
+- the upstream base;
+- tests performed;
+- evidence and limitations;
+- any license or third-party contribution considerations.
+
+## F0–F4 boundary
+
+Forking, copying, or publishing the proposed F0–F4 control package does not adopt or execute it. Adoption and gate advancement remain subject to the authority and evidence rules of the applicable control records.