Public project launch preparation

.github/ISSUE_TEMPLATE/bug.yml

@@ -38,4 +38,4 @@ body:
     id: runtime
     attributes:
       label: Runtime
-      placeholder: "Node.js 24, PostgreSQL 17"
+      placeholder: "Node.js 24, PostgreSQL 18"

.github/workflows/check.yml

@@ -12,9 +12,12 @@ permissions:
 jobs:
   check:
     runs-on: ubuntu-latest
+    timeout-minutes: 10
     steps:
       - name: Checkout repository
         uses: actions/checkout@v7
+        with:
+          persist-credentials: false
       - name: Check community files
         shell: bash
         run: |

CONTRIBUTING.md

@@ -1,15 +1,17 @@
 # Contributing
 
-AuthModules is being developed as a collection of focused repositories. Package repositories will be opened independently once their boundaries and first-release implementations are stable.
+AuthModules is a collection of focused public repositories. Each repository owns one package or one ecosystem responsibility.
 
-This repository accepts changes only to the organization profile and shared community health files.
+Open implementation changes in the repository that owns the affected package. Use the central `authmodules` repository for architecture, cross-package contracts, integration behavior, and design discussions. This `.github` repository owns only the organization profile and shared community health files.
 
 ## Before opening a pull request
 
-1. Keep the change limited to organization-wide community files.
-2. Keep repository-facing code, documentation, tests, commits, and pull requests in English.
-3. Add focused regression tests for behavior changes.
-4. Confirm that the community-file workflow passes.
-5. Keep support and security guidance consistent across the shared templates.
+1. Check for an existing issue or discussion when the change affects public behavior or more than one package.
+2. Keep the change within one repository responsibility. Coordinate contract changes with every affected package rather than introducing hidden cross-package coupling.
+3. Keep repository-facing code, documentation, tests, commits, and pull requests in English.
+4. Add focused regression tests for behavior changes and security fixes.
+5. Run the repository's `npm run check` command and include any additional adapter-specific integration check documented by that repository.
+6. Do not include credentials, raw tokens, passwords, OTP values, personal data, private provider responses, or generated build artifacts.
+7. Keep public APIs minimal and backward-compatible. Explain any unavoidable contract change and its ecosystem impact in the pull request.
 
-Package implementation and contract contributions will be accepted in their owning repositories after those repositories are published.
+Report suspected vulnerabilities through the private security-reporting route described in `SECURITY.md`, not through a public issue.

SECURITY.md

@@ -4,10 +4,10 @@
 
 This repository contains organization-wide community files and has no versioned releases. Only its current `main` branch is maintained.
 
-AuthModules packages are still in private pre-release development. Package-specific support policies will be published with their repositories and first releases.
+Package repositories inherit this policy unless they publish a narrower policy. Until then, the latest published package version and the current `main` branch are maintained.
 
 ## Reporting a vulnerability
 
-Use GitHub private vulnerability reporting in the affected public repository. Until package repositories are published, organization-wide reports may be submitted privately through this repository. Do not open a public issue containing exploit details, credentials, tokens, personal data, or provider responses.
+Use GitHub private vulnerability reporting in the affected repository. Organization-wide reports may be submitted privately through this repository. Do not open a public issue containing exploit details, credentials, tokens, personal data, or provider responses.
 
 Include the affected package and version or commit, impact, reproduction conditions, and any suggested mitigation. Reports will be acknowledged and triaged before public disclosure.

SUPPORT.md

@@ -1,5 +1,5 @@
 # Support
 
-Public package support has not opened yet. Support and design channels will be announced with the first package repositories.
+Use the affected package repository's issue tracker for package-specific problems. Use the central `authmodules` Discussions area for cross-package design and usage questions. Check `SECURITY.md` for the supported-version policy.
 
 AuthModules is a library ecosystem, not a hosted authentication service. Operational support for an application's infrastructure, SMTP provider, database, or framework deployment remains with that application and provider.

profile/README.md

@@ -4,7 +4,7 @@ Composable TypeScript building blocks for authentication and identity.
 
 AuthModules is an open-source ecosystem of small, independent packages with explicit boundaries. Applications keep control of policy, user experience, persistence, HTTP composition, and deployment.
 
-> **Project status:** private pre-release development. Package repositories and `0.1.0` releases will appear only after their implementations and contracts are ready for public use.
+> **Project status:** pre-1.0 development. Package availability is determined by published releases; compatibility may change before 1.0.
 
 ## Design principles
 
@@ -20,7 +20,7 @@ AuthModules is an open-source ecosystem of small, independent packages with expl
 
 The ecosystem is being designed around contracts, orchestration, authentication methods, storage, cryptography, session tokens, framework adapters, delivery, guards, compliance tooling, and reliable side-effect processing.
 
-The repositories remain private while these boundaries can still change. No package or version is currently published or supported.
+Pre-1.0 contracts may still evolve. Shared reporting and support routes are defined in [SECURITY.md](../SECURITY.md) and [SUPPORT.md](../SUPPORT.md).
 
 ## Security