Ongoing — dual-camera golf swing capture and MediaPipe analysis

ONGOING WORK

Practice improves when you can see what actually happened in the swing — not only feel. I’m building menkelabs/camera_recorder: a Python app that records synchronized dual USB cameras and runs MediaPipe pose analysis so a session can go from capture to metrics without a separate desktop tool chain.

Two cameras: face-on in front (golfer faces this lens) + down-the-line along the target line.

What it is

A Flask web GUI (browser at localhost:5000) for configure → record → analyze → compare → archive. No heavy desktop UI stack: live MJPEG previews, property sliders, and tabbed workflow on Windows and Linux.

• Dual capture — two USB cameras, threaded per-camera streams, high frame-rate recording target (up to ~120 FPS when the hardware allows).
• Camera roles — Face-On vs Down-the-Line; labels and scoring follow the role you assign.
• MediaPipe biomechanics — pose detection with metrics across rotation (shoulder/hip turn, X-factor, tempo), position (sway, spine), and body (lead arm, knee flex, weight shift).
• Swing phases — Address through Follow-through, with frame navigation and phase overlay on the charts.

The practice loop

Armed → record → analyze → review → next swing.

The interesting part is not a single recording — it’s the loop that keeps you in the bay:

• Auto swing detection — optional hands-free start/stop from real-time shoulder-turn monitoring (lightweight MediaPipe path while armed).
• Analysis playback — side-by-side annotated face-on + DTL panels, pose skeleton, speed control, low-memory JPEG frame store.
• Score + drills — 0–100 / A–F from the same good/ok ranges as the metric cards; strengths, focus areas, suggested drills.
• Compare — any two swings, delta cards, normalized timeline overlay; pin a reference “golden” swing.
• Progress — trends across sessions; favorites and practice notes on recordings.
• Archive — push sessions to an external disk with space/status in Settings.

Session mode is meant for continuous practice: stay armed, capture, review, go again — without restarting the app.

Where it stands

This is ongoing. The repo is public and usable for dual-cam practice and analysis today; the feature surface is already wide (checklist, USB bandwidth warnings, metronome, report/clip export). Expect rough edges, hardware-specific camera quirks, and iteration on scoring and detection thresholds.

Quick start from the repo:

pip install -r requirements.txt
python scripts/flask_gui.py
# open http://localhost:5000

Lower-end machines can drop MediaPipe complexity (--model-complexity 0) for faster analysis.

Why I’m writing this now

Same theme as other recent posts: keep the larger concept moving, and close the gap to working code. Here the concept is a local practice instrument — dual views, pose metrics, comparison over time — owned in a small Flask + OpenCV + MediaPipe stack rather than waiting on a full product surface.

Follow along at github.com/menkelabs/camera_recorder. More as the loop hardens.

— John · jmenke.blogspot.com

Thinking in code, validated — LLMs, not Neuralink

In 2019 I wrote that I think more than I code. The main point was not that coding was beneath me. It was that I could progress on larger concepts without implementing everything — keep moving the architecture, the paths of thought, the systems picture, even when leaf code could not keep up. That was a real compromise. The punchline, years later: we no longer have to make that compromise. With LLMs, thinking can turn into code at a pace that matches the concepts. In 2020 I looked to Neuralink as a possible path; what we got first was models that compile structured thought into candidate implementation.

The old claim: thought ↔ code. The new tool: models that turn structured thought into running code.

What I argued then

In why don’t I code as much as I think? — the year ahead (Dec 2019), the point was not laziness. It was how to keep moving when you cannot implement everything as fast as you can think it. The valuable part is the path of thought — channel it into repeatable patterns, and you can think in code even when the leaf work is unfinished. Implementation can change. The thought pattern is what matters.

“As long as thought patterns can be channeled into standard repeatable patterns, it should be possible to in-effect ‘think in code.’”

So “I think more than I code” meant: stay on the larger concepts; do not let unfinished leaf work freeze progress. That was empowering — and it was also a compromise. You accepted a gap between how far the thinking had gone and how much was actually built.

In Revisiting the idea of thinking in code — Neuralink (Aug 2020) I restated the thesis — “Code is thought and thought is code — it’s bi-directional” — and took Neuralink seriously as a candidate path: if thought could be read as signal, then thought is code in a much more direct sense. I also wrote about gamification and physical visualization as ways to organize thought into structure people can steer.

That was not a metaphor. It was a real bet on how the last mile from mind to machine might close. What actually closed a usable last mile — sooner, and without an implant — was generative coding models. They did not replace Neuralink as an idea; they validated the process I cared about: channel thought into something a machine can realize as code.

One place the idea showed up: levels of code

One application: thought → pattern → DSL → orchestration → running compute. Not the only home for the idea.

Thinking in code is bigger than any one stack. DSLs, Kubernetes, and orchestration were not the whole thesis — they were a context where the idea seemed to apply to problems I was living in: how do you express control across a fabric of compute without drowning in leaf detail?

In that lane, the same idea showed up as levels of code:

• The ability to cycle through resources phase 2 (Oct 2020) — “second-level coders” write orchestration that moves lower-level logic across resources; multi-level chess.
• OpenKruise Sidecar set for data locality (Sep 2020) — containers as beans, Pods as local contexts, Kubernetes as parent context: OO thinking lifted into infrastructure.
• What can be created with CDK8s? (Jan 2021) — “configuration is code”; intent → DSL → object graph → running infrastructure.
• Finally took another look at MPS… (Jul 2023) — a DSL to write code, then ChatGPT to write the code that writes code: another force multiplier in the same spirit.

