fix: keep a Mate's pictures for a week; env values stored and reported without echo

docs/spec-mate.md

@@ -2982,16 +2982,32 @@ the next one. Describing never opens a change, and with none open there is nothi
 **A change's pictures (2026-09-29; in HQ since 2026-10-02).** The pictures that prove a change
 are the screenshots `zerops_browser` takes, and each is kept as one of the Mate's pictures
 (`workflow.KeepPicture`, under the state dir) and named in the tool's result — `screenshot.picture`,
-`shot-3`, an id never given twice; the newest twenty are kept, and every one a kept description
-names. A description shows one as `![what it shows](shot-3)`: `describe-change` sends each picture
+`shot-3`, an id never given twice, with how long it is kept (`screenshot.keptFor`). The bound is
+time and bytes, not a count: a picture is kept for a week after it is taken
+(`workflow.PictureKeepFor`) — a change's "before" is often taken hours, or a whole step, ahead of
+its description (run 12: 30 pictures taken over seven hours, refused under a newest-twenty rule) —
+while the store holds at most 256 MiB (`workflow.PictureStoreBytes`), past which the oldest go
+first (counting the files on disk); the newest is always kept, and every one a kept description
+names outlives both — a pair record that does not parse is skipped, and nothing is pruned while the
+pairs' directory cannot be read. A picture already on a change outlives its file: its entry keeps the
+address HQ serves it at while that change is a pair's current one (90 days at most), so a change made
+a draft by a push is described again with the same picture; only another change needs the file, and
+a refusal lists only the pictures the change being described can show. Reading the store writes
+nothing. One store
+per state dir, shared under its own lock by every zcp process of the Mate (its conversation,
+helpers, subagents). A description shows one as `![what it shows](shot-3)`: `describe-change` sends each picture
 it names to HQ as the change's attachment (`POST /api/mate/changes/:repo/:n/attachments`, the PNG as
 the body, at most 20 MiB, once per change, the address remembered with the picture) and publishes it
 as `<img alt width height src>` at `https://<HQ>/api/apps/<appId>/changes/<repo>/<n>/attachments/<id>`,
 which the client reads as the person — the width and height the picture's shape at 720 pixels wide
 at most, so a reader reserves its box before the bytes arrive. Never a body with a broken picture: a
-picture the Mate does not keep is refused before anything is written, and one HQ will not keep
-writes nothing and keeps the words. `TestDescribeChange_Pictures`, `TestKeepBrowserPicture`,
-`TestKeepPicture_*`, `TestPictureRefs`.
+picture the Mate does not keep is refused before anything is written — the refusal names the
+pictures it does keep and how long one is kept; one pruned while the words went on is refused the
+same way and the words are not kept — and one HQ will never take (over 20 MiB, or a 4xx other than
+408/429) writes nothing and drops the words, while HQ refusing for now keeps them for the next
+delivery. A picture's file kept only as another change's address is one the change being described
+cannot show. `TestDescribeChange_Pictures`, `TestKeepBrowserPicture`,
+`TestKeepPicture_*`, `TestDescribeChange_MissingPictureNamesWhatIsKept`, `TestPictureRefs`.
 
 **A merge may come at any moment (2026-10-03; delivered through HQ).** A change appears in
 its Mate's conversation as soon as it opens, and the person may merge it while the agent still
