Ask
Find a real constraint, repeated frustration, or unanswered engineering question.
THE LABORATORY / ENGINEERING NOTEBOOK
A question.
An experiment.
Something worth keeping.
The smaller tools and unusual prototypes are part of how the larger systems developed. This notebook follows the question, the observed behavior, and the useful engineering idea that can survive the experiment.
Try the Last Good Build pattern ↓THE METHOD
Try
Build a small enough experiment that its behavior can be understood.
Check
Observe the result—including failures—and distinguish it from what was intended.
Keep
Preserve the useful behavior as a tool, test, pattern, or reusable capability.
TRY THE PATTERN / LOCAL SIMULATION
What if a failed change
didn’t take away
the working application?
The Last Good Build experiment separates the application serving the user from the candidate under construction. A failed candidate should remain a failed attempt, while the user keeps the working version.
Try a failure first. Then choose a passing candidate and promote it.
This browser-local simulation explains the pattern. It does not run Buttons, compile an application, or establish production deployment behavior.
SERVING THE USERbuild-001● healthy
CANDIDATE / BUILD-002Awaiting checksNo candidate result yet
The user has a healthy application while the next change is prepared.
THE EXPERIMENT RECORDS
Follow a question.
Open an entry to see the observation, its source, and what remains unproven. Historical implementations and current research are kept distinct.
Keep the work recoverable.
What happens when a candidate fails, a task stops, or a repeated operation changes the wrong thing?
Prototype directionLast Good BuildKeep the working application while a candidate earns promotion.
The observation
Separate the application currently serving the user from the candidate under construction. A failed candidate should not become the user’s new working state.
What remains to establish
The diagram and simulation here explain the pattern. They do not start builds or establish current recovery parity in a Buttons release.
Source: Buttons operator and flow archive; owner knowledge transfer.
Documented working runnerFailure drives continuationObserved results decide what happens next.
The observation
Numbered steps, progress files, informative errors, and MasterLog provide an inspectable cycle. A later review can send earlier work back below completion and the runner revisits it.
What remains to establish
The original behavior is distinct from the planned portable durable kernel and its broader recovery guarantees.
Source: Original Error-Driven Orchestration Machine README and family reconstruction ledger.
Retained tools; bounded checksDeterministic engineering operationsGenerate what repeats. Verify what changes.
The observation
Typed mapping components, explicit output ownership, and maintenance APIs show how small tools support the larger factory. Current notes distinguish component-output checks from complete CLI acceptance.
What remains to establish
Component-output checks establish specific generated behavior. A complete portable project/module factory and full CLI acceptance remain consolidation work.
Source: Current SpazOut and TempFileRemover READMEs; abcsharp consolidation ledger.
Make knowledge reusable.
What should an assistant know, what should an execution record preserve, and how does feedback stay useful?
Reviewed implementation lineageA map before renovationSeparate cheap discovery from expensive interpretation.
The observation
Retained C# v2 and an isolated Fabric adapter provide a basis for repository intelligence. Deterministic inventories and selectively refreshed enrichment have different cost and evidence profiles.
What remains to establish
Scan coverage, freshness, external references, and configured provider behavior remain version-specific concerns.
Source: DevBuddy v2 family decision ledger.
Concrete catalog/reconciliation lineageOrganizational knowledge that shipsVersion a practice once. Bring it into the developer loop.
The observation
The source review identifies concrete TypeScript catalog/reconciliation work. Portable source assets and thin assistant adapters aim to reduce duplicated organizational instructions.
What remains to establish
The new shared-core boundary and support for particular assistants need implementation-specific verification.
Source: AI Dev Bridge and PromptTxt entries in the family ledger.
Reviewed runtime lineageRecord, replay, compareAn AI output should leave a record you can question.
The observation
The reviewed runtime has a need/binding/configuration spine, execution evidence work, and local/deterministic provider lineage. Replay and evaluation can make changes in behavior inspectable.
What remains to establish
The review records stream, authorization, hosting, and evidence gaps. This website does not rerun the donor test suite or claim full closure.
Source: Fabric v3 family decision ledger, retain-and-harden assessment.
Retained C# lineage; shared-engine workClose the evidence loopRelease is a moment in the learning cycle.
The observation
The reviewed capture/domain/pipeline and progress implementation are selected for retention. The product direction carries contributor context through decisions, work, verification, and communication back.
What remains to establish
Consent, private retrieval, execution effects, and extracted shared services remain important implementation-specific boundaries.
Source: Context Feedback Bridge entry in the family decision ledger.
Turn patterns into foundations.
Which responsibilities are shared across applications, and which still belong to the experience being built?
Retained source; active developmentEnterprise modules with ownersCompose reusable behavior without hiding its boundaries.
The observation
AccountModule, FinancialModule, and LiveRoom are permanent enterprise modules. NoBugs and GeneralChat are existing lazy modules. Current notes record bounded mapping, realtime, and capability-boundary work.
What remains to establish
SurveyModule remains planned lazy infrastructure. Individual checkpoints are not whole-DNF or production-topology certification.
Source: Current Alloc ecosystem implementation notes, October 2026.
Historical donors; ongoing consolidationA room can become many experiencesCoordinate people, then give the room something useful to do.
The observation
Voting, questions, presentation, group feedback, and playful participation belong to an experience family. LiveRoom supplies coordination responsibilities; those experiences supply their own behavior.
What remains to establish
Preserving all accepted donor behavior remains current work. An experience is not another permanent enterprise module.
Source: AddToMeeting / LiveVotingApp donor map and current DNF priorities.
Research and designKeep evidence attached to intentDo not lose the reason when the work changes tools.
The observation
Discovery distinguishes claims from observations. Intent preserves why work exists. Feedback returns evidence from lived experience to future decisions.
What remains to establish
ZoneFold’s spatial experience and the fully connected decision-to-delivery system remain design and integration directions.
Source: ZoneFold, StraightLine, and Context Feedback Bridge source atlas and owner brief.
SOURCES & MATURITYKeep the record—and its limits.
These notes combine James’s knowledge transfer with local project documentation and source-review records. Historical source findings are identified as historical. Website tests do not certify the underlying donor systems.
- Current Alloc ecosystem implementation notes.
- Retained SpazOut and TempFileRemover documentation.
- The original EDO runner documentation.
- Family decision ledger v0.4 and copy map v0.6.
- Product atlas, design material, and owner brief.
A working component, a bounded test, and an integrated product establish different things. Product pages show the relevant state. Raw working repositories are not automatically public; sharing and availability are discussed directly.
Ask for an implementation walkthrough ↗