{{ greeting }}
One live, usable, tested course by 25 October, with evidence for the next version. Tick a task when it is genuinely done — nothing here is a percentage guess, and only you can tick your own list.
{{ wCountLabel }}
Where the cohort is
Everyone sees everyone. Module work is shown as a share of your own modules, so five modules and seven modules compare fairly. This is not a race — it is how we spot who needs help before Wednesday.
Your tasks, milestone by milestone
The current milestone is open; the rest are folded away until you need them. Each milestone ends in a gate — if a gate is ticked after its date, every date after it moves by the same number of days, so your plan stays honest instead of staying tidy.
Ten tasks, once per module
Your course has its own modules with its own names, so this list is built from your course form. Name three to six modules there and the ten tasks below repeat for each one, all due by the production gate on 4 October.
This is an example. Fill in your course form and these ten tasks appear once for every module you name, with your own module titles.
Wednesdays, 90 minutes
This calendar shows the shared cohort plan — the dates that apply to almost everyone. Axèle and Esther start producing later in October and follow their own shifted dates, which appear in their own task lists, not here. Weekly through October, then two November reviews and monthly support to February. Every session has one focus and you leave with one commitment.
Feedback, slippage, and what everyone is building
2 · Put the Worker on groups.buildknowhow.net/Course-Creation-C1/api/*. It checks name + PIN against participant.pin_hash and sets a signed cookie carrying pid and role.
3 · In store.js, swap each localStorage line for the fetch already written in the comment above it.
participant(pid PK, name, pin_hash, role, topic, shift_days DEFAULT 0) progress(pid, task_id, done INT, done_on TEXT, hours REAL, note TEXT, PRIMARY KEY(pid, task_id)) course(pid PK, main_title, niche_title, icp, modules_json, updated_at) feedback(id PK, pid, submitted_at, unclear, stuck, rating INT, quote, quote_name, wants_video INT, consent INT, other, photo_key, status DEFAULT 'Not Seen')
Yes — comfortably, and it is the right choice rather than a compromise. Sixteen people × roughly 170 tasks each is about 2,700 rows in progress, plus 16 course records and a few hundred feedback rows over six months. That is a few megabytes against a 10GB ceiling, and the whole cohort dashboard is one indexed query. D1 also gives you 30-day point-in-time recovery, which matters more here than raw capacity: if someone bulk-unticks their list by accident you can wind the table back.
The rule to hold: D1 stores facts and keys, never files. Testimonial photos go to R2 and D1 keeps the object key. Putting images in the database is what turns a fast table into a slow one.
Index for the read you actually do. progress(pid, task_id) as primary key covers the personal list; add INDEX(done) for the cohort roll-up.
Add cohort_id now. When this becomes a paid product you want cohort two in the same database, not a second deployment. Retrofitting a tenant column later is the expensive version.
One write path. D1 is single-writer; at this scale that is irrelevant, but keep every write behind the Worker so ticks can't race.
Weekly export. A scheduled Worker dumping JSON to R2 costs nothing and means the cohort's six months of evidence survives any mistake, including mine.