docs: add contributor safety and governance training

CANDIDATE.md

@@ -1,5 +1,9 @@
 # Candidate Instructions
 
+## Required orientation
+
+Before beginning the exercise, read [`CONTRIBUTOR_SAFETY_AND_GOVERNANCE.md`](./CONTRIBUTOR_SAFETY_AND_GOVERNANCE.md). Completing this technical exercise does not itself grant employment, Playtester status, repository ownership, canon authority, or access to live systems or private evidence.
+
 ## Objective
 
 Implement the standalone TypeScript systems exercise in this repository. The exercise is a training proxy for architectural skills used by Loptr Lab; it is not the canonical Veiled Dominion game engine.
@@ -82,3 +86,4 @@ npm test
 - [ ] Functional and class APIs share one rules model
 - [ ] Additional reaction uses the extension framework
 - [ ] `NOTES.md` contains honest design analysis and test output
+- [ ] Contributor-safety orientation completed before any live-project access

CONTRIBUTOR_SAFETY_AND_GOVERNANCE.md

@@ -0,0 +1,72 @@
+# Contributor Safety and Governance
+
+## Purpose
+
+This module prepares candidates to collaborate safely before they receive access to a live project, community, or production system. It is general training. It does not reproduce private case evidence or turn a real person into a training subject.
+
+Technical skill does not replace professional consent, rights clearance, accessibility review, or least-privilege access.
+
+## Before collaboration begins
+
+1. Verify the person or organization, relevant credits, references, and authority over the proposed work.
+2. Put the scope, responsible contact, timeline, compensation, approvals, attribution, ownership, and permitted portfolio use in writing.
+3. Identify every third-party name, likeness, character, brand, recording, image, clip, dataset, or other protected asset.
+4. Define communication and conduct boundaries, including sexual-harassment, privacy, surveillance, retaliation, and emergency-escalation expectations.
+5. Begin with a small, reversible assignment and an explicit end date.
+6. Record who may approve, publish, modify, remove, or retain the work.
+
+Public enthusiasm, private conversation, tags, reposts, speculative ideas, or audience access do not by themselves establish a partnership.
+
+## Staged access
+
+A prospective contributor starts as a time-limited candidate with access only to onboarding material, a sandbox, and the work required for the assignment.
+
+Do not grant a candidate:
+
+- repository ownership or branch-protection control;
+- deployment, billing, store, analytics, or production credentials;
+- Discord administration or access to private safety, supporter, legal, or payment channels;
+- customer records, addresses, private reports, unpublished case evidence, or unrelated source files.
+
+Expanded access requires a named sponsor, written scope, least-privilege review, and expiration date. When work ends, revoke roles, teams, tokens, shared-drive permissions, scheduling access, and third-party integrations.
+
+## Safe exit terms
+
+A written agreement should distinguish:
+
+- **Termination clause:** when and how either party may end the relationship.
+- **Kill fee:** payment still owed when commissioned work is cancelled.
+- **Immediate termination:** conduct that permits prompt disengagement, such as threats, sexual misconduct, retaliation, surveillance, credential misuse, or serious confidentiality violations.
+- **Post-termination duties:** payment, return or deletion of material, credential revocation, attribution, portfolio use, takedown responsibilities, and evidence preservation.
+
+Templates are educational starting points, not legal advice. Obtain qualified review for actual agreements.
+
+## Variant and creative-work gate
+
+Before proposing a Veiled Dominion variant:
+
+1. Read the engine repository's [variant workflow](https://github.com/Loptr-Lab/veiled-dominion-engine/blob/main/docs/VARIANT_CREATION_WORKFLOW.md).
+2. Start from the [variant template](https://github.com/Loptr-Lab/veiled-dominion-engine/blob/main/docs/variants/VARIANT_TEMPLATE.md).
+3. Review the original [Dread Pressure example](https://github.com/Loptr-Lab/veiled-dominion-engine/blob/main/docs/variants/examples/DREAD_PRESSURE.md).
+4. Declare source type, implementation status, rules authority, commercial-use status, accessibility review, and rights review.
+5. Keep third-party-inspired material separate from reusable original expression.
+6. Do not treat documentation, a prototype, a playtest, or repository inclusion as acceptance into canon.
+
+The engine repository is authoritative for variant workflow, classification, and promotion decisions. [Engine PR #38](https://github.com/Loptr-Lab/veiled-dominion-engine/pull/38) preserves the governance change history.
+
+## Candidate checkpoint
+
+Before receiving a scoped live-project task, a candidate should be able to:
+
+- distinguish informal promotion from contracted collaboration;
+- identify when a rights or accessibility review is required;
+- explain least-privilege access and demonstrate a revocation plan;
+- distinguish a termination clause from a kill fee;
+- document assumptions and disagreements without altering evaluation contracts;
+- explain why payment does not automatically grant Playtester status, canon authority, employment, or production access.
+
+## Reporting and records
+
+Document observable conduct and technical facts separately from interpretation. Preserve relevant records privately, minimize personal data, and use the appropriate platform, safety, legal, or emergency channel. Do not publish allegations, explicit material, residential details, or private evidence in a repository.
+
+The permanent technical record belongs in GitHub. Sensitive evidence does not.

README.md

@@ -96,12 +96,13 @@ This exercise is the hands-on centerpiece of **Track A: Prototype Engineer** bel
 ### Phase 0: Foundations (all tracks, ~1 week)
 
 - Read **[`THE_THRESHOLD.md`](./THE_THRESHOLD.md)** first — the world, its philosophy, and why "restraint over conquest" and "myth is undecoded science" are the two ideas everything else here has to serve
+- Complete **[`CONTRIBUTOR_SAFETY_AND_GOVERNANCE.md`](./CONTRIBUTOR_SAFETY_AND_GOVERNANCE.md)** before receiving live-project, community, or production access
 - **GitHub & Git Prerequisite:** If you are new to GitHub workflows, complete the official **[GitHub Skills Tutorial](https://learn.github.com/skills)** to practice branching, commits, and pull requests in a sandbox environment.
 - Study the core game rules (see the engine repo's `RULEBOOK_v0.1`) well enough to explain them without notes
 - Understand the turn/phase loop architecture at a conceptual level
 - If working in a team: playtest the tabletop version with 3–4 people before writing code
 
-**Checkpoint:** you can explain the core rules and diagram the turn loop from memory.
+**Checkpoint:** you can explain the core rules and diagram the turn loop from memory; distinguish informal promotion from contracted collaboration; identify rights and accessibility gates; and describe a least-privilege access and revocation plan.
 
 ### Track A: Prototype Engineer (this repo, ~4 weeks)
 
@@ -148,6 +149,8 @@ Finishing this exercise well is a real, gradable signal — see `REVIEWER_SCOREC
 - **Engine repo:** [github.com/Loptr-Lab/veiled-dominion-engine](https://github.com/Loptr-Lab/veiled-dominion-engine) — the real game
 - **Full game design doc:** `docs/design/GDD.md` in the engine repo
 - **Accessibility engineering specs:** `docs/ENGINE_ACCESSIBILITY_A11Y_PARADOX.md` and `docs/ENGINE_ACCESSIBILITY_AUDIO_AURA.md` in the engine repo
+- **Contributor safety:** [`CONTRIBUTOR_SAFETY_AND_GOVERNANCE.md`](./CONTRIBUTOR_SAFETY_AND_GOVERNANCE.md) — consent, vetting, staged access, exit terms, and variant review gates
+- **Variant governance:** [workflow](https://github.com/Loptr-Lab/veiled-dominion-engine/blob/main/docs/VARIANT_CREATION_WORKFLOW.md), [template](https://github.com/Loptr-Lab/veiled-dominion-engine/blob/main/docs/variants/VARIANT_TEMPLATE.md), and [worked example](https://github.com/Loptr-Lab/veiled-dominion-engine/blob/main/docs/variants/examples/DREAD_PRESSURE.md) in the engine repository
 
 ## Contact
 

RESEARCH_AND_CANON_BOUNDARY.md

@@ -38,6 +38,12 @@ Use the analytic loop:
 - Do not silently convert training abstractions into canonical mechanics.
 - Do not copy narrative adaptations or experimental Duet behavior into this exercise as though they were canonical rules.
 - Link authoritative game documentation instead of duplicating or paraphrasing rules when precision matters.
+- Keep collaborator-safety training general and reusable; do not copy private allegations, explicit material, residential details, or identifiable case evidence into this repository.
+- Treat the engine repository as authority for variant status, rights gates, accessibility review, and canon promotion.
+
+## Contributor governance boundary
+
+This repository may teach consent, collaborator vetting, least-privilege access, revocation planning, and safe exit terms through [`CONTRIBUTOR_SAFETY_AND_GOVERNANCE.md`](./CONTRIBUTOR_SAFETY_AND_GOVERNANCE.md). It does not adjudicate personal disputes, store private evidence, grant production access, or authorize third-party intellectual property.
 
 ## Canonical principle