Concepts

Most of dev3d's behaviour follows from four ideas. Read these first and the guides, the reference and the internals pages will make sense on the first pass; skip them and you will keep meeting decisions that look arbitrary because the reason lives one level down.

What the four ideas are

dev3d is not a chat application with agents attached. It is an organisation that happens to be drawn as a building, running pipelines that happen to be measured in dollars, inside directories that happen to be the only place it may write. Those four nouns — organisation, pipeline, turn, directory — are where the design decisions actually live, and each of the four pages in this section explains one of them.

They are load-bearing rather than illustrative. The floor plan is not a theme over a dashboard: the seat a role occupies is a field on the role, and the anchor name in the 3D asset is a contract a Blender script asserts at build time. The model a turn runs on is not a setting on a role; it is recomputed per turn from the role's policy, the stage's task class, an estimated complexity, the installation's posture, and the budget left in the run. A run's directory is not the currently selected project; it is Run.workspacePath, frozen when the run was submitted. And the boundary that confines tool calls is not a sandbox: it is one path check that eight of the fifteen built-in tools actually call, with the shell and git gated by a human instead and extension tools not confined at all.

The pages assume only the ones before them. The office comes first because it is what you see; routing second because it is what the office is spending; projects and floors third because it is where the office is allowed to spend it.

In this section

Page	The question it answers
The office	Why the interface is a floor plan rather than a dashboard, what the furniture encodes, and how a floor grows itself.
Model routing	How one model gets chosen for one turn, what the postures and tiers really do, and what a plugin's routing rule may and may not change.
Projects, organisations and floors	What a workspace boundary actually protects, and the three places where it stops being a boundary.

If you want the mechanics before the model, How a run flows is the same territory from the other direction: it follows one brief from submission to report and names the objects as they appear. If you want to see it move first, Quick start gets a run going in a few minutes and the office is fully demonstrable with no provider keys at all.

The office is the application

The canvas is not one pane of a layout. There is exactly one WebGLRenderer, created in a mount effect, and every other surface — the info popout, the inspector, the brief dock, the full-page sheets — floats over it. Switching tabs mounts and unmounts panels; it never touches the renderer, the camera, the avatars or the socket. That single decision is why a run streaming for ten minutes does not churn WebGL contexts while you read the transcript, and it is why "go to the Projects page" does not mean "leave the office".

The consequence is peculiar for anyone used to reading documentation: the interface has to be described by what it encodes, not only by where the buttons are. A colour is a status. A floor is an organisation. A room module is a capacity decision. The office takes that seriously, including the parts that are aspirational rather than working.

A turn's model is chosen, not assigned

Every role declares a model policy, and the policy is not the answer — it is an input to a decision that runs again for every turn. Capability filtering happens first and is not tier-based. Then the posture and any escalation threshold resolve a target tier. Then a weighted score decides between the candidates, with weights explicit enough to compute the outcome by hand.

This is the page where the documentation had to be corrected most. The old version described a tier-band filter followed by a price sort, and that is not what the code does: the real formula is 0.45·fitness + 0.20·quality + 0.35·tierAffinity − costPressure·relativeCost − reliabilityPenalty + hintBonus, a better-fitting model can win from outside the requested tier, and a plugin rule that names a tier genuinely moves the walk. Model routing has the mechanism, a worked example with real rejection strings, and the caveats stated plainly.

A boundary, and the places it is not one

An organisation — the UI calls it a project, and it is a floor of the building — has a directory. Runs are stamped with it at submission, every tool call is resolved against it, and the record stays truthful after the project is renamed or forgotten. That protects one project from another. It does not protect the machine from the operator, does not confine run_shell beyond its working directory, and does not confine a plugin's own tools at all. Projects, organisations and floors draws that line precisely, with a table of what is and is not stopped.

The honest framing is worth stating here as well as there: dev3d is trusted-network software. It is designed for a machine you control, running projects you have chosen to point it at. Anything stronger would be a claim the code does not support.

The one idea underneath all of them

If a future page ever seems to describe dev3d as a generic agent framework with a novelty skin, one of these four ideas is being skipped. Come back here.