If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/trifectatechfoundation/teach-rs shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Mixed signals — read the receipts

• Last commit 3w ago
• 14 active contributors
• Distributed ownership (top contributor 32% of recent commits)
• CC-BY-SA-4.0 licensed
• CI configured
• ⚠ Non-standard license (CC-BY-SA-4.0) — review terms
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live trifectatechfoundation/teach-rs repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/trifectatechfoundation/teach-rs.

What it runs against: a local clone of trifectatechfoundation/teach-rs — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in trifectatechfoundation/teach-rs | Confirms the artifact applies here, not a fork | | 2 | License is still CC-BY-SA-4.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 50 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of trifectatechfoundation/teach-rs. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/trifectatechfoundation/teach-rs.git
#   cd teach-rs
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of trifectatechfoundation/teach-rs and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "trifectatechfoundation/teach-rs(\\.git)?\\b" \\
  && ok "origin remote is trifectatechfoundation/teach-rs" \\
  || miss "origin remote is not trifectatechfoundation/teach-rs (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(CC-BY-SA-4\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"CC-BY-SA-4\\.0\"" package.json 2>/dev/null) \\
  && ok "license is CC-BY-SA-4.0" \\
  || miss "license drift — was CC-BY-SA-4.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f "COURSE.md" \\
  && ok "COURSE.md" \\
  || miss "missing critical file: COURSE.md"
test -f "book/SUMMARY.md" \\
  && ok "book/SUMMARY.md" \\
  || miss "missing critical file: book/SUMMARY.md"
test -f "exercises/2-foundations-of-rust/2-ownership-and-references/README.md" \\
  && ok "exercises/2-foundations-of-rust/2-ownership-and-references/README.md" \\
  || miss "missing critical file: exercises/2-foundations-of-rust/2-ownership-and-references/README.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 50 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~20d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/trifectatechfoundation/teach-rs"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Teach-rs is a modular, reusable university course curriculum for teaching Rust programming language to computer science students. It provides a structured collection of lecture slides, hands-on exercises (organized in exercises/ with Cargo projects), and teaching tools—not a self-teaching resource, but rather a framework for educators to create tailored Rust courses by selecting and composing from pre-built modules. Monorepo structure: book/ contains mdBook source (slides, guides in book/SUMMARY.md, book/teachers_guide.md); exercises/ is organized hierarchically (1-course-introduction/, 2-foundations-of-rust/) with numbered modules containing Cargo projects (e.g., exercises/2-foundations-of-rust/1-basic-syntax/1-basic-syntax/ with src/bin/ containing individual executable examples). Supporting docs in root: COURSE.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md.

Computer science educators (professors, teaching assistants, bootcamp instructors) who want to teach Rust in formal classroom settings (universities, vocational schools, community colleges) and need modular, peer-reviewed course material rather than building from scratch.

Actively maintained but explicitly incomplete. The README states 'while all available material is user-ready, this repo is not yet as exhaustive as we'd like.' GitHub Actions workflows exist (build-deploy.yml, zizmor.yml) indicating CI/CD setup. Community channels are active (Matrix chat badge in README). Honest assessment: production-ready for existing material, but still in active expansion phase with contribution gaps.

Low immediate risk—this is educational material, not a runtime dependency. However: no production code to break, so risk is reputational/pedagogical rather than technical. The repo explicitly does not include exercise solutions (by design for student learning), which means contributors must understand the pedagogical philosophy. Single organization (trifectatechfoundation) maintains it; dependent on community contributions for expansion.

Active development evidenced by: multiple GitHub issue templates (ask-a-question, collaboration-request, report-a-mistake, suggest-an-improvement), security scanning workflow (zizmor.yml), and organized exercise structure suggesting ongoing curation. Specific visible work: exercises for 'Foundations of Rust' module (basic syntax, ownership/references/move-semantics, borrowing) are being built out.

git clone https://github.com/trifectatechfoundation/teach-rs.git
cd teach-rs
cd exercises/2-foundations-of-rust/1-basic-syntax/1-basic-syntax
cargo run --bin 01