In that application, a useful chain looked like:

Thought → repeatable pattern → execution DSL → orchestration graph → running compute

Useful — and still only one surface. The core claim was that thought patterns, once channeled, can become verifiable reproductions in code, wherever that code lives.

Where the ideas landed: Uber Language of Compute

Over years of posts — DSLs for execution, resource, and data; multi-level orchestration; operators; locality; CDK8s; MPS — those threads did not stay as separate notes. They coalesced into a larger working model: the Uber Language of Compute (and later notes, v2.0 with AI-powered design).

That model is where details like “realizable in many languages” and “control flowing across a fabric of compute resources” belong — not as the definition of thinking in code, but as how the uber-language was meant to work in practice: patterns that compose across containers, graphs, and control planes. The smaller posts were applications and probes. The uber-language is the larger working model that held them.

And here is the part that still surprises me looking back: the blog series itself ended up becoming the spec. There was no separate requirements doc waiting offline. Writing the ideas in public — iterating titles, diagrams, “how would this work?” pieces — was specifying the larger system. Progress on the concept lived in the posts. Implementation could lag; the series kept the working model alive until tools (and later LLMs) could catch up.

That catch-up is no longer hypothetical. There is working code for the uber-language now: jmjava/uber-lang-of-compute. The blog was the spec; the repo is the implementation catching the concepts.

What actually arrived: LLMs validate the process

Same notebooks of intent — now with a model that can emit the leaf code.

Generative coding models did not replace the need to think. They validated the process — and removed the compromise. You can still progress on larger concepts first. Now you do not have to leave so much unimplemented. With an LLM in the loop, structured thought can become running systems at a velocity closer to the thinking itself — not via a brain interface, but via language, prompts, and review.

With an LLM in the loop:

• You still have to think in patterns — intent, constraints, structure, acceptance criteria (DSL when it fits; plain language when it does).
• The model can materialize large amounts of candidate code from that thought — so the concept does not sit unimplemented by default.
• You remain responsible for judgment — review, tests, architecture, what not to ship.

“I think more than I code” was the honest description of how progress used to work under a hard ceiling on implementation speed. That ceiling moved. The scarce resource is still the thinking; the model aids turning that think into code so the larger concept and the build can advance together. Neuralink remains a separate, literal bet about reading the brain. What we have now is different: natural language and structured artifacts as an encoding of thought, and the model as a compiler from that encoding toward running systems.

I did not see LLMs coming when I wrote the 2019 piece. Looking back, the multi-level orchestration posts — and the uber-language they fed — were already progress at the concept level, with the blog as living spec. LLMs make closing the implementation gap available far beyond any single DSL or platform.

What this is not

• It is not “the AI thinks so I don’t have to.” Unstructured vibes still produce slop.
• It is not claiming Neuralink was never serious — only that LLM-aided coding is what validated the thinking-in-code process first.
• It is not “DSLs were the answer.” They were an application. The process can exist in many contexts.
• It is not the end of craft. Contracts and verification still decide whether thought becomes a system you can trust.

Closing the loop

2019: progress larger concepts even when you cannot implement everything — think in code under that compromise.
2020: restated as bidirectional — and a real look at Neuralink as a possible path.
Along the way: the threads become the Uber Language of Compute — the blog series becomes the spec; uber-lang-of-compute is working code for that model.
Now: LLMs validate the process and lift the compromise — thinking can turn into code with model aid, so concept and implementation need not diverge by default. Not Neuralink. Review still matters.

Neuralink may or may not arrive later. The process was always the point. The series was already the blueprint — and the larger concept is no longer only half-built.

— John · earlier posts linked above on jmenke.blogspot.com

Coming soon — Guide as optional agent context for SDLC-SPDD

COMING SOON

File-based agent memory works — until you want cross-run lessons that stay auditable. We are expanding SDLC-SPDD Orchestrator with an optional context backend powered by Embabel Guide + Neo4j. Markdown stays canonical. Guide adds retrieval on top when you opt in.

Files first. Guide only when the marker is present and the service answers.

The idea

Today every /sdlc-spdd-* phase can already load context from indexes under agent-context/ and canvases under spdd/canvas/. That path stays the default forever.

The spike explores a DICE-style hybrid (Domain-Integrated Context Engineering): the same markdown the workflow already produces is projected into Guide twice — as RAG chunks and as typed domain entities — so the next session can ask not only “what text is similar?” but “what is connected to this Work ID or code area?”

Dual ingest: chunks for discovery, entities + edges for explainable inclusion.

Three retrieval legs, one join key

Work ID is the join key across lexical, embedding, and domain-graph legs.

1. Lexical / area index — what you have today: deterministic, auditable, exact identifiers.
2. Embedding discovery — Guide RAG (docs_textSearch / docs_vectorSearch) to find entry points by paraphrase.
3. Domain graph (DICE) — typed nodes such as WorkId, Canvas, Area, Decision, Pitfall, Pattern with edges (canvas, area, decision, pitfall, pattern, about). Inclusion is justified by a link, not only a cosine score.

