Winter Soldier Wake — S.P.A.R.K. Chat Log

The original folder had two CSS files: wSoldierDevStylesBS5-1.css (basic nav/footer) and bs5-breakpointMediaQueries.css (a visual breakpoint debug aid with colored borders). Neither was suitable for production.

Decision: replace both with a single wSoldierWakeStyles.css covering both pages. Both pages share the same visual identity (they’re a two-step workflow), so one stylesheet is simpler to maintain than two.

The old files remain on disk but are no longer linked. No content from either file was preserved — the old CSS was minimal scaffolding, not production design.

The Activate Novices app uses a steel-blue palette derived from the cold metallic tones in buckyActivation.jpg. Since Winter Soldier Wake uses the same source images (both in the local images/ folder), the same palette was adopted wholesale:

• --ws-steel #4a9abb — mirrors --an-steel from Activate Novices
• --ws-ice #c2e8f5 — mirrors --an-ice
• --ws-steel-light #7ec8e3 — mirrors --an-steel-light
• Body background: same Memory_Suppressing_Machine_CW_1.webp with identical gradient overlay values (0.68/0.73)
• Hero background: same buckyActivation.jpg with identical linear-gradient mask

Reusing the palette instead of creating new tokens makes the two apps feel like a family. A user navigating from Activate Novices to Winter Soldier Wake (or vice versa) will recognize the visual register immediately.

Activate Novices marks JS Apps as the active nav link because it is a pure HTML5/JavaScript app. Winter Soldier Wake marks Processing as active because its core engine is p5.js — a JavaScript port of the Processing creative coding framework.

This distinction matters for students learning to categorize tools: p5.js apps belong in the Processing family, not just generic “JS Apps,” even though JavaScript is the delivery language. The nav link communicates that categorical distinction every time the page loads.

HTML best practice prefers <button> elements over <input type="button">. However, activateSoldierSketch.js directly reads and writes the .value property of pauseBtn:

pauseBtn.value = "Continue";    // paused state label
pauseBtn.value = "Pause";       // running state label

The .value property is only meaningful on form controls (input, select, textarea). On a <button> element, .value is always an empty string and setting it does nothing visible — the button text would never update. Since the sketch is the source of truth and was not to be modified, both controls stay as <input type="button">. They are styled using the input#pauseBtn and input#restartBtn CSS selectors in wSoldierWakeStyles.css.

This is a good example of “reading the existing code before changing the structure.” A casual refactor to <button> elements would have silently broken the pause label without throwing any error.

The p5.js library must load after the page’s initApp() script block but before activateSoldierSketch.js. The reason: p5.js begins executing the sketch immediately after its own library script loads, calling setup() synchronously. At that moment, wordList, appDiv, and loadingPara must already be defined as globals.

<!-- 1. App init (defines wordList, appDiv, loadingPara) -->
<script> ...initApp()... </script>

<!-- 2. p5.js library -->
<script src="p5.js CDN"></script>

<!-- 3. Sketch (references globals from step 1, uses p5 from step 2) -->
<script src="scripts/activateSoldierSketch.js"></script>

The body onload handler runs initApp() before the browser executes the inline <script> blocks at the bottom of the body — wait, actually that’s the opposite. Inline scripts at the bottom of the body run synchronously as the parser reaches them, before onload fires. The variable declarations (var wordList etc.) are hoisted, so they exist as undefined when p5 loads. The body onload then populates them before any user interaction triggers the sketch. This works because p5.js calls setup() only after the document is fully loaded — i.e., at the same time as onload. The ordering here is safe for this specific use pattern.

Winter Soldier Wake is intentionally a two-page experience: Program (enter words) → Activate (watch animation). This is a deliberate pedagogical choice from the original 2023 design — it makes localStorage tangible. Students can see: “I saved data on page 1; page 2 reads it without me passing it again.”

The hero context links reinforce the workflow in both directions:

• wakeSoldierIndex.html hero → links to winterSoldierSPARK.html (“New to Bucky’s story?”)
• activateSoldier.html hero → links back to wakeSoldierIndex.html (“Re-program the sequence”)

The sketch’s setup() function contains this line:

contentDiv = document.getElementById("content");   // line 63
myWidth = .9 * contentDiv.clientWidth;              // line 67 — crashes if null

In the original legacy HTML, the main wrapper was <div id="content" class="container mt-5 mb-5">. The upgrade renamed the container to use a class (ws-shell) but forgot to carry the id attribute forward. getElementById returned null, and accessing .clientWidth on null threw the TypeError.

