Prepare contributor docs and PR-only repository governance

.github/CODEOWNERS

@@ -0,0 +1,3 @@
+# Review routing; this file does not itself enforce branch protection.
+# Owners must retain write access. Extend this list as maintainers join.
+* @TemoSulava

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,23 @@
+name: Feature proposal
+description: Discuss a focused improvement before implementation.
+title: "[Feature]: "
+body:
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem
+      description: Who encounters this problem and what are they trying to do? Use synthetic examples; omit private page data.
+    validations:
+      required: true
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposed behavior
+      description: Describe the outcome, alternatives and scope limits. New modules can use the module proposal template.
+    validations:
+      required: true
+  - type: textarea
+    id: validation
+    attributes:
+      label: Validation and implications
+      description: How could we verify this? Note any permission, privacy, dependency or accessibility implications.

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,5 +1,18 @@
-Describe the concrete problem and resulting behavior, with a synthetic before/after example when useful.
+## Problem and change
 
-Validation: commands/counts, loaded-extension or production/visual evidence as relevant. State unrun checks and limitations.
+Describe the concrete problem and resulting behavior, with a synthetic before/after example when useful. Link the issue (for example, `Closes #123`) if applicable.
 
-For contract/lifecycle/permission/dependency changes, link the design/security assessment and full verification evidence. Treat page strings as untrusted; own cleanup and preserve generation/reset semantics. Do not include private browsing data in artifacts. Human validation remains separate.
+## Validation
+
+List commands/results, loaded-extension or production/visual evidence as relevant. State unrun checks and limitations. Human validation remains separate.
+
+## Review checklist
+
+- [ ] Focused change on a topic branch; contribution and conduct policies followed.
+- [ ] Relevant checks passed; documentation and meaningful tests updated when needed.
+- [ ] Scope limits and pending human checks stated accurately.
+- [ ] No secrets or private browsing data in code, reports or artifacts.
+- [ ] Dependency changes assessed per ADR 003, or no dependency changes.
+- [ ] Permission, contract, lifecycle or export changes include design/security assessment and full verification evidence, or are not applicable.
+
+Maintainers: merge only after required CI and review. Do not bypass protection or push directly to main.

.github/main-protection.json

@@ -0,0 +1,21 @@
+{
+  "required_status_checks": {
+    "strict": true,
+    "contexts": ["verify"]
+  },
+  "enforce_admins": true,
+  "required_pull_request_reviews": {
+    "dismiss_stale_reviews": true,
+    "require_code_owner_reviews": true,
+    "required_approving_review_count": 1,
+    "require_last_push_approval": false
+  },
+  "restrictions": null,
+  "required_linear_history": false,
+  "allow_force_pushes": false,
+  "allow_deletions": false,
+  "block_creations": false,
+  "required_conversation_resolution": true,
+  "lock_branch": false,
+  "allow_fork_syncing": false
+}

AGENTS.md

@@ -6,7 +6,7 @@ No backend, telemetry, broad host permissions, remote code, or AI services.
 Use strict message schemas. Treat page strings as untrusted. Never export sensitive values.
 Every effect needs idempotent cleanup. Preserve generation/reset semantics across races.
 Record unsupported scope explicitly. Continue until finished or concretely blocked.
-Push each completed task to the implementation branch, as authorized by the user.
+Work on a topic branch and submit a pull request into main. Never push directly to main.
 Before adding/updating any dependency, inspect official package/version identity, source, lifecycle scripts, integrity/provenance and known advisories. Record the assessment; never disable verification. See docs/decisions/003-dependency-security.md.
-After each completed task, push and use a PR to merge into main, as authorized by the user. Respect required repository checks/reviews. If GitHub API access is externally blocked, record the pending PR/merge and continue independent implementation; retry after configuration changes.
-If PR creation is unavailable, user authorizes direct fast-forward push to main after each completed task. Fetch/check ancestry first; never overwrite unrelated remote changes.
+Respect required repository checks and reviews. If PR creation or merge is blocked, leave the branch and report the blocker; never fall back to a direct push or bypass protections.
+Contributor policy is in CONTRIBUTING.md and maintainer settings are in docs/repository-governance.md. Session-specific authorization does not grant contributors merge or release authority.