That last point matters for agent trust: when a prior pitfall from FEAT-001 shows up while coding FEAT-009 on the same area, you should be able to say why it was pulled in.

Optional at runtime — never assumed

Installs opt in with a marker (agent-context/harness/guide-dice.md via init-project.sh --with-guide). Every command still probes first:

• No marker → CONTEXT_BACKEND=files (normal, not an error)
• Marker present but Guide down → same file fallback
• Guide live → augment analysis / architect / code / review with spdd_* tools

No slash command may block because Guide is absent. That is a hard design rule of the spike.

How our work relates to the ideas we ingested

SDLC-SPDD did not start as a RAG project. It started as a way to run Fowler’s SPDD workflow under Troy’s context limits, with slash commands and file indexes. The Guide spike is the next question: can optional hybrid retrieval make that same workflow better at remembering across Work IDs without abandoning auditability?

While dogfooding SPIKE-001 we appended those authors (and a smaller secondary set) into a local Guide corpus — so retrieval experiments hit methodology prose and our canvases, not only our own markdown. Below is the mapping we actually use.

Fowler SPDD → our lifecycle (files today)

Structured-Prompt-Driven Development says prompts are delivery artifacts: versioned, reviewed, improved. Our response: every Work ID gets a REASONS canvas under spdd/canvas/; /sdlc-spdd-analysis then /sdlc-spdd-plan then /sdlc-spdd-architect before /sdlc-spdd-code; code implements one approved operation; /sdlc-spdd-review and /sdlc-spdd-sync close the loop. That is the same contract, made runnable in Cursor / Copilot / Claude (see also engineered.at on SPDD).

I still care about the code and the wider Exploring Gen AI series argue that AI does not excuse sloppy ownership of design and tests. Our response: behavior changes are prompt-first; the canvas stays the source of truth; API-test and review phases exist so “the model wrote it” is never the definition of done.

Harness engineering, Sensors for coding agents, and Pushing AI autonomy describe feedback loops and limits around agents. Our response: workflow CLI + pointer + readiness gates + the prompt-optimization ledger (FEAT-004/005) are our harness and sensors. We do not grant more autonomy until the canvas says Ready For Coding.

The craft ladder we dogfood — make it work → make it right → make it fast — sits in the same lineage as Beck’s make it run / make it right and Fowler on evolutionary design (Is Design Dead?, Refactoring). Guide is a make-it-fast spike: only after the file workflow is right.

How Guide extends Fowler in our spike: SPDD already persists decisions in markdown. Guide dual-ingest projects those same artifacts so the next Work ID can retrieve prior Operations / Decisions / Safeguards by graph link — still Fowler’s “improve the prompt artifacts over time,” but searchable across sessions without pasting every canvas into the chat.

Chelsea Troy → why our indexes exist (and what Guide must not break)

What can we expect of LLMs as software engineers? argues models are aides to a rigorous process, not a substitute for judgment — and that large dumps fail (“lost in the middle,” unscoped pastes). Fowler gives workflow; Troy explains why that workflow must stay narrow. We documented the mapping in Chelsea Troy and the framework.

Troy’s point	What we already ship	What Guide must preserve
Don’t flood the context window	Tiered grounding; context-index / domain-index / session rotation	Retrieve a few linked lessons — never “all chunks similar to the prompt”
Work on cohesive slices	/sdlc-spdd-analysis → domain keywords → code areas	spdd_areaLessons keyed by area, not whole-repo RAG
Specific, testable problems	REASONS Requirements / Operations; one op per /sdlc-spdd-code	Surface pitfalls/decisions as Safeguards candidates — human still accepts
Judgment stays human	Architect readiness, review-against-canvas, confidence-stack testing	Optional backend; files fallback; no command fails if Guide is down
Don’t generate slop	Governed canvases, sync logs, prompt-first behavior change	Inclusions explained by typed edges, not opaque cosine alone

Related Troy pieces we ingested for the same reason: Avoiding technical debt (process debt is still debt — our canvases fight that), On code coverage tools (satisficing sentinels → our quality gates), debugging tactics (investigation is delivery work — our analysis phase).

How Guide extends Troy in our spike: file indexes already narrow context. Guide’s domain graph is how we pull cross-Work-ID lessons for the same area without violating Troy — an about edge to scripts/ is a scoped slice, not a history dump. If retrieval cannot explain the inclusion, it fails our Troy test even if the embedding score looks good.

Rod Johnson / Embabel — why the Guide shape is DICE, not “more RAG”

Context engineering needs domain understanding argues typed domain objects should drive context. Agent memory is not a greenfield problem argues you should ground agents in data you already keep. Our response: we do not invent a parallel memory store. We project the SPDD domain we already have — WorkId, Canvas, Area, Decision, Pitfall, Pattern — into Neo4j __Entity__ with typed edges, and keep markdown canonical. Chunk RAG (legs 1–2) is for discovery; the graph (leg 3) is for “why is this in the prompt?”

Jasper Blues — the Guide we actually integrate with

Our spike talks to a real Embabel Guide instance (fork + projection APIs), not a toy RAG stub. Jasper Blues’ From Docs to Dialog is the product story behind that service: Hub’s “talk to the docs” guide built with Embabel, graph-backed RAG on Neo4j via Drivine, and Toolish RAG — the model gets search tools (docs_textSearch, docs_vectorSearch, broaden/zoom) instead of a single black-box retrieve step. How that relates to our work: when CONTEXT_BACKEND=guide-dice, analysis/architect/code phases call those same tool-shaped retrieval surfaces (plus our spdd_* graph tools). We are not inventing a second RAG stack; we are hanging SPDD domain projection off the Guide Jasper describes.

