@lawaty/lacode 0.1.5 → 0.1.6

package/dist/agents.js

@@ -58,13 +58,45 @@ Every question of the form "what does this file do", "where is X handled", or
   ("read src/auth.ts", "grep for 'migration' in *.py", "list the src/
   directory"), one batch per question. Ask for the exact lines or
   file:line references you need, not a survey.
-- **Implementation \u2192 @implement**, with a finalized plan: the exact
-  steps, the files to touch, and the constraints you already learned from the
-  explorers. It edits, writes, and runs tests.
+- **Implementation \u2192 @implement**, one decided unit at a time: the exact
+  steps, the exact files, the design you have already chosen, and the command
+  that proves it. Never one whole refactor handed over in a single piece \u2014
+  see \`# Task size\` below.
 
 The agents you spawn are the pooled \`explore\` / \`implement\` bases \u2014
 spawn the bare name and let the pool route, never a \`-1\`/\`-2\` slot variant.
 
+# Task size
+
+\`@implement\` runs on a cheap pooled model. It can carry out a decision; it
+cannot make one. So what you hand it is always a small ask \u2014 never a mid or
+large task.
+
+A small ask is one change, one concern, already decided by you. Before handing
+it over you should have explored, through \`@explore\`, far enough to know what
+the change is and to have chosen the design: which class or value object, which
+members, what becomes a \`static\`, what gets deleted. \`@implement\` executes that
+choice. It never invents one.
+
+It does not have to arrive fully pre-digested. Letting it find the call sites,
+read the code around them and work out which files it touches is normal and
+expected \u2014 that is exploration an agent should be free to do. What it must never
+be handed is a problem to solve.
+
+Too small is fine and costs little. Too large is the failure: "convert the
+decode modules into named units, decide which are dead, keep the output
+byte-identical, verify conformance and report" is not a task, it is the whole
+project. A cheap agent handed it will improvise a design, skip the verification
+you never spelled out, and return something you cannot trust.
+
+When the work does not divide into small asks it is not implementation work
+yet \u2014 send it to \`@plan\`, or keep it yourself.
+
+Split into one ask per task, spawn independent asks together in a single
+message so they run in parallel, and sequence only what truly depends on what.
+If a returned ask turns out to need a decision you did not make, you make the
+call and hand out a corrected ask.
+
 # What stays yours
 
 \`edit\`, \`write\`, and \`bash\` are available to you. Use them to apply what a
@@ -275,6 +307,25 @@ write, and run code/bash to make the plan's changes real. Work from the plan
 as given \u2014 if it's ambiguous or you believe it's wrong, say so explicitly
 rather than silently improvising a different approach.
 
+# Before you start
+
+The ask you receive is a small one, and it is already decided: the change is
+specified and the design is chosen. Work from it as given rather than silently
+substituting an approach of your own.
+
+Expect to do your own locating. Finding the call sites, reading what you touch
+and working out which files are involved is normal work, not a sign of a bad
+brief \u2014 do it without asking.
+
+What is not yours to do is decide. If the ask asks you to choose an approach,
+pick the right abstraction, settle a judgement call, or work out what the
+requirement even is, stop and report that back instead of improvising. A
+confident wrong design costs more than no change at all.
+
+Size works the same way. A small ask that turns out to be bigger than it looked
+is a signal to come back and say so: complete the part that is decided, and
+report precisely what else needs deciding.
+
 Make changes incrementally where possible, and verify your own work (run
 tests/build/lint if available) before considering a step done.
 

package/dist/index.js

@@ -38,9 +38,9 @@ var USER_MODELS_PATH = join(USER_CONFIG_DIR, "pool.json");
 var USER_MODELS_TXT = join(USER_CONFIG_DIR, "pool.txt");
 var FALLBACK_SLOTS = [
   { index: 1, model: "opencode/space-bunny-free", weight: 3 },
-  { index: 2, model: "openrouter/nvidia/nemotron-3-ultra-550b-a55b:free", weight: 2 },
+  { index: 2, model: "opencode-go/step-5-preview-free", weight: 2 },
   { index: 3, model: "opencode/big-pickle", weight: 1 },
-  { index: 4, model: "openrouter/thinkingmachines/inkling:free", weight: 1 }
+  { index: 4, model: "opencode/step-5-preview-free", weight: 1 }
 ];
 function parseSlots(parsed, origin) {
   const problems = [];
@@ -512,13 +512,45 @@ Every question of the form "what does this file do", "where is X handled", or
   ("read src/auth.ts", "grep for 'migration' in *.py", "list the src/
   directory"), one batch per question. Ask for the exact lines or
   file:line references you need, not a survey.
-- **Implementation \u2192 @implement**, with a finalized plan: the exact
-  steps, the files to touch, and the constraints you already learned from the
-  explorers. It edits, writes, and runs tests.
+- **Implementation \u2192 @implement**, one decided unit at a time: the exact
+  steps, the exact files, the design you have already chosen, and the command
+  that proves it. Never one whole refactor handed over in a single piece \u2014
+  see \`# Task size\` below.
 
 The agents you spawn are the pooled \`explore\` / \`implement\` bases \u2014
 spawn the bare name and let the pool route, never a \`-1\`/\`-2\` slot variant.
 
+# Task size
+
+\`@implement\` runs on a cheap pooled model. It can carry out a decision; it
+cannot make one. So what you hand it is always a small ask \u2014 never a mid or
+large task.
+
+A small ask is one change, one concern, already decided by you. Before handing
+it over you should have explored, through \`@explore\`, far enough to know what
+the change is and to have chosen the design: which class or value object, which
+members, what becomes a \`static\`, what gets deleted. \`@implement\` executes that
+choice. It never invents one.
+
+It does not have to arrive fully pre-digested. Letting it find the call sites,
+read the code around them and work out which files it touches is normal and
+expected \u2014 that is exploration an agent should be free to do. What it must never
+be handed is a problem to solve.
+
+Too small is fine and costs little. Too large is the failure: "convert the
+decode modules into named units, decide which are dead, keep the output
+byte-identical, verify conformance and report" is not a task, it is the whole
+project. A cheap agent handed it will improvise a design, skip the verification
+you never spelled out, and return something you cannot trust.
+
+When the work does not divide into small asks it is not implementation work
+yet \u2014 send it to \`@plan\`, or keep it yourself.
+
+Split into one ask per task, spawn independent asks together in a single
+message so they run in parallel, and sequence only what truly depends on what.
+If a returned ask turns out to need a decision you did not make, you make the
+call and hand out a corrected ask.
+
 # What stays yours
 
 \`edit\`, \`write\`, and \`bash\` are available to you. Use them to apply what a
@@ -729,6 +761,25 @@ write, and run code/bash to make the plan's changes real. Work from the plan
 as given \u2014 if it's ambiguous or you believe it's wrong, say so explicitly
 rather than silently improvising a different approach.
 
+# Before you start
+
+The ask you receive is a small one, and it is already decided: the change is
+specified and the design is chosen. Work from it as given rather than silently
+substituting an approach of your own.
+
+Expect to do your own locating. Finding the call sites, reading what you touch
+and working out which files are involved is normal work, not a sign of a bad
+brief \u2014 do it without asking.
+
+What is not yours to do is decide. If the ask asks you to choose an approach,
+pick the right abstraction, settle a judgement call, or work out what the
+requirement even is, stop and report that back instead of improvising. A
+confident wrong design costs more than no change at all.
+
+Size works the same way. A small ask that turns out to be bigger than it looked
+is a signal to come back and say so: complete the part that is decided, and
+report precisely what else needs deciding.
+
 Make changes incrementally where possible, and verify your own work (run
 tests/build/lint if available) before considering a step done.
 

package/dist/pool.js

@@ -38,9 +38,9 @@ var USER_MODELS_PATH = join(USER_CONFIG_DIR, "pool.json");
 var USER_MODELS_TXT = join(USER_CONFIG_DIR, "pool.txt");
 var FALLBACK_SLOTS = [
   { index: 1, model: "opencode/space-bunny-free", weight: 3 },
-  { index: 2, model: "openrouter/nvidia/nemotron-3-ultra-550b-a55b:free", weight: 2 },
+  { index: 2, model: "opencode-go/step-5-preview-free", weight: 2 },
   { index: 3, model: "opencode/big-pickle", weight: 1 },
-  { index: 4, model: "openrouter/thinkingmachines/inkling:free", weight: 1 }
+  { index: 4, model: "opencode/step-5-preview-free", weight: 1 }
 ];
 function parseSlots(parsed, origin) {
   const problems = [];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lawaty/lacode",
-  "version": "0.1.5",
+  "version": "0.1.6",
   "description": "Ultimate opencode setup for Go users — cost-controlled pooled subagents, hang recovery, and notifications for opencode.",
   "license": "MIT",
   "type": "module",

package/presets/README.md

@@ -36,10 +36,10 @@ in place, no JSON and no objects:
 
 ```text
 # provider/model-id                       weight
-opencode-go/longcat-2.5-preview-free      3
+opencode-go/step-5-preview-free           3
 opencode/space-bunny-free                 2
 opencode/big-pickle                       1
-opencode/longcat-2.5-preview-free         1
+opencode/step-5-preview-free              1
 ```
 
 `#` starts a comment (whole-line or trailing), blank lines are ignored, and the

package/presets/free-tier.json

@@ -20,8 +20,8 @@
     "  3. once EVERY slot is at its ceiling, the overflow goes to the least loaded slot,",
     "     so a burst past the summed ceilings degrades to even spreading and never blocks",
     "",
-    "With this file: longcat (opencode-go) takes 3 sessions to itself, then space-bunny",
-    "takes 2, then big-pickle and longcat (Zen) take 1 each -- sequence 1,1,1,2,2,3,4,...",
+    "With this file: space-bunny takes 3 sessions to itself, then step-5-preview",
+    "(opencode-go) takes 2, then big-pickle and step-5-preview (Zen) take 1 each -- sequence 1,1,1,2,2,3,4,...",
     "Equal weights give a plain round robin in list order. 2,2,1,1 reproduces the old",
     "primary/overflow cycle exactly, which is why the old tier values still work.",
     "",
@@ -53,8 +53,8 @@
   ],
   "slots": [
     { "model": "opencode/space-bunny-free", "weight": 3 },
-    { "model": "opencode-go/longcat-2.5-preview-free", "weight": 2 },
+    { "model": "opencode-go/step-5-preview-free", "weight": 2 },
     { "model": "opencode/big-pickle", "weight": 1 },
-    { "model": "opencode/longcat-2.5-preview-free", "weight": 1 }
+    { "model": "opencode/step-5-preview-free", "weight": 1 }
   ]
 }