@turri-dev/cli 0.1.15-next.5bcaf8b → 0.1.16-next.ad20bf1

package/.pi/themes/turri-dark.json

@@ -33,7 +33,7 @@
     "searchMatchBg": "neon",
     "searchMatchText": "abyss",
     "userMessageBg": "",
-    "userMessageText": "white",
+    "userMessageText": "neon",
     "customMessageBg": "",
     "customMessageText": "grauzone",
     "customMessageLabel": "neon",

package/dist/init-config.js

@@ -281,8 +281,9 @@ export function quickStartConfig(vendor = "other", bedrock, models) {
         `max-specs-per-pulse: ${DEFAULTS.maxSpecsPerPulse}`,
         `max-lines-per-pulse: ${DEFAULTS.maxLinesPerPulse}`,
         "",
-        "# Rules left out of the spec-writing agents' prompts - the files of genome/rules/, without .md: [concise-specs].",
-        "rules-off: []",
+        "# Rules left out of the spec-writing agents' prompts - the files of genome/rules/, without .md. The integration rules",
+        "# are left out to start with: take one out of this list when this project writes an integration against a REST API.",
+        "rules-off: [integration-embedded, integration-embedded-testing, integration-standalone]",
         "",
         "# Credentials the agents' commands need while they work: dotenv files by path, and variables from turri's",
         "# environment by name - files: [.env], vars: [MY_SERVICE_API_KEY]. Their values are masked in everything an agent is shown.",

package/docs/config.md

@@ -87,7 +87,7 @@ models:                              # each agent role's model, thinking and tur
 | `conformance-budget` | under `conformance-tests: chosen` or `module`: how many of a module's functional specs may be chosen for conformance tests, beside those with acceptance tests - a count (`2`) or a share of its functional specs (`30%`, rounded up, at least one). Every choice for the module counts, whenever it was made; the chooser is told what is left, and can choose no more. Your own `conform` is not limited. A stack's `config.turri.<stack>.yaml` can set its own | no limit |
 | `review` | `true` or `false`: whether the code and its unit tests - and the conformance tests - are reviewed once they pass: two reviews at most, the second weighed by the arbiter; off, a job lands once its tests pass. A module's first pulse of one functional spec - the project set up and the smallest thing that runs - lands on its unit tests with no review - see [regenerating the code](regenerating.md#the-code-and-its-unit-tests-are-reviewed) | `false` |
 | `mutation-testing` | `true` or `false`: whether the coding agent and the reviewer have `can_it_fail` - one change put in the code for one run of the unit testing script, to see that a test catches it; on a copy of the code, or in place and put back after the run (see [regenerating the code](regenerating.md#checking-its-own-work)). `turri regenerate --mutation-testing false` for one run | `true` |
-| `rules-off` | a list of rule names - `integrations`, `concise-specs`, the files of `genome/rules/` without `.md` - left out of the conversation's prompt and every \*\*\*plain-writing agent's: a rule this project's own skills or AGENTS.md replace, such as one that says to probe a live API before any \*\*\*plain is written. The project's alone | none |
+| `rules-off` | a list of rule names - `integrations`, `concise-specs`, the files of `genome/rules/` without `.md` - left out of the conversation's prompt and every \*\*\*plain-writing agent's: a rule this project's own skills or AGENTS.md replace, such as one that says to probe a live API before any \*\*\*plain is written. `turri init-config` writes it with `integration-embedded`, `integration-embedded-testing` and `integration-standalone` - take them out when the project writes an integration against a REST API. The project's alone | none |
 | `allow-to-stop-jobs` | `true` or `false`: whether turri stops a running job \*\*\*plain has moved on from - a functional spec it regenerates changed, or a file one links was edited - rolls it back and regenerates \*\*\*plain as it now is. `false`: the job runs to its end and lands, and what changed since is regenerated on top of it by the next job - see [regenerating the code](regenerating.md). Your own `halt` stops a job either way | `true` |
 | `release-after-pulse` | `true` or `false`: whether every pulse that lands code releases it, in the chat, as its last stage - before the module's next pulse starts, whatever the chat is doing: an agent on the coding model looks for the project's release guidance as the chat does (what was passed to `release` this conversation, AGENTS.md, the project's skills) and, when it says to release after a build, does what it says - see [deploy](deploy.md#after-every-pulse). One release a pulse that lands; a release that fails is said in the pulse's report, and what it landed stays | `false` |
 | `unittests-script` | the unit testing script, by path from the project root - it runs the code's static checks too, exiting 80 when only they fail (see [the static checks](regenerating.md#the-static-checks)) | looked for - see below |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@turri-dev/cli",
-  "version": "0.1.15-next.5bcaf8b",
+  "version": "0.1.16-next.ad20bf1",
   "license": "MIT",
   "type": "module",
   "repository": {