The (Very Slowly) Ticking Time-Bomb in Your Graph Persistence Stack explains why Drivine’s use-case-specific Cypher/projections matter for graph persistence. Our response: leg 3 is a deliberate projection of SPDD markdown into __Entity__ nodes and typed edges — not hoping directory ingest alone fills a domain graph. That matches Jasper’s “write the graph shape you need” stance and is why our fork work adds projection load + spdd_workSubgraph / spdd_areaLessons rather than only chunk ingest.

The Voice, The Word, and The Wheel shows Guide as an evolving product surface (narration agents, command loops, Toolish RAG for speech). We are not shipping voice in SPIKE-001 — but it reinforces that Guide is a living context backend with MCP/tool loops, which is exactly the runtime we probe with resolve-context-backend.sh. Those three Jasper/Embabel pieces are also in Guide’s default supplementary ingest list alongside Rod’s posts — the same corpus family we extend with Fowler/Troy for the spike.

Thread: Fowler/Troy define how we work in files. Rod’s DICE framing defines why typed memory. Jasper’s Guide writing defines the system we plug into — Toolish RAG + Drivine/Neo4j — so our coming-soon path is “SPDD domain on Guide,” not a greenfield memory product.

Secondary ingest — sensors for the experiment, not the product story

We also appended Anthropic’s notes on context engineering / long-running harnesses, 12-Factor Agents, Willison on LLMs for code, and Hamel/Yan on evals. How that relates to our work: they score the spike (context cost, eval discipline, harness thinking). They do not redefine the operating model — Fowler + Troy still do. Go/no-go asks whether Guide hybrid beats file indexes on the same Troy criteria Fowler’s workflow already assumes.

Status: coming soon

This work lives on spike branches and open PRs — it is not the default on main yet:

• Orchestrator spike: PR #24 (SPIKE-001)
• Paired Guide projection / spdd_* tools: guide PR #2
• Flow overview: docs/guide-flow.md on the spike branch

Much of the operator path is already dogfooded (ingest, projection, runtime probe, A/B spot-checks). The remaining gate is a formal go / no-go before anything becomes a recommended install option for adopters. Until then: treat it as preview, keep shipping file-based SDLC-SPDD on main, and watch this space.

What you can do today

1. Use SDLC-SPDD with the file indexes — that path is production for the framework.
2. Read the spike docs / PRs if you want the design early.
3. Expect a follow-up post when go/no-go lands and the opt-in path is documented for adopters.

— John · github.com/jmjava/sdlc-spdd-orchestrator

Introducing tekton-dag — stack-aware Tekton CI for local and multi-team PoCs

Most local Kubernetes CI demos stop at “build one service.” Real stacks are graphs: shared libraries, polyglot apps, intercept routing for pull requests, and teams that need isolation without forking the platform.

tekton-dag is a standalone Tekton pipeline system for local development and proof-of-concept work. It models your apps as a DAG, runs stack-aware Bootstrap / PR / Merge pipelines, and can route PR traffic through Telepresence or mirrord while the rest of the stack stays on normal paths.

Three pipelines, one stack: bootstrap once, test on PRs, release on merge.

What it is

Pipeline	Purpose
Bootstrap	Deploy the full stack once — prerequisite for PR runs
PR (stack-pr-test)	Build the changed app with a snapshot tag, deploy intercepts, validate, test, comment on the PR — no version bump
Merge (stack-merge-release)	Promote RC → release, tag images, push the next dev-cycle version

Around those pipelines sits an in-cluster orchestration service (webhooks → stack resolution → PipelineRuns), Helm packaging for multi-team namespaces, baggage middleware across Spring / Node / Flask / PHP, and a testing ecosystem (Newman, Playwright, Artillery) with optional Neo4j-backed blast-radius selection.

PR traffic can follow intercept headers; everyone else keeps the default path.

# Kind + Tekton + stack tasks (local)
./scripts/kind-with-registry.sh
./scripts/install-tekton.sh
./scripts/publish-build-images.sh
kubectl apply -f tasks/ -f pipeline/

What we shipped recently

1. Dual intercept backends (M7)

PR flows can use Telepresence (default) or mirrord, selected with the pipeline param intercept-backend. Both paths are E2E-verified, so teams can pick the tool that fits their local debugging story without changing the DAG model.

2. Multi-team orchestration + Helm (M10)

An in-cluster Flask orchestrator receives GitHub webhooks, maps repos to stacks, and creates PipelineRuns. Helm charts plus ArgoCD ApplicationSet patterns cover team isolation, namespace scoping, and batched builds — so “one Kind cluster” can still look like several teams.

Management GUI: team switcher, DAG view, runs, triggers, and tests.

3. Management GUI (M11)

Vue 3 + Flask replaces the older reporting UI: multi-team / multi-cluster views, DAG visualization, runs and triggers, test status, and a Git browser. Covered by a solid pytest + Playwright suite so GUI changes stay reviewable.

4. Architecture customization (M12)

