@bendyline/gilde 0.1.80 → 0.1.82

package/authoring/chat-models/qwen3.8-27b-q4.json

@@ -18,14 +18,14 @@
     "name": "Alibaba",
     "url": "https://huggingface.co/Qwen/Qwen3.8-27B"
   },
-  "version": "1.0.1",
-  "updatedAt": "2026-08-15T00:00:00Z",
+  "version": "1.0.5",
+  "updatedAt": "2026-10-04T00:00:00Z",
   "license": "Apache-2.0",
   "licenseClass": "open",
   "licenseShortName": "Apache 2.0",
   "recoScore": 23,
   "parameterSize": "27B",
-  "approxSizeBytes": 17106775008,
+  "approxSizeBytes": 16464440224,
   "supportsTools": true,
   "contextWindow": 262144,
   "upstream": "https://huggingface.co/Qwen/Qwen3.8-27B",
@@ -66,7 +66,7 @@
       "enableThinking": true,
       "thinkingBudget": 4096,
       "templateKwargs": {
-        "reasoning_effort": "medium"
+        "reasoning_effort": "low"
       }
     },
     "promptTags": {
@@ -88,7 +88,7 @@
           "enableThinking": true,
           "thinkingBudget": 4096,
           "templateKwargs": {
-            "reasoning_effort": "medium"
+            "reasoning_effort": "low"
           }
         }
       },