The fix: add id="content" back to the shell div. The sketch also uses contentDiv in the myResizeCanvas() resize handler, so this ID must always be present on the element that wraps the canvas area.

Look at the sketch’s existing console output:

console.log("...setup...");
console.log("...draw...");
console.log("...pauseApp...");
console.log("...updateProgressBar...");
console.log("...restartSequence...");

These are breadcrumbs — deliberate console.log() statements placed at the entry point of each function. They serve a simple but powerful purpose: when something goes wrong, you can open the browser console and see exactly how far the code got before it failed.

In this debugging session, the console showed ...setup... (line 63) fired successfully, then immediately threw on line 67. That two-line trail told the whole story: setup() was reached, contentDiv was found to be null, and the crash happened before any canvas was created.

We did not need to add new breadcrumbs here because the browser’s own error output included the file name and line number. But if the error had been silent — say, the canvas appeared but rendered nothing — a breadcrumb like this at line 65 would have caught the problem instantly:

contentDiv = document.getElementById("content");
console.log("contentDiv =", contentDiv);   // would print: contentDiv = null

The general principle: place breadcrumbs at the beginning of every significant function. During development they confirm execution flow; during debugging they narrow the failure to a single function. When the code ships, they can stay — they’re invisible to users and cost almost nothing at runtime.

The bottom line: we didn’t need to add breadcrumbs this time because the console errors themselves were informative enough. But the sketch’s existing breadcrumbs were part of why the error was so easy to read — ...setup... in the output confirmed which function was active when the crash occurred. That’s the breadcrumb doing its job.

The News entry explicitly names and links to David M.’s original 2023 sketch. This is a deliberate teaching signal.

Novice contributions don’t always look polished — David’s sketch has no navbar, no styling, no loading state. It has a canvas, a word list, and the core animation logic. And that core logic is good. The entire 2026 app grows from his seed: the growing-text algorithm, the opacity fade, the word-index cycling. The TTG added the localStorage two-page pattern, the progress bar, the pause/restart system — but the kinetic idea came from David.

Linking to the original in the Legacy archive does two things: it honors the contributor, and it creates an immediate before/after for students — they can see a raw sketch next to the fully-wrapped 2026 app and understand exactly what an ecosystem upgrade adds.

The noun-arm icon (noun-arm-4667118-5C9EB3.png) already existed in the app’s images/ folder from the original 2023 build. It was referenced from processing_apps.html via a relative path into the app subfolder:

src="WSoldierWakeSPARK2026-07-21/images/noun-arm-4667118-5C9EB3.png"

This is the same arm icon used in the original legacy nav and in the Activate Novices JS Apps card. Consistent iconography across both apps signals their shared Winter Soldier universe at a glance — a reader browsing either grid will recognize the family relationship before reading a caption.

Your view is correct, and it’s worth being specific about why.

Consider what the full web looks like for the Winter Soldier family now:

movie_clips/winterSoldierSPARK.html
    ↔ WSoldierPPTVids2026-07-20/activateNovices.html
    ↔ WSoldierPPTVids2026-07-20/activateNovicesChatlog.html
    ↔ WSoldierWakeSPARK2026-07-21/wakeSoldierIndex.html
    ↔ WSoldierWakeSPARK2026-07-21/activateWSoldierChatlog.html
    ↔ _LegacyTNT/WinterSoldier2023-05-23/wSoldierActivationDavidM.html

movie_clips.html     → all of the above (via card)
processing_apps.html → Wake (card)
js_apps.html         → Activate Novices (card)
explore.html         → all of the above (via S.P.A.R.K., Processing, Simulations)
news.html            → entry #031 (Activate Novices), entry #032 (Winter Soldier Wake)

A student can arrive at any node — the movie clip, either app, either chatlog, the news entry — and from that entry point they can reach everything else. There is no required starting position. The web has no root; it has only connections.

This is, precisely, how the World Wide Web was designed to work. Tim Berners-Lee’s 1989 proposal was called “Information Management: A Proposal.” The core idea was that documents in a large organization contain references to other documents, and those references should be links — live, traversable connections, not footnotes. The web you’re building here is that idea applied at the site level.

For a classroom site, webbing has three concrete benefits:

1. Every entry point is complete. A student who finds the clip page via search has no idea the Wake app exists until they read the Overview. A student who arrives on the Processing page via the navbar has no idea the state-machine lesson in winterSoldierSPARK.html exists until they follow the link. Neither student needs to start from the home page to eventually encounter all of it.
2. Context accumulates across visits. A student who runs Winter Soldier Wake on Monday and reads the clip page on Wednesday will recognize the vocabulary instantly — growing text, fade, word-index. The webbing made those concepts visible in both places. That reinforcement is what makes things stick.
3. It models professional documentation. Software projects link between README files, changelogs, API docs, and demos. A student who grows up reading a well-linked site learns, passively, what good documentation architecture feels like.

The one discipline required: links must be meaningful. A link that says “click here” teaches nothing. A link that says “program your own activation sequence with Winter Soldier Wake” is a sentence that already gives context — the link just makes the next step frictionless. In every case in this app family, the link text explains the relationship. That’s the work.

Summary of my view: webbing is not decoration. It is the design. The individual pages are the nodes. The links are the knowledge. A page that cannot be reached from three directions isn’t fully part of the ecosystem yet.

Hiding a phrase inside a list of innocent-looking words and making students decode it is a master-class in dual encoding — the psychological principle that information processed in two modes simultaneously (verbal + puzzle-solving) is retained far longer than information delivered once, clearly.

The activation-sequence format adds a third layer: the Winter Soldier theme. Students who have seen the film immediately understand the framing. They are not memorizing a mantra; they are being programmed. The humor of the premise makes the moment memorable, and the decode process makes the content active rather than passive.

And the fourth layer — revealed next — is the most powerful of all.

The Sound of Music refrain is: “When you know the notes to sing, you can sing most anything.” The parallel structure of the two TNT mantras maps directly:

Original:   "When you KNOW the NOTES to SING, you CAN sing MOST ANYTHING"
Sample 1:   "When you HAVE deep POWER to CODE, you SHALL BLESS THINGS are BEST HELD"
Sample 2:   "COLLABORATE with your MACHINE doin’ GOOD, what IS yet UNSEEN"

(Copilot’s best guess before the reveal. Very close — but the master trick was not yet seen. Continue below.)

Both phrases earn their place. Here is why each one matters.

Classic Era: “When you have the power to code, special blessings are bestowed.”

The parallel to Do-Re-Mi is structural: Maria’s conditional (“when you know”) maps to the CS conditional (“when you have”). But the result clause is deliberately different in register. Maria promises personal agency: “you CAN sing most anything.” This phrase promises something more humble and more profound: special blessings are bestowed.

That shift from active capability to passive receipt is not an accident. “Bestowed” says: the gifts of coding come to you — they are conferred, given, granted. The implication is that coding is not just a skill you acquire; it is an initiation. When you truly have the power, the world opens doors you could not see before. Career paths, problem-solving instincts, creative freedoms, collaborative possibilities — these are not things you claim. They arrive.

The word “special” matters too. Not just blessings but special blessings — particular, specific, not available to those who don’t make the journey. The CS reading is clear: those who understand how computers think have access to a category of power that remains invisible to everyone else. The mantra names that asymmetry without bragging about it.

AI Era: “Collaborate with your machine, then code what is yet unseen.”

This is the second verse of the same song — written for a different world. Where the classic phrase is conditional (“when you have the power”), this one is imperative: collaborate. It does not say “use AI” or “prompt well.” It says collaborate — a word that implies mutual contribution, shared credit, reciprocal investment. The machine is not a tool here; it is a partner.

The then is the hinge. Collaborate first — that is the prerequisite. Then code what is yet unseen. The AI era mantra preserves the irreducibly human act at the centre: you still code. The collaboration is not a replacement for coding; it is the preparation for a kind of coding that was previously impossible. “What is yet unseen” points at the frontier — the problems not yet formulated, the programs not yet imagined, the applications not yet attempted. That is where AI-enabled developers can go.

Together, the two phrases tell a complete curriculum story:

1. Master the fundamentals (notes to code) → receive the gifts they bring (special blessings bestowed)
2. Collaborate with AI (machine partnership) → code what no one has coded before (yet unseen)

Neither phrase replaces the other. The classic phrase is still true in the AI era — fundamentals still matter; the blessings are still bestowed. The new phrase adds a second chapter, not a revised first one.

The Maria connection runs deeper than melody. Maria didn’t just teach the children notes — she taught them that music was accessible, that it belonged to them, that they could use it to name their experience and face their world. That is the same thing a great CS teacher does. The notes are different. The song is the same.

One final observation: the fact that both mantras are encoded as activation sequences — the same mechanism HYDRA used to program the Winter Soldier — is the most honest joke in the TNT collection. The students are, in fact, being programmed. And unlike Bucky, they’ll know every word of it.