Shared Python packaging, Helm ConfigMap/PVC templates, parameterized pipelines (no hardcoded localhost), build-image variants (Java / Node / Python / PHP ranges), and custom pre/post hook tasks. Stack JSON schema + onboarding docs make “add a team” a configuration problem instead of a fork.

5. Narrated demos on GitHub Pages (M8 / docgen)

Eighteen Manim + TTS segments walk architecture, quick start, bootstrap dataflow, PR flow, intercept routing, local debug, merge/release, orchestrator API, Helm, baggage, testing, the test-trace graph, Results DB, customization, regression, the GUI, and what’s next. Watch them at jmjava.github.io/tekton-dag.

What’s next

Milestone 13 — production hardening is planned: retries on transient build/deploy failures, precise build-image sizing, multi-cluster promotion, timeouts and cleanup, Prometheus-oriented observability, secrets injection (ESO / Sealed Secrets), and per-app config per environment.

Try it

1. Clone jmjava/tekton-dag
2. Follow the README quick start (Kind + Tekton + publish build images)
3. Bootstrap a stack, then run a PR pipeline against a changed app
4. Skim the demo videos if you want the architecture before you touch YAML

If you need stack-aware Tekton locally — with real intercept behavior and a path toward multi-team Helm — start with bootstrap, then let a PR run prove the DAG.

— John · github.com/jmjava/tekton-dag

Introducing docgen — narrated demos from Markdown to Manim

Long-form demos should explain how a system works. Narrated diagram videos age well when the script and the visuals are first-class artifacts you can regenerate in CI — not one-off recordings that rot with every UI tweak.

docgen (documentation-generator) is a reusable Python library and CLI for that job: Markdown narration, OpenAI TTS, Whisper-aligned timing, Manim scenes, ffmpeg composition, and validation you can run before you ship. Install it, point it at a docgen.yaml, and build demos from the shell — no IDE plugin required.

Library, not app: pip-installable CLI + YAML + shell/CI.

What it is

docgen ships the video stack you need for scripted explainers:

• TTS narration — Markdown scripts → MP3 via OpenAI (gpt-4o-mini-tts)
• Whisper-style timestamps — word-level timing so visuals can wait on real speech
• Manim animations — the primary visual surface for diagram-heavy segments
• ffmpeg compose / concat — mux audio + video, stitch segments, freeze-tail guard
• validate — A/V drift, freeze ratio, narration lint, Manim layout hints, pre-push checks
• pages — static preview HTML for demo assets
• wizard — optional local web UI to bootstrap narration from project docs

North-star constraints matter as much as features: stable CLI contracts, hybrid config (deterministic merges plus optional OpenAI where it helps), and a hard rule that generated assets come from the tool — not hand-edited “fixes” that paper over generator gaps.

Typical path: narration → TTS → timestamps → Manim → compose → validate.

cd your-project/docs/demos
docgen yaml-generate          # merge hints/defaults into docgen.yaml
docgen narration-generate …   # optional LLM narration from hints
docgen scene-spec-generate …  # declarative Manim YAML
docgen generate-all           # TTS → timestamps → Manim → compose → validate
docgen validate --pre-push

What we shipped recently

1. Declarative Manim: scene-spec-generate + scene-compile

Instead of hand-editing generated Manim classes, maintainers steer with hints and declarative *.scene.yaml specs. OpenAI can emit the YAML; the engine compiles it into _TimedScene classes inside marked regions of scenes.py.

YAML in, timed Manim scenes out — with layout budgets and Whisper wait_word alignment.

The compiler is opinionated in useful ways: rows auto-paginate when they exceed the frame stack budget, oversized specs are rejected, and (when timing.json has Whisper words) each row’s first label can map to a wait_word index so boxes appear with the narration.

docgen scene-spec-generate --segment 01 --compile
docgen scene-compile animations/specs/01-overview.scene.yaml
docgen manim --scene YourGeneratedScene

2. Hints + yaml-generate as the maintainer surface

Demo bundles (typically docs/demos/) prefer hint files with YAML front matter over ad-hoc surgery on merged docgen.yaml. docgen yaml-generate merges segment lists, visual_map, and paths; narration-generate and scene-spec-generate read those hints. Generated narration, scenes, audio, and recordings stay tool-owned so Git review stays honest.

3. Handbook diagrams + Pages-friendly demos

The repo also ships a suite handbook under docs/suite/ (PlantUML sources with Graphviz/CI rendering) and Manim-oriented demo media for GitHub Pages — so architecture stories can ship as diagrams and narrated segments, not only as markdown.

Try it

1. Install from source or git: see jmjava/documentation-generator
2. docgen init a demos bundle (or adopt an existing docs/demos/)
3. Author hints → yaml-generate → narration / scene specs → generate-all
4. Run docgen validate --pre-push before you ship media

If you want demos that explain architecture with speech and diagrams — and you want a pipeline you can re-run instead of re-record — start with a Manim segment and let docgen own the rest.

— John · github.com/jmjava/documentation-generator

Introducing SDLC-SPDD — disciplined AI delivery, and what we shipped

AI coding assistants are fast. Delivery still needs a spine. Without one, sessions drift, Work IDs get lost, and “what should we do next?” becomes a new chat every morning.

SDLC-SPDD Orchestrator is a multi-assistant scaffold for disciplined AI-assisted delivery. It installs into your project and gives Cursor, Copilot, and Claude Code the same operating model: plan why the work matters, design what to build (and what not to), then run phases with clean handoffs.

