point

name

point

description

Make one small software change by finding its cause and getting clear proof. Use point when the wanted change, the part that causes it, the limits, and the best useful check are local. Examples include one bug fix, small feature, configuration change, focused refactor, or failing test. Use it with line when one shared rule must hold across a technical domain and plane when the change is part of a result that crosses technical domains.

Point

Use $point for explicit invocation.

Think from cause to effect

See the task as a small system of cause and effect. First make doubt smaller. Do not make the scope larger. Keep possible reasons apart. Find the smallest part that makes the effect. Get proof that a change to this part gives the wanted result. Set the boundary by cause and proof, not by file count.

Ask: What must change? What part can cause it? What is the simplest check that can show this answer is wrong? What nearby behavior must stay the same?

Run the loop

1. State the old result, the wanted result, and one local check that can tell if the change works.
2. Work back from the result to the first part that makes it wrong. For a bug, put the possible causes in order. For a feature, find the smallest place to add the new effect and say what it will change.
3. Choose each reading or test by how much it can teach you. Rule out other answers until one cause explains the important behavior and limits. Do not follow a path that cannot change the decision.
4. Make the smallest complete change at the cause. Keep named nearby rules true, including needed failure behavior and compatibility.
5. Run the most direct check and the nearest useful regression check. For a bug, show that the check fails before the change and works after it when this is practical.
6. Report the cause, the changed behavior, the proof, and any important doubt that remains.

Complete a Point in Cluster

When $cluster assigns a local question to point, work inside the objective, scope, context, and authority given by its line. Find the cause, make the smallest complete change or observation, and return direct proof to Line. Keep the Plane → Line → Point relationship intact; if the question expands beyond the domain or divides into a different kind of work, report that change to Line instead of creating another layer.

Return a useful local result and enough direct evidence for Line to judge and integrate it. Use the form that best carries this particular work; do not require fixed handoff fields. Line decides whether the local result is enough for the domain; Point does not claim the whole cluster result.

Stop or use another view

• Stop when one cause fits the proof, the result check passes, and you have checked important local alternatives and regressions to a reasonable level.
• Use line when the cause is the same broken rule in many parts of one technical domain. Use plane when proof must cross a boundary between technical domains.
• Use the skills as views inside one process, not as three full lists. Plane holds the whole and chooses attention. Line keeps shared rules true. Point finds local causes. Explore, make changes, check, and report once. Keep all limits from all active skills. Show any conflict and ask for a decision.