This page is for a technical program manager, delivery systems leader, or engineer sizing up the judgment behind the toolchain rather than the product pitch. It states the stack, the component boundaries, the data contracts between tools, what's enforced in code versus asserted by a model, the trust boundary around API keys, the deploy model, and the debt that's tracked but not yet paid. Plainly, not promotionally.
No build step. The .html file is the deployable artifact: markup, an inline stylesheet, and an inline script where the page is interactive.
An npm-workspaces monorepo (private repo, separate from this site's repo) holding nine of the eleven tools: everything except the persona generator and the product ops radar, which are hand-authored HTML with no network calls.
Every spine app imports the same internal @robdull/toolkit package rather than re-implementing its own client, scoring math, or handoff logic.
Each pipeline step is a declarative config object: { id, buildPrompt, parse, render, maxTokens }. The hook is generic over an array of these, so no app hand-rolls its own step state machine. Every spine app also ships a keyless sample: for most, a demo.html rendering a real captured run through the same step renderers as the live tool; for Business Cases, a worked-example gallery on the tool itself (including the PetHealth EPIC-03 case the demo thread follows). Evaluating any tool costs a visitor nothing and needs no key.
The chain runs entirely same-origin through localStorage, not a backend. Each arrow below is a small versioned TypeScript module, not a loose object shape passed by convention, playing the same role an internal API schema plays between two services.
| Handoff key | Stage | What crosses |
|---|---|---|
| robdull:personas | 01 → 02 | Persona → journey seed |
| robdull:opportunity-seeds | 02 → 03 | Journey pain clusters → intake candidates |
| robdull:journey-seeds | 03 → 02 | Bidirectional: intake can request more journey detail |
| robdull:epics | 03 → 04 | Business + Architecture epics, D/F/V, benefits-realization plan |
| robdull:business-cases | 04 → 05 | kind, caseType, roughEffort, execSummarySeed |
| robdull:epic-ranking | 05 → 06 | Method, weights, scores, funding line |
| robdull:roadmaps | 06 → 07 | Milestones, release windows |
| robdull:brds | 07 → 08 | One BRD per funded epic |
| robdull:backlogs | 08 → 09 | One backlog per epic |
| Jira CSV | 09 → Jira | File download; terminal handoff, no further chain |
The AI drafts every artifact. It does not get the final word on whether that artifact is internally consistent; a handful of checks are computed in plain code and cannot be talked around by a confident-sounding response.
Every public example should identify its origin using one of four labels, applied consistently rather than alternated.
All nine apps in the shared workspace, including the strategy-alignment tool, call api.anthropic.com directly from the visitor's browser using a key the visitor supplies. The key lives in sessionStorage and clears on tab close. Two tools, the persona generator and the product ops radar, make no network calls at all. There is no server anywhere in this system holding anyone's key.
A Cloudflare Worker pattern that would hold a server-side key was evaluated and deliberately not adopted for this deployment. The full reasoning, cost per session, blast radius of a leaked key, and the UX trade-off of asking a visitor for their own key, is written up on its own page rather than asserted here. Read the trade-off ↗
Relevant risks include malicious or compromised site JavaScript, compromised third-party dependencies, browser extensions, shared or unmanaged devices, cross-site scripting, accidental exposure through debugging or screenshots, broadly privileged API keys, and sensitive content transmitted to the model provider.
Appropriate controls before broader testing include a strict Content Security Policy, a dependency inventory and update process, no unnecessary third-party scripts, clear model-provider disclosure, restricted-key guidance, usage monitoring, a sanitized-data requirement, a documented incident contact, and a security review before accepting confidential data.
Workflow state is stored in browser local storage, which enables same-origin handoffs without a backend but creates real limits: state belongs to one browser profile, clearing site data removes it, shared work and concurrent edits aren't supported, there is no server backup, and local data may remain on the device.
Run-file download and restore provide portability, but a run file can contain everything entered and generated, and should be treated as potentially sensitive. Before a run file changes hands: it should be reviewed and sanitized first, notes alone are an acceptable substitute for the file, how received files are stored and eventually deleted should be stated, and files containing employer-confidential content shouldn't be collected.
main is production on both repos. GitHub Pages republishes on every push to this repo's main. There is no staging environment and no automated pipeline. For a solo-maintained portfolio project this is a scope choice, not an oversight: a broken push is caught by hand within minutes, and the alternative, a pipeline maintained for two repos with no team behind them, buys safety this project doesn't currently need.
One deploy-safety habit worth naming: at least one spine app's site directory holds a hand-authored page that is not a build artifact and would be silently deleted by a naive copy-and-overwrite. Deploys diff the existing directory against the fresh build output before wiping anything, specifically to catch that class of mistake before it ships.
Release checklist: build every application, confirm no unexpected file deletion, open each public route, test one complete handoff path, verify sample pages, verify key-modal and API-error behavior, verify run-file download and load, verify Jira CSV generation, check console errors, and record the release version and date.
A short, current list, not an exhaustive one:
The repository behind the nine-tool spine is private, so this page describes the architecture rather than lets you inspect it directly. The shared package has unit test coverage for scoring parity, chain-state handling, and API client behavior. There is no CI gate, no per-app test suite, and no end-to-end test; correctness beyond that unit coverage currently leans on the computed guardrails above and manual verification at each release. If you'd like to look at representative code directly, the scoring module or a single handoff contract, I'm glad to walk through it on request: rob.dull@gmail.com.
This is a working proof of concept suitable for portfolio review and limited evaluation with fictional, public, or sanitized information. It is not suitable for confidential enterprise work or production use.
This page covers the engineering. For what the system actually produces, the end-to-end case study traces one initiative through all nine tools with the real captured output at each step, and the evaluator guide routes PM, ProdOps, and delivery leaders to the proof points for their seat.