Semester Project

World-Class Evidence Integration

Apply the required World-Class Strand inside the existing project scope. Its evidence contract is required; replace lower-value polish rather than adding feature breadth.

Required Output Classification

Required output	Classification	Public/private guidance
Runnable project implementation and repository structure	Portfolio candidate	Polish the public repo only after tests pass, secrets are removed, and setup steps work from a clean checkout.
README with setup, inspection, verification instructions, and known limitations	Portfolio candidate	Make this public-facing if the project is safe to share; keep internal coursework notes in a private evidence folder.
Tests, traces, proofs, diagrams, benchmark outputs, or review notes required by the brief	Checkpoint evidence	Keep raw logs, benchmark runs, and reviewer comments private by default; publish summarized or reproducible versions when useful.
ADRs, design memos, runbooks, benchmark reports, and other high-effort engineering writeups	Portfolio candidate	These are worth polishing publicly when they tell a clear tradeoff story; otherwise keep them as private coursework evidence.
Final reflection, retrospective, or carry-forward notes	Checkpoint evidence	Keep candid self-assessment private unless rewritten as a concise public learning note.

Build a small systems toolkit in C that proves you can move from source code to machine behavior to operating-system interaction without losing control of the details.

---

Project Goal

Create a command-line toolkit with at least three cohesive components:

1. one file-processing utility
2. one process or pipe-based utility
3. one debugging, memory, or measurement artifact that shows how you verified correctness

The project should feel like one small systems repo, not five disconnected exercises.

---

Recommended Project Shape

Use a repo structure like this:

• src/ for implementation files
• include/ for public headers
• tests/ or scripts/ for smoke checks
• Makefile for reproducible builds
• notes/ for debugger output, memory diagrams, benchmark notes, and design reflections

Possible toolkit themes:

• a mini shell plus helper utilities
• a file-inspection and text-processing toolkit
• a small systems lab pack with one networked utility and one process-control utility

Choose one theme and keep the interfaces consistent.

---

Required Technical Scope

Your project must include all of the following:

Module 1 requirements

• clean multi-file C organization
• headers with clear declarations and no duplicate-definition mistakes
• warnings enabled during build

Module 2 requirements

• at least one part that uses dynamic allocation or explicit memory layout reasoning
• a written note on one bug you prevented or fixed using memory reasoning

Module 3 requirements

• one short performance or architecture note
• either disassembly inspection, cache/locality reasoning, or a small benchmark

Module 4 requirements

• at least one of: fork/exec/wait, pipe/dup2, mmap, threads, or sockets
• correct error handling for system calls

Module 5 requirements

• one short reflection on abstraction boundaries in your design
• one explanation of where a higher-level design choice simplified a low-level implementation

---

Strong Project Examples

Option A: Mini Shell Plus Utilities

Build:

• a simple shell that supports one pipeline and basic redirection
• a custom wc-style utility
• a small diagnostic command that prints process or file-descriptor state

Best fit for students who want to lean heavily into Module 4.

Option B: Memory-Safe File Toolkit

Build:

• a file reader or search tool
• a memory-mapped analyzer or indexed reader
• a benchmark comparing buffered I/O vs mmap

Best fit for students who want stronger Module 2 and Module 3 integration.

Option C: Tiny Networked Service

Build:

• a TCP echo or line-oriented server
• a client or load script
• one debugging or profiling note showing how you investigated behavior

Best fit for students who want sockets, concurrency, and operational tooling.

---

Milestones

Milestone	Deliverable	Standard
1	Repo skeleton and build loop	Compiles cleanly with warnings enabled and organized headers
2	Core utility implemented	One meaningful command works end-to-end from the terminal
3	Systems feature added	Process, pipe, thread, socket, or mmap path is working and explained
4	Verification pass	At least one debugger, sanitizer, or tracing artifact captured and interpreted
5	Final integration	README or notes explain architecture, tradeoffs, and known limits

---

Required Evidence

Submit the project with:

• source code and build instructions
• one command transcript showing a successful run
• one debugging or sanitizer transcript
• one short architecture or performance note
• one short reflection on abstraction boundaries and tradeoffs

If the code works but there is no evidence of how you verified it, the project is incomplete.

---

Rubric

