Publish junior-friendly and architect-ready contribution guide

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,44 @@
+name: Bug or accessibility fix
+description: Report a reproducible problem and propose a useful correction.
+title: "[Fix] "
+labels: []
+body:
+  - type: markdown
+    attributes:
+      value: "Describe the issue with evidence and a constructive next step. Do not include secrets, medical records, or private correspondence."
+  - type: input
+    id: location
+    attributes:
+      label: Page or file
+      description: Provide a public URL or repository path.
+      placeholder: docs/index.html
+    validations:
+      required: true
+  - type: textarea
+    id: actual
+    attributes:
+      label: What is wrong?
+      description: Observed behavior, reproduction steps, device or browser if relevant.
+    validations:
+      required: true
+  - type: textarea
+    id: expected
+    attributes:
+      label: Expected behavior and impact
+      description: Explain which task is blocked, confusing, or inaccessible.
+    validations:
+      required: true
+  - type: textarea
+    id: fix
+    attributes:
+      label: Suggested fix or next test
+      description: Provide a patch, minimal example, or concrete investigation path. A fix is welcome but not mandatory for safety or security concerns.
+    validations:
+      required: true
+  - type: checkboxes
+    id: privacy
+    attributes:
+      label: Public sharing
+      options:
+        - label: I removed private identifiers, credentials, and sensitive records.
+          required: true

.github/ISSUE_TEMPLATE/improvement.yml

@@ -0,0 +1,38 @@
+name: Scoped improvement
+description: Suggest a small, testable documentation, code, or architecture improvement.
+title: "[Improve] "
+labels: []
+body:
+  - type: input
+    id: target
+    attributes:
+      label: Area to improve
+      placeholder: Career tracks, accessibility, technology planning, or another path
+    validations:
+      required: true
+  - type: textarea
+    id: problem
+    attributes:
+      label: User need or technical problem
+      description: What task is affected? Include evidence or a source where possible.
+    validations:
+      required: true
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposed change and acceptance criteria
+      description: What should change, and how would we know it works?
+    validations:
+      required: true
+  - type: textarea
+    id: boundaries
+    attributes:
+      label: Risks, accessibility, dependencies, and assumptions
+      description: Distinguish confirmed facts from proposals and unverified items.
+  - type: checkboxes
+    id: privacy
+    attributes:
+      label: Public sharing
+      options:
+        - label: No personal identifiers, private evidence, secrets, or unauthorized assets are included.
+          required: true

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,25 @@
+## What did you fix or improve?
+
+Briefly explain the user-facing problem, affected pages/files, and the actual change. Link an issue if one exists.
+
+## Evidence and testing
+
+- Tested environment (browser, device, local preview or other):
+- Reproduction or acceptance criteria:
+- Internal links and path checks:
+- Keyboard, zoom/reflow, and assistive-technology checks (if relevant):
+- Not tested / unverified:
+
+## Risks and scope
+
+Note dependencies, deployment implications, migration/rollback needs, and whether this changes accessibility, privacy, governance, licensing, or source-of-truth content.
+
+## Contributor checklist
+
+- [ ] This PR is focused and makes a concrete improvement.
+- [ ] I preserved or explained the relationship between source Markdown and rendered HTML.
+- [ ] I have not claimed tests, approval, deployment, or funding eligibility that were not verified.
+- [ ] I have not committed credentials, personal records, confidential evidence, or unauthorized assets.
+- [ ] I have read [CONTRIBUTING.md](../CONTRIBUTING.md) and [contributor safety and governance](../CONTRIBUTOR_SAFETY_AND_GOVERNANCE.md).
+
+Constructive technical disagreement is welcome. Please describe evidence and an actionable path forward; avoid personal judgments.

CONTRIBUTING.md

