Commit 5c1696

2026-08-29 16:39:27 lisa: Add sd/C10: hub + guides for the in-class model Seven curated learning pages plus the C10 home hub, generated by the shared port script (new c10 config): the C100-* cluster, the tick sheet, the solutions booklet and the assessment paperwork stay out of the wiki. Each page gains a skill title, a lead naming the rubric band it serves, one earned mermaid visual and a Check Your Understanding fold. The git-log examples are anonymised (prior-cohort names, hostnames and repo URL removed). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RxqgYbTNNYrPNuko6xfbKs

/dev/null .. sd/C10/C10-home.md
@@ 0,0 1,60 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C10-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# C10 — Skills in Evaluating the Solution and Assessing the Project Plan
+
+	The Hamilton and Alexandra College · Year 12 · 2026
+
+	C10 is the *lightest* criterion in the SAT: almost all of its evidence already exists in your repository. There is no checkpoint, no separate validation sitting and no interview. Each judgement is **taught** in a short slot, **written** by hand in class from printouts of your own work, and **graded** against what your repo already shows.
+
+	```mermaid
+	flowchart LR
+	H["At home<br/>C10 Booklet — The Last Mile<br/>practise on Godot Tetris"] --> T
+	T["In class · 3 instruction slots<br/>5–10 min each"] --> C
+	C["In class · 3 collected class writes<br/>handwritten · no internet"] --> G
+	R["Already in your repo<br/>C4 matrix · SRS, mockup and UI trail<br/>baseline Gantt · commit history"] --> G
+	G["Your C10 mark<br/>4 indicators × 25% = /40"]
+	```
+
+	*Two streams meet at your mark: what you write by hand on the day, and what your repository already proves. Neither carries C10 on its own.*
+
+	## How C10 runs
+
+	| Indicator | Taught — slot (5–10 min) | Written in class (collected) | Graded from |
+	|---|---|---|---|
+	| **C10-1** Solution evaluation | **Slot 1** — Use · Explain · Propose | Class write 1 — your solution (≈ half a lesson) | Your C4 matrix, and the repo evidence each verdict cites |
+	| **C10-2** Stages evaluation | **Slot 2** — evaluate, don't describe | Class write 2 — your process (≈ 20 min) | SRS versions, mockups and UI screenshots, timestamped |
+	| **C10-3** Plan modifications | **Slot 3** — annotate, then judge twice | Class write 3, side A — your plan, annotated (≈ 10 min) | Baseline Gantt, board snapshots, commit history |
+	| **C10-4** Plan effectiveness | **Slot 3** — same slot; the sheet walked through | Class write 3, side B — the effectiveness sheet (≈ 15 min) | The collected sheet and the dates it cites |
+
+	Each indicator is scored out of 10 and is worth **25%** of the criterion — **/40** in total.
+
+	> [!NOTE]
+	> **Conditions — all three class writes.** 🔒📱 Handwritten on the sheet provided: no internet, no devices, no notes. Your teacher hands you printouts of *your own* work — your C4 matrix, your SRS/mockup/UI trail, your plan. Sheets are collected at the end of the lesson.
+
+	::: info
+	# Two dates are checked before your marks are set
+	Your **C4 evaluation matrix** must have been committed *before* the C9 beta window opened, and your **SRS refresh** *before* the C6/7 validation. Your teacher reads those dates from the server — `git log`, or the commit page on GitHub, never a date typed inside a document. Criteria fixed before the results exist are predictions your evaluation genuinely tests; criteria written afterwards can be shaped to fit and prove nothing. You might lose marks if either is overdue.
+	:::
+
+	At home you practise each judgement in the **C10 Booklet — The Last Mile** on the worked Godot Tetris example, watch the set video, and complete the *commit-now* prep step before class write 3 — commit your plan's current state with an honest note of what has changed since your C01 baseline. Honest gaps count. The booklet and the full assessment package are in your `S-C10` folder.
+
+	## Foundations
+
+	- [Essential Terms](/sd/C10/Essential%20Terms)
+
+	## C10-1 — Evaluating the solution
+
+	- [Proposing a Future Evaluation Strategy](/sd/C10/Future%20Evaluation%20Strategy)
+
+	## C10-2 — Evaluating the analysis, design and development stages
+
+	- [Writing the Development Process Portfolio](/sd/C10/Development%20Process%20Portfolio)
+
+	## C10-3 — Documenting the modifications to your project plan
+
+	- [Tracking Plan Changes](/sd/C10/Tracking%20Plan%20Changes) — annotated Gantt charts and project logs
+	- [Recording Project Progress](/sd/C10/Recording%20Project%20Progress) — a 20-minute practice task
+	- [Reading a Git Log](/sd/C10/Reading%20a%20Git%20Log) — three real logs, anonymised
+
+	## C10-4 — Assessing the effectiveness of your project plan
+
+	- [Project Plan Effectiveness](/sd/C10/Project%20Plan%20Effectiveness)
/dev/null .. sd/C10/Development Process Portfolio.md
@@ 0,0 1,180 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C10-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# Writing the Development Process Portfolio
+
+	*How to turn analysis, design and development into a case study C10-2 can be marked from. Read it before class write 2.*
+
+	> [!NOTE]
+	> **The bands this serves.** C10-2, 5–6: *evaluates the use of the analysis, design and development stages*. 7–8: *critically evaluates the process … from start to finish … and how this process assisted in meeting requirements*. 9–10: *discusses and justifies improvements that could be made … by approaching the stages differently*. Describing what you did stops at 3–4.
+
+	```mermaid
+	flowchart LR
+	A["Analysis<br/>what I discovered<br/>about the problem"] --> RA["retro<br/>went well ·<br/>was tricky ·<br/>next time"]
+	RA --> B["Design<br/>how I planned<br/>the solution"]
+	B --> RB["retro<br/>went well ·<br/>was tricky ·<br/>next time"]
+	RB --> C["Development<br/>how I built<br/>the solution"]
+	C --> RC["retro<br/>went well ·<br/>was tricky ·<br/>next time"]
+	RC --> D["Evaluation<br/>how the three stages<br/>helped me meet<br/>the requirements"]
+	```
+
+	*The retrospectives are not decoration between the stages — they are the material the final evaluation is built from. Skip them and stage 4 has nothing to evaluate.*
+
+	## **What is this?**
+
+	Your **development story** - a case study showing how you navigated the PSM stages, made critical decisions, and learned from challenges.
+
+	**Purpose:** Tell the story of your journey through analysis → design → development, showcasing critical thinking and lessons learned.
+
+	---
+
+	## **📖 Write Your Development Story**
+
+	### **Think Case Study, Not Checklist**
+
+	Instead of: _"I completed analysis stage"_
+	Write: _"During Week 2 analysis, I discovered users actually needed X when I assumed they needed Y, so I updated my requirements and interviewed 3 more users..."_
+
+	---
+
+	## **🎯 Story Structure (C10-2)**
+
+	### **Stage 1: Analysis** - _"What I discovered about the problem"_
+
+	**Your Narrative:**
+
+	- **The investigation**: How did you research the problem?
+	- **Key discoveries**: What surprised you about user needs?
+	- **Decision moments**: When did you change direction and why?
+	- **Problem-solution pairs**: Challenge you hit → How you solved it
+
+	**Evidence to Include:**
+
+	- Research notes with captions: _"This interview revealed users needed offline mode"_
+	- Meeting minutes/user feedback
+	- Requirements evolution screenshots
+
+	**Mini-Retrospective:**
+
+	- **What went well?**
+	- **What was tricky?**
+	- **Action for next time:** _"Next project I'll prototype earlier"_
+
+	### **Stage 2: Design** - _"How I planned the solution"_
+
+	**Your Narrative:**
+
+	- **Design evolution**: Show how designs changed and improved
+	- **Choice explanations**: _"I chose React over vanilla JS because..."_
+	- **Alternative paths**: What other designs did you consider?
+	- **User feedback integration**: How did feedback shape your design?
+
+	**Evidence to Include:**
+
+	- "Before" and "After" mockups showing evolution
+	- Decision logs with reasoning
+	- Annotated wireframes: _"Changed button layout after usability feedback"_
+
+	**Mini-Retrospective:**
+
+	- **What went well?**
+	- **What was tricky?**
+	- **Action for next time:**
+
+	### **Stage 3: Development** - _"How I built the solution"_
+
+	**Your Narrative:**
+
+	- **Technical journey**: Key coding decisions and challenges
+	- **Problem-solving moments**: _"When I couldn't get the API to work, I..."_
+	- **Tool choices**: Why you picked specific technologies
+	- **Scope adjustments**: How you handled changing requirements
+
+	**Evidence to Include:**
+
+	- Git commit examples with context: _"This commit fixed the login bug discovered in testing"_
+	- Code snippets with explanations
+	- Bug fixes with problem-solving rationale
+
+	**Mini-Retrospective:**
+
+	- **What went well?**
+	- **What was tricky?**
+	- **Action for next time:**
+
+	### **Stage 4: Evaluation** - _"How PSM helped me succeed"_
+
+	**Your Analysis:**
+
+	- **PSM effectiveness**: How did each stage contribute to meeting requirements?
+	- **Critical thinking moments**: Key decisions that shaped the project
+	- **Process improvements**: What would you do differently?
+	- **Professional growth**: What did this process teach you?
+
+	---
+
+	## **📁 Portfolio Format Ideas**
+
+	### **Timeline-Based Story:**
+
+	Week-by-week narrative with artifacts and reflections at each stage
+
+	### **Visual Case Study:**
+
+	Annotated screenshots/mockups with decision explanations and lessons learned
+
+	### **Problem-Solution Journey:**
+
+	Organize around major challenges faced and how you solved them
+
+	### **Decision Tree Format:**
+
+	Show key decision points with reasoning and outcomes
+
+	---
+
+	## **📊 Evidence + Reflection Template**
+
+	|**PSM Stage**|**Key Evidence**|**What I Learned**|**Next Time I'd..**|
+	|---|---|---|---|
+	|Analysis|Research notes, user interviews|Users needed offline mode|Interview users earlier|
+	|Design|Wireframes, mockup evolution|Simple designs work better|Get feedback on every iteration|
+	|Development|Git commits, code solutions|Testing early saves time|Set up automated testing from start|
+	|**Overall**|**Complete journey reflection**|**PSM stages prevented major rework**|**Plan for more user feedback loops**|
+
+	---
+
+	## **✨ Pro-tips:**
+
+	**Tell YOUR story** - Include personality, choices, and real experiences
+
+	**Show evidence with context** - Each artifact needs a caption explaining why it matters
+
+	**Be honest about struggles** - Challenges overcome demonstrate critical thinking
+
+	**Connect to requirements** - Explain how your process helped meet FR/NFR
+
+	**Use visuals** - Screenshots, diagrams, timelines make it engaging
+
+	## **🎯 Remember:**
+
+	This isn't about having a perfect process - it's about **demonstrating thoughtful reflection** on your development journey and **showing what you learned** along the way!
+
+	---
+
+	## Check Your Understanding
+
+	**1.** Which of these two sentences can reach band 7–8, and why?
+	(a) *"I completed the design stage, producing mock-ups and a data dictionary."*
+	(b) *"Designing the data dictionary before coding meant the save-file format was settled early, so the two save bugs found in alpha testing were format bugs, not design bugs."*
+
+	>| ### Answer
+	>| (b). It evaluates *the use of* the stage — it says what the stage did for the project and ties it to a requirement being met. (a) outlines what was produced, which is band 3–4 territory.
+
+	**2.** Band 9–10 asks you to justify improvements *by approaching the stages differently*. Why is "I would have coded faster" not enough?
+
+	>| ### Answer
+	>| It is not a change to a stage. An answer that opens the band names a different way of running analysis, design or development — prototyping before finalising the SRS, say — and then justifies it against something that actually went wrong.
+
+	**3.** Every artefact you include needs a caption. What must the caption say?
+
+	>| ### Answer
+	>| Why the artefact matters — the decision it evidences — not what it is. *"Wireframe v2"* is a label; *"Changed the button layout after two testers missed the hold control"* is a caption.
/dev/null .. sd/C10/Essential Terms.md
@@ 0,0 1,102 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C10-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# Essential Terms — C10
+
+	*Every term you need to recognise and use correctly across C10. Click a term to reveal its definition — if you cannot define it in your own words, you cannot use it in a class write.*
+
+	```mermaid
+	flowchart TD
+	V["C10 vocabulary"] --> A["The judgement<br/>evaluation · evaluation criteria<br/>testing · beta testing"]
+	V --> B["What you judge against<br/>SRS · functional requirements<br/>non-functional requirements<br/>constraints · solution boundaries"]
+	V --> D["Quality factors defined here<br/>efficiency: functionality<br/>effectiveness: accuracy · usability<br/>accessibility · relevance · timeliness<br/>completeness · maintainability"]
+	V --> E["The plan<br/>project management · Gantt chart<br/>version control · PSM"]
+	V --> F["Why plans move<br/>scope creep · personnel changes<br/>technical issues"]
+	D -.-> G["Nearby, but NOT VCAA factors<br/>reliability · fit for purpose"]
+	```
+
+	*The glossary is one long list; the clusters above are the five jobs those words do in C10. The full VCAA lists are **3 efficiency factors** and **11 effectiveness factors** — see [Efficiency vs Effectiveness](/sd/C04/Efficiency%20vs%20Effectiveness) for the complete table. Only the factors this glossary defines are shown.*
+
+	## Topics:
+	- Evaluation of solution against SRS and criteria
+	- Reviewing the development process
+	- Assessing plan modifications
+	- Evaluating plan effectiveness
+	- Scope creep, personnel changes and technical issues
+
+
+	>| ### Evaluation
+	>| The final stage of the problem-solving methodology. It checks how well the solution is satisfying the needs of the user for which it was originally created.
+
+	>| ### Evaluation criteria
+	>| Performance criteria made from the expectations and specification.
+
+	>| ### Software requirements specification (SRS)
+	>| A single document that contains the outcomes of the analysis stage of the problem-solving methodology, including scope, constraints, functional requirements and non-functional requirements.
+
+	>| ### Functional requirements
+	>| The desired operations of a program that have specified inputs, behaviours and outputs.
+
+	>| ### Non-functional requirements
+	>| Qualitative requirements of a solution, often tied to solution constraints.
+
+	>| ### Completeness
+	>| The extent to which all necessary features and functionality are included in the software.
+
+	>| ### Functionality
+	>| The extent to which a solution is suited to its purpose.
+
+	>| ### Accuracy
+	>| The degree to which software correctly performs its intended functions without errors.
+
+	>| ### Usability
+	>| The extent to which a system is easy to learn and use.
+
+	>| ### Accessibility
+	>| Ensures that software can be used by people with a wide range of abilities and disabilities.
+
+	>| ### Relevance
+	>| The degree to which software meets the current needs and requirements of its users or market.
+
+	>| ### Timeliness
+	>| The ability of software to provide information or functionality when it is needed, without undue delay.
+
+	>| ### Scope creep
+	>| The tendency for a project's requirements to increase over time, often leading to delays and budget overruns.
+
+	>| ### Personnel changes
+	>| Modifications or transitions in the team composition that can impact the development process and timelines.
+
+	>| ### Technical issues
+	>| Challenges or problems related to the technology being used in software development, potentially impacting project progress.
+
+	>| ### Project management
+	>| A method of recording the progress of a project and managing resources to operate within time, resource and cost availability.
+
+	>| ### Gantt chart
+	>| A type of bar chart or graphic timeline that shows the progress of a project by placing tasks on a timeline, often with comments or annotations.
+
+	>| ### Problem-solving methodology (PSM)
+	>| An approach that develops the stages involved in solving a problem.
+
+	>| ### Constraints
+	>| Factors that may limit or restrict solution requirements.
+
+	>| ### Solution boundaries
+	>| The limits or edges of what a project or solution will encompass.
+
+	>| ### Fit for purpose
+	>| To be well suited for a role or purpose.
+
+	>| ### Maintainability
+	>| How easy a solution is to look after once it has been put in place.
+
+	>| ### Reliability
+	>| How much a solution can be depended upon to function as designed, and for how long.
+
+	>| ### Version control
+	>| The method that keeps track of the current, most up-to-date document through a drafting process.
+
+	>| ### Testing
+	>| Checks the accuracy of information outputs.
+
+	>| ### Beta testing
+	>| The phase of software testing where a sample of the intended audience tests the software in a real environment.
\	No newline at end of file
/dev/null .. sd/C10/Future Evaluation Strategy.md
@@ 0,0 1,113 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C10-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# Proposing a Future Evaluation Strategy
+
+	*How to write the future evaluation strategy C10-1 asks for. Read it before class write 1.*
+
+	> [!NOTE]
+	> **The band this serves.** C10-1, 9–10: *"Proposes an evaluation strategy to be conducted sometime in the future to evaluate the efficiency and effectiveness of the software solution that includes: the time frame for the evaluation to be conducted, the evaluation criteria to be used, the individuals to conduct the evaluation and their responsibilities."* All four ingredients, or the band does not open.
+
+	```mermaid
+	flowchart LR
+	D["Deployment<br/>day 0"] --> U["Real users, real work<br/>3–6 months"]
+	U --> E["Evaluation window<br/>2–4 weeks"]
+	E --> R["Findings · decisions about improvements"]
+	S["System data<br/>logs · usage frequency · crash reports"] --> E
+	F["User feedback<br/>satisfaction ratings · usability survey"] --> E
+	```
+
+	*The strategy sits on a timeline, which is why "later" never scores: the gap before the window is what gives users time to form a real opinion, and the window itself is what the two data streams feed.*
+
+	A plan for evaluating your software solution **after it's been used for a while** by real users in real situations.
+
+	**Purpose:** Conduct a post-launch review of solution usability and performance to ensure ongoing effectiveness.
+
+	---
+
+	## **🎯 Required Components (C10-1)**
+
+	### **1. Time Frame** - _When will the evaluation happen?_
+
+	- 🔹 **When**: 3-6 months after software deployment
+	- 🔹 **Why**: Users need time to get comfortable with the solution
+	- 🔹 **Duration**: 2-4 weeks for data collection and analysis
+
+	**Example:** _"Evaluation will be conducted 6 months after deployment (March 2026), taking 3 weeks to complete."_
+
+	### **2. Evaluation Criteria** - _What will be measured?_
+
+	- 🔹 **Start with key questions**:
+	- Is usability still strong?
+	- Have bugs/errors increased?
+	- Do all original requirements still work?
+	- Are users satisfied with performance?
+	- 🔹 **Use your existing criteria** from the evaluation matrix
+	- 🔹 **Combine process + outcome measures**:
+	- **System data**: logs, usage frequency, crash reports
+	- **User feedback**: satisfaction ratings, usability surveys
+
+	**Example:** _"Evaluate usability, speed of processing, accuracy, and user satisfaction using original criteria plus system performance logs."_
+
+	> ⚠️ **Use VCAA-named factors only.** "Your existing criteria" means the criteria you built in C4 — but double-check them before reusing them here. Worked examples in the wild — including one in the C4 task sheet — list "resource usage" and "response time" as efficiency factors. Neither is a VCAA-named factor. The real list is exactly **3 efficiency factors** (Speed of Processing, Cost of Data and File Manipulation, Functionality) and **11 effectiveness factors** (Accessibility, Accuracy, Attractiveness, Clarity, Communication of Message, Completeness, Maintainability, Readability, Relevance, Timeliness, Usability) — see [Efficiency vs Effectiveness](/sd/C04/Efficiency%20vs%20Effectiveness) for the full table with descriptions. If your C4 evaluation matrix carried over a non-VCAA factor name, relabel it using the correct factor before you evaluate against it here — a criterion named "resource usage" can usually be reframed as "cost of data and file manipulation" or "speed of processing," depending on what you were actually measuring.
+
+	### **3. Individuals** - _Who will do the evaluation?_
+
+	- 🔹 **End users** (people actually using the software)
+	- 🔹 **Technical evaluator** (developer/IT person)
+	- 🔹 **Stakeholder representative** (manager/decision maker)
+
+	**Example:** _"5 regular users, 1 IT administrator, and 1 department manager will participate."_
+
+	### **4. Responsibilities** - _Who does what?_
+
+	- 🔹 **Users**: Provide feedback, complete surveys, participate in interviews
+	- 🔹 **Technical evaluator**: Measure performance, analyze usage data
+	- 🔹 **Stakeholder**: Review results, make decisions about improvements
+
+	---
+
+	## **📝 Simple Template**
+
+	### **Future Evaluation Strategy for [Your Software Name]**
+
+	**When:** [Time frame - when and how long]
+
+	**What:** [List 3-5 key criteria to evaluate — VCAA-named efficiency/effectiveness factors, see the warning above]
+
+	**Who:** [List roles and number of people]
+
+	**How:** [Brief description of evaluation methods]
+
+	**Responsibilities:**
+
+	- **Users**: [What they need to do]
+	- **Technical**: [What technical person does]
+	- **Manager**: [What stakeholder does]
+
+	---
+
+	## **✨ Pro-tip:**
+
+	Keep it realistic and practical. Think about what would actually happen if someone wanted to check how well your software is working after 6 months of real use.
+
+	## **🚫 Don't Overthink It**
+
+	This is a **proposal**, not a detailed research plan. One page is usually enough!
+
+	---
+
+	## Check Your Understanding
+
+	**1.** A student writes: *"We will evaluate the software later using our criteria."* Which of the four required ingredients are missing?
+
+	>| ### Answer
+	>| Three, arguably all four. *When* — "later" is not a time frame. *Who* — no individuals named. *Responsibilities* — nothing said about who does what. Even *which criteria* is only gestured at; the criteria have to be named.
+
+	**2.** Your C4 matrix has a row called "response time". Can you reuse it here as written?
+
+	>| ### Answer
+	>| No. "Response time" is not a VCAA-named factor. Work out what you were actually measuring and relabel it — usually **speed of processing**. The same goes for "resource usage", which is usually **cost of data and file manipulation**.
+
+	**3.** Why does the strategy ask for system data *and* user feedback rather than one of them?
+
+	>| ### Answer
+	>| They answer different halves of the question. System data (logs, crash reports, usage frequency) evidences efficiency and reliability of operation; user feedback evidences effectiveness — whether the solution is still usable, accessible and relevant to the people using it.
/dev/null .. sd/C10/Project Plan Effectiveness.md
@@ 0,0 1,185 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C10-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# Assessing the Effectiveness of Your Project Plan
+
+	*The C10-4 judgement: was the plan any good, and how do you know? Read it before class write 3, side B.*
+
+	> [!NOTE]
+	> **The bands this serves.** C10-4, 5–6: *describes the reasons why changes were made and how they impacted the effectiveness of the plan*. 7–8: *discusses how the changes impacted the completion of the project and the effectiveness of the plan*. 9–10: *evaluates the changes, **with evidence**, and how they impacted completion and overall effectiveness*. The words "with evidence" are why C10-3's record decides your C10-4 mark.
+
+	```mermaid
+	flowchart LR
+	D["Your C10-3 record<br/>annotations · logs · commit dates"] --> Q1
+	Q1["What happened?<br/>the facts"] --> Q2["What was the impact?<br/>positive · negative · neutral"]
+	Q2 --> Q3["What would I do next time?<br/>the learning"]
+	Q3 --> V["A verdict on the plan,<br/>carried by the evidence"]
+	Q3 -.->|"repeat per major change"| Q1
+	```
+
+	*Three questions, run once per significant change, then one verdict over the lot. The loop is why the record has to exist first — the facts step has nowhere to start without it.*
+
+	## **What is this?**
+
+	A thoughtful **post-project analysis** looking back at how well your planning worked and what you learned about project management.
+
+	**Purpose:** Assess the effectiveness of your project plan using evidence from your tracking data (C10-3) to demonstrate critical evaluation skills.
+
+	**⚠️ Important:** This reflection is based entirely on **actual events and logged modifications**, not retrospective reconstruction.
+
+	---
+
+	## **🎯 Reflection Framework (C10-4)**
+
+	### **Optional: Build on milestone mini-retrospectives**
+
+	_If you wrote brief reflections during your project, use them as foundation:_
+
+	- **Post-Analysis**: What worked in problem investigation?
+	- **Post-Design**: How effective was your design process?
+	- **Post-Alpha Testing**: What did testing reveal about your planning?
+	- **Post-Beta Testing**: How did user feedback change your timeline?
+
+	### **Your final reflection should answer:**
+
+	- **Was my project plan effective?** Why or why not?
+	- **What factors made it work well or poorly?**
+	- **How did changes impact my project completion?**
+	- **What patterns emerged in my modifications?**
+	- **What would I do differently next time?**
+
+	### **💭 Use Simple Reflective Thinking:**
+
+	For each major issue, ask yourself:
+
+	- **What happened?** (The facts)
+	- **What was positive/negative?** (Impact analysis)
+	- **What will I do next time?** (Learning)
+
+	---
+
+	## **📝 Reflection Structure**
+
+	### **1. Overall Plan Assessment** - _"How effective was my plan?"_
+
+	**Rate your plan's effectiveness (with justification):**
+
+	- **Highly Effective (80-100%)**: Plan worked well with minor adjustments
+	- **Moderately Effective (60-79%)**: Plan needed several modifications but project succeeded
+	- **Somewhat Effective (40-59%)**: Plan required major changes, some delays occurred
+	- **Ineffective (0-39%)**: Plan failed to guide project successfully
+
+	**Evidence-based justification:** _"My plan was 75% effective because I completed all requirements on time, but underestimated testing phases by 4 days total."_
+
+	### **2. Effectiveness Factors Analysis** - _"What worked and what didn't?"_
+
+	#### **✅ What Made the Plan Effective:**
+
+	- **Realistic timeframes**: Which estimates were accurate?
+	- **Good planning decisions**: What early choices paid off?
+	- **Flexibility**: How did the plan adapt to changes?
+	- **Resource allocation**: Were resources planned well?
+
+	#### **❌ What Made the Plan Less Effective:**
+
+	- **Underestimated tasks**: Which took longer than expected?
+	- **Missing considerations**: What didn't you plan for?
+	- **Over-optimistic timelines**: Where were you unrealistic?
+	- **Resource constraints**: What limitations affected the plan?
+
+	**Example:** _"Effective: I allocated extra time for coding which absorbed alpha testing delays. Ineffective: I didn't plan for user tutorial creation - beta testing revealed this need."_
+
+	### **3. Change Impact Analysis** - _"How did modifications affect completion?"_
+
+	**Use your C10-3 tracking data to analyze:**
+
+	- **Positive changes**: Modifications that improved project outcomes
+	- **Negative changes**: Modifications that caused delays or problems
+	- **Neutral changes**: Modifications with minimal impact
+	- **Change attribution**: Who/what drove each change (you, teacher, user feedback, technical issues)
+
+	### **4. Planning Approach Evaluation** - _"What does this reveal about my planning effectiveness?"_
+
+	**Based on the evidence:**
+
+	- **Planning strengths**: What aspects of my approach worked well?
+	- **Planning weaknesses**: What aspects need improvement?
+	- **Overall planning accuracy**: How realistic were my original estimates?
+	- **Adaptability**: How well did my plan handle unexpected changes?
+
+	**Example:** _"My planning showed strength in coding estimates but weakness in testing allocation. The plan demonstrated good adaptability when technical issues arose, with minimal impact on final delivery."_
+
+	---
+
+	## **📋 Simple Reflection Template**
+
+	### **Project Plan Effectiveness Reflection**
+
+	**Overall Assessment:** [Rating/100 with justification]
+
+	**What Made My Plan Effective:**
+
+	1. [Factor 1 with evidence]
+	2. [Factor 2 with evidence]
+	3. [Factor 3 with evidence]
+
+	**What Made My Plan Less Effective:**
+
+	1. [Issue 1 with evidence]
+	2. [Issue 2 with evidence]
+	3. [Issue 3 with evidence]
+
+	**Change Impact Summary:**
+
+	- **Most helpful change:** [Change + why it helped + who/what drove it]
+	- **Most problematic change:** [Change + why it caused issues + who/what drove it]
+	- **Overall impact:** [Did changes mostly improve or harm project completion?]
+
+	**Evidence from Project Logs:**
+
+	- [Reference specific log entries that support your assessment]
+	- [Include 2-3 examples of changes with outcomes and attribution]
+
+	**Planning Approach Evaluation:**
+
+	1. **Planning Strengths:** [What worked well in your approach]
+	2. **Planning Weaknesses:** [What aspects were less effective]
+	3. **Estimate Accuracy:** [How realistic were your original timelines]
+	4. **Plan Adaptability:** [How well did your plan handle changes]
+
+	**Final Conclusion:** [Was the plan successful in helping you complete the project? One paragraph summary]
+
+	---
+
+	## **✨ Pro-tips:**
+
+	**Use your C10-3 data** - Reference specific log entries as evidence
+
+	**Be honest** - Authentic reflection shows maturity and learning
+
+	**Think like a project manager** - What would you tell someone planning a similar project?
+
+	**Connect to outcomes** - Link plan effectiveness to final solution quality
+
+	**Show growth** - Demonstrate what you learned about project management
+
+	## **🎯 Remember:**
+
+	This isn't about having a perfect plan - it's about **demonstrating thoughtful analysis** of your planning effectiveness and **showing professional growth** in project management skills!
+
+	---
+
+	## Check Your Understanding
+
+	**1.** *"My plan was effective because I finished the project."* Which band does that reach?
+
+	>| ### Answer
+	>| Band 1–2 at best. Finishing is not evidence about the plan. A band 7–8 answer names specific changes, says how each affected completion, and only then judges the plan.
+
+	**2.** Where does the evidence for C10-4 come from?
+
+	>| ### Answer
+	>| From your C10-3 record — the annotated baseline, the logs and the commit dates — plus the C01 plan you started from. C10-4 adds no new evidence; it judges what C10-3 collected.
+
+	**3.** You underestimated testing by four days but delivered on time because you had padded the coding phase. Is that a strength or a weakness of the plan?
+
+	>| ### Answer
+	>| Both, and saying so is what "evaluates" means. The estimate was wrong (a weakness in accuracy) and the padding absorbed it (a strength in adaptability). A verdict that names both, with the dates behind them, beats one that picks a side.
/dev/null .. sd/C10/Reading a Git Log.md
@@ 0,0 1,233 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C10-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# Reading a Git Log as a Project Record
+
+	*Three real Year 12 commit histories, anonymised. This is what a marker sees when they open yours.*
+
+	> [!NOTE]
+	> **The band this serves.** C10-3, 7–8: *"Uses adjustments or logs/journals to document and explain the modifications made to the initial project plan."* A commit history is a log. On its own it is a thin one; it becomes strong when the messages, and the log files committed alongside the code, explain what changed and why.
+
+	## The two commands
+
+	Run either one inside your project folder. The second is the one worth keeping — send it to a file and commit it: `git log --pretty=format:"%h %ad | %s" --date=iso > C10/plan-log.txt`
+
+	```
+	git log --oneline --decorate --graph --date=short
+	git log --pretty=format:"%h %ad | %s" --date=iso
+	```
+
+	## What the shape of a log tells a marker
+
+	```mermaid
+	gantt
+	title Where the commits actually landed — three real logs, anonymised
+	dateFormat YYYY-MM-DD
+	axisFormat %d %b
+	section Log A · 6 commits
+	early work :a1, 2025-06-12, 2025-06-24
+	nothing committed :done, a2, 2025-06-24, 2025-08-10
+	both submissions, 2 min apart :milestone, a3, 2025-08-10, 0d
+	section Log B · 17 commits
+	steady work, some branching :b1, 2025-06-12, 2025-07-29
+	nothing committed :done, b2, 2025-07-29, 2025-08-10
+	submission :milestone, b3, 2025-08-10, 0d
+	section Log C · 43 commits
+	steady work, weekly logs :c1, 2025-06-05, 2025-08-08
+	```
+
+	*Before anyone reads a single message, the dates draw the term. Log A has a seven-week hole and two commits two minutes apart at the end; Log C has a trail you could write a C10-3 answer straight off. Same task, same term.*
+
+	## Log A — six commits
+
+	*Four commits in the first fortnight, then nothing for seven weeks, then both submissions two minutes apart. There is no record here of anything changing, so there is nothing for an annotation to cite.*
+
+	```
+	* 315926d (HEAD -> master, origin/master, origin/HEAD) SAT7 Submission
+	* 0c1b34f SAT6 submission
+	* cb93486 feeback response message
+	* 983e56b update
+	* f335202 basic image ai code
+	* 7260fdc Initial commit
+	```
+
+	```
+	student@laptop project % git log --pretty=format:"%h %ad | %s" --date=iso
+	315926d 2025-08-10 15:50:52 +1000 | SAT7 Submission
+	0c1b34f 2025-08-10 15:48:15 +1000 | SAT6 submission
+	cb93486 2025-06-24 13:01:19 +1000 | feeback response message
+	983e56b 2025-06-23 15:22:26 +1000 | update
+	f335202 2025-06-13 12:00:35 +1000 | basic image ai code
+	7260fdc 2025-06-12 12:06:32 +1000 | Initial commit
+	```
+
+
+	## Log B — seventeen commits
+
+	*Steady work with branches and merges, and dated log files committed alongside the code — `log-2025-06-20.md`, `log-2025-06-23.md`, `log-2025-07-25.md`. Those log files are the C10-3 evidence; the code commits are the corroboration.*
+
+	```
+	* 2ddb1f0 (HEAD -> main, origin/main, origin/HEAD) SAT6 Submission
+	* 6772106 (tag: SAT6-ready) Create log-2025-07-25.md
+	* e05c066 Updates
+	* 4545ee8 added tidbits folder for tidbits
+	* 6fa86df Added Code
+	* 13325d1 Merge branch 'main' of https://github.com/example/project
+	|\
+	| * 4b21469 Create SRS.md
+	| * 5200f8f Create log-2025-06-23.md
+	| * e3d831c Update log-2025-06-20.md
+	| * 3ba0e74 Update log-2025-06-20.md
+	| * b0806ef Create log-2025-06-20.md
+	* | 17e4fed Working on main menu
+	* | e6f656a added button
+	|/
+	* cf11366 Update README.md
+	* 1a44882 16/06/2025. Readme.md updated
+	* 627535b Test Changes
+	* 896368b Create Godot Project
+	```
+
+
+	```
+	2ddb1f0 2025-08-10 16:28:36 +1000 | SAT6 Submission
+	6772106 2025-07-29 13:04:58 +1000 | Create log-2025-07-25.md
+	e05c066 2025-07-27 16:29:41 +1000 | Updates
+	4545ee8 2025-07-25 12:06:22 +1000 | added tidbits folder for tidbits
+	6fa86df 2025-07-25 12:01:17 +1000 | Added Code
+	13325d1 2025-06-26 11:33:04 +1000 | Merge branch 'main' of https://github.com/example/project
+	4b21469 2025-06-26 11:25:13 +1000 | Create SRS.md
+	17e4fed 2025-06-24 13:01:03 +1000 | Working on main menu
+	5200f8f 2025-06-23 15:30:25 +1000 | Create log-2025-06-23.md
+	e3d831c 2025-06-23 15:20:04 +1000 | Update log-2025-06-20.md
+	e6f656a 2025-06-20 12:09:17 +1000 | added button
+	3ba0e74 2025-06-20 11:58:21 +1000 | Update log-2025-06-20.md
+	b0806ef 2025-06-20 11:56:45 +1000 | Create log-2025-06-20.md
+	cf11366 2025-06-16 14:21:08 +1000 | Update README.md
+	1a44882 2025-06-16 14:20:27 +1000 | 16/06/2025. Readme.md updated
+	627535b 2025-06-12 12:21:54 +1000 | Test Changes
+	896368b 2025-06-12 12:18:22 +1000 | Create Godot Project
+	```
+
+	## Log C — forty-three commits
+
+	*Small, frequent commits across the whole term, with numbered logs. The messages are informal and some say almost nothing — that matters less than you would think. The dates, the cadence and the numbered log files are what a marker can use.*
+	```
+	student@laptop project % git log --oneline --decorate --graph --date=short
+	* 4f8758e (HEAD -> main, origin/main, origin/HEAD) Buttons complete hell yeah :D
+	* f41017b GOT MOST BUTTONS WOKRING WOOOHOOO
+	|\
+	| * f6b7415 Update Log 05.md
+	| * ae82aca Create Log 05.md
+	* | 25b0ce4 GOT (most) BUTTONS WORKING WOOOOOOOOOOOO)
+	|/
+	* f0bce3d All functonal requirements (that are still valid) have been met
+	* fbb7778 MVP almost complete
+	* 74aae74 Create log 04.md
+	* 3d452dc A simple version of the main song scene is complete
+	* 7b66e55 Got the staarting music after tapping 16 times working!!!!
+	* 56b9f12 k
+	|\
+	| * 4dfc924 Update and rename Log 03 to Log 03.md
+	| * 516938b Create Log 03
+	* | 7ba030a Got the standard deviation equation working
+	|/
+	* e05e69e More stuff set up
+	* 9f74fdc starting to get the main system wokring.. not really but :P
+	* edb457e uh
+	|\
+	| * 5629d8c Update log02.md
+	* | 4dd1db8 Added recourses
+	|/
+	* ed4f1d4 ds
+	* 94e22c5 uh kinda useless
+	* ef72a41 figured saving
+	* c30c2a2 Update log02.md
+	* 4d754a7 Update log02.md
+	* c98b612 Create log02.md
+	* 4fa565d Started Creating Class
+	* 9605c8f uh
+	|\
+	| * c962668 Update log01.md
+	| * 88b94ec Create log01.md
+	* | 1057653 click detection set up
+	|/
+	* b39c1cd Just in case
+	* 7812305 does this work
+	* 67d6eff add song menu
+	* e5c4dc1 Changed hitbox of button to a collision polygon
+	* 71f82f7 Created Menu
+	* 2b83bb5 Practice end
+	* 71b4b0e New stuff from practice
+	* 5de717f hi
+	* 58d28fb Updated Read Me
+	* 674aca7 m
+	* ec57136 Update README
+	* 8cffaae Setup Godot
+	* f24b245 Initial commit
+	```
+
+
+	```
+	student@laptop project % git log --pretty=format:"%h %ad | %s" --date=iso
+	4f8758e 2025-08-08 14:27:08 +1000 | Buttons complete hell yeah :D
+	f41017b 2025-08-08 14:20:57 +1000 | GOT MOST BUTTONS WOKRING WOOOHOOO
+	25b0ce4 2025-08-08 14:19:14 +1000 | GOT (most) BUTTONS WORKING WOOOOOOOOOOOO)
+	f6b7415 2025-07-25 12:04:25 +1000 | Update Log 05.md
+	ae82aca 2025-07-25 11:57:19 +1000 | Create Log 05.md
+	f0bce3d 2025-07-19 11:37:40 +1000 | All functonal requirements (that are still valid) have been met
+	fbb7778 2025-07-19 11:19:36 +1000 | MVP almost complete
+	74aae74 2025-07-17 14:06:07 +1000 | Create log 04.md
+	3d452dc 2025-07-17 14:02:14 +1000 | A simple version of the main song scene is complete
+	7b66e55 2025-07-17 13:25:59 +1000 | Got the staarting music after tapping 16 times working!!!!
+	56b9f12 2025-07-10 10:01:50 +1000 | k
+	7ba030a 2025-07-10 10:01:21 +1000 | Got the standard deviation equation working
+	4dfc924 2025-07-10 09:46:30 +1000 | Update and rename Log 03 to Log 03.md
+	516938b 2025-07-10 09:37:02 +1000 | Create Log 03
+	e05e69e 2025-07-10 09:31:02 +1000 | More stuff set up
+	9f74fdc 2025-06-27 10:09:33 +1000 | starting to get the main system wokring.. not really but :P
+	edb457e 2025-06-25 10:46:22 +1000 | uh
+	5629d8c 2025-06-25 10:45:26 +1000 | Update log02.md
+	4dd1db8 2025-06-24 15:13:32 +1000 | Added recourses
+	ed4f1d4 2025-06-24 13:01:15 +1000 | ds
+	94e22c5 2025-06-24 13:00:43 +1000 | uh kinda useless
+	ef72a41 2025-06-24 12:00:09 +1000 | figured saving
+	c30c2a2 2025-06-24 11:39:18 +1000 | Update log02.md
+	4d754a7 2025-06-24 11:39:00 +1000 | Update log02.md
+	c98b612 2025-06-24 11:36:21 +1000 | Create log02.md
+	4fa565d 2025-06-24 11:35:12 +1000 | Started Creating Class
+	9605c8f 2025-06-23 21:12:48 +1000 | uh
+	1057653 2025-06-23 21:11:03 +1000 | click detection set up
+	c962668 2025-06-20 14:24:26 +1000 | Update log01.md
+	88b94ec 2025-06-20 12:08:41 +1000 | Create log01.md
+	b39c1cd 2025-06-20 12:03:14 +1000 | Just in case
+	7812305 2025-06-16 14:23:15 +1000 | does this work
+	67d6eff 2025-06-16 14:19:01 +1000 | add song menu
+	e5c4dc1 2025-06-16 09:55:09 +1000 | Changed hitbox of button to a collision polygon
+	71f82f7 2025-06-15 12:47:15 +1000 | Created Menu
+	2b83bb5 2025-06-13 12:02:51 +1000 | Practice end
+	71b4b0e 2025-06-13 11:54:14 +1000 | New stuff from practice
+	5de717f 2025-06-12 12:07:18 +1000 | hi
+	58d28fb 2025-06-06 11:47:39 +1000 | Updated Read Me
+	674aca7 2025-06-05 15:21:00 +1000 | m
+	ec57136 2025-06-05 15:19:35 +1000 | Update README
+	8cffaae 2025-06-05 15:17:42 +1000 | Setup Godot
+	f24b245 2025-06-05 14:51:31 +1000 | Initial commit
+	```
+
+	---
+
+	## Check Your Understanding
+
+	**1.** Log A's last two commits are two minutes apart and are the only commits in seven weeks. What does that cost the student under C10-3?
+
+	>| ### Answer
+	>| Almost everything above band 1–2. There is no record of modifications to annotate, describe, explain or evaluate — the history shows one drop, not a project. C10-3 scores what the evidence carries.
+
+	**2.** Log C's messages include "uh", "ds" and "hi". Does that sink it?
+
+	>| ### Answer
+	>| No. Untidy messages are not the instrument being marked — the *record of changes* is, and Log C has numbered log files and a dense date trail. Better messages would make the record easier to cite, but the trail is there.
+
+	**3.** You have written nothing down all term. What is the honest thing to do before class write 3?
+
+	>| ### Answer
+	>| The commit-now prep step: commit your plan's current state — a Gantt or board export — with an honest note of what has changed since your C01 baseline, and save your `git log` output beside it. An honest, thin record scores; an invented one contradicts the server dates.
/dev/null .. sd/C10/Recording Project Progress.md
@@ 0,0 1,123 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C10-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# Recording Project Progress — a 20-Minute Practice Task
+
+	*A worked scenario for practising the three C10-3 recording techniques on somebody else's project, before you apply them to your own.*
+
+	> [!NOTE]
+	> **The band this serves.** C10-3, 7–8: *"Uses adjustments or logs/journals to document and explain the modifications made to the initial project plan."* The three techniques below — annotation, task adjustment, log entry — are exactly the instruments that descriptor names.
+
+	## Task Overview
+
+	**Duration:** 20 minutes
+	**Skills:** SD41KS01 - Monitor, modify and annotate project plans as necessary
+	**Assessment:** C10-3 preparation
+
+	## Scenario
+
+	You're the cybersecurity developer for an online quiz application used by schools. Your original project plan estimated:
+
+	- User authentication system: 2 days
+	- Data encryption implementation: 2 days
+	- Security testing and vulnerability assessment: 1 day
+	- **Total: 5 days**
+
+	**Reality:** It's now Day 4, and you've discovered several critical security issues that will extend your timeline significantly.
+
+	```mermaid
+	gantt
+	title The quiz-app scenario — planned 5 days, actual 8
+	dateFormat YYYY-MM-DD
+	axisFormat Day %d
+	section Planned
+	Authentication :p1, 2025-01-01, 2d
+	Encryption :p2, 2025-01-03, 2d
+	Security testing :p3, 2025-01-05, 1d
+	section Actual
+	Authentication +1 (two-factor) :crit, a1, 2025-01-01, 3d
+	Encryption +1 (end-to-end) :crit, a2, 2025-01-04, 3d
+	Testing +1 (SQL injection) :crit, a3, 2025-01-07, 2d
+	```
+
+	*Read the slip off the bars: every task moved by one day, and because they run in sequence the finish date moved by three. This is the picture your annotations have to explain.*
+
+
+	## Your Task
+
+	Apply the three project recording techniques to document what's happening:
+
+	### 1. Annotations to Project Plans
+
+	**Tool:** Create a simple Gantt chart (GitHub Projects, Excel, or hand-drawn)
+
+	**Instructions:**
+
+	- Mark your original timeline
+	- Add annotations showing:
+	- Authentication took 3 days (not 2) due to implementing two-factor authentication for teacher accounts
+	- Data encryption will need 3 days (not 2) because quiz answers require end-to-end encryption
+	- Security testing needs 2 days (not 1) after discovering SQL injection vulnerabilities
+
+	**What to annotate:** Why security requirements changed, not just that they changed
+
+	### 2. Adjustments to Tasks
+
+	**Tool:** Create 3 GitHub Issues or log entries
+
+	**Record these cybersecurity task modifications:**
+
+	- **Original task:** "Basic user login system"
+
+	- **Modified task:** "Multi-factor authentication with role-based access (student/teacher/admin)"
+
+	- **Reason:** School district requires enhanced security after recent data breaches
+
+	- **Original task:** "Encrypt stored quiz data"
+
+	- **Modified task:** "Implement AES-256 encryption for data at rest and TLS 1.3 for data in transit"
+
+	- **Reason:** Compliance with student privacy regulations
+
+
+	### 3. Monitoring Progress Using Logs/Journals
+
+	**Tool:** OneNote page or simple document
+
+	**Create a 4-day cybersecurity progress log:**
+
+	- **Day 1:** "Basic login working, but district security officer requested two-factor authentication review"
+	- **Day 2:** "Implementing SMS-based 2FA, discovered need for backup codes for students without phones"
+	- **Day 3:** "Encryption module complete, but penetration testing revealed session hijacking vulnerability"
+	- **Day 4:** "Behind schedule but security compliance significantly improved - no data breach risks identified"
+
+	## Deliverables
+
+	1. Annotated cybersecurity project timeline showing changes
+	2. Three security task adjustment records with compliance reasoning
+	3. Four-day cybersecurity progress journal
+
+	## Success Criteria
+
+	✅ Demonstrates understanding of **why** security changes occurred, not just **what** changed
+	✅ Shows practical application of each recording technique in cybersecurity context
+	✅ Prepares evidence for C10-3 assessment requirements
+	✅ Reflects real-world cybersecurity project challenges
+
+	## Reflection Questions
+
+	1. Which technique gave you the clearest picture of cybersecurity project changes?
+	2. How would this security documentation help you plan future cybersecurity implementations?
+	3. What would happen if security modifications weren't properly recorded for compliance audits?
+	4. Why is thorough documentation especially critical in cybersecurity projects?
+
+	## Real-World Connection
+
+	**Cybersecurity projects often require extensive documentation because:**
+
+	- Compliance audits need detailed change records
+	- Security incidents require traceability of all modifications
+	- Budget justification for extended timelines due to security requirements
+	- Team handovers must include complete security implementation history
+
+	---
+
+	**Assessment Connection:** This task directly prepares you for demonstrating C10-3: "Documents the modifications made to the initial project plan throughout the duration of the project" while building cybersecurity awareness.
\	No newline at end of file
/dev/null .. sd/C10/Tracking Plan Changes.md
@@ 0,0 1,213 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C10-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# Tracking Plan Changes — Annotated Gantt Charts and Project Logs
+
+	*The two instruments C10-3 is marked from, and the meta-log that turns them into a judgement. Read it before class write 3.*
+
+	> [!NOTE]
+	> **The bands this serves.** C10-3, 3–4: *annotations outline the modifications*. 5–6: *annotations describe them*. 7–8: *adjustments or logs/journals document and explain them*. 9–10: *evaluates the modifications*. Each rung adds something — an annotation that only says *what* changed cannot reach 7–8, and no amount of logging reaches 9–10 without a verdict.
+
+	```mermaid
+	flowchart LR
+	G["Annotated Gantt<br/>baseline vs actual"] --> M
+	E1["Log entry<br/>date · what changed · why<br/>impact · who decided · evidence"] --> M
+	E2["Log entry"] --> M
+	E3["Log entry"] --> M
+	M["The meta log — your final entry<br/>What pattern of changes?<br/>Reactive or proactive?<br/>Did they help or harm?"] --> C4["C10-4<br/>plan effectiveness"]
+	```
+
+	*Everything funnels into one entry. The individual logs are evidence; the meta-log is the judgement, and it is also what C10-4 draws on.*
+
+	## What is this?
+	By reviewing **how and why your plan changed**, you gain evidence of adaptability and critical decision-making—not just task tracking.
+
+	**Purpose:** Document project modifications with reflective analysis for C10-3 assessment.
+
+	---
+
+	## 🎯 Choose Your Tracking Method
+
+	### Option 1: Traditional Approach
+
+	- **📊 1. Annotated Gantt Chart**
+	- 📝 2. Project Log File
+
+	### Option 2: GitHub Approach
+
+	- 📊 1. GitHub Projects (Gantt view)
+	- 📝 2. GitHub Issues (tracking)
+
+	---
+
+	## 📊 Annotated Gantt Chart Guide
+
+	### What to Show:
+
+	- 🔹 **Original timeline** (from Unit 3) vs **actual timeline**
+	- 🔹 **Task modifications**: Added, removed, or changed tasks
+	- 🔹 **Duration changes**: Tasks that took longer/shorter than planned
+	- 🔹 **Milestone shifts**: Deadlines that moved
+	- 🔹 **Resource adjustments**: When you needed help or changed priorities
+
+	### How to Annotate:
+
+	#### Traditional Method (GanttProject/Excel):
+	```
+	Annotation Examples:
+	• "Extended coding by 3 days - alpha testing revealed more bugs"
+	• "Added validation task - requirements changed after client feedback" • "Moved documentation earlier - needed for beta testing prep"
+	• "Reduced UI design time - focused on functionality first"
+	```
+
+	#### GitHub Projects Method:
+	- Use **milestone descriptions** to explain changes
+	- Add **timeline comments** on project board
+	- Use **labels** to categorise change types (scope, technical, timeline)
+	- **Project notes** explain major modifications
+
+	---
+
+	## 📝 Project Logs Guide
+
+	### What to Track:
+	- 🔹 **Date and time** of each change
+	- 🔹 **What changed** (task, deadline, scope, resources)
+	- 🔹 **Why it changed** (testing results, technical issues, feedback)
+	- 🔹 **Impact** (how it affected other tasks)
+	- 🔹 **Decision maker** (you, teacher feedback, user input)
+
+	### Log Categories:
+
+	- **Scope changes**: New/removed features - *Did this add value or cause delay?*
+	- **Timeline adjustments**: Extended/compressed tasks - *Did this make the project finish earlier/later?* - **Technical issues**: Bug fixes, tool problems - *Did this improve solution quality?*
+	- **Resource changes**: Help needed, priority shifts - *Did this make development more efficient?*
+	- **User feedback**: Changes from testing - *Did this better meet user needs?*
+	- **AI assistance**: When AI tools helped/hindered development progress - *Did this speed up or complicate development?*
+
+	### 💭 Add Reflection Checkpoints:
+
+	After major milestones (alpha testing, beta testing, major feature completion), write **1-2 reflective sentences**:
+
+	- *"After alpha testing, I realized my original timeline was too optimistic for validation work"*
+	- *"Beta feedback showed users needed simpler navigation - good thing I built this modularly"*
+
+	### 📸 Include Evidence Annotations:
+
+	For 2-3 key log entries, add supporting evidence:
+
+	- **Screenshot**: Before/after interface changes
+	- **Code snippet**: Key bug fix or improvement
+	- **Timeline visual**: Gantt chart section showing the change
+	- **Caption**: *"This validation fix prevented major user errors"*
+
+	### Option 1: Traditional Log File
+
+	#### Simple Log Template:
+	```
+	WEEK 4 REVIEW (Post-Alpha Testing):
+	DATE: 2025-08-12
+	CHANGE: Extended coding phase by 2 days
+	REASON: Alpha testing found validation errors
+	IMPACT: Beta testing delayed by 1 day, but solution quality improved
+	DECISION: Worth the delay to fix critical bugs
+	EVIDENCE: [Link to testing results, commit #a3b2c1]
+	REFLECTION: Original timeline was too optimistic for validation work
+
+	WEEK 6 REVIEW (Post-Beta Testing):
+	DATE: 2025-08-18 CHANGE: Added user tutorial feature
+	REASON: Beta testers confused by interface
+	IMPACT: Extra 3 days development, but much better usability scores
+	DECISION: Essential for user adoption
+	EVIDENCE: [Screenshots of old vs new interface]
+	REFLECTION: Should have planned for user guidance from the start
+	```
+
+
+
+
+	---
+
+	### Option 2: GitHub Issues Method
+
+	#### Issue Structure:
+	```
+	Title: [TIMELINE] Extended coding phase
+	Labels: timeline-change, technical-issue
+	Milestone: Week 5 Development
+
+	Description:
+	**What Changed:** Coding phase extended by 2 days
+	**Reason:** Alpha testing revealed validation errors
+	**Impact:** Beta testing timeline pushed back
+	**Status:** Resolved - bugs fixed, back on track
+
+	**Evidence:** - Link to testing results
+	- Commit hash of bug fixes
+	- Updated project timeline
+	```
+
+	#### GitHub Projects Benefits:
+	- **Visual project board** with timeline and status tracking
+	- **Issue linking** to commits and evidence
+	- **Real-world project management** practice
+
+	---
+
+	## ⚠️ Don't Forget the Meta Log:
+
+	**Final log entry (C10-3-9)**: Evaluate all modifications you made to your initial project plan.
+
+	**Meta-Reflection Questions:**
+
+	- What **pattern** of changes occurred? (Mostly scope creep? Technical challenges? Good adjustments?)
+	- Were changes **reactive** (fixing problems) or **proactive** (improving quality)?
+	- Did modifications **improve** or **harm** project success?
+	- What does this tell you about your **original planning**?
+
+	This meta-analysis becomes crucial evidence for C10-4 effectiveness assessment.
+
+	---
+
+	## 📋 Documentation Checklist
+
+	**For C10-3 Assessment, Include:**
+
+	- 🔲 **Original plan** (baseline for comparison)
+	- 🔲 **All modifications** documented with dates
+	- 🔲 **Reasons for changes** clearly explained
+	- 🔲 **Impact analysis** (how changes affected other tasks)
+	- 🔲 **Change categories** (scope, timeline, technical, resources)
+	- 🔲 **Resolution status** (how issues were resolved)
+
+	---
+
+	**✨ Pro-tips:**
+
+	**Document as you go** - Don't try to recreate logs at the end
+	**Be specific** - "Testing revealed bugs" vs "Alpha testing found 3 validation errors in user input"
+	**Show impact** - Explain how each change affected the bigger picture
+	**Use timestamps** - Real dates and times show authentic tracking
+	**Link evidence** - Connect logs to actual project artifacts (commits, tests, etc.)
+
+	**🎯 Remember:**
+
+	C10-4 will use this tracking data to assess your plan's effectiveness, so **detailed logs = better C10-4 reflection**!
+
+	---
+
+	## Check Your Understanding
+
+	**1.** Which band does this log entry reach, and what would lift it one rung?
+	*"Week 4: extended coding by 2 days."*
+
+	>| ### Answer
+	>| Band 3–4 — it outlines the modification and nothing else. Adding *why* and its *impact* ("alpha testing found three input-validation errors; beta testing slipped a day but the build was stable") moves it into explanation, which is the 7–8 territory.
+
+	**2.** Why does the guide insist on real dates and timestamps rather than tidy round numbers?
+
+	>| ### Answer
+	>| Because the record has to be authentic, and your teacher reads commit dates from the server. A log reconstructed at the end contradicts the commit history it claims to describe.
+
+	**3.** What separates the meta-log from the entries above it?
+
+	>| ### Answer
+	>| The entries record; the meta-log judges. It looks across all the changes for a pattern — mostly scope creep? mostly technical? reactive or proactive? — and says whether the modifications helped or harmed the project.
sd/VCE Software Development Hub.md ..
@@ 28,6 28,7 @@
	- [C07 — Skills in Developing the Software Solution](/sd/C07/C07-home)
	- [C08 — Skills in Debugging and Alpha Testing the Software Solution](/sd/C08/C08-home)
	- [C09 — Skills in Conducting Beta Testing](/sd/C09/C09-home)
+	- [C10 — Skills in Evaluating the Solution and Assessing the Project Plan](/sd/C10/C10-home)
	## Tools