Daily commands: For exercises: navigate to a specific exercise directory (e.g., exercises/2-foundations-of-rust/1-basic-syntax/1-basic-syntax/) and run cargo run --bin <number> (e.g., cargo run --bin 01). For course material: build mdBook with mdbook build book/ (outputs to book/book/). No dev server; this is static documentation + Rust binaries.

• README.md — Primary overview of teach-rs project, its purpose as a university Rust course, and how to contribute—essential context for all contributors.
• CONTRIBUTING.md — Defines contribution guidelines, workflows, and standards that every contributor must follow to maintain consistency.
• COURSE.md — Core curriculum structure and learning objectives that define the pedagogical scope and progression of all exercises.
• book/SUMMARY.md — Table of contents for the mdBook course material; defines the narrative flow and module organization.
• exercises/2-foundations-of-rust/2-ownership-and-references/README.md — Anchor exercise module for ownership & borrowing—the conceptual foundation upon which all advanced Rust modules depend.
• .github/workflows/build-deploy.yml — CI/CD pipeline that validates all exercises and builds the course book; failures block contributions.
• book.toml — mdBook configuration that controls how course material is structured, themed, and published.

Add a new foundational exercise module

1. Create a new numbered subdirectory under exercises/2-foundations-of-rust/ (e.g., exercises/2-foundations-of-rust/7-new-topic/) (exercises/2-foundations-of-rust/README.md)
2. Add a Cargo.toml with package name and edition 2021 (exercises/2-foundations-of-rust/1-basic-syntax/1-basic-syntax/Cargo.toml)
3. Create starter binary exercises in src/bin/ following the numbered pattern (01.rs, 02.rs, etc.) (exercises/2-foundations-of-rust/1-basic-syntax/1-basic-syntax/src/bin/01.rs)
4. Write a markdown learning guide explaining the topic (e.g., basic-syntax.md) (exercises/2-foundations-of-rust/1-basic-syntax/basic-syntax.md)
5. Update book/SUMMARY.md to add the new module to the course navigation (book/SUMMARY.md)

Add a new advanced crate engineering project

1. Create a new numbered directory under exercises/3-crate-engineering/ (e.g., 6-my-project/) (exercises/3-crate-engineering/3-bsn/Cargo.toml)
2. Define library logic in src/lib.rs with comprehensive documentation and error types (exercises/3-crate-engineering/3-bsn/src/lib.rs)
3. Add optional test fixtures (e.g., valid_bsns.in, invalid_bsns.in) for real-world scenarios (exercises/3-crate-engineering/3-bsn/valid_bsns.in)
4. Create a main.rs that demonstrates library usage with error handling (exercises/3-crate-engineering/1-my-serde-app/src/main.rs)
5. Document the exercise goals and expected implementation in a README.md (exercises/3-crate-engineering/README.md)

Expand course material and slides

1. Add a new markdown file to book/slides/ or book/assets/ for lecture content (book/SUMMARY.md)
2. Update book/SUMMARY.md with a new entry pointing to your slides file (book/SUMMARY.md)
3. Reference supporting exercises from the exercises/ tree to link theory and practice (book/teachers_guide.md)
4. Add complementary content to book/teachers_guide.md if the material requires instructor notes (book/teachers_guide.md)

• Rust + Cargo — Language being taught; native package manager enables students to build, test, and ship real projects from day one.
• mdBook — Lightweight, Rust-native static site generator ideal for narrative course material and searchable documentation.
• GitHub + GitHub Actions — Centralized version control and CI/CD validation ensures all exercises compile and tests pass before merge.
• Markdown — Universal, version-control-friendly format for both lesson slides and README documentation.

• Modular exercises under numbered directories (1-setup, 2-foundations, 3-engineering)

  • Why: Mirrors a progression from beginner to intermediate; each student/instructor follows a clear path.
  • Consequence: Requires careful numbering and sequencing; adding exercises in the middle requires careful consideration of order.

• Binaries in src/bin/ for foundational exercises instead of main.rs

  • Why: Allows multiple independent starter problems in a single crate, reducing cognitive load and boilerplate.
  • Consequence: Students must learn cargo run --bin 01 syntax; more fragmented than a single main-based flow.

