Commit 3a4e7e

2026-04-19 18:26:41 lisa: sd: fix TELOS URL (rename), embed Roadmap video via macro, colour AI-Disclosure flowchart, simplify T/V/E to table, rework Critical Path with Gantt-first + eyeball method

sd/AI Disclosure.md ..
@@ 8,16 8,34 @@
	flowchart TD
	A[You need to do C01 work] --> B[Use AI — ask it something]
	B --> C[Read the output carefully]
-	C --> D{Is it right for\nyour project?}
-	D -- Yes, mostly --> E[Keep what fits,\nrewrite the rest]
-	D -- No / generic --> F[Reject or heavily\nrewrite it]
-	E --> G[Open AI-disclosure-log.md\nAdd an entry: prompt · output · kept · changed]
+	C --> D{Is it right for<br/>your project?}
+	D -- Yes, mostly --> E[Keep what fits,<br/>rewrite the rest]
+	D -- No / generic --> F[Reject or heavily<br/>rewrite it]
+	E --> G[Open AI-disclosure-log.md<br/>Add an entry: prompt · output · kept · changed]
	F --> G
	G --> H[Commit to GitHub]
-	H --> I[Validation — locked conditions\nNo AI. No phone. No internet.]
-	I --> J{Can you explain\nyour decisions?}
-	J -- Yes --> K[You pass the\nauthenticity test]
-	J -- No --> L[Gap between your brief\nand your understanding shows]
+	H --> I[Validation — locked conditions<br/>No AI. No phone. No internet.]
+	I --> J{Can you explain<br/>your decisions?}
+	J -- Yes --> K[You pass the<br/>authenticity test]
+	J -- No --> L[Gap between your brief<br/>and your understanding shows]
+
+	classDef action fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
+	classDef decision fill:#fef3c7,stroke:#d97706,color:#78350f
+	classDef keep fill:#dcfce7,stroke:#16a34a,color:#14532d
+	classDef reject fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
+	classDef log fill:#ede9fe,stroke:#7c3aed,color:#4c1d95
+	classDef validate fill:#fef2f2,stroke:#991b1b,color:#7f1d1d,stroke-width:2px
+	classDef pass fill:#bbf7d0,stroke:#15803d,color:#14532d,stroke-width:2px
+	classDef fail fill:#fecaca,stroke:#b91c1c,color:#7f1d1d,stroke-width:2px
+
+	class A,B,C action
+	class D,J decision
+	class E keep
+	class F reject
+	class G,H log
+	class I validate
+	class K pass
+	class L fail
	```
	---
sd/Critical Path.md ..
@@ 2,81 2,71 @@
	Identifying the critical path is the difference between a level 9–10 project plan and a screenshot of a Gantt chart — it is the one concept the C1-3 interview tests hardest on planning.
-	{{Video|src=https://www.youtube.com/watch?v=HbynnR0VN10}}
+	## Start with a Gantt chart
-	## What is the critical path?
+	{{Video|src=https://www.youtube.com/watch?v=D9xNrD3APg4}}
-	The **critical path** is the longest chain of **dependent** tasks from the start to the end of a project. It determines the **minimum possible duration** of the project. A **dependency** exists when one task (the *successor*) cannot start until another task (the *predecessor*) is finished. Any delay on a critical path task directly delays the whole project — there is no buffer.
+	A Gantt chart shows tasks as horizontal bars on a timeline. The length of each bar = the task's duration. The position of each bar encodes dependencies: a successor task's bar can't start until its predecessor's bar ends. Your GitHub Projects **Roadmap View** is a Gantt chart — it just doesn't label the critical path for you. See [Roadmap View vs Gantt Chart](/sd/Roadmap%20View%20vs%20Gantt%20Chart) for how they compare.
-	Tasks that sit off the critical path have **slack time** (also called *float*): the amount of time they can be delayed without pushing back the project end date. Understanding which tasks have slack — and how much — is what separates a plan you can reason about from a plan that is just a list of dates.
+	## The critical path — the bottleneck
-	## Worked example
+	Think of the critical path as the **bottleneck chain**: the longest sequence of dependent tasks from the very start of your project to the very end. It sets the **minimum possible finish date**. If any task on this chain slips by a day, the whole project finishes a day late — there is no buffer anywhere along it.
-	The diagram below models a small software project. Tasks on the critical path are highlighted in red; all durations are in days.
+	## Finding it by eyeball
+
+	Here's a 19-day project with 8 tasks (A–H):
	```mermaid
