plane

name

plane

description

Shape one visible result across two or more technical domains, from an intentionally incomplete sketch through implementation and release. Use plane when meaning, control, or guarantees must cross UI, API, services, data, infrastructure, observability, or time. Hold the cross-domain shape, pass each domain branch to line, and integrate the returned domain results without mistaking unfinished branches for completed work.

Plane

Use $plane for explicit invocation.

Hold the whole and let Line do the branches

Start with the final state seen by a person or system. Work back through the domains, boundaries, handoffs, and release states that can make that result true or false. plane holds the whole shape of a result; it does not demand that every point be finished.

Do not expand every domain inside plane. Choose the current cross-boundary question or path, keep the other branches in their proper places, and pass each branch that can be owned and proved inside one technical domain to line. Line does the domain work behind that place; plane keeps the relations between Lines and the final result coherent.

A useful Plane can begin as a sketch. At that stage it may contain pseudocode, partial code, placeholders, unresolved names, or syntax that is not yet valid. Its job is to show the shape and relations of the result, not to pretend to be a runnable program.

Ask:

• What must eventually be seen at the end?
• What is the current question: shape, decision, implementation, integration, or release?
• Which relation must Plane resolve, and which domain branches belong to Line?
• Which unknown could change the shape of the whole plane, and which conclusions must remain provisional until it is resolved?
• What must be true before a sketch may become an implementation or a release?

Pass domain work to Line

In plane, pass marks a real branch whose details belong to line. It is how a line appears from the plane before its domain result has been integrated:

This place belongs to the result. Plane preserves its boundary meaning; Line makes the branch work.

Passing keeps the branch visible in the whole while preventing Plane from absorbing domain detail. It is an ownership and attention decision, not laziness, completion, or permission to invent a result. Plane may retain an explicitly unresolved branch when it is outside the current promise, but that is not a completed pass. Once the branch belongs to the promise, passing it means giving it to Line; Line must return a coherent domain result before Plane can call the path complete.

Outside a cluster, this may simply mean continuing the same work through the line view. Inside a cluster, it may mean giving the branch to a line agent. The relation between the views stays the same either way.

Pass a branch to line when:

• its outcome has a clear place in the cross-domain result;
• its work and proof can be owned inside one technical domain;
• Plane can state the boundary meaning the branch must preserve; and
• Line can decide its internal rule and local work without redefining the whole result.

Give line only the context that makes the branch meaningful: its place in the result, the boundary expectation, the current stage, and any dependency or acceptance evidence that matters. Use whatever form best fits the work; a rough node, short note, conversation, or direct assignment can be enough. In a sketch, a bare pass can mark the place that will become line work. Do not impose a fixed handoff form or turn each marker into a second plane.

If a branch cannot be understood or proved within one domain, it is not line work yet. Keep the cross-domain question in plane, resolve the boundary or split the shape, and only then pass the resulting domain branches to line.

In a clearly marked draft, the literal language construct pass or another non-runnable placeholder is acceptable as the location of a line. In source presented as an implementation, use pass only when doing nothing is the truthful behavior. Otherwise use the project's honest no-op, disabled, or not-implemented form. Never let a placeholder quietly claim the result that its line has not returned.

Do not treat a passed branch as settled merely because it has been assigned. It remains unfinished when:

• a later statement relies on its answer but is presented as final;
• its line has not returned a coherent domain result and fitting evidence;
• its returned result changes or fails to preserve plane's boundary meaning;
• it protects people, data, money, security, cleanup, or another consequential guarantee that is being promised now; or
• the work has moved to a stage whose artifact is expected to be implemented, integrated, or delivered.

Let the stage set the standard

Use the same plane at different levels of completion. Do not apply delivery checks to a sketch merely because the sketch is written near code.

If a sketch could be mistaken for buildable source, mark its draft state plainly. Do not run syntax, compilation, type, or test checks by habit; use one during sketching only when it can answer the conceptual question currently in doubt.