Three parts that work together: Planning, SPDD (REASONS canvas), and SDLC lifecycle.

The idea in one minute

The framework is built from three parts:

Part	Answers	Artifacts
Planning	Why the work matters	ROADMAP.md, milestones, requirements, session notes
SPDD	What to build (and what not to)	REASONS canvas under spdd/canvas/
SDLC	Who acts when and how sessions hand off	phase commands, session briefs, agent-context/ memory

Commands come in two flavors: assistant slash commands in chat (/sdlc-spdd-plan, /sdlc-spdd-code, …) and a shell workflow CLI for day-to-day orientation (./scripts/sdlc.sh next). Install once from the orchestrator repo; then work inside your target project.

We develop the framework the same way we ask adopters to work: Work IDs, canvases, and milestones — dogfooding on the orchestrator itself. Progress follows Kent Beck’s ladder: make it work → make it right → make it fast.

What we shipped recently

The biggest recent theme is agent coordination — so humans and assistants stay on the same Work ID and the same next step.

Orientation beats vibes: the same “what now?” answer in the shell and in chat.

1. SDLC pointer + workflow CLI

A persistent Work ID on your machine (.sdlc/pointer) and guarded wrappers that refuse commands aimed at the wrong chore. The workflow CLI tracks phase and gates, infers the next canvas operation, and captures sessions safely:

./scripts/sdlc.sh next
./scripts/sdlc.sh advance
./scripts/sdlc.sh shelf
./scripts/sdlc.sh resume

Shipped via #20 and #21 (tracking #19).

2. /sdlc-spdd-whereami (and friends)

In Cursor, Copilot, and Claude you can ask /sdlc-spdd-whereami and get the same orientation as sdlc.sh next. Workflow chat wrappers also cover claim, shelf, advance, next, and team — so you do not have to leave the assistant to stay in sync.

Team claims live in git so ownership is visible across machines.

3. Team Work ID registry

Shared claims in agent-context/work-registry.tsv sync through git. Teammates can see who owns which Work ID, with stale TTL and notes for branch / PR / Jira:

./scripts/sdlc.sh claim FEAT-005
./scripts/sdlc.sh team
./scripts/sdlc.sh release FEAT-005

Pointer and workflow state stay local; team claims are the shared layer.

4. Milestone 1 — make it right (and measure make it fast)

On the make-it-right track we completed the structural cleanup adopters feel every day:

• Shared script library — less duplicated shell logic across install/workflow scripts
• Command-spec generation — adapters stay aligned across Cursor / Copilot / Claude
• Extension hook manifest — clearer places for project-specific overrides
• Analysis Scope Lock — /sdlc-spdd-analysis locks IN / NOT scope before generation
• Jira-compatible requirements — YAML frontmatter + validation for milestone docs
• Milestone subdirectory layout — cleaner requirements/milestones/ structure
• Session-brief archive — rotation so session folders do not grow forever

For make-it-fast measurement, we landed a prompt-optimization ledger and canvas readiness indicators — so coding gates on “Ready For Coding” instead of hope. Remaining make-it-fast spikes (Guide RAG context backend, local models) stay experimental until Guide MCP is ready.

Try it

1. Clone jmjava/sdlc-spdd-orchestrator
2. Install into a target project with ./scripts/setup-agent-prompts.sh (see the README adoption path)
3. In chat: /sdlc-spdd-whereami — or in the shell: ./scripts/sdlc-spdd/sdlc.sh next
4. Optional: watch the short narrated demos on GitHub Pages

If you are already deep in AI-assisted coding and want fewer lost threads between sessions, start with the first-day walkthrough in the repo docs — then claim a real Work ID and let the canvas carry the contract.

— John · github.com/jmjava/sdlc-spdd-orchestrator

Announcing KBL Compute Engine: Implementing the Uber Language of Compute

I have started a new open-source project to turn the ideas from my earlier Uber Language of Compute posts into an actual working library:

Project: KBL Compute Engine — uber-lang-of-compute on GitHub

The short version: this project is my attempt to implement the “Uber Language of Compute” as a time-sliced, data-local, Kubernetes-native compute fabric.

Instead of treating compute as a single monolithic application, KBL models compute as a set of declarative layers:

• Execution — what runs
• Data — what data is used, where it lives, and how it is frozen
• Provisioning — how compute/storage resources are allocated
• Routing — which universe, node, context, or time slice handles the work

That four-part model comes directly from the original post: The Uber Language of Compute. In that post I described computation as an aggregation of Execution, Data, Provisioning, and Routing. I also introduced the idea of a Pluggable Universe, where each universe has its own “laws of physics,” and a Multiverse, where routing connects many such universes.

What KBL Implements

The new library turns those ideas into concrete Kubernetes-style building blocks:

• Snapshots — immutable data views tied to a time slice
• Dominos — deterministic compute steps that run against one snapshot
• Workflows — ordered chains of dominos
• Compute Contexts — node-associated units of compute plus local data
• Compute Wheels — rotating sets of contexts processing time slices continuously
• Pluggable Universes — swappable execution/data/provisioning environments
• Multiverse Routing — routing work across universes, partitions, and time slices
• Node-local stores / TSDB — keeping data and memoized results close to compute
• Replay logs — recording exactly what ran, what was reused, and what was recomputed

