docs: reconcile organization governance and maturity

CODE_OF_CONDUCT.md

@@ -0,0 +1,29 @@
+# CoreLink Code of Conduct
+
+CoreLink Platform is developed in a professional, technical community. Participation in repositories, issues, pull requests, discussions, reviews, and project spaces requires respectful and constructive behavior.
+
+## Expected behavior
+
+- Focus criticism on ideas, code, interfaces, evidence, and outcomes rather than people.
+- Use clear, professional language and assume good-faith technical disagreement unless evidence shows otherwise.
+- Respect privacy, security boundaries, customer confidentiality, and contributor consent.
+- Give actionable review feedback and distinguish blocking defects from preferences.
+- Correct mistakes transparently and update stale claims when repository evidence changes.
+
+## Unacceptable behavior
+
+Harassment, threats, discrimination, sexualized conduct, doxxing, deliberate disclosure of private information, sustained personal attacks, spam, and attempts to bypass security or authorization controls are not acceptable.
+
+## Scope
+
+This policy applies to CoreLink-managed GitHub spaces and to project-related interactions where a participant is representing CoreLink.
+
+## Reporting
+
+For conduct concerns, use a private channel available to the CoreLink maintainers rather than a public issue when disclosure could harm a participant. Security vulnerabilities must follow `SECURITY.md` and must not be reported through public issues.
+
+## Enforcement
+
+Maintainers may edit or remove inappropriate content, restrict participation, close conversations, or escalate repeated/severe incidents. Enforcement decisions should be proportionate, documented where appropriate, and avoid exposing private reporter information.
+
+This project may adopt a more formal community enforcement process as the contributor community grows.

CONTRIBUTING.md

@@ -1,87 +1,60 @@
 # Contributing to CoreLink Platform
 
-Thank you for your interest in contributing to CoreLink Platform.
-
-This document describes the contribution process shared by public repositories in the CoreLinkPlatform organization.
+Thank you for contributing to CoreLink Platform. CoreLink is managed as one product with multiple implementation and release boundaries.
 
 ## Before contributing
 
-Before opening a pull request:
-
 1. Search existing issues and pull requests.
 2. Confirm that the change belongs in the selected repository.
-3. Open an issue before implementing major features or public API changes.
-4. Avoid exposing private infrastructure, internal hostnames, customer information, credentials, or implementation-specific provider details.
+3. For material product, architecture, security, or public-contract changes, link the relevant Product Epic or open a design issue first.
+4. Do not expose private infrastructure, internal hostnames, customer information, credentials, or implementation-specific provider details in public surfaces.
+5. Update documentation whenever behavior, compatibility, maturity, or supported operations change.
 
 ## Repository responsibilities
 
-- `api-contracts`: API, event, webhook, and schema contracts
-- `developer-docs`: tutorials, guides, concepts, and API documentation
-- `sdk-typescript`: TypeScript, Node.js, React, and Next.js SDKs
-- `sdk-python`: Python SDK
-- `sdk-java`: Java and Spring integrations
-- `examples`: runnable integration examples
-- `cli`: CoreLink command-line interface
-- `mcp-server`: Model Context Protocol integrations
-- `mock-server`: API simulation and local development
+- `platform`: private CoreLink runtime and operational implementation.
+- `Console`: hosted SaaS console. The capitalized name is an existing naming exception retained to avoid release/link churn.
+- `api-contracts`: public/admin/internal API, event, webhook, and schema contracts.
+- `developer-docs`: tutorials, guides, concepts, reference, and developer operations documentation.
+- `sdk-typescript`: TypeScript client.
+- `sdk-python`: Python client.
+- `sdk-java`: future Java/Spring client; currently Scaffold.
+- `cli`: future developer/operator CLI; currently Scaffold.
+- `mcp-server`: future MCP integration boundary; currently Scaffold.
+- `mock-server`: future contract-driven local/CI simulation; currently Scaffold.
+- `website`: public product website and developer discovery surface.
+- `product-planning`: product hierarchy, cross-repository Epics, milestone gates, risks, and acceptance decisions.
+- `.github`: organization governance, community health, maturity, contribution, security, and shared templates.
+
+The archived `demo-repository` is not an active product boundary. There is currently no standalone `examples` repository; runnable examples belong in the repository that owns them or in `developer-docs` until an examples repository is deliberately created.
 
 ## Public terminology
 
