diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
new file mode 100644
index 0000000..a12b633
--- /dev/null
+++ b/.github/CODEOWNERS
@@ -0,0 +1,3 @@
+# Default ownership for repository changes.
+# Keep this file aligned with the maintainers who can review security and release changes.
+* @eimyroot
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..c69eb97
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,28 @@
+# Contributing to APPLAYLIST
+
+Thank you for helping improve APPLAYLIST. Keep changes focused, reviewable, tested, and reversible.
+
+## Workflow
+
+1. Open or reference an issue for material behavior changes.
+2. Create a focused branch from the repository's default branch.
+3. Make the smallest complete change that solves the stated problem.
+4. Add or update tests and documentation.
+5. Run the repository's documented verification commands.
+6. Open a pull request and include risk, evidence, and rollback notes.
+
+## Pull request standard
+
+A pull request must state:
+
+- what changed and why;
+- what was intentionally left out;
+- verification commands and results;
+- security, compatibility, data, and operational risks;
+- rollback or safe-disable procedure.
+
+Do not commit secrets, personal data, generated runtime state, local databases, or unverifiable claims. A green check proves only the scope exercised by that check.
+
+## Governance
+
+Maintainer review is required. Security-sensitive, release, authorization, persistence, billing, and production-effect changes require explicit owner approval and must fail closed when required evidence is missing.
diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 0000000..e6d263e
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,23 @@
+# Security Policy
+
+## Supported scope
+
+Security fixes are maintained on the current default branch while APPLAYLIST remains pre-release. Repository visibility or a passing CI run is not a production-readiness guarantee.
+
+## Reporting a vulnerability
+
+Do not disclose vulnerabilities, credentials, personal data, private URLs, or exploit details in public issues or pull requests. Use GitHub private vulnerability reporting when enabled. If it is unavailable, open a public issue requesting a private contact without including sensitive details.
+
+Include the affected revision, component, prerequisites, minimal reproduction, impact, expected safe behavior, and a suggested mitigation when known.
+
+## Security baseline
+
+- never commit credentials or production data;
+- keep privileged decisions and authorization server-side;
+- apply least privilege and deny-by-default behavior;
+- validate untrusted input and bound resource use;
+- preserve auditable evidence without logging secrets;
+- treat missing or unverifiable security evidence as a failure, not success;
+- rotate exposed credentials even if the committed file is later removed.
+
+No response-time or remediation SLA is promised while the project remains pre-release.