P2: establish enterprise OSS governance baseline

.github/CODEOWNERS

@@ -0,0 +1,11 @@
+# Default ownership for this independently released public repository.
+* @tuzuminami
+
+# Security, public contracts, release metadata, and automation require maintainer review.
+/SECURITY.md @tuzuminami
+/package.json @tuzuminami
+/pnpm-lock.yaml @tuzuminami
+/packages/contracts/ @tuzuminami
+/db/migrations/ @tuzuminami
+/.github/ @tuzuminami
+/docs/ @tuzuminami

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,27 @@
+name: Bug report
+description: Report a reproducible public behavior defect.
+title: "bug: "
+labels: [bug]
+body:
+  - type: markdown
+    attributes:
+      value: Do not include credentials, private prompts, production data, or tenant data. Report security concerns through SECURITY.md instead.
+  - type: textarea
+    id: behavior
+    attributes:
+      label: Observed behavior
+      description: Include a minimal public-safe reproduction and expected result.
+    validations:
+      required: true
+  - type: textarea
+    id: environment
+    attributes:
+      label: Version and environment
+      description: Include ASTER version or commit, runtime, and database mode when relevant.
+    validations:
+      required: true
+  - type: textarea
+    id: impact
+    attributes:
+      label: Compatibility and operational impact
+      description: Note tenant, authorization, migration, or service impact if known.

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,5 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Security vulnerability report
+    url: https://github.com/tuzuminami/aster/security/advisories/new
+    about: Use the private security reporting path for vulnerabilities, secrets, or sensitive data exposure.

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,24 @@
+name: Feature request
+description: Propose a public, independently deployable improvement.
+title: "feature: "
+labels: [enhancement]
+body:
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem
+      description: Describe the public user or operator problem without private data or internal strategy.
+    validations:
+      required: true
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposed behavior
+      description: Include API, contract, compatibility, migration, and operational implications.
+    validations:
+      required: true
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternatives and risks
+      description: Include security, tenant isolation, data-handling, or maintenance tradeoffs.

.github/pull_request_template.md

@@ -0,0 +1,35 @@
+## Change
+
+Describe the user-visible or operational behavior changed by this pull request.
+
+## Tracking
+
+- Issue or requirement ID:
+- Release or deployment impact:
+
+## Compatibility
+
+Choose exactly one.
+
+- [ ] No public API, contract, package, or migration impact.
+- [ ] A compatible additive change.
+- [ ] A breaking change with an approved migration and release note.
+
+## Safety and Operations
+
+- [ ] Tenant, authorization, idempotency, and audit behavior were considered where relevant.
+- [ ] No secrets, production data, private prompts, or local-only material are included.
+- [ ] Observability, rollback, and operational impact are documented or not applicable.
+
+## Evidence
+
+- [ ] Tests or other reproducible verification were added or updated.
+- [ ] `pnpm run verify` passed locally.
+- [ ] Documentation and OpenAPI/JSON Schema artifacts remain aligned, when applicable.
+
+## Solo Maintainer Review Record
+
+- Decision rationale:
+- Principal risks considered:
+- Rollback or containment plan:
+- Known follow-up or residual risk:

CONTRIBUTING.md

@@ -19,6 +19,8 @@ pnpm test
 - Add or update tests for success, invalid input, authorization/tenant failure, idempotency, audit, and fail-closed behavior when relevant.
 - Do not include secrets, production data, private prompts, local evidence, private planning files, or machine-specific paths.
 - Run the private-boundary guard before opening the PR.
+- Complete the pull-request template, including compatibility, safety, operational, and verification evidence.
+- Follow the protected-branch and release expectations in `docs/RELEASE_GOVERNANCE.md`.
 
 ## Dependency Policy
 

README.md

@@ -168,6 +168,7 @@ TEST_DATABASE_URL=postgres://aster:aster_dev_password@127.0.0.1:5432/aster pnpm
 
 - See `CONTRIBUTING.md` for development and pull request expectations.
 - See `SECURITY.md` for vulnerability reporting and data-handling expectations.
+- See `docs/RELEASE_GOVERNANCE.md` for ownership, review, branch protection, and release expectations.
 - See `CODE_OF_CONDUCT.md` for participation standards.
 
 ## License

SECURITY.md

@@ -7,7 +7,7 @@ target the default branch while the next release is in development.
 
 ## Reporting a Vulnerability
 
-Do not open a public issue for suspected vulnerabilities, secrets, private prompts, production conversation data, or tenant data.
+Do not open a public issue for suspected vulnerabilities, secrets, private prompts, production conversation data, or tenant data. Use this repository's enabled GitHub private vulnerability reporting path instead.
 
 Send a private report to the repository owner with:
 

docs/RELEASE_GOVERNANCE.md

@@ -0,0 +1,55 @@
+# Release Governance
+
+ASTER is independently versioned and released. This document records the minimum
+GitHub configuration expected for changes to the default branch and published releases.
+
+## Ownership and Review
+
+- `CODEOWNERS` assigns the repository, contracts, migrations, workflows, security policy,
+  and release metadata to the maintainer.
+- Pull requests use the repository template to record compatibility, safety, operational,
+  documentation, and verification evidence.
+- Security vulnerabilities, secrets, production data, and tenant data use the private path
+  in `SECURITY.md`, not public issues or pull requests.
+
+## Default-Branch Protection
+
+Configure an active repository ruleset named `main-pr-ci` for `refs/heads/main`:
+
+- require a pull request before merge, with all review conversations resolved;
+- require the GitHub Actions check named `verify` to pass against the latest
+  target branch commit;
+- block non-fast-forward updates and branch deletion;
+- apply no bypass actor during normal solo-maintainer operation.
+
+ASTER is currently maintained by one account. Do not require approving reviews or
+CODEOWNERS reviews while that remains true: GitHub does not allow an author to approve
+their own pull request, so those settings would block every maintainer change. The
+maintainer records the review rationale in the pull request and requires green `verify` CI.
+For a genuine incident, the owner may use an explicitly audited ruleset bypass only;
+the recovery must be followed by a pull request that restores the protected state.
+
+After a second write-capable maintainer is added, enable these additional protections:
+
+- require one approving review and dismiss stale approvals when new commits are pushed;
+- require review of CODEOWNERS-owned paths;
+- require the same `CI / verify` status check before merge.
+
+## Release Protection
+
+- Create releases from an annotated semantic-version tag after the protected default branch
+  is green. This rule applies to releases created on or after 2026-07-13;
+  the existing lightweight `v1.0.0` tag is a historical exception and is not rewritten.
+- Configure an active `release-tags` ruleset for `refs/tags/v*` that blocks tag
+  updates and deletion. Only create a tag from the verified merge commit.
+- Run `pnpm run verify` and inspect `pnpm pack --dry-run` before creating a tag.
+- Document compatibility, migration, rollback, and known operational limitations in release notes.
+- Keep release automation and provenance implementation in the supply-chain release work;
+  this governance baseline does not publish artifacts automatically.
+
+## Maintainer Evidence
+
+For every release created on or after 2026-07-13, retain the pull request, green CI run URL, review record, tag, release notes,
+and package file list plus SHA-256 evidence in the public repository history. The earlier `v0.1.0` and
+`v1.0.0` releases predate this evidence policy and remain historical exceptions. Do not attach private logs,
+secrets, customer data, or internal planning material.