-Public interfaces must use capability-oriented and implementation-independent terminology.
-
-Use terms such as:
-
-- Device Registry
-- Device Gateway
-- Fleet Engine
-- IoT Runtime
-- Telemetry Pipeline
-- Command Gateway
-- Provisioning Engine
-- Digital Twin Service
-- Integration Adapter
-- Identity Provider
-
-Do not expose internal provider, vendor, product, infrastructure, or deployment names in:
-
-- public APIs;
-- schemas;
-- SDK types;
-- package names;
-- examples;
-- documentation;
-- error codes;
-- telemetry fields;
-- MCP tools and resources.
+Public interfaces must be capability-oriented and implementation-independent. Prefer CoreLink-owned concepts such as Device Registry, Device Gateway, Telemetry Pipeline, Command Gateway, Provisioning Engine, Integration Adapter, and Identity Provider.
+
+Do not expose provider-specific models, credentials, identifiers, package names, error codes, or payload fields as CoreLink public contracts.
 
 ## API and schema changes
 
-Changes to public contracts must:
+Public-contract changes must:
 
-- preserve stable operation identifiers;
-- include request and response examples;
-- define error responses;
-- document authentication and authorization requirements;
-- include compatibility impact;
-- update the changelog;
-- pass contract linting and breaking-change checks.
+- preserve stable operation identifiers where compatibility requires it;
+- include request/response examples;
+- define error responses and auth requirements;
+- document compatibility impact;
+- update the changelog/version metadata;
+- pass contract linting and breaking-change checks;
+- reconcile affected SDKs, docs, Console behavior, mock/MCP/CLI consumers, and release notes.
 
-Breaking changes require an approved proposal and a versioning plan.
+Breaking changes require an approved versioning and migration decision.
 
 ## Pull requests
 
-Pull requests should:
-
-- address one logical change;
-- include tests where applicable;
-- update documentation;
-- avoid unrelated formatting changes;
-- use clear commit messages;
-- include compatibility and security considerations.
+Pull requests should address one logical change, include tests where applicable, update documentation, avoid unrelated formatting churn, identify compatibility/security implications, and link the owning Issue/Epic when one exists.
 
 ## Commit style
 
-Use concise imperative commit messages:
+Use concise imperative Conventional Commit-style messages where practical:
 
 ```text
 feat: add device command schema
@@ -90,10 +63,14 @@ docs: document client credentials flow
 chore: update contract validation workflow
 ```
 
-## Development status
+## Maturity and support claims
+
+Use the organization maturity vocabulary: **Scaffold, Experimental, Alpha, Beta, Stable, Deprecated, Planned**. A merged feature, generated package, public repository, or release tag does not by itself establish Stable support. Check `REPOSITORY_MATURITY.md` and the owning repository's release evidence.
+
+## Security
 
-The project is under active development. APIs and SDKs may change until the first stable release.
+Security vulnerabilities must follow `SECURITY.md` and must not be disclosed in public issues or pull requests.
 
 ## License
 
-By contributing, you agree that your contributions will be licensed under the license declared by the target repository.
+By contributing, you agree that contributions are governed by the license declared by the target repository. Public visibility does not imply an open-source license.

README.md

@@ -1,27 +1,28 @@
 # CoreLink GitHub Community Health
 
-Repository-wide community-health and contribution assets for CoreLink
-repositories.
+Organization-wide governance and community-health assets for CoreLink repositories.
 
 ## Contents
 