@@ -0,0 +1,58 @@
+# Contribute to Loptr Lab Training
+
+**Build in public. Improve the work. Show the fix.**
+
+Loptr Lab welcomes first-time developers, experienced engineers, accessibility reviewers, technical writers, and systems architects. You do **not** need an invitation, a personal email address, or access to production systems to participate in this public repository. A GitHub account is sufficient to propose changes.
+
+We value direct, technically rigorous feedback. Criticism of code and architecture is welcome **when it is actionable and respectful**. Personal put-downs, dismissive speculation, and repetitive negative comments without evidence or a path forward do not help the project. You do not have to implement every fix yourself: a reproducible issue, failing test, minimal example, or specific patch proposal is valuable.
+
+## Your first contribution — junior developers
+
+1. Read the [README](README.md), [contributor safety and governance](CONTRIBUTOR_SAFETY_AND_GOVERNANCE.md), and the [training guide](docs/index.html).
+2. Browse [open issues](https://github.com/Loptr-Lab/training/issues). Look for `good first issue`, `documentation`, or `accessibility` labels **if available**. If none exist, open an issue with one clearly scoped improvement.
+3. Select a small change: fix a broken link, improve a confusing instruction, correct mobile reflow, add a missing label, or repair a reproducible defect.
+4. Fork this repository on GitHub; create a descriptive branch in your fork.
+5. Edit the source. For HTML pages in `docs/`, check page titles, shared CSS, relative links, mobile widths, keyboard navigation, and visible focus. Keep source Markdown and styled HTML consistent when both are present.
+6. Preview the changed HTML using a local static server or a trusted preview of your own fork. GitHub's source viewer is **not** a rendered-site preview. The public site is [Loptr Lab Training](https://loptr-lab.github.io/training/); it reflects the published branch, not your unmerged changes.
+7. Open a pull request against `Loptr-Lab/training:main`. Explain what changed, why, how you tested it, and any limitations. Screenshots are optional; never include private data.
+8. Respond to review notes. A maintainer decides whether and when a change merges.
+
+**No computer?** You can open an issue, inspect files, and propose documentation edits through GitHub's mobile web interface. You do not need an elaborate local toolchain for your first docs improvement.
+
+## Senior engineers and architects
+
+Skip the introductory steps if you know the workflow. Please contribute **verifiable engineering work**, not drive-by verdicts.
+
+- State the defect or design risk, affected files/routes, reproduction steps, expected versus actual behavior, and impact.
+- Propose the smallest safe correction, a testable alternative, or a scoped design issue. For significant architecture changes, discuss interfaces, failure modes, migration and rollback paths before replacing working systems.
+- Preserve the work-led, accessibility-first information architecture. Do not substitute a favorite framework, hardware vendor, or stack without demonstrating a need.
+- Avoid unrequested rewrites, dependency churn, speculative claims about deployment, or hidden changes to governance.
+- Demonstrate outcomes with tests, source links, screenshots when useful, and a clear distinction between validated, proposed, and unverified work.
+
+**Good review:** “At 320px, the comparison table overflows and hides the second column. Reproduce in Safari; I propose a scrollable table wrapper and a focus-visible cue, with the viewport test attached.”
+
+**Not useful:** “This site is terrible. Rewrite everything.”
+
+## The contribution contract
+
+- **Privacy by default.** Use public GitHub issues and pull requests; don't collect personal email, health details, case files, benefits identifiers, passwords, private correspondence, or credentials. Never paste secrets into issues or logs.
+- **Accessibility is a requirement.** Check semantic headings, text reflow, focus order, keyboard operation, assistive-technology labeling, contrast, and reduced-motion needs when relevant. Say explicitly what you did and did not test.
+- **Be constructive, not unquestioning.** You may disagree strongly with a proposal or report a safety problem without providing code. Include evidence, impact, and an actionable next step when possible. Safety, harassment, privacy, and security concerns may be reported without publishing sensitive details or a public proof of concept.
+- **Consent and scope.** Contributions are public proposals, not invitations to production access, paid employment, ownership, or official representation. Current open review work is voluntary and unpaid. Agree in writing before any scoped collaboration on time, boundaries, public disclosure, attribution, and exit arrangements. Paid work requires a separate agreement.
+- **Maintainer review is final for this repository.** A PR is not a guarantee of acceptance, deployment, affiliation, or publication. Keep disagreements about the implementation rather than the person.
+- **Respect licenses and rights.** Submit only work you have permission to contribute. Do not add third-party assets, recordings, branding, or private case evidence without documented authorization.
+
+## What makes a useful issue?
+
+Use the issue templates. Summarize the problem, link to the page or file, describe observed versus expected results, give reproduction steps where possible, and propose a measurable fix. Choose a concise issue title. For accessibility issues, identify the affected task rather than assuming a diagnosis.
+
+## Pull request checklist
+
+- [ ] My change has one clear purpose and links to an issue where appropriate.
+- [ ] I checked affected internal links and relative paths.
+- [ ] I reviewed readability, keyboard navigation, and mobile reflow where relevant.
+- [ ] I reported actual testing and unverified claims separately.
+- [ ] I included no private information, secrets, or unlicensed content.
+- [ ] I understand that maintainer approval controls merging and publishing.
+
+For detailed authorization and contributor safety expectations, read [Contributor Safety and Governance](CONTRIBUTOR_SAFETY_AND_GOVERNANCE.md).

README.md

@@ -28,6 +28,14 @@ The [guide homepage](./docs/index.html) is the canonical orientation page. It as
 | [Worked example](./docs/case-study/README.md) | Follow an anonymized retraining plan from goal through lessons learned. |
 | [Legacy curriculum reference](./LEGACY_TRAINING_MANUAL.md) | Consult preserved predecessor material from the earlier README. |
 
+## Contribute — junior developers and senior architects welcome
+
+**Bring a fix, a reproducible issue, or a scoped proposal.** [Start with the contributor guide](./CONTRIBUTING.md). No invitation, personal email address, or production access is needed to fork, discuss, or submit a pull request through GitHub.
+
+New developers can begin with a broken link, a mobile layout improvement, or an accessibility check. Experienced engineers should provide evidence, expected outcomes, and an implementable correction rather than unproductive criticism. Respectful disagreement, safety concerns, and good-faith bug reports remain welcome even when the reporter cannot supply code.
+
+Open work is voluntary and unpaid; contribution does not imply employment, ownership, publication, or approval. Maintainers review and approve merges. [Report a problem or propose an improvement](https://github.com/Loptr-Lab/training/issues/new/choose).
+
 ## Scope and privacy
 
 This repository provides educational information and preparation tools. It does not determine eligibility, guarantee funding, or replace advice from a qualified professional. Program rules, prices, and eligibility can change; verify current information with the responsible decision-maker.