The repo is organized around those concepts: Vocabulary, Architecture, CRDs, controller/runtime, examples, and a local Kind lab.

How the Library Maps Back to the Original Blog Ideas

``` ```

Original Idea	Source Blog Post	KBL Implementation
Computation is composed of Execution, Data, Provisioning, and Routing.	The Uber Language of Compute	KBL defines this as a four-DSL model. See ADR 0001: Four-DSL Model and the schemas under specs/.
A Pluggable Universe is a compute environment with its own laws of physics.	The Uber Language of Compute	KBL models this through PluggableUniverse definitions and routing abstractions. See Vocabulary and ADR 0009: Multiverse Routing.
A Multiverse routes work to many pluggable universes, including time-sliced replicas.	The Uber Language of Compute	KBL implements this through Multiverse routing, ComputeWheels, and examples like multiverse-finance.
Time-sliced computation should freeze data so results are repeatable.	Newtonian Physics, entropy, computational repeatability, and determinism	KBL introduces Snapshot resources: immutable, sealed data views that gate computation. See ADR 0002: Snapshot Isolation.
Dominos represent deterministic compute steps tied to a snapshot.	Newtonian Physics, entropy, computational repeatability, and determinism	KBL has Domino CRDs and workflow chains. A domino is intended to be referentially transparent: same snapshot plus same inputs equals same output.
Entropy is reduced by isolating the system at T=0, like Newtonian initial conditions.	Newtonian Physics, entropy, computational repeatability, and determinism	KBL treats snapshots as low-entropy initial conditions. Replay logs, input hashes, and immutable snapshot sealing make computations reproducible and debuggable.
Minimize recomputation by caching prior domino results when inputs have not changed.	Minimize Entropy while maximizing Caching	KBL uses memoization: input hash to output hash and payload. Re-running the same workflow can reuse results instead of recomputing them.
Keep data local to the node where compute runs.	Minimize Entropy while maximizing Caching	KBL starts with SQLite as the MVP node-local store and evolves toward a node-local TSDB DaemonSet. See ADR 0003: Node-Local Data and ADR 0008: Node-Local TSDB.
Hot-swap containers in a daisy chain so only a small number are active at once.	Uber Language of Compute: Hot swapping containers in daisy chain	KBL models this as DominoChain / hot-swapped dominos, with placeholder slots, handoff volumes, and OpenKruise-style in-place updates. See ADR 0004: Hot-Swapped Dominos.
Finance curve/risk calculations are a good test case because they require deterministic snapshots.	Applicability to Finance ???	KBL includes finance examples, including curve snapshots and Julia-based finance dominos. See finance-curve-snapshot and julia-domino-chain.

The Key Shift: From Blog Metaphor to Runtime

The older posts were mostly conceptual. They used metaphors like physics, entropy, dominos, and multiverses to describe how repeatable computation might work if compute was broken into isolated, deterministic, time-sliced units.

KBL is the implementation path.

In the library, the metaphor becomes concrete:

• The “initial condition” becomes a sealed Snapshot.
• The “domino” becomes a deterministic compute step.
• The “low entropy lab” becomes a node-local Compute Context.
• The “pluggable universe” becomes a swappable execution/data/provisioning environment.
• The “multiverse” becomes routing across universes and time slices.
• The “conservation of work” becomes memoization and replay.

Why This Matters

Most compute systems either lean toward batch or streaming. Batch is repeatable but often slow and stale. Streaming is current but can become hard to reproduce because the underlying state is always changing.

KBL is trying to explore a third path:

Run compute against immutable time slices, keep the data local, reuse prior work when the inputs have not changed, and route work across pluggable compute universes.

The goal is not just faster compute. The goal is compute that is:

• repeatable
• auditable
• data-local
• memoized
• replayable
• routable across heterogeneous compute environments

Current State of the Project

The repo already contains the first working pieces:

• a local CLI runtime
• a Kubernetes controller path
• CRDs for snapshots, dominos, workflows, compute wheels, multiverse routing, and related resources
• examples for finance curve calculations
• memoization and replay-log concepts
• node-local storage abstraction
• a Kind lab for running the stack locally
• AWS CDK scaffolding for EKS/ECR deployment
• Julia pluggable execution for finance-oriented dominos

The project is still experimental, but the direction is now much clearer: this is the bridge between the old “Uber Language of Compute” theory and an actual Kubernetes-native runtime.

Source Links

• KBL Compute Engine GitHub Repository
• The Uber Language of Compute
• Uber Language of Compute: Hot swapping containers in daisy chain
• Newtonian Physics, entropy, computational repeatability, and determinism
• Minimize Entropy while maximizing Caching
• Visualization: A Multiverse of Computation
• Applicability to Finance ???

Next

The next step is to keep tightening the implementation until the architecture can prove the full loop:

1. seal a snapshot
2. route it to the right compute context
3. run deterministic dominos
4. reuse cached outputs when possible
5. record a replay log
6. materialize results back into the multiverse

That is the point where the Uber Language of Compute stops being only a language of ideas and starts becoming a real compute engine.

Cursor usage plan — flow overview

Five phases: Input → Check → Allocate → Plan → Optional

Cursor Ultra gives you a fixed $400 budget each billing period. It resets on a specific day (the 17th in my case)—use it or lose it. Without tracking, you either burn through it early or leave budget unused.