-- `CONTRIBUTING.md`: contribution expectations.
-- `CODE_OF_CONDUCT.md`: community behavior policy.
-- `SECURITY.md`: vulnerability-reporting policy.
-- `GOVERNANCE.md`: project governance.
-- `ISSUE_TEMPLATE/`: organization-wide bug, feature, implementation, Product Epic and documentation forms.
-- `PULL_REQUEST_TEMPLATE.md`: pull-request checklist.
-- `profile/README.md`: organization profile shown on GitHub.
-- `REPOSITORY_MATURITY.md`: reconciled repository roles and maturity claims.
+- `CONTRIBUTING.md` — contribution expectations and repository responsibility map.
+- `CODE_OF_CONDUCT.md` — community behavior and enforcement baseline.
+- `SECURITY.md` — private vulnerability-reporting policy.
+- `SUPPORT.md` — support routing and maturity expectations.
+- `GOVERNANCE.md` — project decision model.
+- `RELEASE_POLICY.md` — shared maturity, provenance, compatibility and release rules.
+- `ISSUE_TEMPLATE/` — organization-wide issue forms.
+- `PULL_REQUEST_TEMPLATE.md` — pull-request checklist.
+- `profile/README.md` — organization profile shown on GitHub.
+- `REPOSITORY_MATURITY.md` — reconciled active-repository roles and maturity claims.
 
-## Usage
+## Source-of-truth boundaries
 
-GitHub applies these files automatically only when this repository is named
-`.github` at the organization level. If it is intentionally named `github` in
-local development, copy or sync the reviewed files to the organization's
-special `.github` repository before relying on GitHub to display or enforce
-them.
+- Product hierarchy, Epics, milestone gates, risks and acceptance decisions: `product-planning`.
+- Organization policy and maturity: `.github`.
+- Machine-readable API/event contracts and compatibility: `api-contracts`.
+- Human-facing developer guidance: `developer-docs`.
+- Repository-specific implementation/deployment details: the owning repository.
 
-Product Epics are owned by `product-planning`; executable Features/Tasks stay in the repository that implements them and link to exactly one primary Product Epic. Repository-local templates may narrow these defaults but must preserve that hierarchy.\n\nPlatform changes must also follow the architecture rules in the `platform`
-repository, including tenant isolation, upstream-adapter boundaries, audit and
-documentation review.
+Product Epics are owned by `product-planning`; executable Features/Tasks stay in the repository that implements them and link to a primary Product Epic. Repository-local templates may narrow these defaults but must preserve that hierarchy.
+
+Platform changes must also follow architecture, tenant-isolation, adapter-boundary, audit and evidence rules documented by the `platform` repository.

RELEASE_POLICY.md

@@ -0,0 +1,42 @@
+# CoreLink Release Policy
+
+CoreLink is one product with multiple release boundaries. Runtime, contracts, Console, SDKs, tools, documentation, and the website may have separate artifacts, but supported claims must reconcile through one product maturity model.
+
+## Maturity
+
+Use: **Scaffold, Experimental, Alpha, Beta, Stable, Deprecated, Planned**.
+
+A tag or package publication does not by itself establish support. Supported releases require the owning repository's release gate plus compatible contract, security, documentation, and operational evidence.
+
+## Version provenance
+
+Released artifacts should identify immutable source and dependency revisions. Generated SDKs and contract consumers must identify the exact contract tag/revision used. Branch names are not release provenance.
+
+## Release contents
+
+Where applicable, a release should include:
+
+- version/tag and immutable commit SHA;
+- maturity classification;
+- compatible contract/runtime/tool versions;
+- release notes and known limitations;
+- build/package provenance and SBOM when supported by the release workflow;
+- deployment/install instructions;
+- migration and rollback guidance;
+- security/support implications.
+
+## Breaking changes
+
+Breaking public-contract changes require an explicit major-version/migration decision. Consumer releases must not silently drift from normative contracts.
+
+## Pre-release channels
+
+Alpha/Beta/RC artifacts must be labeled as prerelease and must not be described as Stable. Scaffold repositories must not publish installation instructions that imply a supported artifact exists.
+
+## Product acceptance
+
+Engineering completion, CI success, deployment success, and Product Acceptance are distinct. Product milestone acceptance remains owned by `product-planning` and must be backed by retained evidence appropriate to that milestone.
+
+## Cross-repository reconciliation
+
+A release or maturity change should update affected compatibility matrices, developer docs, repository README/status text, organization maturity/profile, and website claims in the same change set or link explicit follow-up work.