Talk through your architecture, the patterns it uses, and the tools it depends on. Ask what belongs where, why a choice matters, and what you need to learn next.
Burdgen is Laravel first. Explore routes, controllers, Blade components, tests, and database observations alongside the conversations and decisions that explain them.
Private preview. Browser access for reading and dispatch. A connected runner for local execution.
Because a failed payment should not make the customer start over. Keep that reasoning with the change.
Return to the original discussion and the choice you made.
Save its rationale with file links and citations.
Use the recorded context when preparing the next request.
Where does this behavior belong? Why this pattern? What is this tool doing for us?
Use questions like these to explore your project. Bring the architecture, its patterns, and the tools you rely on into the conversation.
Join the interest listStart with a project question, then explore its files, relationships, and available explanations. Put the discussion beside the code so you can check an explanation against what is actually there.
Ask what a pattern solves, how a tool fits, and where an approach stops being useful. Use examples from the project to make unfamiliar ideas concrete.
A question you cannot yet answer is a place to start. Follow the concepts behind a change, revisit the reasoning, and use that understanding in the next decision. Grow with your architecture as it changes.
Generated explanations depend on configured AI and available project context. The source records remain there to check.
The useful part of a conversation is often the choice buried halfway through it.
Browse imported coding sessions, reopen the messages, and find decisions by text, project, branch, file, or date. Follow a decision back to its source before you revisit the same question.
Revisit the instructions, tool activity, and recorded answers in an imported session. Browse related plans, memory documents, artifacts, and terminal history where those sources have been imported.
Write a title and rationale, attach relevant files, and add citations. Curated decisions can be written directly or promoted from imported history, then searched by title or rationale.
The current conversation and decision import is built around Claude Code history. Other history sources depend on their importers; Burdgen does not automatically collect every chat from every provider.
Build a profile of how you like to build. Turn the opinions you stand behind into a manifesto you can configure.
Some preferences follow you from project to project. You favor composition, want behavior covered by tests, or expect core pages to work without JavaScript. Keep those opinions with the reasoning and experience that shaped them.
Your manifesto is a curated collection of those opinions. Choose what belongs in it, where each principle applies, and when a project needs an exception. Give the next plan a starting point that reflects your judgment.
The user-visible profile makes tradeoffs atomic and customizable. Each is a separate choice you can inspect and adjust, with what you gain, what you give up, and where the choice applies. Change one tradeoff without rewriting your entire philosophy.
See how Deliberation shapes your manifesto
Join the interest listBring together the approaches you prefer, the tradeoffs you accept, and the choices you keep returning to. Use conversations and decisions to understand why.
Choose which opinions should guide future work. Make each tradeoff explicit, keep the supporting reasoning, and distinguish a general preference from a rule for one project.
Carry relevant opinions into project instructions and planning. Make exceptions explicit so one application's constraints do not become rules for every codebase.
Use implementation and review to test your opinions. Revise the manifesto as you learn, keeping the reasoning behind both the old position and the new one.
The preference profile and configurable manifesto are part of the workflow we are developing. Burdgen's existing versioned project instructions provide a starting point.
The model that explains a change and the environment that executes it are separate choices. Burdgen keeps requests and run records independent of the selected execution provider.
Generated summaries, commit messages, and other AI features have their own provider and model settings. A configured local or hosted model can serve the features that support it.
Coding model choices depend on the connected agent runtime. Changing an app's summary model does not change the runner's coding model.
Connect an execution environment with the repository, workspace, and tools the task needs. Keep the request and its results in Burdgen as your development setup changes.
Connections must be configured and authorized. An unavailable target is reported as unavailable, rather than silently replaced.
We are working toward strong support for local models, with the same attention to project context and review as hosted models. Available choices depend on the feature and connected environment.
You need to know what exists, what you asked for, and what changed. Burdgen gives each of those a place.
Open a project and follow its repositories, indexed files, symbols, and references. For supported projects, inspect routes, components, tests, dependencies, and database observations without starting every investigation from a file search.
The reader identifies missing, partial, and stale evidence. What you see depends on the sources you have connected and indexed.
Move through pull requests, commits, changed files, and review conversations. Inspect the code behind a change and return to the larger pull request when you need the surrounding discussion.
Source records and generated explanations remain distinct, so an interpretation does not replace the evidence.
Describe the outcome, attach inputs, select an execution target, and state the permissions the work needs. The request gets a permanent page with the context that was submitted.
Changed your mind? Submit a correction linked to the original request instead of rewriting what the runner received.
Inspect a request's task plan, dependencies, and available actions. Follow the work at the task level, and retry, skip, cancel, or re-plan where the current task state allows it.
Earlier plan versions stay available. Being ready is separate from having permission to execute.
Pair a Mac or Linux runner with a repository and local workspace. Burdgen checks the target's reported capabilities and authorization before it dispatches work.
The runner connects outward. You do not open an inbound port on your computer.
Read the execution status, events, output, result, and uploaded artifacts from the run page. Closing your browser does not end accepted work or erase its record.
A successful run is an execution result. You still need to review whether the change does what you intended.
Your browser is a way into the work. It does not have to stay open for the work to continue.
Read how Burdgen worksRead the project or pull request. Decide what needs to change and what evidence would make the result worth accepting.
Choose the workspace and target, add the instructions and inputs, and declare the required permissions.
The runner retrieves authorized work and reports progress. The request page keeps the output and result available as they arrive.
Inspect the returned evidence. Continue with a linked correction when the result needs another pass.
Pairing authorizes a particular repository and workspace. You can revoke that connection from settings without deleting the computer's files or the history of its runs.
The repository checkout, local tools, and agent process. The machine must be online and the runner must be polling to take work.
Submitted requests, uploaded inputs, execution events, output, results, and artifacts. Connected repository data also lives in the hosted workspace.
Output and artifacts can contain source code. Local execution does not mean that all project data stays on the machine.
Code gets rewritten. The reasoning behind it is worth keeping. Join the interest list for a workspace that helps you find your decisions, learn from the work, and carry that understanding into what comes next.