• Separate book/ (mdBook) from exercises/ (Rust code)

  • Why: Decouples pedagogical narrative from code examples; allows independent updates and source control of slides.
  • Consequence: Risk of slides and exercises drifting out of sync if not actively maintained together.

• No runtime dependencies in intro project or early exercises

  • Why: Keeps initial barrier to entry low; students focus on language, not ecosystem.
  • Consequence: Later crate engineering exercises (serde, custom types) introduce complexity; may surprise beginners.

• Interactive web-based coding environment (relies on local Rust installation).
• Real-time collaboration or instructor grading automation.
• Localization or multi-language support (English-only course material).
• Video lectures (slides + exercises + reading only).
• Certification or official accreditation (open-source educational material).

Pedagogical constraint: Exercises intentionally omit solutions; contributors must understand this design philosophy and write exercises that encourage compiler feedback and peer discussion rather than providing answer keys. Mdbook rendering: Course material is built to book/book/ but versioned material lives in book/ source; ensure you're editing source, not outputs. Binary naming convention: Exercise binaries use zero-padded numbers (01.rs, 02.rs, etc.); this convention should be maintained for consistency. Module numbering: Exercises are numbered by course module (1-course-introduction, 2-foundations-of-rust); adding new modules requires coordinating the numbering scheme with maintainers.

• Ownership and Move Semantics — Core to Rust's memory safety guarantee; teach-rs dedicates an entire module (2-foundations-of-rust/2-ownership-and-references/) with progressive exercises to ensure students internalize this before learning borrowing
• Borrow Checker Rules — Rust's unique compile-time safety mechanism; exercises in teach-rs deliberately expose students to borrow-checker errors so they learn to read compiler messages constructively
• Modular Curriculum Design — teach-rs is explicitly a framework for composable modules rather than a fixed course; educators select and sequence modules to fit their institution's needs and student background
• Compiler-Driven Learning — teach-rs leverages the Rust compiler as a pedagogical tool; exercises are designed to trigger helpful compiler messages rather than failing silently, turning error feedback into a learning aid
• Open Educational Resources (OER) — teach-rs is explicitly licensed for reuse and modification by educators; the repo structure and CONTRIBUTING guidelines reflect OER best practices for version control and attribution
• Cargo Workspace and Binary Targets — teach-rs organizes exercises as Cargo projects with multiple binary targets (src/bin/01.rs, etc.); understanding this structure is essential for running and modifying exercises
• FFI (Foreign Function Interface) — 21% of the repo is C code, indicating planned or existing exercises on unsafe Rust and C interoperability; critical for systems programming and real-world Rust use cases

• rust-lang/rust-by-example — Official Rust documentation with runnable examples; complementary resource for self-study that teach-rs explicitly does not target
• ferrous-systems/teaching-material — Another Rust teaching initiative; potentially collaboratable or inspirational for curriculum design
• rust-lang/book — The Rust Programming Language book; foundational reading material that teach-rs complements with interactive exercises
• rust-lang/rustlings — Small self-paced Rust exercises; similar problem domain but designed for self-teaching rather than classroom instruction
• trifectatechfoundation/teach-rs-content — Likely companion repo (if it exists) for additional course content or community-contributed materials

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add automated exercise validation workflow for all Cargo projects

