docs(maintainers): refine handbook and remove code of conduct

docs/maintainers/README.md

@@ -36,5 +36,3 @@ Maintainers own the changes they take on, including validation, regression preve
 Important product-direction decisions go through the Product Owner. Maintainers retain responsibility for feasibility, implementation, maintainability, and security.
 
 AI coding or review agents can help collect evidence, test hypotheses, and prepare changes, but they are not the qualified human reviewer required for high-risk changes. A maintainer must inspect and accept the evidence.
-
-Project spaces follow the [Code of Conduct](../../CODE_OF_CONDUCT.md).

docs/maintainers/documentation.md

@@ -16,7 +16,6 @@ Keep root documents easy to find:
 - `README.md`
 - `CONTRIBUTING.md`
 - `SECURITY.md`
-- `CODE_OF_CONDUCT.md`
 
 Not every named directory exists today; do not invent a parallel documentation store just to match this map.
 

docs/maintainers/product-and-features.md

@@ -4,11 +4,15 @@ Pewds is the Product Owner for Odysseus and has final authority over product dir
 
 ## Which changes require product approval?
 
-**Product Owner approval before implementation:** new features and material changes to product direction or behavior.
+**Product Owner approval before implementation:** substantial new features, changes to product direction, and product changes that are hard to reverse.
 
-**No separate product approval by default:** bug fixes, security fixes, maintenance, tests, CI, documentation, and internal refactors, unless they materially change product behavior or direction.
+**No separate product approval by default:** bug fixes, security fixes, maintenance, tests, CI, documentation, internal refactors, and small, reversible product changes within existing direction.
 
-A security or reliability fix that changes behavior should state the user-visible impact and seek product input when its direction is genuinely ambiguous. Urgent containment need not wait if it preserves existing product intent.
+Maintainers may make those smaller product decisions. Pewds can ask for changes or a rollback; the maintainer owns safe rollback or recovery.
+
+### Urgent security and reliability fixes
+
+Urgent fixes or containment may proceed without prior product approval, even if behavior temporarily changes. Keep the change to what stops the immediate problem, notify Pewds promptly, and record the reason and rollback or recovery plan. Agree on any lasting product-direction change with Pewds afterwards. Normal high-risk review and repository checks still apply.
 
 ## Product Owner initiated
 
@@ -25,7 +29,7 @@ A Product Owner proposal is already product-approved; it is not automatically te
 
 ```text
 Feature proposal
-    -> Product Owner accepts / rejects
+    -> Product Owner accepts / rejects, where approval is required
     -> technical feasibility
     -> plan and implementation
     -> risk-based review and validation
@@ -39,4 +43,4 @@ The Product Owner decides **what belongs in Odysseus**. Maintainers decide **how
 
 A rejected or out-of-scope feature can be maintained independently in a contributor's fork.
 
-If the Product Owner is unavailable, new product-direction decisions wait unless that authority was explicitly delegated. Urgent security and reliability corrections that do not redefine product direction may continue under normal review rules.
+If the Product Owner is unavailable, work requiring prior product approval waits unless authority was explicitly delegated. Smaller decisions and urgent fixes follow the rules above.

docs/maintainers/review-playbook.md

@@ -4,8 +4,11 @@ Use this as a **repeatable review method**, not as an extra organizational appro
 
 No single checklist replaces engineering judgment. Increase depth with risk.
 
-## 1. Establish provenance and scope
+## 1. Understand the PR and establish its review gates
 
+- Establish the problem, what the PR fundamentally proposes, and why the approach makes sense.
+- Check product direction, architecture fit, and scope before detailed review.
+- Write down the questions the review must answer, the evidence needed, and what would block further review or approval.
 - Confirm repository, source fork, target branch (`dev`), exact **HEAD SHA**, and current base.
 - Review the full effective diff, commit history, issue, prior feedback, and related upstream changes.
 - Confirm the branch is mergeable against the **current** `dev`, not an older local snapshot.
@@ -40,6 +43,8 @@ For substantive or ambiguous work, ask the contributor or prepare a clearly sepa
 
 ## 4. Build an evidence record
 
+Run contributor code under the [runtime isolation rules](testing-and-releases.md#runtime-isolation).
+
 Useful evidence includes:
 
 - Pre-fix reproduction, expected outcome, and actual outcome.

docs/maintainers/testing-and-releases.md

@@ -4,6 +4,12 @@ Validation must match the actual change, and evidence must state what was **run*
 
 `dev` is the integration and stabilization branch. `main` is the curated release destination. Changes land in `dev`; a release promotes a verified `dev` revision to `main`.
 
+## Runtime isolation
+
+Run contributor-controlled tests, builds, installs, and repros in an isolated, secretless environment. Use disposable containers or microVMs where appropriate, with no credentials, sensitive host files, production data, or host/container-management sockets exposed. If safe isolation is unavailable, record the check as not run.
+
+Agents may use a skill for the maintainer's preferred environment and handling; the same isolation requirements apply.
+
 ## Change validation
 
 - Run focused tests that cover the modified behavior and failure cases.