CLN v2.2 · Live Examples · Feb 2026
CLN Scripts
Each script below is rendered HTML from raw CLN source.
Hover operators for context menus ·
Click spoilers to reveal hidden content ·
Consecutive
( ) blocks at the same indent level → flex-row columns.
01/
Project: Parallel Feature Tracks
PROJECT
Two parallel development tracks — Backend and Frontend — with cross-references between dependent tasks,
spoiler-wrapped implementation details, and task status markers.
// ##overview · Overview
=
Goal: give users real-time action statistics — zero-latency dashboard
@
deadline: 2026-04-01 ☐
// ##backend · Backend
=
Server-side — WebSocket API + task queues
.
build WebSocket API ☐
|
library: socket.io
!
overload risk at 10k concurrent connections !!
*
mitigation: horizontal scaling via Redis
cluster of 3 nodes, Pub/Sub channels per user segment, sticky sessions via nginx
.
configure task queues ☐
@
depends on »WebSocket API
// ##frontend · Frontend
=
Client-side — charts dashboard + WebSocket events
.
build charts dashboard ☐
|
library: Chart.js
*
design per
Figma file v3.2 — component library "Analytics v2", frame "Dashboard · Desktop"
.
handle WebSocket events + reconnect logic ☐
!
must implement exponential backoff on disconnect !!
// ##deps · Critical Dependencies
@
integration testing scheduled: 2026-03-25 ☐
?
What is the biggest integration risk in this project?
Protocol mismatch — if Backend ships a WebSocket event schema that Frontend doesn't handle, the dashboard silently shows stale data. The fix: define the event contract in a shared CLN spec file before either track starts coding.
02/
Topic: Sorting Algorithms
EDUCATIONAL
Quick Sort vs Merge Sort — a parallel comparison with spoiler-hidden self-test answers.
Demonstrates CLN as a study document that is also an Anki source.
=
Both algorithms average O(n log n) — difference is in guarantees and memory
?
Which has guaranteed O(n log n) in worst case?
Merge Sort — Quick Sort degrades to O(n²) on already-sorted input without randomisation.
// ##quick · Quick Sort
=
divide-and-conquer — partition around pivot, recurse
+
in-place — O(1) extra memory
+
fast cache performance — sequential access
-
unstable — equal elements may reorder
!
worst case O(n²) — triggered by sorted/reverse-sorted input !!
*
prevention:
randomised pivot selection — reduces worst-case probability to astronomically small. Alternatively: median-of-three pivot.
→
best for: arrays in RAM, average-case performance priority
// ##merge · Merge Sort
=
divide-and-conquer — split, sort halves, merge
+
guaranteed O(n log n) — no worst-case degradation
+
stable — equal elements preserve original order
-
requires O(n) extra memory — not in-place
*
ideal for:
linked lists (no random access needed), external sort on disk, any use case requiring stable sort (e.g. sort by last name preserving first-name order).
→
best for: linked lists, large external datasets, stable sort requirement
?
Which algorithm for sorting a doubly-linked list?
Merge Sort. It doesn't need random access — it splits the list by pointer manipulation and merges in O(n log n). Quick Sort on a linked list is O(n²) in practice because pivot-based partitioning requires O(n) traversal each time.
?
What single change makes Quick Sort safe for production?
Randomised pivot. A single line: swap arr[pivot] with arr[rand(low, high)] before partitioning. This makes the O(n²) worst case probability-1/n! rather than deterministic.
03/
MDA: Remote Work Impact on Productivity
MDA · depth 3
Multi-Dimensional Analysis with two top-level parallel dimensions.
Each dimension contains a nested parallel block for sub-categories.
Cross-references link to the recommendations section.
// ##dim1 · Individual Productivity
.
Factors affecting individual output
Upsides
+flexible schedule
+no commute cost
+fewer office interruptions
*
data:
Owl Labs 2023 — 77% of respondents reported higher productivity when remote.
Downsides
-blurred work-life boundary
-sense of isolation
!
burnout risk — boundary erosion leads to always-on behaviour !!
→
see »recommendations for mitigation
// ##dim2 · Team Synchronisation
.
Effects on collaboration and decision speed
Async Comms
+more deliberate responses
+written record by default
-decision latency increases
~
tension: speed vs quality of decisions
Resolution depends on decision type: reversible decisions → async is fine. Irreversible or high-stakes → synchronous session required.
Tools & Process
|Slack · Zoom · Miro · Notion
!tools don't fix culture — structure does !!
*
critical practice: »document all decisions in CLN with cross-refs
// ##arch · Recommendations
=
all key decisions documented in CLN files with cross-references
.
establish async-first defaults: every meeting produces a CLN decision record
.
define "synchronous triggers" — the exact conditions that warrant a live call
→
outcome: team operates at async speed with sync-quality decisions on critical items
?
What is the third-order cascade effect of remote work on knowledge retention?
Tacit knowledge atrophies. In-office, knowledge transfers informally through proximity. Remote work forces explicit documentation or it disappears when people leave. CLN as a mandatory decision-record format directly addresses this — it converts tacit decisions into retrievable structured artefacts.
04/
Task: Tech Stack Choice for MVP
DECISION
Two options evaluated in parallel with dense inline spoilers.
A decision criterion block with a spoiler answer. Demonstrates
CLN as a decision record — the reasoning is preserved, not just the outcome.
=
Goal: ship working prototype fast, minimal cost, room to scale
@
decision deadline: 2026-03-15 ☐
// ##opt-a · Option A — Python Monolith
.
Django + DRF + PostgreSQL
+
rapid development —
full CRUD in 1–2 days using DRF ModelViewSet + serialisers. Django admin = free back-office.
+
batteries included —
auth, migrations, ORM, admin panel, form validation — all built-in. Zero glue work.
-
GIL limits concurrency —
Python's Global Interpreter Lock prevents true parallel thread execution. Fine for I/O-bound, problematic for CPU-bound tasks at scale.
!
monolith scaling ceiling —
horizontal scaling requires stateless refactor first. Session state in DB = bottleneck at ~500 rps.
*
threshold: viable if first-month users < 500
→
verdict: fastest start, lowest ceiling
// ##opt-b · Option B — JS Fullstack
.
Node.js + Express + MongoDB
+
single language front + back —
shared types, shared validation logic, shared utility functions. Context-switch cost eliminated.
+
event-loop handles high concurrency —
Node's non-blocking I/O manages 10k+ concurrent connections on a single thread. No GIL.
+
MongoDB scales horizontally natively
-
weak typing —
runtime errors that TypeScript would catch at compile time. Mitigation: add TS from day one, but this adds ~1 week setup.
-
more boilerplate than Django —
no built-in admin, auth, or ORM. Each requires a separate library choice (Passport.js, Mongoose, AdminBro).
→
verdict: higher setup cost, no scaling ceiling for MVP range
// ##decision · Decision Criterion
?
Which option if expected growth: 1,000 users in first month?
Option B (Node.js + MongoDB). At 1k users/month the concurrency spikes (login storms, notification bursts) will hit Django's GIL ceiling. MongoDB's horizontal sharding handles the document growth without schema migrations. The extra setup cost (~1 week) is worth the headroom.
?
Which option if the team has only Python developers?
Option A — and plan a rewrite milestone at month 3. A slow production system beats a stalled project. The rewrite trigger: response time p95 > 500ms under normal load. Document this decision now so it's not a surprise later.
→
decision recorded:
Option B selected — 2026-03-10 · rationale: growth forecast 1k/month, team adding 1 JS developer, MongoDB flexibility for evolving schema during MVP iteration.
@
review this decision if growth forecast changes ☐