`api_organize`

Render one organization lens over the module as the text the CLI's `organize` prints: page (how organized the program is, at a glance: layers, blocks, holes), stack (the blocks by layer in the order a reader learns them, with reuse), conventions (how the project writes each recurring shape and where it disagrees with itself), aid (the separate heuristic reading for a weaker reader; clearly labeled as such), layers (the packages in rows by level, the packages each one uses with how many of their definitions, and the direct effect sites and tables in each package's own definitions; `layers` in the result holds the packages with their definitions and levels, and the package and definition edges, all from type-checked references), effects (each declared route as a tree, in source order, of every effect its handler can reach: the calls to it, the IO values handed to a definition as an argument, the typed branch tests around it, and transaction scopes; `effects` in the result holds one row per effect use with its route, table, site, the chain of definitions with the frames around each position, passedTo and under) or writes (the same with only row writes). The effects lens states structure; it does not judge whether a write should sit under a wrapper or a guard. With a view argument over stack or conventions, an authored view (order, foreground, declared groups, captions) renders under the unchanged page or is refused with the reason. The implementations lens returns a structured comparison: all typed user references, signatures, direct primitive effects, access findings, and located compiled repetition. Its nested groups and role meanings are authored, never inferred architecture or permission proof. The page lists; the reader judges.

Kind: Organize. Origin: Yichus/Mcp::catalog.

CLI: yichus organize — the same renderers, reached differently and not one-for-one: the tool's lens argument is page, stack, conventions, aid, layers, effects, writes or implementations, and its view is a parameter; the CLI's subcommands are page, vocabulary, stack, conventions, aid, layers, effects, writes, map, flow, view and diff. map is ToolKind.AbstractionMap; implementations has no subcommand; the tool's effects and writes also return the tree's rows, and layers its facts; vocabulary, flow and diff no tool.

Parameters

sources (required, array) — JSON array of {fileName, source} Bosatsu files for the module.
lens (required, string) — page, stack, conventions, aid, layers, effects, writes, or implementations (structured nested map and comparison).
title (optional, string) — Optional title line (default: the first file name).
view (optional, string) — For implementations, required JSON string: {schemaVersion: "implementation-view-1", question, pins: [qualified binding ids], groups: [{id, label, parent?: group id, members: [qualified binding ids]}], roles: [{id, label, references: [qualified binding ids]}]}. Optional order lists group:<id> or node:<qualified binding> layout identities to override automatic peer ordering; dependency bands are retained. Each binding has at most one direct group; parents must be acyclic. Cells are keyed by pin id then role id. Unknown identities or fields are rejected. Otherwise, optional VIEW document over stack or conventions: {lens, order, foreground, groups, captions}. The page renders unchanged and the view renders under it: the author's order and foreground, groups that must be families the program declares (Yichus/Organize::FamilySpec), captions of at most 160 characters with no verdict word, labeled says:. A view naming an unknown id, an undeclared group, a verdict word, or leaving out a mandatory fact (the stack's roots; a declared family's divergent members) is refused: text carries the page alone and viewRefused names the element and the reason.
focus (optional, string) — Optional, stack only: a block's bare name (when unique) or Pkg/Name::binding. The svg then draws that block and every block it is built from, transitively, under the same rules, and its legend counts the blocks and edges outside that cone; the text page is unchanged. An unknown or ambiguous name is refused with the candidates.

Read the result according to this tool’s scope: static checks, bounded execution checks, and descriptive diagrams answer different questions. A successful call is not a general approval of the program. The safety and permissions guide compares the checks and provides editable ownership, guard, and role examples.