Stage	What the whole view must carry	What it does not yet require
Sketch	Final result, actors, domains, boundaries, current path, line-shaped branches, assumptions, and open decisions	Completed lines, runnable code, valid syntax, compilation, complete types, or full tests
Build	The chosen path's real interfaces, state, effects, failures, and ownership; every required branch has a line owner or an honest unresolved marker	Proof of lines outside the current change
Integration	Returned line results preserve meaning across the boundaries the result now crosses; old and new states are understood	Exhaustive checks for paths outside the promised integration
Delivery	Every promised line is integrated or explicitly refused; required checks and release/recovery evidence match the risk	Unrelated checks that cannot change the release decision

The table is a progression, not a command to advance early. A user asking for a sketch receives a sketch. A user asking for working software does not receive a sketch labeled as done. Move a branch forward when the current stage, user promise, or path makes it relevant.

Make the full path take shape

1. Name who or what sees the eventual result. State the old result, desired result, and the current stage of the work.
2. Draw the domains and paths for control, data, identity, authority, failure, time, and ownership. Mark the source of truth, trust boundaries, asynchronous work, irreversible actions, and places used to run or observe the system when those relations matter.
3. Choose one cross-boundary path and state why it has the next claim on attention. Keep unrelated paths visible without expanding them.
4. Resolve the unknowns that can change the Plane. For each boundary the current stage reaches, state the meaning, owner, state changes, errors, compatibility, and needed retry or idempotency behavior. In a sketch, these may remain rough or undecided.
5. Pass each one-domain branch on the current path to line. Let that line choose its shared rule, cover every affected part, and use point for local causes. Keep the cross-domain promise and boundary decisions in plane.
6. Integrate each returned line result into the path. If it exposes a cross-domain question or changes boundary meaning, reshape the plane before asking a line to continue. Replace draft placeholders that would mislead callers.
7. At integration or delivery, check the boundaries that now carry the promise: permissions, failure, concurrent work, recovery, observability, migration, rollout, and rollback in proportion to the result and its risks.
8. Report the visible result, current stage and path, integrated Lines, unfinished or unassigned pass branches, boundary rules, evidence, and remaining gaps.

Integrate what Line returns

A pass is resolved only when line has made the branch coherent and plane has confirmed that its result preserves the surrounding boundary meaning. Plane owns that integration judgment; Line owns the domain proof.

Ask line to work or revisit a branch when the current path reaches it, a new fact changes it, another line depends on it, or the stage brings it inside the current promise. A permanently empty behavior is a real contract decision in plane, not an unresolved pass.

Hold a Cluster result

When $cluster is active, the root agent is plane; do not add a second Cluster coordinator. Hold the whole user result and its boundary contracts. Each participating domain branch that plane passes becomes one line agent's work. Accept the returned domain results and join their point evidence into one plane result. Keep the work relationship fixed as Plane → Line → Point. If a lower layer reports a cross-domain concern, reshape the plane and pass the resulting domain work to the fitting line rather than letting agents skip a layer.

Keep every pass in the plane map, but do not count assignment as completion. Return the integrated result, boundary evidence, full acceptance evidence, and every branch that still belongs to a later promise. The root plane owns final acceptance and completion.

Stop or use another view

• A sketch is complete when the whole relationship, current path, important boundaries, line-shaped branches, and decisive unknowns are clear enough to guide the next move. It may not run.
• A build is complete when the promised path is implemented to the local standard of its language and project, and remaining gaps are honest.
• An integration is complete when the result's meaning and guarantees survive the boundaries it crosses, including relevant old-and-new states.
• A delivery is complete when the stated release promise has proportionate evidence, recovery is understood, and no required line remains hidden behind pass.

Use line for the work behind each one-domain pass. Use point inside line for a local question. Use the skills as views inside one process, not as repeated full checklists: plane holds and integrates the cross-domain result, line resolves a domain branch, and point finds a local cause. Show conflicts and ask for a decision when the user must choose the risk, promise, or order.