CODE_OF_CONDUCT.md

@@ -0,0 +1,11 @@
+# Code of Conduct
+
+AccessLab welcomes contributors of all backgrounds, abilities and experience levels. This policy applies to repository issues, pull requests, reviews and other project spaces, and to interactions while representing the project.
+
+Be respectful and constructive. Critique work rather than people, explain disagreements, respect privacy and communication preferences, and provide accessible text descriptions for visual evidence. Do not demand that someone disclose a disability or personal experience to justify feedback.
+
+Harassment, discriminatory language, threats, sexual attention, personal attacks, deliberate disruption and publishing private information without permission are unacceptable.
+
+The maintainer, [@TemoSulava](https://github.com/TemoSulava), handles reports. Use a private channel you already share with the maintainer. If none is available, open an issue asking for a private contact without naming people or sharing incident details. Do not use vulnerability reporting for conduct complaints. Anyone affected may stop participating or block contact while a report is considered.
+
+Maintainers will consider the context and impact, protect reporter privacy where possible, and may edit or remove content, warn a participant, restrict participation temporarily or permanently, or block an account. There is no promised response time. A report involving the sole maintainer currently has no independent project appeals body; GitHub's abuse reporting remains available for platform violations.

CONTRIBUTING.md

@@ -1,11 +1,47 @@
 # Contributing
 
-Start with README's pinned setup and deterministic demo. Read AGENTS.md, the implementation plan, task ledger and relevant evidence. Work in the existing isolated checkout; no additional worktree is needed. Preserve unrelated changes. Keep fixes small enough to review and include concrete behavior and appropriate validation in a PR.
+## Start here
+
+Read [README.md](README.md), [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md), [AGENTS.md](AGENTS.md) and the relevant architecture, tests and task evidence. Contributions are licensed under this repository's MIT license; retain attribution and third-party notices. Submit only work you have the right to contribute.
+
+Use issues for reproducible bugs, feature proposals and module designs. Ask for design feedback before major changes or selecting optional v0.2 work. Maintainers can label suitable issues `good first issue` or `help wanted`; ask in the issue before starting a large change to avoid duplicate effort. There is no guaranteed review turnaround.
+
+## Fork, branch, pull request
+
+External contributors should fork the repository. Contributors with write access also use topic branches. **Never push directly to `main`, force-push `main`, or bypass review/checks.** See [repository governance](docs/repository-governance.md) for the protection settings and their current activation status.
+
+```sh
+git clone https://github.com/YOUR-USERNAME/AccessLab.git
+cd AccessLab
+git remote add upstream https://github.com/TemoSulava/AccessLab.git
+git fetch upstream
+git switch -c fix/descriptive-name upstream/main
+```
+
+Use README's pinned Node/pnpm versions. Before installing a changed dependency, complete the security assessment below. For the committed baseline:
+
+```sh
+pnpm audit
+pnpm install --frozen-lockfile
+pnpm exec playwright install chromium
+```
+
+On Linux, browser libraries may require `pnpm exec playwright install --with-deps chromium`. Preserve unrelated local changes. Use short, descriptive commits and keep the PR focused on one problem. Push to your fork with `git push -u origin HEAD`, then open a PR targeting `TemoSulava/AccessLab:main`. Use a draft PR for work in progress. Changes requested in review belong on the same topic branch; do not create a replacement PR just to evade feedback.
+
+Fill in the PR template with the trigger, resulting behavior, validation and limitations. A maintainer reviews and merges after CI and conversations are resolved. Automated tools must follow the same PR rules; failed PR creation is a blocker, never permission to push directly to main. Release publication requires separate maintainer authorization.
+
+## Implementation rules
 
 Use the public module contract and local registry: follow docs/module-author.md and templates/. Modules must validate unknown configuration, own every effect, handle AbortSignal, clean up idempotently, and tolerate disconnected targets. Keep audit violations, manual review and inspection heuristics separate. Test meaningful behavior against synthetic fixtures; never capture credentials or real personal page data into test artifacts.
 
 No remote module loading, telemetry, backend, broad permissions, page code execution, synthetic clicking on arbitrary host pages or unsupported compliance/disability claims. Treat page strings as untrusted; use text rendering and strict schemas. Document scope limits and failures instead of silently reducing coverage. Ask maintainers for design review before permission, API, export-schema or arbitrary-page manipulation changes.
 
-Before adding/updating dependencies, inspect official identity, exact version, repository, lifecycle scripts, integrity/provenance and advisories; record in ADR 003 and keep a frozen lockfile. No check guarantees absence of compromise. Reuse existing packages or platform APIs when suitable. Run pnpm verify for shared contracts/lifecycle changes and milestones; run relevant subsets for isolated changes. Package and inspect production manifest when changing runtime permissions/builds.
+## Dependencies and verification
+
+Before adding/updating dependencies, inspect official identity, exact version, repository, lifecycle scripts, integrity/provenance and advisories; record in [ADR 003](docs/decisions/003-dependency-security.md) or linked PR evidence and keep a frozen lockfile. No check guarantees absence of compromise. Reuse existing packages or platform APIs when suitable. Do not disable integrity checks, signatures, TLS validation or security checks to make an install pass.
+
+Run `pnpm verify` for shared contracts/lifecycle changes and milestones; run relevant subsets for isolated changes. Package with `pnpm package` and inspect the production manifest when changing runtime permissions/builds. See [docs/testing.md](docs/testing.md) for meaningful unit, component, loaded-extension and visual tests. Documentation-only changes should verify links and examples; CI still runs the complete suite. State checks you could not run. Do not update visual expectations simply to hide a regression.
+
+CI uses standard GitHub-hosted Linux runners and pinned official actions. No paid Marketplace action, larger runner or external paid service is required. Keep tokens read-only and never expose secrets to fork code. Discuss CI changes with the maintainer.
 
-Describe the trigger, behavior change, tests and limitations in the PR. Human checks stay explicitly pending until a named evaluator records results. Do not publish a release or make broad accessibility claims based on automated gates alone. The user-authorized task completion helper pushes a task branch and waits for CI before merging via PR; contributors should follow their repository review rules instead of assuming that session-specific authorization applies to them.
+Human checks stay explicitly pending until a named evaluator records results. Do not publish a release or make broad accessibility claims based on automated gates alone. Use [SECURITY.md](SECURITY.md) for private vulnerability reports; issues and PRs must contain only synthetic, shareable data.

README.md

@@ -36,6 +36,10 @@ Verification runs lint, types, unit/component tests, production build, loaded-ex
 
 ## Scope and contribution
 
+Contributions are welcome through pull requests into `main`. Fork the repository, work on a topic branch, and follow [CONTRIBUTING.md](CONTRIBUTING.md). Start with a focused bug fix, documentation improvement or fixture test; discuss new modules and permission changes in an issue first. Maintainers review contributions before merging. Direct pushes to `main` are prohibited by project policy; see [repository governance](docs/repository-governance.md) for the enforcement setup and current access limitation.
+
+Please follow our [Code of Conduct](CODE_OF_CONDUCT.md). Use [bug reports](https://github.com/TemoSulava/AccessLab/issues/new?template=bug_report.yml) or [feature proposals](https://github.com/TemoSulava/AccessLab/issues/new?template=feature_request.yml); report vulnerabilities privately using [SECURITY.md](SECURITY.md).
+
 Top document and discoverable open shadow roots; no iframe/closed-shadow coverage. Audit budget is 5,000 elements / 1,000 interactive targets; oversized documents fail explicitly before the engine can block the page. Previews require a static region ≤500 elements. Rendering approximations do not reproduce lived experience. No accounts, backend, telemetry, remote scans or all-site permission.
 
 Read [privacy/scope](docs/privacy-and-scope.md), [architecture](docs/architecture.md), [module tutorial](docs/module-author.md), [test guide](docs/testing.md), [contribution guide](CONTRIBUTING.md), [security policy](SECURITY.md) and [task evidence](docs/tasks/status.json). Optional v0.2 pointer sandbox requires explicit selection and is outside this v0.1 build.

docs/repository-governance.md

@@ -0,0 +1,50 @@
+# Repository governance
+
+## Policy and activation status
+
+All changes to `main` go through a pull request, passing CI and maintainer review. This applies to collaborators, maintainers and automated agents. There is no direct-push fallback. CODEOWNERS routes review to `@TemoSulava`; ownership alone does not enforce review or block pushes.
+
+On 2026-10-08, GitHub reported this public repository's `main` as unprotected and its ruleset list as empty. The current integration returns HTTP 403 (`Resource not accessible by integration`) for branch protection administration. The committed configuration is ready, but enforcement must be enabled by an owner using Repository Settings or an appropriately scoped credential. Until then, GitHub does not technically block collaborators with write access from pushing directly; project policy still prohibits it. Keep external contributors on forks and grant write access sparingly.
+
+## Enable free built-in protection
+
+Public repositories can use these branch protections on GitHub Free. No Marketplace app, paid plan or custom Action is needed. In **Settings → Branches → Add branch protection rule**, target `main` and enable:
+
+- Require a pull request before merging, with one approving review and code-owner approval.
+- Dismiss stale approvals when new commits are pushed.
+- Require status check `verify` from **Verify and package**, and require the branch to be up to date before merging.
+- Require conversations to be resolved.
+- Do not allow bypassing the above settings (including administrators).
+- Keep force pushes and branch deletions disabled.
+
+Do not add a bypass actor or require the external GitGuardian check. The existing security app is not a dependency of the contributor workflow. GitHub does not let an author approve their own PR: maintainer-authored PRs need another eligible code owner. Add trusted maintainers with write access to CODEOWNERS as the team grows. Do not temporarily weaken protection to merge your own PR.
+
+Alternatively, from the repository root, an owner with repository Administration write permission can apply the reviewed configuration:
+
+```sh
+gh api --method PUT repos/TemoSulava/AccessLab/branches/main/protection \
+  --input .github/main-protection.json
+gh api repos/TemoSulava/AccessLab/branches/main/protection
+gh api repos/TemoSulava/AccessLab/branches/main --jq '{name, protected}'
+```
+
+The PUT replaces classic protection for this branch. Review any existing settings first rather than overwriting stronger rules. Confirm the required check, review settings, administrator enforcement and disabled force pushes/deletion in the response. A committed JSON file is not proof that protection is active. Once applied, update this activation-status section with the verified result. Admins can still edit settings; periodically inspect protection and collaborator access.
+
+## CI without paid services
+
+The repository is public and `.github/workflows/verify.yml` uses standard `ubuntu-24.04` runners, which GitHub provides free for public repositories. All four actions are SHA-pinned official actions (`actions/checkout`, `pnpm/action-setup`, `actions/setup-node`, `actions/upload-artifact`). No paid Marketplace action, larger runner, deployment service or new dependency is introduced. GitHub artifact storage has separate quotas; retain the current short retention periods and do not enable paid overages. Reassess quotas before making the repository private.
+
+In **Settings → Actions → General**:
+
+- Allow only the official actions used by the workflow (including `pnpm/action-setup`) and require full SHA pinning if that setting is available.
+- Set default workflow token permissions to read repository contents; disable workflows creating/approving PRs.
+- Require approval for all outside collaborators' fork workflow runs. Review the workflow diff before approving; never approve blindly.
+- Do not send secrets or write tokens to fork PRs. Keep `pull_request`, read-only job permissions, and `persist-credentials: false`; do not introduce `pull_request_target` execution of PR code.
+
+Owner-only settings are not stored in workflow YAML. The integration also returns 403 for Actions settings; verify them in the UI. Required `verify` must run for every PR, including docs changes: do not add path filters that leave required checks pending. CI success supports review; it does not establish human accessibility validation.
+
+## Maintainer review
+
+Review the problem, scope, privacy/permissions, effect cleanup, meaningful tests, dependency assessments and documentation. Resolve feedback before merging and retain the audit trail in the PR. Give contributors specific, respectful requests. A reviewed security or dependency change may need additional design discussion. Releases remain separate from PR merges and must follow the release checklist.
+
+Enable GitHub private vulnerability reporting in **Settings → Security** if available, and verify the private reporting link in SECURITY.md. Use Issues for public, synthetic bug reports and feature/module proposals. Use the Code of Conduct for participation expectations; avoid collecting personal disability or browsing data in project artifacts.