The repo contains numerous Cargo.toml exercises across exercises/2-foundations-of-rust/* but lacks a CI workflow to verify they compile and pass tests. This prevents regressions when students submit solutions or maintainers update exercises. A GitHub Actions workflow should run cargo build and cargo test for each exercise directory.

• [ ] Create .github/workflows/exercise-validation.yml that discovers all Cargo.toml files in exercises/ directory
• [ ] Configure workflow to run cargo check and cargo test for each exercise
• [ ] Add matrix strategy to test against stable Rust edition and verify exercises///Cargo.toml exercises compile
• [ ] Document in CONTRIBUTING.md that all exercises must pass validation before merge

Create comprehensive README.md files for each exercise chapter with learning objectives

While exercises/2-foundations-of-rust/README.md and exercises/2-foundations-of-rust/2-ownership-and-references/README.md exist, most subdirectories (1-basic-syntax, 1-move-semantics, 2-borrowing, 3-advanced-syntax/*) lack README.md files explaining learning goals, prerequisites, and how to run exercises. This creates friction for self-guided learners.

• [ ] Add README.md to exercises/2-foundations-of-rust/1-basic-syntax/ with learning objectives and instructions to run src/bin/*.rs files
• [ ] Add README.md to exercises/2-foundations-of-rust/2-ownership-and-references/1-move-semantics/ explaining ownership concepts and linking to theory
• [ ] Add README.md to exercises/2-foundations-of-rust/2-ownership-and-references/2-borrowing/ with borrowing rules and expected behavior
• [ ] Add README.md to exercises/2-foundations-of-rust/3-advanced-syntax/* (error-propagation, error-handling, slices, ring-buffer) with context and completion criteria

Add solution verification tests in exercises using doctests and assert macros

Exercise files like exercises/2-foundations-of-rust/1-basic-syntax/src/bin/01.rs through 05.rs appear to be starter templates but lack integrated tests to guide students or auto-verify correctness. Adding doctests and assertion-based checks would provide immediate feedback without requiring external test files.

• [ ] Review exercises/2-foundations-of-rust/2-ownership-and-references/1-move-semantics/src/bin/01.rs through 04.rs and add #[cfg(test)] modules with assertions validating expected behavior
• [ ] Add doctests to exercises/2-foundations-of-rust/3-advanced-syntax/2-error-handling/src/main.rs demonstrating proper error handling patterns
• [ ] Document test execution in exercise README.md files (e.g., cargo test --bin 01)
• [ ] Ensure tests fail on common mistakes (e.g., unwrap instead of ? operator, incorrect ownership moves) to guide learners

• Add missing borrowing exercises: The file structure shows 2-foundations-of-rust/2-ownership-and-references/2-borrowing/ with only a Cargo.toml—implement src/bin/01.rs through 05.rs with progressive exercises on mutable vs. immutable borrows, borrowing rules, and common borrow-checker errors.
• Expand basic-syntax exercises documentation: Create a basic-syntax.md file in exercises/2-foundations-of-rust/1-basic-syntax/ that explains the learning outcomes and hints for each of the 05 exercises (currently exists at basic-syntax.md but may need expansion with pedagogical context).
• Add C interop examples: The repo contains 21% C code but no visible exercises on FFI; create a new submodule under 2-foundations-of-rust/ or later module with a Cargo project demonstrating #[repr(C)], linking to C libraries, and unsafe blocks for system calls.

This Rust educational course repository has a strong security posture overall. It contains no detected critical vulnerabilities, malicious dependencies, or infrastructure misconfigurations. The codebase consists primarily of educational exercises with minimal dependencies and no web-facing components. Main recommendations focus on enhancing educational best practices around sensitive data handling: implementing a security policy for responsible disclosure, improving documentation about preventing accidental credential commits, and strengthening .gitignore patterns. The educational nature of the project reduces attack surface significantly.

• Low · Configuration Files Without Sensitive Data Protection Guidelines — exercises/2-foundations-of-rust/5-closures-and-dynamic-dispatch/1-config-reader/config.json, config.yml. The repository contains configuration files (config.json, config.yml) in the exercises directory. While these appear to be example/template files for educational purposes, there is no clear documentation about preventing sensitive data from being committed to version control. Fix: Add clear documentation in CONTRIBUTING.md and exercise README files about never committing credentials or sensitive data. Include a .gitignore template example that excludes *.local.json, *.local.yml, and .env files. Consider adding pre-commit hooks documentation.
• Low · Missing Security Policy — Repository root. The repository does not appear to have a SECURITY.md file for responsible disclosure of security vulnerabilities. This makes it harder for security researchers to report issues privately. Fix: Create a SECURITY.md file following GitHub's guidelines for security policy, providing clear instructions for responsible vulnerability disclosure.
• Low · Incomplete .gitignore for Educational Content — .gitignore. No specific security-focused .gitignore entries visible for preventing accidental commits of sensitive files that students might create during exercises (e.g., API keys, .env files, credentials). Fix: Ensure .gitignore includes entries for: .local., .env*, secrets.*, *.pem, *.key, and other sensitive file patterns. Add comments explaining why each pattern is needed for educational purposes.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.