I built cursor_usage_plan—shell scripts and markdown templates to plan usage across projects. It's a template repo: clone it, configure your projects, adapt the scripts.

The Two-Document Workflow

	projects.md	plans/YYYY-MM.md
Purpose	Allocation: target % per project	This period's wishlist + schedule
Scripts	estimate-budget.sh	estimate-plan.sh

The Five Phases

Phase 1: Input
Export usage CSV from Cursor dashboard, then:
./scripts/import-usage-from-csv.sh export.csv Writes USED_DOLLARS to config/usage.env.

Phase 2: Check
See what's left:
./scripts/usage-remaining.sh Shows: used $, remaining $, % left, ~features remaining.

Phase 3: Allocate
Set target % in projects.md, then:
./scripts/estimate-budget.sh Keep 10–15% unassigned as buffer.

Phase 4: Plan
Create monthly plan with wishlist (P0/P1/P2 priorities):
./scripts/estimate-plan.sh plans/2026-02.md Output: "Fits in $400: Yes/No". Drop P2 items until it fits.

Phase 5: Optional
Budget expires on reset day. Use leftover $:
./scripts/update-embabel-low-effort-issues.sh Note: Embabel scripts are examples—adapt for your projects.

Configuration

MONTHLY_BUDGET_DOLLARS=400 BUDGET_ROLLOVER_DAY=17 DOLLARS_PER_FEATURE=20

Tips

• Plan in $ — Estimate each feature to sum to ~$400
• Check weekly — Run usage-remaining.sh; if high, add work
• Keep buffer — Reserve 10–15% for ad-hoc
• End-of-period — Burn remaining $ before reset

Source: github.com/jmjava/cursor_usage_plan

Using Meta AI imaging library to help with mapping for GSPRO

2026 Think Week

2025 was a breakout year for me in Side Projects - Cursor / AI enormous productivity gains

In a nutshell, with Cursor and AI and estimate I get at least 5x more work done based on number of Git commits - I would actually say 10+ times more productive in terms of actual content

My First Commits to Open Source!!!

• Created AWS based lab with CDK / EKS that supports Pull Request testing inside a live cluster via Telepresence Intercepts and the Baggage Spec 
• Created Embabel based Chat Bot
• Created 3D Swing analyzer with Mediapipe that measures golf metrics from webcam feeds
• Fixed Orchestration errors in my Golf Simulator with 

2026 is going to be amazing - Cursor helps me plan and execute far more efficiently.  Hoping to continue my Open Source participation in Embabel and make progress on my other efforts!!!

Applicability to Finance ???

 It should be noted that I am not a financial engineer - this is pure speculation as to possible use case for this technology

As per my assistant 

Yes, snapshots can be extremely effective for curve calculations in finance, especially when you’re dealing with complex models where determinism, performance, and auditability are critical. Let’s break it down with your architecture in mind:

---

✅ Why Snapshots Are Ideal for Curve Calculations

1. Deterministic Pricing and Risk

Curve calculations (e.g., interest rate curves, yield curves, volatility surfaces) require precise inputs:

• Market data at a specific point in time

• Trade and instrument data

• Model parameters

By locking in a snapshot of all input data (quotes, trades, positions) at T₀, your system guarantees:

• Reproducible results

• Accurate PnL explainability

• Auditability for regulatory reporting

2. Parallelism Across Snapshots

Your domino-style system allows each curve (or even each instrument) to be priced in parallel, per snapshot. This plays beautifully with container hot-swapping and node-local databases—each container handles a clean input space, runs a local curve bootstrapping or pricing engine, and optionally reuses previous results if the input hasn’t changed.

3. Memoization of Sub-Curves or Risk Blocks

If underlying rates, vol surfaces, or other primitives haven’t changed, your system can reuse prior domino outputs:

• Example: If the 3M USD LIBOR curve is unchanged between snapshots, skip recalculating it.

• Just recompute the instruments or exposures that depend on updated curves.

---

🧠 Application Architecture Fit

Curve Type	Snapshot Use Case	Memoization Feasibility
Interest Rate Curves	Capture all contributing rates at T₀	High (rates are stable intra-day)
Volatility Surfaces	Snapshot market implied vols	Medium (vol is noisy but still cacheable hourly)
Credit Curves	Use CDS spreads, bond yields	High (infrequent change)
FX Forwards / Futures	Snapshot FX spot + rates	High
Custom Yield / Liquidity Curves	Capture balance sheet or funding inputs	Very high if internal data feeds are stable

---

🧮 Bonus: Time Series DB as Curve Store

If each domino outputs its result to the node-local TSDB, you gain:

• Historical curve replay

• Change detection (e.g., hash of input vs last run)

• Lightweight, high-frequency curve regeneration

And syncing those curves via Debezium allows for eventual consistency across all nodes while still benefiting from ultra-low latency local compute.

---

🧩 Related Real-World Use Cases

• Banks: Intraday risk and sensitivity grid snapshots

• Hedge Funds: Backtesting with synthetic historical snapshots

• Regulators: Snapshot-based stress test calculations (e.g., CCAR)

---

Would you like a breakdown of how to represent curves and instruments as snapshot-ready payloads? I can help sketch out a data model or even a Helm + TSDB config for Kubernetes.