-	flowchart LR
-	classDef cp fill:#e53935,color:#fff,stroke:#b71c1c
-	classDef off fill:#1565c0,color:#fff,stroke:#0d47a1
-
-	S(["Start"]):::cp
-	A["Survey users\n3 days"]:::cp
-	B["Write SRS\n5 days"]:::cp
-	C["Design UI\n4 days"]:::cp
-	D["Design data model\n3 days"]:::off
-	E["Code core features\n8 days"]:::cp
-	F["Write user docs\n3 days"]:::off
-	G["Beta test\n4 days"]:::cp
-	EN(["End"]):::cp
-
-	S --> A
-	A --> B
-	B --> C
-	B --> D
-	C --> E
-	D --> E
-	E --> F
-	E --> G
-	F --> EN
-	G --> EN
+	gantt
+	dateFormat D
+	axisFormat Day %d
+	tickInterval 1day
+
+	section Critical path
+	A : crit, a, 0, 3d
+	B : crit, b, after a, 4d
+	D : crit, d, after b, 5d
+	G : crit, g, after d, 4d
+	H : crit, h, after g, 3d
+
+	section Off-path (slack)
+	C : c, 0, 5d
+	E : e, after c, 4d
+	F : f, after b, 2d
	```
-	**Path durations (all durations in days):**
-
-	| Path | Tasks | Total |
-	|------|-------|-------|
-	| **Critical** | Start → Survey users → Write SRS → Design UI → Code core features → Beta test → End | **24 days** |
-	| Off-critical (data model branch) | … → Write SRS → Design data model → Code core features → … | 23 days |
-	| Off-critical (user docs branch) | … → Code core features → Write user docs → End | 23 days |
-
-	**Walkthrough:**
-
-	- Both *Design UI* and *Design data model* are predecessors of *Code core features* — Code cannot start until **both** are done. Design UI takes 4 days (done at day 12 after Survey + SRS); Design data model takes 3 days (done at day 11). Code must wait for day 12, so the UI branch controls when Code can start.
-	- The critical path runs: Survey users (3) → Write SRS (5) → Design UI (4) → Code core features (8) → Beta test (4) = **24 days total**.
-	- *Design data model* finishes at day 11 but Code cannot start until day 12 — it has **1 day of slack**.
-	- *Write user docs* (3 days) runs in parallel with Beta test (4 days) after Code core features. It finishes one day before Beta test, giving it **1 day of slack**.
+	Trace the chain where bars touch end-to-end with **no gap**:
-	## Slack time
+	- **A** (days 0–3)
+	- **B** (days 3–7)
+	- **D** (days 7–12)
+	- **G** (days 12–16)
+	- **H** (days 16–19)
-	**Slack time** is how much a task can slip without delaying the project end date. To calculate it:
+	**Critical path: A → B → D → G → H.**
-	> Slack = Latest Start Time − Earliest Start Time
+	### Why C, E, F aren't on it
-	Or equivalently: how long the critical path is, minus the total duration of the chain that includes this task. If the result is zero, the task is on the critical path.
+	These tasks have **slack** — they can slip without delaying the project end date. Task F finishes at day 7, but its successor G doesn't start until day 12. That's a 5-day gap: F has **5 days of slack**. You could delay F by up to 5 days and the project still finishes on time.
-	Example from the diagram above: *Design data model* has an earliest start of day 8 (after Survey users + Write SRS). Code core features must start no later than day 12 (so that the 24-day critical path is not extended). Design data model takes 3 days, so its latest start is day 9. Slack = Latest Start − Earliest Start = 9 − 8 = **1 day**.
+	### The rule
-	
-	*Image by Gcd822, CC BY-SA 4.0, via [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:CPM_with_EST,_LST,_EFT,_LFT.png).*
+	Look for the chain where there's **zero breathing room** between the end of one bar and the start of the next. That's your critical path.
	## Why it matters at validation
-	The C1-3 interview rubric explicitly requires level 9–10 students to *document dependencies and the critical path* (`C012-Roadmap-vs-Gantt.md`). A screenshot of a Roadmap View with no annotations cannot evidence this — you must add dependency arrows, highlight the critical path, and label slack time on non-critical tasks before your interview.
+	The C1-3 interview rubric requires level 9–10 students to *document dependencies and the critical path* (`C012-Roadmap-vs-Gantt.md`). A Roadmap View screenshot with no annotations cannot evidence this — you must add dependency arrows, highlight the critical path, and label slack on non-critical tasks before your interview.
	"Trace your critical path" is a Tier 4 interview question. The expected response is to point to your annotated plan and explain: which tasks form the chain, why each dependency exists, what the minimum project duration is, and which tasks have slack. Saying "I think these tasks are the most important ones" is not an answer — the critical path is defined by **dependency chains and duration**, not importance (`C013-Milestones-and-Dependencies.md`).
	> Common mistake: confusing "important tasks" with "critical path tasks." Some important tasks have slack and are not on the critical path. Some critical path tasks are routine — they are critical because of where they sit in the dependency chain, not because they are difficult.
+	## Go deeper — the maths
+
+	If you want to calculate critical path the formal way (EST, LST, EFT, LFT, float), watch this:
+
+	{{Video|src=https://www.youtube.com/watch?v=Yzmpp49KKg0}}
+
	## See also
	- [Problem-Solving Methodology](/sd/Problem-Solving%20Methodology)
sd/Roadmap View vs Gantt Chart.md ..
@@ 6,7 6,7 @@
	## Watch first (3 min)
-	[Use GitHub Roadmap to sequence tasks in a timeline view — GitHub on YouTube](https://www.youtube.com/watch?v=jV7Vdav7N3U)
+	{{Video|src=https://www.youtube.com/watch?v=jV7Vdav7N3U}}
	---
sd/T.E.L.O.S. Feasibility.md .. sd/TELOS Feasibility.md
sd/Testing vs Validation vs Evaluation.md ..
@@ 1,62 1,40 @@
	# Testing vs Validation vs Evaluation
-	Confusing these three terms in the C1-2 writing test or C1-3 interview drops marks instantly — they belong to the same PSM stage (Development) except Evaluation, which is its own stage entirely.
+	Confusing these three terms in the C1-2 writing test or C1-3 interview drops marks instantly — Testing and Validation both live in Development, while Evaluation is its own stage.
-	---
-
-	```mermaid
-	flowchart TB
-	subgraph DEV["PSM Stage 3 — Development"]
-	direction LR
-	T["**Testing**\n──────────\nDoes the program\nwork correctly?\n\nExample: enter 25\nin age field →\ncorrect output"]
-	V["**Validation**\n──────────\nIs the input\nreasonable?\n\nExample: reject −3\nas an age before\nprocessing starts"]
-	end
-	subgraph EVAL["PSM Stage 4 — Evaluation"]
-	direction LR
-	E["**Evaluation**\n──────────\nDoes the solution\nmeet its criteria?\n\nExample: does the\nfinished app satisfy\nall requirements?"]
-	end
-	DEV --> EVAL
-	```
+	## The three at a glance
-	---
+	| Term | PSM stage | Purpose | Concrete example |
+	|------|-----------|---------|------------------|
+	| Testing | Development | Does the program run correctly? | Entering `25` into an age field gives the expected output |
+	| Validation | Development | Is the input reasonable before processing? | Rejecting `−3` or `"abc"` as an age before any calculation runs |
+	| Evaluation | Evaluation | Does the finished solution meet its criteria? | "Does it satisfy all functional requirements listed in the SRS?" |
	## Testing
	Testing checks that the program **runs correctly** — given an input, does it produce the expected output? You write test cases before or during coding and run them as you build. Testing catches bugs: wrong calculations, broken logic, features that don't behave as designed. It happens inside the **Development** stage.
-	**Example:** You enter `25` into an age field and expect the program to calculate a result based on that age. If the output matches what you designed, the test passes. If the program crashes or returns the wrong value, testing has found a bug to fix.
+	**Example:** Enter `25` into an age field and expect a calculated result. If the output matches the design, the test passes. If the program crashes or returns the wrong value, testing has found a bug to fix.
	## Validation
-	Validation checks that **data entered by the user is reasonable or acceptable** before the program processes it. It runs at the point of input — not after — and prevents garbage data from reaching the rest of the program. Like testing, validation is part of the **Development** stage.
+	Validation checks that **data entered by the user is reasonable** before the program processes it. It runs at the point of input — not after — and prevents garbage data from reaching the rest of the program. Like testing, validation is part of the **Development** stage.
-	**Example:** The same age field should reject `−3` — that is not a valid age. Validation code checks for this (e.g. `if age < 0: display error`) and stops the bad value from being used in any calculation. The program hasn't "crashed" without validation; it just silently produces a wrong answer.
+	**Example:** The age field should reject `−3`. Validation code checks for this (`if age < 0: display error`) and stops the bad value from being used in any calculation.
	> Key distinction: testing checks whether the *program* works; validation checks whether the *data* is acceptable.
	## Evaluation
-	Evaluation judges whether the **completed solution meets the evaluation criteria** set during the Design stage and addresses the original problem. It is its own PSM stage — Stage 4 — separate from Development. You are not checking individual inputs or features here; you are assessing the solution as a whole against measurable standards.
+	Evaluation judges whether the **completed solution meets the evaluation criteria** set during the Design stage. It is PSM Stage 4 — separate from Development. You are not checking individual inputs or features; you are assessing the solution as a whole against measurable standards.
-	**Example:** "Does the finished app allow 90% of beta testers to complete onboarding in under 2 minutes?" That criterion was written in Design. Evaluation collects evidence (surveys, observation, usage data) and checks whether the criterion was met.
+	**Example:** "Does the finished app allow 90% of beta testers to complete onboarding in under 2 minutes?" That criterion was written in Design. Evaluation collects evidence (surveys, observation, usage data) and checks whether it was met.
	> Common mistake: saying your solution "works" as part of Evaluation. Whether it works is testing. Evaluation asks whether it *meets user needs and requirements*.
-	---
-
-	## Quick reference
-
-	| Term | PSM stage | What it checks | Example |
-	|------|-----------|----------------|---------|
-	| Testing | Development | Program runs correctly | Entering `25` in age field → correct output |
-	| Validation | Development | Input is reasonable/acceptable | Rejecting `−3` as an age before processing |
-	| Evaluation | Evaluation | Solution meets evaluation criteria | "Does it satisfy all functional requirements?" |
-
-	---
-
	## Why it matters at validation
-	The C1-2 writing test and C1-3 interview both probe PSM knowledge directly. A question like "which Development activities does your project plan include?" expects you to name validation, testing, and documentation separately — not lump them together. At the C1-3 interview, you may be asked to point to evidence of each activity in your GitHub Projects board. If your plan only shows "testing" with no separate validation tasks, that signals a gap. At Stage 4, markers also check that you are measuring against your Design-stage criteria, not just describing whether the app runs.
+	The C1-2 writing test and C1-3 interview both probe PSM knowledge directly. A question like "which Development activities does your project plan include?" expects you to name validation, testing, and documentation separately — not lump them together. At the C1-3 interview you may be asked to point to evidence of each activity in your GitHub Projects board. If your plan only shows "testing" with no separate validation tasks, that signals a gap. At Stage 4, markers check that you are measuring against your Design-stage criteria, not just describing whether the app runs.
	See `C013-Annotate-Project-Plan.md` for guidance on annotating your plan so each PSM activity is visible to the interviewer.
sd/VCE Software Development Hub.md ..
@@ 33,7 33,7 @@
	- [Problem-Solving Methodology](/sd/Problem-Solving%20Methodology) — the four stages (Analysis, Design, Development, Evaluation) and their activities
	- [Testing vs Validation vs Evaluation](/sd/Testing%20vs%20Validation%20vs%20Evaluation) — three similar-sounding terms that mean different things
	- [Critical Path](/sd/Critical%20Path) — the longest chain of dependent tasks; how to find it and why it matters for C1-3
-	- [T.E.L.O.S. Feasibility](/sd/T.E.L.O.S.%20Feasibility) — Technical, Economic, Legal, Operational, Scheduling — the feasibility framework for your design brief
+	- [TELOS Feasibility](/sd/TELOS%20Feasibility) — Technical, Economic, Legal, Operational, Scheduling — the feasibility framework for your design brief
	- [Roadmap View vs Gantt Chart](/sd/Roadmap%20View%20vs%20Gantt%20Chart) — what GitHub Projects renders, what it doesn't, and how to close the gap
	- [AI Disclosure](/sd/AI%20Disclosure) — how to log AI use so your work stays authentic