@clize/clize 0.35.1 → 0.35.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@clize/clize",
-  "version": "0.35.1",
+  "version": "0.35.2",
   "mcpName": "ai.clize/clize",
   "description": "The real-world capability layer for AI agents — domains, email, deploy, media, SEO/GEO. CLI + MCP.",
   "keywords": [

package/skills/clize-seo/SKILL.md

@@ -120,9 +120,10 @@ your list. No amount of enumeration produces this. Fold it back into the matrix
 
 ---
 
-## 2. The shape of one analysis
+## 2. The shape of one round
 
-A cold start is a funnel, and the funnel has a known size and a known price.
+A round is a funnel with a known size and a known price — and there is no such thing as an
+"analysis round": every round ends in pages or in a blocker the human must clear (§10).
 
 ```
 30–100 candidates            (§1: competitor teardown + capability matrix)
@@ -235,6 +236,14 @@ will — it cannot measure those. That half of the state exists only here.
   rounds while every session executed "the existing ledger").
 - **Narrative goes underneath as footnotes.** Two or three lines about what the pattern means.
   Not six paragraphs of themes.
+- **Every ledger file counts, and a plan is a queue.** A site may carry more than one ledger
+  (tabledi: `worksheet.md` for en-US and `worksheet-global.md` for the other markets); rows in
+  all of them are the site's rows, and a round that counts only one file will report "nothing
+  to build" beside 27 verified cells. A batch plan written under an earlier count rule (`≤5,
+  wait for impressions`) is not re-planned and never "the next batch": each cell is re-gated
+  on its own SERP verdict, and every cell that passes is a `to build` row for step ⓪ of the
+  next session (§10). tabledi's B1–B4 — 27 locale tool cells, 15 SERPs bought — sat under
+  "next batch" through three sessions.
 
 **Page batches — the second table in the ledger.** Keyword rows hold bets; the batch table holds
 what the site's composition is doing, and it is what the batch gate and the retire rule (§7.3)
@@ -252,7 +261,7 @@ sitemap — and `unseenTotal` says how much of the site the list is showing you.
 
 ### The pass/fail test
 
-Six ways an analysis fails. The first is about *what you found*, the last two about *what you
+Six ways a round fails. The first is about *what you found*, the last two about *what you
 funded*; the middle three are about *whether you actually ran the analysis you claim to have
 run* — all six have been observed in real runs that read as finished.
 
@@ -281,7 +290,8 @@ run* — all six have been observed in real runs that read as finished.
    the pages they support. Observed in the field (2026-08-31 second run): five funded pages,
    placement nearly invisible in the deliverable.
 6. **Rows without pages — and families without rows.** Buildable rows — a serp verdict that is
-   not a wall, an intent you can serve — left unshipped at session end are stock, not output.
+   not a wall, an intent you can serve — left unshipped at session end, or handed to "next
+   round" without one of the three blockers in §10 ⑤, are stock, not output.
    An opportunity written in prose (a cluster, a family, a locale axis) with no rows behind it
    is test 1 wearing a different coat. The deliverable counts shipped
    URLs, not qualified rows; a ledger of twenty rows and two pages is a session that spent itself
@@ -536,6 +546,18 @@ each after the first. clize.ai went from one page per session to seven in one se
 a family generator existed, and tabledi shipped forty in two days from one. Build the generator
 before the second page of any family, and never machine-translate a family page.
 
+**On a site that already has tools, this round's page count is the locale siblings of the tools
+it has.** A sibling is one strings entry (tabledi: a `DICT` table in `tools/apps.js`; clize.ai:
+a `strings.<loc>.mjs`) and its gate is its own SERP (§7.2). Count existing tools × verified
+locale cells before anything else — tabledi had 23 tools, 6 markets, 27 cells already verified
+open, and three sessions wrote "next batch" beside them while building one page. New tools are
+code and tests, one to three per session: they are the next batch's rows, not this batch's
+excuse. And **building a page that passed the gates is never a question for the human.** The
+human's gates are money, external-facing changes (a redirect, DNS, a published post) and sends.
+Ask for those in one line and build while you wait — never bundle the pages into the question
+(tabledi, 2026-09-02: one redirect that needed a yes was asked together with three pages that
+did not, and all four waited).
+
 ### 7.1 The pipeline — five steps, each with a pass/fail
 
 | step | act | it passed if |
@@ -790,12 +812,18 @@ which is free (sv/kd are monthly data, SERPs move slowly). The entry read is the
 each round's real question is **where the next unit of work goes** — double down where a signal
 appeared, stop where none did, and keep enumerating cells the ledger has not priced yet.
 
-**A round is five steps: ① read the feedback (`check`, free) → ② allocate (double down / stop
-loss / new bet) → ③ execute (pages, placement, the occasional paid query) → ④ book it (write
-what you put in back into the ledger, §3) → ⑤ report it (two tables, below).** Step ④ is the
-one that gets skipped, and skipping it breaks step ② two weeks later: "flat, no signal" and
-"flat, no signal, *and we already pitched five roundups*" are different rows, and only the
-ledger can tell them apart.
+**A round is a pipeline, and it opens by building.** ⓪ **ship the qualified batch** — every
+`to build` row from the last round and every plan cell with its own SERP verdict (§3), in every
+ledger file — before reading a single number, while the session's budget is whole → ① read the
+feedback (`check`, free) → ② allocate (double down / stop loss / new bet) → ③ execute what is
+cheap now (siblings, retargets, placement drafts) and write the rest as the next session's
+`to build` rows → ④ book it (§3) → ⑤ report it (two tables, below). This round's analysis
+qualifies the *next* round's batch; it does not postpone this one's. Step ⓪ is the step that
+vanished in three consecutive runs: each read, diagnosed, wrote a ledger, named itself an
+"analysis round" and handed the pages to "next time". Step ④ is the other one that gets
+skipped, and skipping it breaks step ② two weeks later: "flat, no signal" and "flat, no signal,
+*and we already pitched five roundups*" are different rows, and only the ledger can tell them
+apart.
 
 ```
 clize seo check            # free — every session on an existing site starts here
@@ -859,8 +887,12 @@ every row the round touched, one line each:
 | open webui api key | en-US | open | /docs/integrations/open-webui | integration doc | to build: generator first |
 | claude code preise | de-DE | official_wall | — | — | skip |
 
-`status` is one of `built` (shipped this round), `to build` (buildable, not shipped — say why),
-`exists` (a page already carries it), `skip` (with the reason). Second, **placement** — target /
+`status` is one of `built` (shipped this round), `to build`, `exists` (a page already carries
+it), `skip` (with the reason). A `to build` row carries a blocker, and only three exist:
+`needs human` (a redirect, a send, money — asked in one line, §7), `needs tool code` (a new
+client-side tool; name the session it ships in), `needs generator` (no family scaffold yet).
+"Analysis round", "next batch" and "awaiting go-ahead" are not blockers — a row wearing one of
+those means the session is not finished, and it goes back to step ⓪. Second, **placement** — target /
 page / status (`sent` / `drafted` / `blocked: needs human`). Then at most five lines of
 narrative. A report that is findings and no pages table is test 1 (§3) in its final form: the
 human cannot act on a paragraph. A round with an empty pages table says so *in* the table, with