@@ -3239,7 +3255,7 @@ and a build HQ did not make is followed by its Zerops process (`GET /process/{id
 | MB-31 | In a Mate, enrolled yet or not, launch-production refuses before it reads a scope or writes anything, and its next step names only a change the Mate's fresh state says is still open; a merged one points at the projects page, and none, or one closed without merging, says to deliver through the stage half first; with no readable enrollment it says the answer is HQ's. A container that is not a Mate keeps its route, an enrollment file on its disk notwithstanding. zcp `TestHandleLaunchProduction_AMateRefusesBeforeAnyStep` (the handler, Mate and not, enrolled and not: no SSH read, admin client, staged token or state file before the refusal), `TestLaunchProduction_AMateDeliveringThroughHQRefusesAndSaysWhatIsTrue`, `TestLaunchProduction_AMateWithoutItsEnrollmentSaysSo` (the next step). |
 | MB-32 | A project's flow and its one next step are one derivation the projects page, the left menu and a Mate's conversation all draw (D29): worst first, a failed deploy the next step — production's before a stage's — a failed stage never hiding a release, and a failed production keeping the release that might clear it; production "After the first merge" with nothing to press while `main` is empty; a preview only the stage half beside its own dev half; a group stage drawn only where one exists; the conversation's step from the flow — its own mergeable change, as _Review_ at the composer's top, and nothing of the project's. The page lays it out one way: a _Next steps_ item carries its row's own verb (_Review_, _Review release_, _+ Add production_), a _Review_ opening the review and nothing merging or releasing from the page, and a step with no verb to press is not listed; a cell holds at most two lines, a row one verb at the end of the cell it acts on (and _Review release_ beside a failed production); an empty step is a muted word, never a dashed place; _Add stage_ and _Add production_ are the project menu's, never a footer link; a Mate opens from its chip, its tile or its card. The left menu draws production as one chip on the project's heading, a stage only where there is no production, and dots no heading — a folded one shows its busy Mates' faces. `groupFlow.test.ts` — "takes the worst step first: $case", "reads production as $case", "offers Add production only where $case → $addable", "still ranks a failed production above the release", "names production's failure before a stage's, and keeps the release a failed stage does not block", `pairPreviewRoute` "is $case"; `mateNextStep.test.ts` — "$case" (its cases include "its own change, waiting for the person's review", "another Mate's change", "its own change that does not merge"); `OverviewView.test.tsx` — "carries the step's verb %s on each strip item, the row's own verb", "leaves a step with no verb to press out of the strip", "never holds more than two lines in a cell: %s", "puts the verb in the cell it belongs to", "still offers the release beside a broken production, not just the build (D28)", "draws a group stage under main only where one exists — never an empty slot", "reads production as coming after the first merge, with nothing to press", "opens any Mate a row names into its conversation, by a real button in reading order", "opens a tile's Mate from the whole tile, with no Open button beside it"; `ProjectsView.test.tsx` — "names the next step in its header, without the verb", "keeps Add stage and Add production in the group menu: no footer links", "draws each Mate as a row that carries its Preview on its first line"; `flowSteps.test.tsx` — "says its word in the muted hand, never dashed: %s", "holds its verbs at the cell's end, in order"; `projectsView.logic.test.ts` — "says %s awaits somebody: %s"; `SidebarZeropsTree.test.tsx` — "never dots a project for the production it does not have"; `SidebarProductionChip.logic.test.ts` — "$state" (its cases include "no production, only stage"), "draws no chip where there is neither a production nor a stage"; `SidebarProjects.logic.test.ts` — "headingFaces — who a folded project's heading shows (M15)"; `ZeropsReviewDoors.test.tsx` — "every door opens the review and never acts itself (R1)". |
 | MB-33 | A Mate proposes only the recipe tiers `main` of the application's recipe repository in HQ lacks (D30): a tier directory `main` has any file in is left whole, the group's first recipe lands whole, a top-level file `main` has is never proposed. The proposal is the Mate's own change in `group`, titled exactly "Mate: the group's import files" with no description, its branch `main`'s tree with the missing files written over it, so it only adds; it moves forward only — a changed composition on its head, with `main` as a second parent once `main` moved — and one `main` has overtaken is brought to `main`'s tree and adds nothing. A group whose `main` has every tier gets no change opened, and the agent's `group-recipe` answers that `main` already carries every tier. Every `buildFromGit` is the pair's repository in HQ. zcp `TestMissing_ATierTheRepositoryHas_IsLeftWhole`, `TestGroupRecipe_ProposedAsTheMatesChange`, `TestGroupRecipe_ProposesOnlyWhatMainLacks`, `TestGroupRecipe_FollowsTheProjectOnTheSameChange`, `TestGroupRecipe_MainMovedUnderAnOpenProposal`, `TestGroupRecipe_AProposalMainOvertookAddsNothing`, `TestGroupRecipe_OpensNothingMainAlreadyHas`, `TestHandleGroupRecipe_Table`. |
-| MB-34 | A Mate's description of its change is its change's body in HQ: set on the pair's open change — on record or named by the Mate's state, never opened by describing — kept on the pair while HQ does not answer and put on with the next push that moves nothing (one that opens or moves the change drops it: the change stays a draft until described again), and never put on a change it was not written for (one that merged or closed first is named to the Mate and nothing is kept; words kept for a change that is gone are dropped); every delivery or push that leaves a change open asks for it. The pictures it names are the Mate's own kept screenshots, attached to the change once each and published as `<img alt width height src>` at HQ's address; a picture not kept is refused before anything is written, and one HQ will not keep writes nothing and keeps the words. A wired pair's push credential is brought to the enrollment's before a delivery or a git-push, and a credential refusal marks the pair, which heals once a fresh session authenticates. zcp `TestDescribeChange`, `TestDescribeChange_KeptWordsMeetThePushAfterThem`, `TestDescribeChange_Refusals`, `TestWorkflowTool_DescribeChangeReachesItsHandler`, `TestDescribeChange_Pictures`, `TestKeepBrowserPicture`, `TestADeliveryBringsTheCredentialToTheCurrentOne`. |
+| MB-34 | A Mate's description of its change is its change's body in HQ: set on the pair's open change — on record or named by the Mate's state, never opened by describing — kept on the pair while HQ does not answer and put on with the next push that moves nothing (one that opens or moves the change drops it: the change stays a draft until described again), and never put on a change it was not written for (one that merged or closed first is named to the Mate and nothing is kept; words kept for a change that is gone are dropped); every delivery or push that leaves a change open asks for it. The pictures it names are the Mate's own kept screenshots, attached to the change once each and published as `<img alt width height src>` at HQ's address; a picture not kept for that change is refused before anything is written, and one HQ will never take writes nothing and drops the words (HQ refusing for now keeps them). A wired pair's push credential is brought to the enrollment's before a delivery or a git-push, and a credential refusal marks the pair, which heals once a fresh session authenticates. zcp `TestDescribeChange`, `TestDescribeChange_KeptWordsMeetThePushAfterThem`, `TestDescribeChange_Refusals`, `TestWorkflowTool_DescribeChangeReachesItsHandler`, `TestDescribeChange_Pictures`, `TestKeepBrowserPicture`, `TestADeliveryBringsTheCredentialToTheCurrentOne`. |
 | MB-35 | A new Mate stands up from its application's AI Agent tier, read from HQ, in one call (D32): every pair built from the application's repositories in HQ is read by zcp's naming, not its setups' names, adopted as the adopt route records it with the tier's setups, checked out onto the Mate's branch from the repository the tier names (never one HQ would have to make), and deployed every dev half at once, the first call answering once they stand with the stages queued, and on the second call each stage from its dev half once what its build reads stands (with no reads, every stage above it by priority); a stage never called for stays `READY_TO_DEPLOY` — with nothing committed, pushed or proposed; the runtimes the browser is still importing are waited for, bounded; a refusal before anything is touched names the adopt route, a pair that fails stops alone with the model's next step and holds only the halves whose builds read it, which say what they waited for, and a second call skips what is done. Registered in a Mate only, and a Mate's AGENTS.md sends "Stand up development of the project." to it first. zcp `TestStandup_StandsUpEveryPairFromTheRecipe`, `TestStandupAfter_EveryDevHalfStartsAtOnce`, `TestStandupReads_FromTheRecipe`, `TestStandupReads_EveryRouteTheWriterCounts`, `TestStandup_ReturnsOnceDevelopmentIsUp`, `TestStandup_ASecondCallContinuesAndSkipsWhatIsDone`, `TestStandup_TheModelIsTheBackup`, `TestStandup_WaitsForTheRuntimesTheBrowserIsImporting`, `TestParseMateTier`, `TestParseMateTier_PairsOnlyRepositoriesOfThisApplication`, `TestParseRecipeImportShape_RolesFollowTheHostnameConvention`, `TestAdoptPair_RecordsWhatTheAdoptRouteRecords`, `TestServer_StandupToolGating`, `TestBuildAgentsMD_Container_StandUpRoutesToTheTool`; integration `TestStandup_OverMCP_AMateInNoApplicationIsRefusedAndNothingIsTouched`. |
 | MB-36 | A kept Mate session is presented only after the descriptor names the expected project and its environment and the Mate confirms it with every scope the client asks for; one the Mate ended or one short of a scope is forgotten and a throwaway opens a new one; no word keeps it and mints; it never waits on the mint pace; the account's close, a refused stored login and a displaced session each end it at its Mate (D33). `keptSessions.test.ts` (client runtime and web), `identityExchange.test.ts`, `exchangeDriver.test.ts`, `signIn.guards.test.tsx`. |
 | MB-37 | A group recipe writes each search engine at no less than 2 GB `minRam` and 0.5 GB `minFreeRamGB` on every tier and never lowers a value; an unread scale writes no block; `profileOverrides` and the free-memory buffer are carried; a scaling proposal is the Mate's change in the recipe repository in HQ, written over `main`, rewriting only that host's block in every tier naming it; it refuses a block it cannot splice safely, moves forward on the same change for the same host, brings a stale one to `main`'s tree when nothing differs, and is refused while the Mate's additive proposal is open there, which in turn leaves an open scaling proposal alone; the steer speaks only after a change that finished (D34). `group_floors_test.go`, `host_scaling_test.go`, `group_profile_overrides_test.go`, `scale_test.go`; zcp `TestGroupRecipeScaling_SteersAndProposesOneHostsBlock`, `TestGroupRecipeScaling_ProposesFromMainsHeadEveryTierFresh`, `TestGroupRecipeScaling_OneOpenChangeInTheRecipeRepository`, `TestScratch_File`. |

internal/knowledge/themes/core.md

@@ -49,22 +49,22 @@ services[]:                            # REQUIRED
 ```
 
 ### Preprocessor Functions
-Enable with `#zeropsPreprocessor=on` as first line. Syntax: `<@function(<args>)>`, chain modifiers with `|`: `<@generateRandomString(<32>)|sha256>`.
+Enable with `#zeropsPreprocessor=on` as first line. Syntax: `<@function(<args>)>`, chain modifiers with `|`: `<@generateRandomString(<32>)|sha256>`. Write a space after each comma between arguments (`<@f(<a>, <b>)>`): without it the preprocessor fails.
 
 **Functions:**
 - `<@generateRandomString(<len>)>` -- random alphanumeric string
 - `<@generateRandomBytes(<len>)>` -- random bytes (binary)
-- `<@generateRandomInt(<min>,<max>)>` -- random integer in range
-- `<@pickRandom(<opt1>,<opt2>,...)>` -- pick random from options
-- `<@setVar(<name>,<content>)>` / `<@getVar(<name>)>` -- store and retrieve variables
-- `<@generateRandomStringVar(<name>,<len>)>` -- generate + store string variable
-- `<@generateJWT(<secret>,<payload>)>` -- JWT token generation
-- `<@getDateTime(<format>,[<tz>])>` -- formatted datetime
+- `<@generateRandomInt(<min>, <max>)>` -- random integer in range
+- `<@pickRandom(<opt1>, <opt2>, ...)>` -- pick random from options
+- `<@setVar(<name>, <content>)>` / `<@getVar(<name>)>` -- store and retrieve variables
+- `<@generateRandomStringVar(<name>, <len>)>` -- generate + store string variable
+- `<@generateJWT(<secret>, <payload>)>` -- JWT token generation
+- `<@getDateTime(<format>, [<tz>])>` -- formatted datetime
 - `<@generateED25519Key(<name>)>`, `<@generateRSA2048Key(<name>)>`, `<@generateRSA4096Key(<name>)>` -- key pairs (stores pubKey/privKey)
 
 **Modifiers** (applied with `|`): `sha256`, `sha512`, `bcrypt`, `argon2id` (hashing) | `toHex`, `toString` (encoding) | `upper`, `lower`, `title` (case) | `noop` (testing)
 
-**Rules:** Functions return strings. Two-phase processing: preprocessing then YAML parsing. Values generated once at import -- fixed after, not regenerated. Escape special characters: `\<`, `\>`, `\|` (double-escape `\\` for backslash)
+**Rules:** Functions return strings. Two-phase processing: preprocessing then YAML parsing. Values generated once at import -- fixed after, not regenerated. Escape special characters where the preprocessor reads them — an import YAML with `#zeropsPreprocessor=on`, and a `zerops_env` value holding a `<@…>` expression: `\<`, `\>`, `\|` (double-escape `\\` for backslash). A `zerops_env` value without `<@` — and so a `project.envVariables` value in `zerops_import` — is stored exactly as written: no escaping there.
 
 **Always-available** `${...}` functions: `${random(length)}`, `${randomInt(min,max)}`, `${sha256(value)}`, `${bcrypt(value,rounds)}`, `${argon2id(value)}`, `${jwt(algo,secret,payload)}`, `${generateRSAKeyPair(bits)}`, `${generateEd25519KeyPair()}`
 

internal/ops/browser.go

@@ -155,6 +155,9 @@ type BrowserScreenshotResult struct {
 	// ("shot-3") — how a change's description shows it, as
 	// ![what it shows](shot-3). Set by the tools layer, which keeps it.
 	Picture string `json:"picture,omitempty"`
+	// KeptFor is how long the picture is kept after it is taken ("7 days"),
+	// so the Mate knows how long it has to show it. Set with Picture.
+	KeptFor string `json:"keptFor,omitempty"`
 }
 
 // NetworkRequest is one entry from BrowserBatchResult.NetworkOutput.