@@ -170,17 +170,35 @@
   },
   "llamaCpp": {
     "huggingfaceRepo": "unsloth/Qwen3.8-27B-GGUF",
-    "filename": "Qwen3.8-27B-Q4_K_M.gguf",
-    "quantization": "Q4_K_M",
-    "residentBytes": 20528130010,
+    "filename": "Qwen3.8-27B-UD-Q4_K_M.gguf",
+    "quantization": "UD-Q4_K_M",
     "mmprojFilename": "mmproj-F16.gguf"
   },
   "mlx": {
     "huggingfaceRepo": "mlx-community/Qwen3.8-27B-4bit",
-    "quantization": "4bit"
+    "quantization": "4bit",
+    "drafter": {
+      "huggingfaceRepo": "mlx-community/Qwen3.8-27B-MTP-4bit",
+      "kind": "mtp",
+      "residentBytes": 860162893
+    }
   },
   "releasePatch": {
     "tuning": {
+      "reasoning": {
+        "templateKwargs": {
+          "reasoning_effort": "low"
+        }
+      },
+      "profiles": {
+        "thinking-general": {
+          "reasoning": {
+            "templateKwargs": {
+              "reasoning_effort": "low"
+            }
+          }
+        }
+      },
       "engine": {
         "llamaCpp": {
           "spec": {

package/authoring/tactical/books/bug-fix-tdd.json

@@ -53,7 +53,7 @@
         "description": "Establish the failure on the real code, as a running test that fails for the right reason.",
         "suggestedRole": "debugging engineer",
         "capabilityFloor": "small",
-        "prompt": "The bug to fix: {{scope}}\n\nEstablish the failure on the REAL code before changing anything. Read the bug description and the involved source. Find how this project runs its tests (`list_package_scripts`, then read the existing test layout). Write ONE focused test that captures the exact wrong behavior, in the project's real test layout and style — never a scratch file like `src/bug.test.js`. Then run the suite with `run_package_script` (`test`) and confirm it FAILS because of your new test, for the right reason — quote the failing assertion. If the command needs first-use approval, say so and wait rather than guessing. If you cannot reproduce the bug at all, record every attempt honestly; do not invent a cause.\n\nWrite `{{workPath}}/repro.md` with exactly these sections: `## Symptom` (what the user sees, in their words), `## Repro command` (the exact command you ran), `## Expected`, `## Actual`, `## Red evidence` (the failing test's path and the quoted failing output from the real run). Cite the real files involved with backtick paths.",
+        "prompt": "The bug to fix: {{scope}}\n\nEstablish the failure on the REAL code before changing anything. Read the bug description and the involved source. Find how this project runs its tests (`list_package_scripts`, then read the existing test layout). Write ONE focused test that captures the exact wrong behavior, in the project's real test layout and style, and save it with `write_file` — never a scratch file like `src/bug.test.js`. That test file is the ONLY workspace file you may write in this step: do not edit the source under test, because the run must fail against today's code and the fix belongs to a later step. Then run the suite with `run_package_script` (`test`) and confirm it FAILS because of your new test, for the right reason — quote the failing assertion. If the command needs first-use approval, say so and wait rather than guessing. If you cannot reproduce the bug at all, record every attempt honestly; do not invent a cause.\n\nWrite `{{workPath}}/repro.md` with exactly these sections: `## Symptom` (what the user sees, in their words), `## Repro command` (the exact command you ran), `## Expected`, `## Actual`, `## Red evidence` (the failing test's path and the quoted failing output from the real run). Cite the real files involved with backtick paths.",
         "output": {
           "path": "{{workPath}}/repro.md",
           "minBytes": 500,
@@ -181,7 +181,7 @@
         "description": "Re-run the original reproduction and the whole suite; record the real results.",
         "suggestedRole": "software engineer",
         "capabilityFloor": "small",
-        "prompt": "Prove the fix with fresh eyes. Read `{{workPath}}/repro.md` and re-run the EXACT reproduction command it records with `run_package_script` (the suite runs ONLY through `run_package_script` with script name \"test\"; `run_installed_script` is for named ops scripts and is NOT the test runner) — the previously failing test must now pass, and the whole suite must be green. Anything you could not actually run gets labeled unverified, never claimed. If something regressed, your fix was too broad — go back and narrow it before validating again.\n\nWrite `{{workPath}}/validation.md` with exactly these sections: `## Repro re-run` (the command and what happened to the once-failing test), `## Suite` (the full-suite result), `## Result` (red-to-green confirmed, or what remains unverified and why).",
+        "prompt": "Prove the fix with fresh eyes. Read `{{workPath}}/repro.md` and re-run the EXACT reproduction command it records with `run_package_script` (the suite runs ONLY through `run_package_script` with script name \"test\"; `run_installed_script` is for named ops scripts and is NOT the test runner) — the previously failing test must now pass, and the whole suite must be green. Anything you could not actually run gets labeled unverified, never claimed. If something regressed, your fix was too broad: narrow it at the defect site with `replace_in_file` (never by weakening or deleting the reproduction test), re-run the suite, and record the narrowing under `## Result`.\n\nWrite `{{workPath}}/validation.md` with exactly these sections: `## Repro re-run` (the command and what happened to the once-failing test), `## Suite` (the full-suite result), `## Result` (red-to-green confirmed, or what remains unverified and why).",
         "output": {
           "path": "{{workPath}}/validation.md",
           "minBytes": 400,

package/authoring/tactical/books/dependency-upgrade.json

@@ -137,7 +137,7 @@
         "description": "Re-run the whole suite on the final tree, spot-check the adaptations, and record a concrete rollback path.",
         "suggestedRole": "software engineer",
         "capabilityFloor": "medium",
-        "prompt": "Prove the result with fresh eyes. Re-run the whole suite with `run_package_script` (`test`) - it must be green on the final tree; if it is not, go back and fix or revert before verifying again. Re-read `{{workPath}}/change-notes.md` and spot-check each adaptation at its real location with `read_file`. Then record the rollback path: exactly which manifest and lockfile entries (or vendored files) to restore, and in what order, to return to the pre-upgrade state. Anything you could not actually run gets labeled unverified, never claimed.\n\nWrite `{{workPath}}/verification.md` with exactly these sections: `## Suite` (the full-suite command and its result), `## Adaptations verified` (which call sites you re-opened and what you confirmed), `## Rollback` (the concrete revert steps), `## Result` (upgraded and green, or what remains unverified and why).",
+        "prompt": "Prove the result with fresh eyes. Re-run the whole suite with `run_package_script` (`test`) - it must be green on the final tree. If it is not, fix the broken call site with `replace_in_file`, or revert the stage that broke it (manifest, lockfile, and touched files back exactly as they were, with `write_file`, then `npm_install`); re-run the suite, and record the fix or revert under `## Result` before verifying again. Re-read `{{workPath}}/change-notes.md` and spot-check each adaptation at its real location with `read_file`. Then record the rollback path: exactly which manifest and lockfile entries (or vendored files) to restore, and in what order, to return to the pre-upgrade state. Anything you could not actually run gets labeled unverified, never claimed.\n\nWrite `{{workPath}}/verification.md` with exactly these sections: `## Suite` (the full-suite command and its result), `## Adaptations verified` (which call sites you re-opened and what you confirmed), `## Rollback` (the concrete revert steps), `## Result` (upgraded and green, or what remains unverified and why).",
         "output": {
           "path": "{{workPath}}/verification.md",
           "minBytes": 450,

package/authoring/tactical/books/refactor-module.json

@@ -53,7 +53,7 @@
         "description": "Record the current truth before changing anything: suite green, structural measurements, and the guardrail — with characterization tests added first where coverage is thin.",
         "suggestedRole": "software engineer",
         "capabilityFloor": "medium",
-        "prompt": "The refactor scope: {{scope}}\n\nCapture the current truth before changing anything — measure BEFORE, so the improvement can be proven later with the same method. Read the involved source and find how this project runs its tests (`list_package_scripts`, then read the existing test layout). Run the suite with `run_package_script` (`test`) and confirm it is GREEN before any restructuring; if it is already red, stop and report that honestly instead of refactoring on a broken base. If the command needs first-use approval, say so and wait rather than guessing.\n\nWhere the code you are about to restructure lacks tests, write characterization tests FIRST: tests that pin the CURRENT behavior — bugs and quirks included — in the project's real test layout and style. They are the guardrail. Run them and record that they pass against today's code; do not fix anything they reveal.\n\nThen record the structural measurements this refactor targets, as numbers gathered by a stated method: duplicated blocks and where each copy lives, function lengths, file sizes, tangled responsibilities — counted, not adjectived.\n\nWrite `{{workPath}}/baseline.md` with exactly these sections: `## Current behavior` (what the code does today and which tests pin it, including any characterization tests you just added), `## Measurements` (the structural numbers and the exact method used to gather them), `## Guardrail` (what must not change: public API, observable behavior, and the suite staying green). Cite the real files involved with backtick paths.",
+        "prompt": "The refactor scope: {{scope}}\n\nCapture the current truth before changing anything — measure BEFORE, so the improvement can be proven later with the same method. Read the involved source and find how this project runs its tests (`list_package_scripts`, then read the existing test layout). Run the suite with `run_package_script` (`test`) and confirm it is GREEN before any restructuring; if it is already red, stop and report that honestly instead of refactoring on a broken base. If the command needs first-use approval, say so and wait rather than guessing.\n\nWhere the code you are about to restructure lacks tests, write characterization tests FIRST: tests that pin the CURRENT behavior — bugs and quirks included — in the project's real test layout and style, each saved with `write_file`. They are the guardrail. Run them and record that they pass against today's code; do not fix anything they reveal. New test files are the ONLY workspace files you may write in this phase — do not touch the source you are about to restructure.\n\nThen record the structural measurements this refactor targets, as numbers gathered by a stated method: duplicated blocks and where each copy lives, function lengths, file sizes, tangled responsibilities — counted, not adjectived.\n\nWrite `{{workPath}}/baseline.md` with exactly these sections: `## Current behavior` (what the code does today and which tests pin it, including any characterization tests you just added), `## Measurements` (the structural numbers and the exact method used to gather them), `## Guardrail` (what must not change: public API, observable behavior, and the suite staying green). Cite the real files involved with backtick paths.",
         "output": {
           "path": "{{workPath}}/baseline.md",
           "minBytes": 500,
@@ -93,7 +93,7 @@
         "description": "Design the target structure and an ordered sequence of small stages, each individually reversible and each leaving the tree working. No source edits.",
         "suggestedRole": "software architect",
         "capabilityFloor": "medium",
-        "prompt": "Read `{{workPath}}/baseline.md`, then design the restructure as a sequence of small stages. State the target structure concretely: what exists after the refactor that does not exist now, and what disappears. Break the work into ordered stages where EACH stage is individually reversible and leaves the tree working with the suite green — extract this function, move that block behind a seam, collapse the duplicate — never a big-bang rewrite. Name the files each stage touches. State the acceptance criteria: the measured target from the baseline moving (with the figures it should reach), the suite green after every stage, and the public API unchanged unless you explicitly declare a break here and say why. Do not edit any source in this phase.\n\nWrite `{{workPath}}/plan.md` with exactly these sections: `## Target` (the end structure), `## Stages` (numbered, each reversible, each naming its files), `## Acceptance criteria`. Cite the real files with backtick paths.",
+        "prompt": "Read `{{workPath}}/baseline.md`, then design the restructure as a sequence of small stages. State the target structure concretely: what exists after the refactor that does not exist now, and what disappears. Break the work into ordered stages where EACH stage is individually reversible and leaves the tree working with the suite green — extract this function, move that block behind a seam, collapse the duplicate — never a big-bang rewrite. Name the files each stage touches. State the acceptance criteria: the measured target from the baseline moving (with the figures it should reach), the suite green after every stage, and the public API unchanged unless you explicitly declare a break here and say why. Do not edit any source in this phase.\n\nWrite `{{workPath}}/plan.md` with exactly these sections: `## Target` (the end structure), `## Stages` (numbered, each reversible, each naming its files), `## Acceptance criteria`. Cite at least two files that exist today with backtick paths, such as the modules you read. A backticked path means the file exists NOW — every one is checked and a missing file is rejected — so write a file the refactor will CREATE as plain text without backticks, marked as new (for example: new file src/shared-name.js).",
         "output": {
           "path": "{{workPath}}/plan.md",
           "minBytes": 500,
@@ -127,7 +127,7 @@
         "description": "Execute the planned stages at the real sites, keeping the suite green between stages.",
         "suggestedRole": "software engineer",
         "capabilityFloor": "medium",
-        "prompt": "Read `{{workPath}}/plan.md` and `{{workPath}}/baseline.md`, then execute the stages in order at the REAL sites — edit the actual files with `read_file` plus `write_file`/`replace_in_file`; there is no prescribed output path for source changes and never a scratch copy. After EACH stage, run the suite with `run_package_script` (`test`) and confirm it is still green before starting the next; a stage that goes red gets reverted or narrowed until green, not stacked on. Keep behavior identical: no fixes or features smuggled in under cover of the restructure — if you find a genuine bug, record it in your notes for the user instead of silently changing behavior the tests pin. Keep the characterization tests from the baseline; they ride along as permanent guards.\n\nWrite `{{workPath}}/change-notes.md` with exactly these sections: `## Stages executed` (each stage, in order, with its suite-green confirmation), `## Files touched` (backtick path per line), `## Deviations from plan` (anything done differently than plan.md and why; write `none` honestly when there are none).",
+        "prompt": "Read `{{workPath}}/plan.md` and `{{workPath}}/baseline.md`, then execute the stages in order at the REAL sites — edit the actual files with `read_file` plus `write_file`/`replace_in_file`; there is no prescribed output path for source changes and never a scratch copy. After EACH stage, run the suite with `run_package_script` (`test`) and confirm it is still green before starting the next; a stage that goes red gets reverted or narrowed until green, not stacked on. Keep behavior identical: no fixes or features smuggled in under cover of the restructure — if you find a genuine bug, record it in your notes for the user instead of silently changing behavior the tests pin. Keep the characterization tests from the baseline; they ride along as permanent guards.\n\nWrite `{{workPath}}/change-notes.md` with exactly these sections: `## Stages executed` (each stage, in order, with its suite-green confirmation), `## Files touched` (one backtick path per line for every file that exists after your stages, including files you created; name a file a stage deleted in plain text without backticks, for example: deleted src/old-copy.js — every backticked path must exist), `## Deviations from plan` (anything done differently than plan.md and why; write `none` honestly when there are none).",
         "output": {
           "path": "{{workPath}}/change-notes.md",
           "minBytes": 600,
@@ -209,7 +209,7 @@
         "Observable behavior unchanged (or changed only as the plan declared): public API and outputs held, and the pinning tests still pass unmodified — open the touched files and the tests; do not grade from change-notes.md alone.",
         "The measured target moved against the recorded baseline using the same method: verification.md quotes both figures side by side, and the duplication/structure improvement is visible in the real files, not just claimed.",
         "No stage left the suite red (receipts, not claims): the recorded runs show green between stages and green at the end.",
-        "Every stage in change-notes.md matches a plan.md stage or an honestly recorded deviation, and every touched file it names exists.",
+        "Every stage in change-notes.md matches a plan.md stage or an honestly recorded deviation, and every touched file it cites in backticks exists (a file a stage deleted is named as deleted, in plain text).",
         "The public API is unchanged unless plan.md explicitly declared a break, and no fix or feature was smuggled in under cover of the restructure."
       ]
     }

package/authoring/tactical/books/test-suite-backfill.json

@@ -44,7 +44,7 @@
         "description": "Read the target modules and rank untested behavior by breakage cost; choose concrete targets. No test writing yet.",
         "suggestedRole": "quality engineer",
         "capabilityFloor": "small",
-        "prompt": "Before writing any test, learn what is worth testing. Read the target module(s) named by the task with `read_file` — the whole file, not the signatures — and read the existing test layout (`list_dir` on the test folder, then the test files) to learn where tests live and how this project writes them. Rank the UNTESTED behavior by breakage cost: what would hurt users or downstream code most if it went silently wrong — boundary semantics, error contracts, arithmetic, state transitions — not what is easiest to cover. Then choose concrete targets: the specific functions and the specific behaviors of each you will pin, including the edge and error cases. Be honest about what you are deliberately leaving untested and why.\n\nWrite `{{workPath}}/risk-map.md` with exactly these sections: `## Modules` (each target module and what it does, with backtick paths), `## Risks ranked` (the untested behaviors ordered by breakage cost, with the cost stated), `## Chosen targets` (the tests you will write, each naming the behavior it pins). Every path you cite must be real.",
+        "prompt": "Before writing any test, learn what is worth testing. Read the target module(s) named by the task with `read_file` — the whole file, not the signatures — and read the existing test layout (`list_dir` on the test folder, then the test files) to learn where tests live and how this project writes them. Rank the UNTESTED behavior by breakage cost: what would hurt users or downstream code most if it went silently wrong — boundary semantics, error contracts, arithmetic, state transitions — not what is easiest to cover. Then choose concrete targets: the specific functions and the specific behaviors of each you will pin, including the edge and error cases. Be honest about what you are deliberately leaving untested and why.\n\nWrite `{{workPath}}/risk-map.md` with exactly these sections: `## Modules` (each target module and what it does, with backtick paths), `## Risks ranked` (the untested behaviors ordered by breakage cost, with the cost stated), `## Chosen targets` (the tests you will write, each naming the behavior it pins). Cite at least two files that exist today with backtick paths, such as the modules and existing tests you read. A backticked path means the file exists NOW — every one is checked and a missing file is rejected — so name a planned test path in plain text without backticks, marked as new (for example: new tests/parser.test.js).",
         "output": {
           "path": "{{workPath}}/risk-map.md",
           "minBytes": 500,
@@ -112,7 +112,7 @@
         "description": "Run the whole suite and record the real result, with a per-test statement of the regression it guards.",
         "suggestedRole": "software engineer",
         "capabilityFloor": "small",
-        "prompt": "Prove the backfill with a full, fresh run. Execute the whole suite with `run_package_script` (`test`) — every test, old and new, must pass. If anything fails, fix the TEST (or honestly report the module bug it exposed); do not touch the module under test to force green. Then account for the coverage: for each new test, one line stating the regression it now guards — what break it would catch that yesterday's suite would have missed. Compare against `{{workPath}}/risk-map.md`: any chosen target you did not cover gets an honest deferral with the reason, never silence.\n\nWrite `{{workPath}}/verification.md` with exactly these sections: `## Suite` (the exact command and the real full-suite result), `## Coverage summary` (per-test: the regression it guards; plus honest deferrals), `## Result` (green confirmed, or what remains open and why).",
+        "prompt": "Prove the backfill with a full, fresh run. Execute the whole suite with `run_package_script` (`test`) — every test, old and new, must pass. If anything fails, fix the TEST with `replace_in_file` (or honestly report the module bug it exposed); do not touch the module under test to force green. Then account for the coverage: for each new test, one line stating the regression it now guards — what break it would catch that yesterday's suite would have missed. Compare against `{{workPath}}/risk-map.md`: any chosen target you did not cover gets an honest deferral with the reason, never silence.\n\nWrite `{{workPath}}/verification.md` with exactly these sections: `## Suite` (the exact command and the real full-suite result), `## Coverage summary` (per-test: the regression it guards; plus honest deferrals), `## Result` (green confirmed, or what remains open and why).",
         "output": {
           "path": "{{workPath}}/verification.md",
           "minBytes": 400,

package/authoring/tactical/wave.json

@@ -3,8 +3,8 @@
   "books": [
     {
       "id": "bug-fix-tdd",
-      "version": "2.0.4",
-      "releasedAt": "2026-09-27T04:00:00Z",
+      "version": "2.0.5",
+      "releasedAt": "2026-10-02T12:00:00Z",
       "minGezelVersion": "1.26236"
     },
     {
@@ -39,8 +39,8 @@
     },
     {
       "id": "refactor-module",
-      "version": "2.0.4",
-      "releasedAt": "2026-09-27T04:00:00Z",
+      "version": "2.0.5",
+      "releasedAt": "2026-10-02T12:00:00Z",
       "minGezelVersion": "1.26236"
     },
     {
@@ -57,8 +57,8 @@
     },
     {
       "id": "dependency-upgrade",
-      "version": "1.0.4",
-      "releasedAt": "2026-09-27T04:00:00Z",
+      "version": "1.0.5",
+      "releasedAt": "2026-10-02T13:00:00Z",
       "minGezelVersion": "1.26236"
     },
     {
@@ -75,8 +75,8 @@
     },
     {
       "id": "test-suite-backfill",
-      "version": "2.0.4",
-      "releasedAt": "2026-09-27T04:00:00Z",
+      "version": "2.0.5",
+      "releasedAt": "2026-10-02T13:00:00Z",
       "minGezelVersion": "1.26236"
     },
     {