Criterion	Meets	Notes
The repo builds cleanly and is organized as a real small C project	[ ]
The project demonstrates systems-level behavior, not just ordinary application logic	[ ]
Memory, process, I/O, or concurrency reasoning is explicit and correct	[ ]
Debugging and verification artifacts are present and interpreted accurately	[ ]
The design shows deliberate abstraction boundaries instead of ad hoc code growth	[ ]

---

Submission Checklist

• Multi-file C project compiles cleanly
• At least one systems primitive is used correctly
• At least one verification artifact is included
• Notes explain one low-level bug or risk and how it was handled
• Notes explain one architecture or abstraction tradeoff
• Project is ready to support the Semester 5 transition

---

Production-Style Project Brief

Use this project as a reviewable engineering brief, not only a completion exercise.

Problem statement

Write a one-paragraph statement covering the user, the problem, the constraint, and the outcome this project is meant to produce.

Required evidence

• working artifact or reproducible deliverable
• README with setup, inspection, and verification instructions
• tests, traces, proofs, diagrams, benchmark output, or review notes appropriate to the semester
• decision log with at least three meaningful tradeoffs
• known limitations section with explicit scope cuts

Review questions

1. What is the smallest vertical slice that proves the project works?
2. Which requirement is most likely to be misunderstood by a reviewer?
3. What did you deliberately not build, and why?
4. What evidence would convince someone else that the result is correct?

Done means

The project is done only when another technical reader can inspect the artifact, run or review the verification evidence, and understand the tradeoffs without a live explanation.

---

Weekly Project Milestones

Use these milestones to keep the project from becoming a last-week scramble.

Milestone	Focus	Evidence
Start	Scope the smallest useful slice	problem statement, non-goals, first task list
Early build	Produce a walking version	runnable skeleton, first test, first committed artifact
Middle	Add the hard part	implementation note, trace/proof/benchmark/design decision
Review	Stress the weak point	failure case, debugging note, peer/self review, correction commit
Finish	Package for inspection	README, verification instructions, known limitations, reflection

Answer-Quality Examples

Quality	What it sounds like
Weak	"I built it because the module asked for it."
Acceptable	"It works for the required examples and I can explain the main idea."
Strong	"Here is the tradeoff I chose, the evidence that supports it, and the case where it would fail."
Portfolio-ready	"A reviewer can inspect the artifact, rerun the checks, and understand why this solution fits this semester's goals."

Future Capstone Connection

Before closing this project, write two sentences on how it could help the final capstone: one reusable technical skill and one artifact habit to preserve.

Calibration Materials

Use these learner-visible calibration materials before self-grading or requesting review:

• Answer key and solution outlines
• Rubric, passing standard, strong traits, and weak patterns

C input-contract evidence

Require all CI1–CI6 at level 2 or above. Reuse the line-reader lab packet in the existing project: capacity traces, consecutive-line behavior, injected errors, compiler/diagnostic output and a fresh-case defense. No aggregate score waives missing input-contract evidence. Preserve the distinction between bounded storage and bounded running time.

Memory ownership evidence

Require all MP1–MP6 at level 2 or above. Reuse the growable-buffer packet: checked sizing, ownership traces, allocation-failure recovery, cleanup and independent transfer. The 20–30-hour package replaces the former short lab; it is not a complete module workload. Required fuzzing/Rust/mitigation/platform work remains separate.

Performance evidence

Require PE1–PE6 at level 2 or above. Reuse the locality measurement packet: checked sums, raw timings, target assembly, model assumptions and a bounded inference. A speedup or fabricated anomaly is never required. The specialized-platform strand remains separate.

Partial-I/O evidence

Require IO1–IO6 at level 2 or above. Reuse the write-progress packet: exact accepted prefixes, bounded retry traces, descriptor ownership and diagnostic evidence. A complete local write does not imply durability or remote processing.

Lexical interpretation evidence

Require all LI1–LI6 at level 2 or above. Reuse the interpreter packet: frame diagrams, two independent closure instances, evaluation-order tests, caller-scope fault evidence and explicit host/resource limitations. The small evaluator does not replace the original mutation, streams, staging or concurrency requirements. A failed gate remains incomplete regardless of aggregate score.

Integrated progression contract

Use the 440–640-hour workload and advancement contract. All 30 module extension gates and all five safety/platform evidence categories must independently reach level 2, alongside existing checkpoint, exam, project and integrity thresholds. Missing evidence means repair required — incomplete. Reuse module artifacts and record time once; the three-hour written exam and two-hour fresh-case defense are included in integration time.