human2ai 0.1.0

package/skills/human2ai/references/composition.md

@@ -0,0 +1,79 @@
+# Composition sessions
+
+The Agent decides which compositional relationships support the user’s intent. Human2AI provides neutral measurements, deterministic relation operations, final relation checks and independent results. Style processing is a separate workflow used only when the request calls for it.
+
+## Draw a reference picture on the canvas
+
+Geometric areas may explicitly set `isLightSource: true` (missing or false means ordinary content). Interpret light markers at the same approximate level as ordinary composition shapes: preserve the intended lighting contribution and broad spatial relationships, not a measured light-patch template. Rectangles suggest band-shaped or extended illumination; circles suggest localized illumination. The drawn width, length, contour and gradient are descriptions, not default output constraints. User instructions and node notes take precedence; otherwise the Agent freely adapts width, length, curvature, continuity, softness and strength to the scene.
+
+An authored band should contribute a band-like or extended lighting tendency, but may be narrower or wider, taper, bend with surfaces, break into patches through occlusion, or blend with other illumination. It need not form a separate complete stripe, remain uniformly wide, pass through an exact point or span the frame. Do not add medium-strong contrast, conspicuous thumbnail visibility, exact coverage or a fixed width merely to prove that the band exists. Keep the broad lighting role without ignoring it altogether. Distinguish a source from the area it illuminates; yellow is only an identification convention. Consider multiple sources individually, while their visible effects may split, overlap or blend naturally.
+
+Generation prompts should describe the lighting intent concisely and leave implementation room, as ordinary regions allow reconstruction, splitting, merging and overlap. Review whether the overall lighting approximately echoes the composition's placement, extension and emphasis, rather than checking every stripe, edge, segment or width. Approximate overall correspondence is sufficient. Tighten only the specific properties explicitly requested by the user. For example, a broad diagonal marker can become a narrower broken wash of light across a face, fabric and background; do not insist on a ruler-like bright rectangle across all three.
+Editor and refined canvases retain marker geometry; generation references use borderless falloff with softened edges. Text regions cannot be light sources. Ordinary editing can toggle the property through draft saving; geometric refinement must preserve it. Never infer or overwrite the flag from a note alone.
+
+Requests such as “把这张图的构图画到画布上”, “按参考图画场景构图”, or “把这张海报转成版面构图” ask for an ordinary editable `composition-draft`. Read [composition-projection.md](composition-projection.md) for interpreting the whole-picture effect, selecting geometry by contribution, writing role explanations, and authoring the draft. First understand how attention, visual weight, rhythm and space work together; then abstract those relationships. A layout photo may contribute several important masses, but identifying its objects or tracing their silhouettes is not the goal. Each description explains what the shape contributes and through which relationship. New node notes and the new draft's overall note stay empty. The Agent inspects the image and authors the draft; Human2AI does not call a vision model. Save through `capture.commands.save`, inspect whether the canvas retains the intended structure and experience without excessive detail, and hand it to the user for editing.
+
+This is full draft authoring. `composition apply` below only refines existing geometry and cannot create the recovered regions. A reference picture does not require a style-library entry or an image node on the canvas.
+
+## Apply a session style to the editable canvas
+
+Use the style workflow in `SKILL.md` and save a complete draft through `style.commands.save`. This supports proportion changes and new accents. The `composition apply` workflow below remains a separate Agent-directed derivative workflow; explicit ratio and geometry-symmetry rules may resize existing areas, while node identity and content remain intact.
+
+Read the current capture and inspect it with `composition inspect --session <session-id> --revision <n> --preview <preview.svg>`. Preserve the user's explicit `processingSemantic`; when it is `null`, ask the user to choose Scene or Editorial before processing. Keep the frame and existing visible text, ids, user notes and approximate placement. In Scene mode interpret areas as subjects and spatial relationships; in Editorial mode interpret them as typography, imagery and negative space. Apply the style through supported sizes, proportions, placement, rotations, weights and optional agent-origin accents. Do not turn the sketch into a literal inventory of bordered boxes.
+
+Coordinates use the signed world coordinate system below, not pixel values copied from the preview. Validate the saved revision and inspect its preview. The browser can copy the current canvas as a PNG and a prompt with one style sentence. For downstream work, use the full bound specification; a guide-bearing preview SVG is not a generation reference.
+
+## Refine a composition
+
+Refinement clarifies the user's composition through deliberate, optional relationships. Mathematical rules are tools, not mandatory templates or evidence of aesthetic quality. Do not select a convenient operation first and invent a reason afterward. Do not bind a style or rewrite the editable capture in response to a refinement request.
+
+1. Discover current methods and the plan schema with `composition methods`. Read the exact saved revision with `capture get`, then run `composition inspect --session <session-id> --revision <n> --preview <source.svg>` and actually inspect the rendered composition. Reuse the user's explicit `processingSemantic`; when it is null, ask for Scene or Editorial. Re-inspect after their choice. Preserve the exact source fingerprint.
+
+2. Read the composition before deciding to change it. Describe the intended viewing experience, relevant masses, scale contrasts, open space, focal relationships and existing motion. Use visible evidence and user notes; do not assume every shape is a subject, every focus has a rank, or every empty space needs filling. Record uncertainty instead of inventing missing intent. `inspect.guidance` provides neutral angle and perpendicular/forward distances from existing shape axes and the direction line to focuses; these measurements do not prove how viewers will look. Distances use output pixels and angles use physical world geometry, including on portrait or moved frames.
+
+3. State the improvement objective, supporting observations and relationships worth preserving. If the current arrangement already expresses its intent or no justified improvement is identifiable, choose `decision: "retain"` and `operations: []`, with a reason. A retain decision is a valid completed refinement; do not move elements merely to show activity. With unresolved intent that materially changes the choice, discuss it before execution.
+
+4. Author a `composition-refinement-plan` with `version: 2`. Include `objective`, `assessment: { intent, observations, uncertainties }`, `preserve`, `tradeoffs`, `rationale`, `fixedIds`, `focusLinks`, `decision` and `operations`. Arrays may be empty. Each selected operation must include `reason` (the observed issue it addresses) and `expectedEffect` (the intended perceptual improvement), in the user's language. Each operation must support the same overall objective. Name concrete ids and measurements; “make it harmonious” is insufficient. Select only necessary rules; zero, one or several may be appropriate.
+
+   - `fixedIds` locks the listed existing nodes completely. User wording and notes remain unchanged by every operation; the original frame, node identities, shapes and images are preserved. Put other preservation intentions in `preserve`; the Agent must review those visually.
+   - `focusLinks: [{ focusId, areaId }]` explicitly associates a focus with a subject. A focus can belong to one area. Moving, resizing or rotating the area carries its focus at its normalized local position; moving a linked focus translates the area. Multiple focuses may belong to one area. Do not infer associations merely from proximity. If linkage would contradict the user's intent, leave it absent.
+   - Operations compute geometry, not final illustration outlines. Size changes require an explicit `size-ratio` or geometric `mirror-symmetry`; direction-line rotation requires `focus-flow`. Do not add visible guide marks to the user's content.
+
+5. Explain the concrete plan and obtain user consent in the conversation unless their existing request already authorizes it. The Agent owns that conversation; Human2AI has no separate approval state or confirmation API. Apply using:
+
+   ```text
+   <runner> composition apply --session <session-id> --revision <n> --plan <plan.json> --output <run.json> --preview <refined.svg>
+   ```
+
+   Execute dependent operations in a deliberate order: establish proportions and subject placement, propagate subject/focus associations, then arrange guidance as applicable. The engine remeasures **every chosen relationship on the final draft**. A later operation cannot silently invalidate an earlier one. `audit.relations` reports before/after/target/error and technical satisfaction; incompatible relations or changed `fixedIds` produce `REFINEMENT_CONSTRAINT` with the affected operation indices. Revise the plan, order, or explicitly conflicting intention; do not repeat a failing plan or overwrite the source to make it fit. This is exact relation validation, not a general constraint optimizer.
+
+6. Require `result.audit.passed` and read every final relation check. Then inspect the final image at the same framing as the source. Does the chosen rule actually strengthen the intended attention, balance, space or flow? Has it harmed a more important relationship or made an incidental mark too prominent? Has changed clipping undermined the subject? Technical satisfaction alone does not answer these questions. Revise the independent result when needed and report the observed outcome and tradeoffs; never claim that the numeric audit proves beauty. A `null` before-value means that relationship was undefined on the source (such as a directional axis before a round mass is elongated).
+
+7. Open or provide `ui.editUrl`. The independent result appears in **Refined / 精修**, with objective, evidence, preservation intentions, tradeoffs and relation measurements. Mathematical rule guides are not rendered and have no display toggle. The canvas shows the authored composition elements; relation measurements remain in the result explanation. Guide coordinates in audit data are not artwork or generation-reference content. Original captures are not modified or appended by refinement. New user edits make an older result stale. If the source revision changes while working, reconnect and reconcile the new intent before presenting the result as current.
+
+### Available relationships
+
+Use `composition methods` as the callable contract. Current v2 relationships include the existing focus anchoring, axis relation, rotation alignment and editorial alignment/spacing operations, plus:
+
+| Method | Explicit choice and result |
+| --- | --- |
+| `frame-placement` | Select `targetId` (area or focus), `axis: x/y`, `alignment: start/center/end`, and `division`. Places the selected center or rotated bounding edge on that frame division. A focus uses its point. |
+| `size-ratio` | Select `targetAreaId`, `dimension: width/height/area`, `referenceId` (area or `frame`), `referenceDimension`, and a positive `ratio`. Lengths compare physical unrotated dimensions; areas compare areas. Width/height changes retain the other dimension; an area change scales both dimensions uniformly. Using the same area with width versus height expresses an aspect ratio. |
+| `mirror-symmetry` | Select `anchorAreaId`, `targetAreaId`, `axis: vertical/horizontal`, `division`, and `match: position/geometry`. The anchor stays in place; the target is reflected. Full geometry additionally matches size and reflected orientation and requires the same primitive. Different shapes may have positional symmetry. |
+| `focus-flow` | Select an existing `sourceId` (area or `direction-1`), `targetFocusId`, and `localAxis: x/y`. Rotate that existing axis toward the focus, retaining its pivot. The direction line uses x; an undirected circle or a focus coincident with the pivot has no meaningful aiming direction. |
+
+`division` accepts `center`, `golden-start`, `golden-end`, `third-start`, `third-end`: respectively 0.5, approximately 0.382, 0.618, 1/3 and 2/3 within the frame. These are optional named choices. A golden ratio is `(1 + sqrt(5)) / 2`, approximately 1.618; always state which measurements it relates. Do not mix area and length dimensions.
+
+Rules need not all be used, and none is compulsory. Mathematics can describe focus placement, symmetry, ratio and guidance, but cannot choose which fits the user's image. Sequentially applying contradictory exact rules does not constitute a coherent plan.
+
+### Compatibility and generation reference
+
+Version 1 plans and stored results remain readable and executable for compatibility. New Agent work uses version 2 so it records intent and validates final relationships. The legacy `strength: "subtle"` is optional and imposes no amplitude limit. Source fingerprint, mode, valid geometry and protected content are still checked. Displacement, rotation, clipping, overlap and visual-center changes are observations, not aesthetic rejection thresholds.
+
+When downstream image generation is authorized, export the saved run through `composition reference --session <session-id> --run <run-id> --output <reference.png>`. Attach the returned image path as a soft spatial map, not line art, and carry the mode-specific interpretation and required typography into the generation instruction. The CLI preview SVG includes guides and outside content and must not replace that PNG.
+
+## Canvas stacking order
+
+Preserve the optional draft-level `layerOrder` array when editing captures. It lists content node ids from back to front, independently of array numbering, geometry, visual weight or scene depth. Without it, the existing type-based draw order applies. Keep ids unique; remove deleted ids and append new ids after the saved order. Browser layer actions preserve selected nodes’ relative order. UI groups move together in this order, which is shared across motion states. Frame boundaries, guides and selection controls are outside the content order. Preview and SVG/PNG output follow this order.
+
+Composition captures may include `states` and `activeStateId`. Preserve both when editing. All states share the top-level node identities, content and metadata; only frame geometry, node geometry and layer order vary. Top-level geometry is the active state's editable layout and is synchronized to its snapshot when validated or saved. Edit the top-level geometry to change the active layout; preserve other state layouts. State snapshots contain no independent node content. Older captures without these fields represent one state. Browser copy actions use the active layout; states do not imply animation.

package/skills/human2ai/references/spatial.md

@@ -0,0 +1,188 @@
+# Authoring 3D spaces
+
+A `spatial` session owns an editable scene, independent of composition and UI sessions. Characters, simple objects, and multiple named output cameras share that scene. The browser's orbit view is temporary; moving a character never reframes an output camera.
+
+## Connect, inspect, edit, review
+
+Use the runner and API origin discovered by the parent skill. Start with `session connect --session <id>` and `capture list --session <id>`. A new space has revision 0 and a default `camera-1`. For an existing revision:
+
+```text
+<runner> spatial methods
+<runner> spatial inspect --session <id> --revision <n> --output inspection.json
+<runner> spatial apply --session <id> --revision <n> --input operations.json --output saved.json
+<runner> spatial render --session <id> --revision <saved-revision> --camera <camera-id> --output camera.png
+```
+
+`methods` returns the complete draft schema and closed operation schema. `inspect` includes the draft and each joint's world position and each bone's upstream pivot and world rotation. `apply` expects a JSON **array** of operations and the latest revision; revision 0 is accepted for a new space. All operations form one atomic change. Initial authoring also creates an empty baseline so it can be undone. Use the returned revision, not `n + 1`. `capture undo` restores a prior document as a new revision. A 409 means reread the latest state and reconcile the user's intervening edits; never silently overwrite it.
+
+After completing an Agent task, open the rendered PNG with an available image viewer. Check silhouette, occlusion, framing, and the requested side/front/high/low angle. Numerical inspection alone is insufficient. Report any unsatisfied constraint. Render each requested output camera; do not present the temporary edit view as the result.
+
+## Camera references for image generation
+
+`spatial render` accepts `--pass color|structure|depth|skeleton`; omission keeps the ordinary color PNG. `spatial methods` exposes `renderPasses`. Export all references using the **same revision and camera**:
+
+```text
+<runner> spatial render --session <id> --revision <n> --camera <camera-id> --pass color --output camera.png
+<runner> spatial render --session <id> --revision <n> --camera <camera-id> --pass structure --output structure.png
+<runner> spatial render --session <id> --revision <n> --camera <camera-id> --pass depth --output depth.png
+<runner> spatial render --session <id> --revision <n> --camera <camera-id> --pass skeleton --output skeleton.png
+```
+
+The HTTP camera PNG route accepts the same optional `pass` query alongside `revision`. Rendering is read-only. Color, structure and depth share dimensions, projection, framing and surface visibility. Color keeps the camera's background/transparency and includes subtle skin-colored finger joint creases, also visible on the editor model. These creases follow the posed skin and scene occlusion; they do not intercept body-part selection. Structure is dark visible contours and surface-following palm-side finger joint arcs on white; it excludes editor rig overlays, hidden finger lines and skin-module boundaries. The lowest crease next to the palm is omitted on every digit: fingers retain the PIP/DIP lines and the thumb retains only its IP line. Depth is an opaque grayscale reference for **all visible characters and objects**: near is white, far is dark, no surface is black. Values 1–255 map one shared linear camera-space range across visible surfaces; a flat-depth scene is white, an empty scene is black. It is a relative 8-bit guidance image, not a metric depth file; a very deep scene can compress small finger depth differences. Do not normalize different objects separately or draw joint lines onto the depth map.
+
+Skeleton projects the character's actual posed bone segments, joint markers and head outline, including fingers and added limbs, through the same camera and clipping planes. Anatomical left is blue, right is orange, and central parts are neutral. It uses a pale opaque background and omits skin, solid scene objects and lighting. Bones remain visible through surfaces: this schematic is not evidence of surface occlusion or a depth map. Use the canonical `--pass skeleton` renderer instead of drawing a separate approximate rig. All four passes keep the same dimensions, projection and framing; only color, structure and depth share surface visibility.
+
+In the workspace, use the camera or observation-box preview's four-option reference selector and PNG download. The chosen representation is transient, and pending/failed saves do not offer a stale camera download. Composition live-camera nodes continue to use color. No generation model or ControlNet pipeline is installed by this export feature.
+
+When preparing an image-generation prompt, identify each input by role: color communicates the overall action and camera composition, structure helps interpret joints and occlusion, depth helps interpret relative distances and foreshortening, and skeleton communicates joint placement and articulation independently of the model's surface. These are **intent references**. The mannequin's face, body shape, skin, muscles and material are not appearance requirements; use the user's requested subject and style, or design an appropriate appearance when those are left open. Skeleton colors, circles and head outlines are also guides and must not appear on the generated subject.
+
+**Explicitly explain the guide markings in every prompt using spatial references.** Lines across fingers indicate joint locations and finger segments. Lines, seams, segmented shapes and simplified forms around feet, chest, waist and other body parts likewise indicate anatomy and placement. They are not markings to reproduce on the final subject. Do not transfer black joint lines, painted bands, segmentation seams, mannequin surfaces or depth-map tones into the generated image. Reconstruct continuous, natural anatomy, skin and clothing appropriate to the requested style; normal skin folds and clothing seams should arise naturally rather than trace the reference guides. Apply this interpretation even when using only the ordinary color reference.
+
+Describe the **approximate action**, the important gesture or contact relationships, and the broad camera direction and framing. Users may leave inaccurate joint angles, proportions, balance or finger overlap while posing. Allow the generator to correct those inaccuracies into a plausible, comfortable or dynamically balanced action while keeping the intended gesture recognizable. Preserve meaningful contacts and front/back relationships, adjusting incidental overlap when needed for coherent anatomy. Avoid instructions to match exact screen coordinates, joint angles, every contour or the entire silhouette, and avoid prioritizing pose fidelity over natural anatomy. Require stricter matching only when the user explicitly asks for that specific relationship or detail. These corrections belong to the generated image; they do not authorize edits to the saved spatial pose or camera.
+
+Review the result for a recognizable action, broadly consistent viewpoint, plausible joints, balance and contact, coherent fingers and clean body surfaces. Correct visible guide-line artifacts, fused digits or implausible articulation; accept small pose and framing differences that improve naturalness instead of forcing a pixel-perfect match.
+
+## Six-view camera boxes
+
+For ambiguous finger overlap, keep the ordinary camera as the **main composition reference** and add an observation box as auxiliary pose evidence. A box is a saved cubic crop, with six orthographic cameras on its faces looking **inward**. It is not an outward environment cubemap. The same saved scene revision drives every view. The box clips all geometry outside its six planes, including foreground occluders; any geometry still inside the volume remains visible. Cut surfaces at the crop boundary are reference artifacts, not anatomical endpoints.
+
+Create a box and fit it in one `spatial apply` batch:
+
+```json
+[
+  { "type": "put-camera-box", "box": {
+    "id": "hands-reference", "name": "Hand reference",
+    "position": [0, 1.2, 0], "rotation": [0, 0, 0],
+    "size": 0.4, "resolution": 512
+  } },
+  { "type": "fit-camera-box", "id": "hands-reference", "region": "hands" }
+]
+```
+
+`put-camera-box` creates/replaces the full box without changing anatomy or the ordinary cameras. `fit-camera-box.region` accepts `scene` (all posed character meshes and solid objects) or `hands` (all palms/fingers, including custom limbs, plus framing margin). Fit retains box rotation; an empty target leaves the box unchanged. Fit is an explicit action, not a tracking constraint. Preserve other fields when adjusting position, XYZ rotation in degrees, or edge length. Rotate slightly and inspect again if important fingers align in several faces. `remove` deletes the box. `draft.cameraBoxes` may be omitted, has at most 24 entries, and shares scene-wide unique IDs. Edge length is 0.05–1000 metres; each square tile is 128–1024 integer pixels. The box does not count toward the requirement to retain one ordinary camera.
+
+```text
+<runner> spatial render --session <id> --revision <n> --box hands-reference --output hands-sheet.png
+<runner> spatial render --session <id> --revision <n> --box hands-reference --view top --pass structure --output hands-top.png
+<runner> spatial render --session <id> --revision <n> --box hands-reference --view sheet --pass depth --output hands-depth.png
+```
+
+`--camera` and `--box` are mutually exclusive. `--view` requires `--box` and accepts `sheet` (default), `front`, `back`, `left`, `right`, `top`, `bottom`. Export individual PNGs by running the command for each face. The sheet is 3×2: front/back/left, then right/top/bottom. Each tile has a 28 px English direction/axis label above it, with 12 px dividers between tiles so cropped limbs do not appear connected across views. Directions refer to the **box-local axes**, not the character's anatomical left/right: front +Z, back −Z, left −X, right +X, top +Y, bottom −Y. In the top image, local −Z points up; in the bottom image, local +Z points up. All faces use the same metric scale. Color preserves transparency; structure/depth use their usual white/black backgrounds, and skeleton uses its pale opaque background with bones visible through surfaces. All four passes support both sheets and individual faces. Box depth maps 0 to `size` metres from each face using a fixed shared linear range, unlike ordinary cameras' visible-surface normalization.
+
+The HTTP route is `GET /api/v1/sessions/:sessionId/spatial/camera-boxes/:boxId.png?revision=<n>&view=sheet&pass=color`. Render is read-only and revision-addressed; box edits are saved and undoable through the existing draft history. `session connect` discovers `spatial.render-box@1`; `spatial methods` exposes the closed operation schemas, `cameraBoxViews`, and `cameraBoxGuidance` (canonical wording: `spatial.cameraBoxGenerationGuidance` in both locale resources).
+
+When generating, export the main camera and auxiliary boxes from the **same revision**. Include the returned `cameraBoxGuidance` in the prompt: the main camera determines composition; the sheet shows the same subjects at one moment from six directions, solely to resolve occlusion, digit ownership and approximate flexion. Request one final image, with no contact-sheet layout, duplicate subjects, direction labels, or joint/body markings. Preserve gesture intent while allowing natural anatomical corrections. Inspect the six views yourself before generation; start with the main camera plus one hand sheet, adding full-space depth or an informative full-resolution face when useful. More views do not guarantee correct fingers, and cannot repair an impossible underlying pose automatically.
+
+## Character model styles
+
+`appearance` is a saved per-character style: `quaternius` (the existing anatomical surface, the default) or `geometric` (a procedural mannequin). To add the new style, include `"appearance": "geometric"` in `add-character`. To switch an existing actor, inspect it and submit `put-character` with its full existing fields and only `appearance` changed. This keeps its joint positions, bone angles, limits, position/rotation pins, proportions, body type and extra limbs exactly intact. The change is saved and undoable; `set-proportions`, hand posing and pose reset retain the selected style. Do not replace the rig to change its rendering style.
+
+Geometric mannequins have blue-gray spherical joints, cylinders connecting joint centers, rigid box palms and feet, and ellipsoid heads with only two dark eyes. Body surfaces follow the actor color. Geometric fingers use stable identity colors: thumb orange, index blue, middle green, ring purple, little pink; both hands and cloned hands share this mapping. Finger joint balls use a lighter shade of the same color, and editor selection brightens the existing hue. These colors remain pose guides rather than requested skin or clothing colors. The terminal head-top and toe landmarks belong inside their solid forms rather than separate hinge balls; fingertips remain rounded. Every articulated finger segment follows the same anatomical axes and limits as the human model. Joint spheres select positional controls, while cylinders, palms, feet and heads select bone rotation. The mannequin itself provides selectable geometry, so the editor does not duplicate its visible rig with an extra helper overlay.
+
+Body type still selects the existing male/female anatomical rig dimensions. Head count and the torso/leg split control the same joint positions; neck length moves the head, palm size and finger length remain independent, and foot size grows the box with the shared mild ankle lift. Cloned arms, hands and heads render from their actual bone hierarchy. No downloaded mesh or skin deformation is used for this style. All camera and observation-box passes use the same scene geometry; skeleton remains a separate schematic PNG pass. For image generation, describe the balls, cylinders, blocks, eye dots and their colors as pose/anatomy guides, not a requested robot or toy appearance unless the user explicitly wants one.
+
+## Skeleton and constraint semantics
+
+Coordinates use a right-handed world: X right, Y up, Z toward the default character's front. Units are metres. Rotations are XYZ Euler **degrees**. Draft version 2 has separate `joints` and `bones`. A joint has a parent-relative rest `offset`, a positional lock, and no rotation control. Each non-root joint has exactly one incoming bone whose `startJointId` is its parent and whose `endJointId` is itself. The bone rotates **before** its endpoint offset is translated: its pivot is the upstream joint. `move-joint.position` is a **world** target; `rotate-bone.rotation` is **local** to the upstream joint frame. Inspect before editing rather than guessing IDs.
+
+`lock-joint.position` pins a world point. `lock-bone.rotation` pins a world orientation while allowing the segment to move. Other controls preserve both types of pin; lengths are fixed during posing. The bounded numerical solver reports `constrained: true` for an unreachable target, returning the best feasible pose it found or the original pose, without a global-optimum guarantee. Never stretch or silently unlock to bypass it.
+
+Every bone has independent `limits.min` and `limits.max` XYZ arrays. Use `set-bone-limits` explicitly to configure these; the bounds must contain both the current rotation and `restRotation`. Pose edits cannot alter standard topology or bone lengths. Standard ranges are provisional anatomical controls, not a biomechanical simulation. Hands rotate at wrists; feet rotate at ankles. For example, `left-elbow` is the upper-arm bone, `left-wrist` the forearm bone, `left-hand` the hand bone; positional wrist selection is joint `left-wrist`.
+
+`reset-pose` restores all stored `restRotation` values and clears that character's joint-position and bone-rotation locks. It preserves its world placement, proportions, appearance, and added limbs/heads, and creates one undoable change. Basic pose presets remain deferred.
+
+The left/right clavicle and hip **connectors** (`modelPart` = `left-shoulder`, `right-shoulder`, `left-hip`, `right-hip`, including copies) have no local rotation on any axis. New characters initialize them with zero angles and zero bounds. Existing authored connector angles and historical bounds remain readable without changing the pose, but cannot be edited: `rotate-bone` returns the unchanged pose with `constrained: true` when a change is requested, IK keeps their local angles, and changed bounds or a pose replacement through operations fail with `SPATIAL_CONSTRAINT` (422). A direct draft save uses the shared invalid-record response (400). `reset-pose` explicitly restores their default angles; undo can restore the prior pose. These connectors still follow their parent in world space; a separate world-rotation pin also constrains parent motion. Pose arms through the upper-arm bones (`left/right-elbow`) and legs through the thigh bones (`left/right-knee`).
+
+`add-character` accepts optional `height` (0.2–20) and `headRatio` (2–12). Use `set-proportions` to change these; fixed points may prevent rescaling. Head count is continuous, including 2.5, 3.5 and 2.7; the UI steps by 0.5 and accepts one decimal. The head reference length is computed directly as height / headRatio. Two- and three-head bodies have distinct matching-topology face/torso contour targets. Their vertex positions and rig dimensions blend continuously through the 2, 3, 4 and 7 references: low counts round the head, shorten the neck, soften anatomical relief and coordinate shoulders, torso, limbs, hands and feet independently. Head depth and torso depth also vary independently of front width to balance the side silhouette. Low-count rest-spine offsets follow longitudinal body scale independently of skin thickness, preventing an exaggerated forward waist bend; this rest-shape correction happens before authored bone rotations. The authored torso/leg split and bone rotations remain intact. Seven and above retain the original adult shape and elongated width curve. Stored joint offsets describe the anatomical base; use `inspect` world transforms for the resulting joint positions and bone lengths. The UI torso/leg slider uses 2-percentage-point steps; the API retains continuous values within its range. Both operations accept optional `bodyType` (`male` or `female`): new/unspecified bodies use the male source; omission in `set-proportions` preserves the current body. Switching updates the source mesh and anatomical dimensions, retaining the pose, locks and custom limbs; positional pin conflicts reject the batch. Use this operation rather than changing only the field on a standard humanoid. Both operations also accept optional `torsoRatio` (0.3–0.7), the torso share of rest height excluding the head; legs receive `1 - torsoRatio`. A smaller value makes longer legs. Omission on an existing character preserves its ratio; an omitted character field uses the model default. Changing this split keeps height, head size, arm/hand/foot lengths and bone rotations, redistributing torso and thigh/calf lengths. Use the same operation with the default ratio reported by a newly created standard character to restore proportions; `reset-pose` only resets pose and locks. Conflicting positional pins reject the edit; never unlock them silently. New characters default to `appearance: "quaternius"`; the optional `geometric` style uses the same rig with generated primitives. Use `put-character` preserving the other fields to change body color. The male and female Quaternius CC0 Superhero meshes are bundled locally with their own rig landmarks, retargeted and skinned identically in the editor and camera output. The editor-only joint/bone overlay is absent from color, structure and depth PNGs; the skeleton pass explicitly projects the rig without editor handles. Plain color is used; textures are not supported. Each hand includes the source five-finger skin weights and articulation. Cloned modules have overlapping attachment seams rather than a watertight mesh union.
+
+Only version-2 scenes using `appearance: "quaternius"` are accepted. The retired character renderer and version-1 conversion have been removed; old appearance or version values fail validation.
+
+```json
+[
+  { "type": "lock-joint", "characterId": "person", "jointId": "right-ankle", "position": true },
+  { "type": "lock-bone", "characterId": "person", "boneId": "left-hand", "rotation": true },
+  { "type": "move-joint", "characterId": "person", "jointId": "left-wrist", "position": [0.6, 1.3, 0.3] },
+  { "type": "rotate-bone", "characterId": "person", "boneId": "left-elbow", "rotation": [-30, 0, -40] }
+]
+```
+
+## Create four arms
+
+For a new space, save this batch. `add-limb` copies a subtree, attaches its root using a local offset, copies the corresponding bone and mesh modules, assigns prefixed joint and bone IDs, and changes the character to `custom`. Existing joints and locks are preserved; new joints and bones start unlocked.
+
+```json
+[
+  { "type": "add-character", "id": "creature", "name": "Four-arm creature", "height": 1.8, "headRatio": 7 },
+  { "type": "add-limb", "characterId": "creature", "sourceJointId": "left-shoulder", "parentId": "chest", "idPrefix": "lower-left", "offset": [0.22, -0.2, 0] },
+  { "type": "add-limb", "characterId": "creature", "sourceJointId": "right-shoulder", "parentId": "chest", "idPrefix": "lower-right", "offset": [-0.22, -0.2, 0] }
+]
+```
+
+For a second head, copy the `neck` subtree and attach it to `chest`, for example `{"type":"add-limb","characterId":"creature","sourceJointId":"neck","parentId":"chest","idPrefix":"second","offset":[0.22,0.23,0]}`. The new head's bone is `second-head`. `modelPart` identifies the original mesh module and is preserved on copies. Reposition/rotate the two neck branches as needed to separate the silhouettes.
+
+For a fully different morphology use `put-character` with the complete character shape returned by `spatial methods`. A custom rig requires unique joint IDs, exactly one root, an acyclic connected hierarchy, nonzero child offsets, and valid angle limits. Keep existing IDs stable when extending a character. Standard humanoid anatomy cannot be arbitrarily rewritten while retaining `kind: "humanoid"`.
+
+## Cameras and objects
+
+Scene-wide `lightingEnabled` defaults to `false`, including drafts where it is omitted. Use `[{ "type": "set-lighting", "enabled": true }]` through `spatial apply` to enable directional lighting and cast shadows, or `false` for evenly lit modeling. Both modes retain nearby contact shading and finger creases. The setting is saved and undoable, applies to every camera's ordinary PNG and composition reference, and does not change structure/depth passes or authored poses. It is not an ambient-light-only switch. `inspect` includes the saved field in `draft`.
+
+`put-camera` creates or replaces a named camera. Preserve the other fields when changing one property. Perspective supports foreshortening; orthographic removes perspective scale changes. Position relative to target determines front/side, slight side, low angle, or high angle. Camera changes never mutate character poses.
+
+```json
+[
+  { "type": "put-camera", "camera": {
+    "id": "side", "name": "Side view", "position": [4, 1.1, 0], "target": [0, 0.9, 0],
+    "projection": "perspective", "fov": 40, "span": 3.2,
+    "width": 1200, "height": 900, "background": null
+  } },
+  { "type": "put-object", "object": {
+    "id": "seat", "name": "Seat", "kind": "box", "position": [0, 0.25, -0.3],
+    "rotation": [0, 0, 0], "size": [0.6, 0.5, 0.6], "color": "#b6a58c"
+  } }
+]
+```
+
+Objects support `box`, `sphere`, and `plane`. PNG dimensions are 128–2048 per axis; `background: null` preserves transparency. At least one camera must remain. Limits are 24 characters, 200 joints per character (including terminal points), 100 objects, 24 cameras, and 100 operations per batch.
+
+## Composition camera references and PNG snapshots
+
+The composition editor can insert several camera references from the same or different spaces. An image node's optional `cameraReference` stores `{ sessionId, cameraId, renderedRevision }`; its `assetId` points to the immutable PNG materialized in the **composition session's** image store. The open editor follows saved source revisions automatically while preserving node placement and width. An explicit camera aspect change adjusts node height to show the complete frame; ordinary pose edits retain both dimensions. A missing/deleted source displays a warning and retains its last PNG.
+
+“Save as image node” retains the live reference and adds a separate image node without `cameraReference`. Both may share the immutable image asset at capture time; future live updates replace only the reference's asset. The snapshot survives source edits and deletion.
+
+An Agent can construct the same nodes through the existing image upload and capture APIs: render the chosen source revision, upload that PNG to the target composition session, read the image-node schema from `capture schema`, add the node with its source pointer and returned asset ID, then save using the latest target revision. Never put a spatial-session asset ID into a composition node. For a static snapshot omit `cameraReference`. Session-based composition previews and reference exports embed the saved image assets, preserving the inspected document revision.
+
+## Body dimensions shared by both sides
+
+`add-character` and `set-proportions` accept four optional, actor-wide factors:
+
+| Field | Range | Effect |
+| --- | --- | --- |
+| `neckLength` | 0.6–1.4 | Moves the head along the posed neck, retaining torso/shoulder and head dimensions. `height` is the base stature; no torso compensation keeps the actual top of the head fixed. |
+| `palmSize` | 0.7–1.3 | Palm dimensions, finger-root spacing and finger thickness. Does not change digit bone lengths. |
+| `fingerLength` | 0.6–1.4 | Axial length of all five digits, independently of palm size. |
+| `footSize` | 0.7–1.4 | Foot width/length scale fully; thickness follows half the percentage change. Ankles rise/fall gently while knees/body stay in place and standing soles remain near their original level. This is a relative size, not a physical shoe number. |
+
+`1` means the current head-count profile's default. Missing character fields behave as `1`; omission in `set-proportions` preserves the existing factor. UI sliders step by 2 percentage points; API values remain continuous inside the bounds. Both sides and cloned hands/feet share these fields, with no left/right overrides. Bone rotations, character placement and locks are retained. Conflicts with fixed world positions reject the entire batch, including complete-document saves. Later height/head/body-type edits and pose resets preserve these factors; use `1` to restore an individual dimension. Editor geometry, `inspect` transforms and PNG output use the same deformation rules.
+
+```json
+[{ "type": "set-proportions", "characterId": "person", "height": 1.8, "headRatio": 3,
+   "neckLength": 1.2, "palmSize": 0.9, "fingerLength": 1.1, "footSize": 1.2 }]
+```
+
+## Hand and finger posing
+
+Standard characters include `left-hand` and `right-hand` palm bones, rotating about their wrist. Every digit (`thumb`, `index`, `middle`, `ring`, `little`) has four joint IDs, for example `left-index-0` (fixed palm attachment/root), `left-index-1` (middle joint), `left-index-2` (distal joint) and `left-index-3` (tip). Incoming bone `-0` is a fixed attachment, not an editable phalanx. Bones `-1`, `-2`, `-3` rotate at their upstream joint. Thumb `-1` is its metacarpal; `-2` and `-3` are its two phalanges. Tips have no outgoing bone. Cloned hands retain these model roles under their cloned IDs; inspect IDs first.
+
+Finger `rotate-bone.rotation` uses anatomical XYZ Euler degrees: X is flexion; Z is limited spread at the first segment; only the thumb base also allows Y opposition/twist. These axes are expressed through the source hand frame, unlike the body's parent-rest XYZ axes. The viewport gizmo uses the same frame. The thumb is the exception: distal bone `thumb-3` flexes on blue local Z (left −90–0°, right 0–90°), while proximal `thumb-2` retains X flexion and allows Z ±45°. The metacarpal `thumb-1` is unchanged. Other fingers’ middle/distal segments keep Y/Z fixed at zero. Saved default thumb bounds are corrected once (`thumbLimitsVersion: 2`) without moving poses or releasing pins; explicitly customized limits are retained. An existing distal X pose keeps enough X range to return to rest; new distal thumbs have X fixed at zero. Limits remain explicitly configurable through `set-bone-limits`. `move-joint` still accepts world coordinates; finger IK is restricted to that digit and reports a constraint rather than moving the wrist/arm to reach a distant target.
+
+Use `pose-hand` for linked controls (all amounts 0–1). Omitted fields preserve their existing angles. `curl` accepts any subset of the five digit names; it drives each selected digit’s three flexion angles. Thumb distal curl writes mirrored Z and clears its old X curl; proximal manual Z is retained. `spread` opens the four non-thumb digits with mirrored left/right directions. `thumbOpposition` coordinates the thumb base’s Y/Z angles toward the palm. Manual per-bone rotation remains available afterward. Both position and world-rotation pins are hard constraints; a conflict rejects the batch without changing saved state.
+
+```json
+[
+  { "type": "pose-hand", "characterId": "person", "handBoneId": "left-hand", "curl": { "thumb": 0.6, "middle": 0.8, "ring": 0.8, "little": 0.8 }, "thumbOpposition": 0.6 },
+  { "type": "pose-hand", "characterId": "person", "handBoneId": "right-hand", "spread": 0.8 }
+]
+```
+
+`reset-hand` takes `characterId` and `handBoneId`; it clears the selected palm/finger locks and restores their default rotations, retaining the arm, character placement, other hand and proportions. `reset-pose` still resets the whole actor, now including fingers. Both are undoable through the shared capture history. `add-limb` on a palm or upstream arm copies all its finger joints, bones and weights. Stored current-v2 Quaternius hands without finger chains are completed in memory when validated, retaining their body pose; a positional lock on the former hand-tip control transfers to the middle fingertip at the same world position. Saved versions are not rewritten. No retired v1/skeleton appearance is accepted; `geometric` uses the current v2 rig.

package/skills/human2ai/references/svg-images.md

@@ -0,0 +1,27 @@
+# SVG image nodes
+
+SVG is an image format inside a composition or UI-layout session. Use the existing `images` nodes and `assetId`; there is no separate SVG session, node schema, or library. Users can upload an SVG file, paste its code, and copy its complete source directly from the image-content panel.
+
+Read the latest capture and its session-specific image-node schema before creating or replacing content. For an existing SVG, use the command returned in `images.commands.source`:
+
+```text
+<runner> image source --session <session-id> --asset <asset-id> [--output <image.svg>]
+```
+
+Without `--output`, the result includes the complete `source` text. Preserve the user's existing shape and styling choices when making a local change.
+
+Author a complete UTF-8 SVG document with `xmlns="http://www.w3.org/2000/svg"` and a usable `viewBox` or explicit dimensions. Use basic shapes, arcs, and Bézier paths; calculate repeated or symmetric geometry with code when useful. Match the current request and applicable session style. Give important parts stable ids when that helps later language-directed edits. Render and inspect the result at its intended size, including in the surrounding composition or interface.
+
+Use a transparent background by default. Do not add a canvas-sized background shape or a background color unless the user asks for one. Shapes may still have their own fills and strokes; use `fill="none"` for unfilled outlines. The composition or interface canvas background is not part of the SVG source. Preserve an uploaded SVG's existing background unless the user requests a change.
+
+Images must be static and self-contained. Shapes, text, local gradients, clipping, masks, filters, and internal `#id` references are supported. Use presentation attributes or simple inline CSS with local `url(#id)` references. Scripts, event handlers, animation, HTML `foreignObject`, DTDs, processing instructions, CSS imports/escapes, and external resources are not accepted. Embedded PNG/JPEG/WebP data images are allowed. Keep source within 10 MiB; the service validates content without rewriting it. Style-reference uploads retain their bitmap-only contract.
+
+Upload through `images.commands.upload`:
+
+```text
+<runner> image upload --session <session-id> --input <image.svg>
+```
+
+The response includes the new asset `id`, MIME type, and original dimensions. Uploading alone does not change the canvas. Bind the returned id to the intended image node's `assetId`, reset `crop` to `null` for replacement, and save the complete capture with its expected latest revision. Preserve the node's id, origin, user note, placement, and other fields unless the requested change requires adjusting them. New Agent-created nodes use `origin: "agent"`; follow the owning draft's coordinate system and stage rules.
+
+Every upload creates a new file. Replacing an image changes the node's asset reference; existing capture history continues to reference the previous file, so capture undo also restores the previous SVG source. Handle revision conflicts through the existing reconnect/read/reconcile workflow.

package/skills/human2ai/references/ui-layout.md

@@ -0,0 +1,100 @@
+# UI layout sessions
+
+Use `ui-layout-draft` for a `ui-layout` session. Use the unified Capture CLI for reading and saving revisions, `ui-layout.render@1` for preview export, and `ui-layout.standardize@1` for geometry standardization. Discover these operations through `session connect`; do not run `composition` commands.
+
+## Export and inspect a saved state
+
+After editing, use the saved revision and inspect the resulting local preview without Chrome MCP:
+
+```text
+<runner> ui-layout render --session <session-id> --revision <saved-revision> --state <state-id> --output <preview.png>
+```
+
+Use a `.svg` output filename for a self-contained vector preview. Both formats embed the selected state's image assets, preserve crop and layer order, omit hidden nodes, and clip to the interface frame. They contain the abstract regions, notes, text and images rather than editor controls or a fully styled consumer UI. The command is read-only and returns `artifact.path`, MIME type, dimensions, the exact revision/fingerprint and the selected state metadata.
+
+Read state ids, names and order from the capture's `stateTabs`; older captures use `start` followed by `stages[].id`. Pass the stable id to `--state`, not the display name. If omitted, the first state in display order is exported, including when `start` has been deleted. Export each state relevant to the task separately. Unknown or deleted state ids fail instead of falling back to another state. Open the PNG with the available local image viewer to check placement, text, visibility and clipping; opening the Human2AI page is unnecessary for this check.
+
+## Capture user-perceived layout intent
+
+A UI layout draft is a flat spatial sketch of what users can see, read, recognize, or interact with. It is not a DOM tree, component tree, CSS layout model, or inventory of framework components.
+
+- Include only the key elements needed to communicate the interface's task, visual hierarchy, and spatial relationships: visible text, images, controls, content footprints, and independently perceptible regions or surfaces.
+- Omit implementation-only wrappers, layout grids, stacks, spacing boxes, providers, and parent rectangles that merely repeat the bounds of their visible children.
+- Treat a rectangle as an approximate content footprint or perceptible visual surface, not as an instruction to render a border, card, or container. Express hierarchy through relative position, scale, visual weight, typography, whitespace, and overlap instead of drawing every implementation layer.
+- Include a parent region and its children only when each communicates distinct user-perceived meaning. A boundary, background, elevation, clipping, scrolling behavior, or interaction can make the parent independently perceptible; code ownership or nesting alone cannot.
+- Put non-visual grouping and implementation constraints in `overallNote`, node notes, or annotations instead of creating another rectangle. Prefer the smallest set of elements that preserves the user's intended experience.
+
+Use `groups` for persistent selection and movement relationships. A group has a stable `id` and `itemIds` containing at least two existing rectangle, text or image ids, for example `{"id":"group-save-button","itemIds":["save-surface","save-label"]}`. Each node belongs to at most one group; groups cannot contain groups and their ids must not collide with node ids. Group membership is shared across motion stages while geometry stays stage-specific. Old captures without `groups` load as an empty array.
+
+When projecting a visible control made from several nodes, group its surface, static label and any icon so the user can move the control immediately. Keep the static text individually editable. Group only elements that should move as one visible unit; do not group all descendants merely because they share a code component. Groups add no visible surface and prescribe no implementation wrapper. The browser creates and dissolves groups through the canvas context menu. Preserve group ids and membership through subsequent edits; when removing nodes, remove their memberships and dissolve groups with fewer than two members.
+
+For example, an implementation tree such as `AppShell > Main > Card > Stack > Button` normally becomes the key visible content and button. Include the card only when its surface is perceptible and important to the layout; omit `AppShell`, `Main`, and `Stack` when they only arrange descendants.
+
+The interface frame defines the intended output area, not a movement boundary. Nodes may remain anywhere on the infinite canvas, including entirely outside the frame. Preserve parked nodes and their visibility flags in captures. A copied static prompt includes only visible nodes whose bounds overlap the frame; a copied motion prompt includes nodes with visible overlap in either the initial or final state and preserves their entering or exiting geometry. Partially overlapping nodes keep their full geometry. Nodes that only touch a frame edge without occupying any area inside are outside for prompt export.
+
+## Apply the bound style
+
+Use the shared style-processing workflow in `SKILL.md`. Read the full specification and reference images, preserve content, functions and approximate arrangement, then improve proportions, whitespace, alignment, text scale and visual weights. Add a small number of purposeful `origin: "agent"` accents where the style calls for them, using perceptible nodes under the rules above. Retain existing origins and user notes. Carry typography, colors and materials into downstream UI implementation because the abstract canvas does not render a complete UI theme.
+
+Preserve the existing stage structure and motion intent. When resizing, moving or adding a node, reconcile its corresponding states in every stage; do not silently flatten motion into a static draft. Save through the connection's `style.commands.save` so the browser receives an editable, undoable version with the processing context.
+
+## Project an existing UI onto the canvas
+
+When the user asks to put the current, old, or existing project UI onto the canvas so they can modify it, treat that request as a reverse projection into an ordinary `ui-layout-draft`. Requests such as “把 UI 放到画布上让我修改”, “把当前页面画到 Human2AI 画布”, or “把旧界面转成布局草图” invoke this workflow without requiring the user to name the session type or Capture commands.
+
+Resolve the target page from the user's current task and the consumer project. If several pages or states are equally plausible and the choice would materially change the draft, ask which one to project. Inspect the UI implementation and, when useful and available, its local rendered result. The saved canvas must contain only the abstract layout evidence described below; never place a screenshot, DOM tree, component tree, source path, or source code on the canvas.
+
+- Use rectangles for dynamic content, media footprints, controls, groups, and independently perceptible regions whose approximate size or placement matters.
+- Use text nodes for visible static product copy. Keep imported static text editable so a user text change expresses a requested copy change in the existing UI.
+- Collapse repeated dynamic rows or cards into the smallest region that preserves their macro layout. Do not project runtime example values as static text.
+- Assign stable item ids and concise semantic types. Put a human-readable explanation of what each projected node represents in `annotation`; keep its initial user-editable `note` empty.
+- Set `origin` to `import` for every node derived from UI that already exists in the consumer project. Use `agent` only for a new layout node proposed by the Agent, while nodes created in the browser use `user`. Preserve origin when a node is edited.
+- Do not add image nodes merely to reproduce the existing UI. Represent image, chart, video, or other dynamic media areas as rectangles with a clear node description.
+
+Create or reuse the smallest clearly matching `ui-layout` session, save the projected draft through the normal Capture command, retain the returned revision as the comparison baseline, and open or provide the session review page. When the request is to place the UI on the canvas “让我修改”, stop after this handoff and wait for the user; do not modify the consumer UI yet.
+
+After the user says the canvas is ready and asks to update the project, read both the retained projection revision and the latest revision. Compare stable item ids and apply the accepted macro intent in the consumer project:
+
+- a missing `import` node requests removal of the represented existing UI;
+- changed geometry or visibility requests a corresponding layout or visibility change without prescribing a particular CSS mechanism;
+- changed text content on an `import` text node requests a change to the existing static copy;
+- a `user` node requests new UI, while an `agent` node remains an Agent-proposed addition;
+- node notes are user instructions and must be preserved and considered together with the structural differences;
+- read-only node descriptions identify nodes but are not themselves user change requests.
+
+Before changing consumer components from canvas geometry, complete the standardization workflow below. Implement the result using the consumer project's own supported viewport scope, layout, components, localization rules, tests, and verification. Do not reproduce approximate canvas coordinates with rigid absolute positioning unless the actual interface constraints require it.
+
+Read the exact latest `document`, make the requested change while preserving its schema and existing unrelated rectangles, texts, images, annotations, notes, and stages, then save it against the latest revision. Apply the selection rules above to new elements and to any requested reconstruction; do not silently remove unrelated existing elements. Human2AI records the layout intent but does not implement the interface in the consumer project.
+
+After saving, open or provide the session review page. Once the user has reviewed the result, standardize it before translating the accepted intent into the consumer project's own components, routing, state, styling, tests, and build process as the project requires.
+
+## Standardize geometry before implementing a canvas
+
+This is required whenever implementing or updating consumer UI from a UI-layout capture, including after user dragging or dimension edits. Reading a capture or handing off an editable projection alone does not require it. Human2AI cannot enforce changes in an external repository; the consumer Agent must complete this step before editing its components.
+
+1. Read the latest capture and compare it with the projection baseline, when available, before standardizing. Preserve the raw revision as evidence of user changes. Save the exact latest `document` to a local JSON file, keeping ids, origins, notes, content, images, visibility, parked nodes, groups and stages.
+2. Identify nearly aligned edges or centers from the user's intended rows, columns and controls, considering notes and the original interface. A coordinate difference alone does not establish alignment intent. Create an alignment plan with the latest capture's `fingerprint` as `sourceFingerprint`. Use actual stage ids (`start` for the base state); choose relationships independently in each stage so motion remains intentional. Group ids and node ids are accepted, but any member of a group resolves to the whole group. An empty `alignments` array is appropriate when there is no supported nearby relationship.
+
+   ```json
+   {
+     "sourceFingerprint": "<latest-capture-fingerprint>",
+     "alignments": [
+       { "stageId": "start", "axis": "x", "edge": "start", "anchorId": "group-primary-button", "itemIds": ["group-secondary-button"] }
+     ]
+   }
+   ```
+
+   `axis` is `x` or `y`; `edge` is `start`, `center` or `end` (left/center/right or top/center/bottom). Each operation moves targets toward the corresponding anchor edge or center. Prefer a single consistent anchor per relationship. Text envelopes use the same deterministic estimate as canvas export; avoid inferring typographic baseline or optical alignment from this estimate.
+3. Execute the command discovered in `session connect` with separate source and output files, adding the plan:
+
+   ```text
+   <runner> ui-layout standardize --input <document.json> --output <standardized.json> --plan <alignment-plan.json>
+   ```
+
+   The command rounds frame geometry, frame-relative node positions, dimensions and font sizes to integer canvas pixels in every stage. Source-image crop fractions remain unchanged. Selected alignment relationships then move each target, or its entire group, by at most 3 pixels on each axis, including cumulative movement. Center alignment retains integer positions and may differ by half a pixel when widths or heights have different parity. Unselected relationships receive rounding only. The command writes a validated document and prints a report with source/result fingerprints and before/after geometry; it does not save the session or change project code. Omitting `--plan` performs rounding only.
+4. Inspect the report against the raw user changes and explicit notes. If a plan is stale, exceeds the tolerance or contains conflicting alignments, reconcile the plan and run it again. Do not enlarge the tolerance or bypass validation. A larger intended layout change belongs in an explicit canvas edit before standardization. Save the standardized document through the normal Capture command against the latest revision when geometry changed; this makes the result visible and undoable. On a revision conflict, reread and standardize the new latest capture. If the report has no changes, retain the current revision without creating a redundant version.
+5. Implement from the standardized result together with the original user diff. Prefer existing layout rules, component sizes and spacing tokens. Determine whether a width means a fixed size, content sizing or available container width from context; do not copy raw canvas floats into CSS or remove legitimate percentages, relative units or image crop fractions. Standardization refines approximate geometry without replacing the consumer project's layout system. Once downstream implementation is authorized, the small standardization changes do not introduce a separate approval gate.
+
+## Canvas stacking order
+
+Preserve the optional draft-level `layerOrder` array when editing captures. It lists content node ids from back to front, independently of array numbering, geometry, visual weight or scene depth. Without it, the existing type-based draw order applies. Keep ids unique; remove deleted ids and append new ids after the saved order. Browser layer actions preserve selected nodes’ relative order. UI groups move together in this order, which is shared across motion states. Frame boundaries, guides and selection controls are outside the content order. Preview and SVG/PNG output follow this order.

package/web/out/404/index.html

@@ -0,0 +1 @@
+<!DOCTYPE html><html lang="zh-CN"><head><meta charSet="utf-8"/><meta name="viewport" content="width=device-width, initial-scale=1"/><link rel="stylesheet" href="/_next/static/css/db96ae2e88545d96.css" data-precedence="next"/><link rel="stylesheet" href="/_next/static/css/3b7982b41ed8eccd.css" data-precedence="next"/><link rel="preload" as="script" fetchPriority="low" href="/_next/static/chunks/webpack-97ae63c0e0b2a512.js"/><script src="/_next/static/chunks/c7879cf7-7873c8afd9c9c666.js" async=""></script><script src="/_next/static/chunks/158-eb00456e1bab68b3.js" async=""></script><script src="/_next/static/chunks/main-app-0cf10803ab17c700.js" async=""></script><script src="/_next/static/chunks/20-0801fc297cda2a7a.js" async=""></script><script src="/_next/static/chunks/678-1305cadf8254d814.js" async=""></script><script src="/_next/static/chunks/app/layout-745ca27ef8830f4f.js" async=""></script><meta name="robots" content="noindex"/><title>以形塑形</title><meta name="description" content="使用基础图形规划画面重心、主体占比与视觉方向。"/><title>404: This page could not be found.</title><script src="/_next/static/chunks/polyfills-42372ed130431b0a.js" noModule=""></script></head><body><div hidden=""><!--$--><!--/$--></div><div style="font-family:system-ui,&quot;Segoe UI&quot;,Roboto,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;;height:100vh;text-align:center;display:flex;flex-direction:column;align-items:center;justify-content:center"><div><style>body{color:#000;background:#fff;margin:0}.next-error-h1{border-right:1px solid rgba(0,0,0,.3)}@media (prefers-color-scheme:dark){body{color:#fff;background:#000}.next-error-h1{border-right:1px solid rgba(255,255,255,.3)}}</style><h1 class="next-error-h1" style="display:inline-block;margin:0 20px 0 0;padding:0 23px 0 0;font-size:24px;font-weight:500;vertical-align:top;line-height:49px">404</h1><div style="display:inline-block"><h2 style="font-size:14px;font-weight:400;line-height:49px;margin:0">This page could not be found.</h2></div></div></div><!--$--><!--/$--><script src="/_next/static/chunks/webpack-97ae63c0e0b2a512.js" id="_R_" async=""></script><script>(self.__next_f=self.__next_f||[]).push([0])</script><script>self.__next_f.push([1,"1:\"$Sreact.fragment\"\n2:I[84954,[\"20\",\"static/chunks/20-0801fc297cda2a7a.js\",\"678\",\"static/chunks/678-1305cadf8254d814.js\",\"177\",\"static/chunks/app/layout-745ca27ef8830f4f.js\"],\"AppI18nProvider\"]\n3:I[91133,[],\"\"]\n4:I[4297,[],\"\"]\n5:I[66999,[\"20\",\"static/chunks/20-0801fc297cda2a7a.js\",\"678\",\"static/chunks/678-1305cadf8254d814.js\",\"177\",\"static/chunks/app/layout-745ca27ef8830f4f.js\"],\"YisiUiInspectorHost\"]\n6:I[31872,[],\"OutletBoundary\"]\n7:\"$Sreact.suspense\"\na:I[31872,[],\"ViewportBoundary\"]\nc:I[31872,[],\"MetadataBoundary\"]\ne:I[57567,[],\"default\",1]\n:HL[\"/_next/static/css/db96ae2e88545d96.css\",\"style\"]\n:HL[\"/_next/static/css/3b7982b41ed8eccd.css\",\"style\"]\n9:X\n0:{\"P\":null,\"c\":[\"\",\"_not-found\",\"\"],\"q\":\"\",\"i\":false,\"f\":[[[\"\",{\"children\":[\"_not-found\",{\"children\":[\"__PAGE__\",{},\"$undefined\",\"$undefined\",4608]},\"$undefined\",\"$undefined\",4608]},\"$undefined\",\"$undefined\",4624],[[\"$\",\"$1\",\"c\",{\"children\":[[[\"$\",\"link\",\"0\",{\"rel\":\"stylesheet\",\"href\":\"/_next/static/css/db96ae2e88545d96.css\",\"precedence\":\"next\",\"crossOrigin\":\"$undefined\",\"nonce\":\"$undefined\"}],[\"$\",\"link\",\"1\",{\"rel\":\"stylesheet\",\"href\":\"/_next/static/css/3b7982b41ed8eccd.css\",\"precedence\":\"next\",\"crossOrigin\":\"$undefined\",\"nonce\":\"$undefined\"}]],[\"$\",\"html\",null,{\"lang\":\"zh-CN\",\"children\":[\"$\",\"body\",null,{\"children\":[[\"$\",\"$L2\",null,{\"children\":[\"$\",\"$L3\",null,{\"parallelRouterKey\":\"children\",\"error\":\"$undefined\",\"errorStyles\":\"$undefined\",\"errorScripts\":\"$undefined\",\"template\":[\"$\",\"$L4\",null,{}],\"templateStyles\":\"$undefined\",\"templateScripts\":\"$undefined\",\"notFound\":\"$undefined\",\"forbidden\":\"$undefined\",\"unauthorized\":\"$undefined\"}]}],[\"$\",\"$L5\",null,{}]]}]}]]}],{\"children\":[[\"$\",\"$1\",\"c\",{\"children\":[null,[\"$\",\"$L3\",null,{\"parallelRouterKey\":\"children\",\"error\":\"$undefined\",\"errorStyles\":\"$undefined\",\"errorScripts\":\"$undefined\",\"template\":[\"$\",\"$L4\",null,{}],\"templateStyles\":\"$undefined\",\"templateScripts\":\"$undefined\",\"notFound\":\"$undefined\",\"forbidden\":\"$undefined\",\"unauthorized\":\"$undefined\"}]]}],{\"children\":[[\"$\",\"$1\",\"c\",{\"children\":[[[\"$\",\"title\",null,{\"children\":\"404: This page could not be found.\"}],[\"$\",\"div\",null,{\"style\":{\"fontFamily\":\"system-ui,\\\"Segoe UI\\\",Roboto,Helvetica,Arial,sans-serif,\\\"Apple Color Emoji\\\",\\\"Segoe UI Emoji\\\"\",\"height\":\"100vh\",\"textAlign\":\"center\",\"display\":\"flex\",\"flexDirection\":\"column\",\"alignItems\":\"center\",\"justifyContent\":\"center\"},\"children\":[\"$\",\"div\",null,{\"children\":[[\"$\",\"style\",null,{\"dangerouslySetInnerHTML\":{\"__html\":\"body{color:#000;background:#fff;margin:0}.next-error-h1{border-right:1px solid rgba(0,0,0,.3)}@media (prefers-color-scheme:dark){body{color:#fff;background:#000}.next-error-h1{border-right:1px solid rgba(255,255,255,.3)}}\"}}],[\"$\",\"h1\",null,{\"className\":\"next-error-h1\",\"style\":{\"display\":\"inline-block\",\"margin\":\"0 20px 0 0\",\"padding\":\"0 23px 0 0\",\"fontSize\":24,\"fontWeight\":500,\"verticalAlign\":\"top\",\"lineHeight\":\"49px\"},\"children\":404}],[\"$\",\"div\",null,{\"style\":{\"display\":\"inline-block\"},\"children\":[\"$\",\"h2\",null,{\"style\":{\"fontSize\":14,\"fontWeight\":400,\"lineHeight\":\"49px\",\"margin\":0},\"children\":\"This page could not be found.\"}]}]]}]}]],null,[\"$\",\"$L6\",null,{\"children\":[\"$\",\"$7\",null,{\"name\":\"Next.MetadataOutlet\",\"children\":\"$@8\"}]}]]}],{},null,false,null]},null,false,\"$9\"]},null,false,null],[\"$\",\"$1\",\"h\",{\"children\":[[\"$\",\"meta\",null,{\"name\":\"robots\",\"content\":\"noindex\"}],[\"$\",\"$La\",null,{\"children\":\"$Lb\"}],[\"$\",\"div\",null,{\"hidden\":true,\"children\":[\"$\",\"$Lc\",null,{\"children\":[\"$\",\"$7\",null,{\"name\":\"Next.Metadata\",\"children\":\"$Ld\"}]}]}],null]}],false]],\"m\":\"$undefined\",\"G\":[\"$e\",[]],\"S\":true,\"h\":null,\"r\":\"$undefined\",\"s\":\"$undefined\",\"a\":\"$undefined\",\"l\":\"$undefined\",\"p\":\"$undefined\",\"d\":\"$undefined\",\"b\":\"TV-jgcACg6HANZAMZTE2S\"}\n9:C\nb:[[\"$\",\"meta\",\"0\",{\"charSet\":\"utf-8\"}],[\"$\",\"meta\",\"1\",{\"name\":\"viewport\",\"content\":\"width=device-width, initial-scale=1\"}]]\n8:null\nd:[[\"$\",\"title\",\"0\",{\"children\":\"以形塑形\"}],[\"$\",\"meta\",\"1\",{\"name\":\"description\",\"content\":\"使用基础图形规划画面重心、主体占比与视觉方向。\"}]]\n"])</script></body></html>

package/web/out/404.html

@@ -0,0 +1 @@
+<!DOCTYPE html><html lang="zh-CN"><head><meta charSet="utf-8"/><meta name="viewport" content="width=device-width, initial-scale=1"/><link rel="stylesheet" href="/_next/static/css/db96ae2e88545d96.css" data-precedence="next"/><link rel="stylesheet" href="/_next/static/css/3b7982b41ed8eccd.css" data-precedence="next"/><link rel="preload" as="script" fetchPriority="low" href="/_next/static/chunks/webpack-97ae63c0e0b2a512.js"/><script src="/_next/static/chunks/c7879cf7-7873c8afd9c9c666.js" async=""></script><script src="/_next/static/chunks/158-eb00456e1bab68b3.js" async=""></script><script src="/_next/static/chunks/main-app-0cf10803ab17c700.js" async=""></script><script src="/_next/static/chunks/20-0801fc297cda2a7a.js" async=""></script><script src="/_next/static/chunks/678-1305cadf8254d814.js" async=""></script><script src="/_next/static/chunks/app/layout-745ca27ef8830f4f.js" async=""></script><meta name="robots" content="noindex"/><title>以形塑形</title><meta name="description" content="使用基础图形规划画面重心、主体占比与视觉方向。"/><title>404: This page could not be found.</title><script src="/_next/static/chunks/polyfills-42372ed130431b0a.js" noModule=""></script></head><body><div hidden=""><!--$--><!--/$--></div><div style="font-family:system-ui,&quot;Segoe UI&quot;,Roboto,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;;height:100vh;text-align:center;display:flex;flex-direction:column;align-items:center;justify-content:center"><div><style>body{color:#000;background:#fff;margin:0}.next-error-h1{border-right:1px solid rgba(0,0,0,.3)}@media (prefers-color-scheme:dark){body{color:#fff;background:#000}.next-error-h1{border-right:1px solid rgba(255,255,255,.3)}}</style><h1 class="next-error-h1" style="display:inline-block;margin:0 20px 0 0;padding:0 23px 0 0;font-size:24px;font-weight:500;vertical-align:top;line-height:49px">404</h1><div style="display:inline-block"><h2 style="font-size:14px;font-weight:400;line-height:49px;margin:0">This page could not be found.</h2></div></div></div><!--$--><!--/$--><script src="/_next/static/chunks/webpack-97ae63c0e0b2a512.js" id="_R_" async=""></script><script>(self.__next_f=self.__next_f||[]).push([0])</script><script>self.__next_f.push([1,"1:\"$Sreact.fragment\"\n2:I[84954,[\"20\",\"static/chunks/20-0801fc297cda2a7a.js\",\"678\",\"static/chunks/678-1305cadf8254d814.js\",\"177\",\"static/chunks/app/layout-745ca27ef8830f4f.js\"],\"AppI18nProvider\"]\n3:I[91133,[],\"\"]\n4:I[4297,[],\"\"]\n5:I[66999,[\"20\",\"static/chunks/20-0801fc297cda2a7a.js\",\"678\",\"static/chunks/678-1305cadf8254d814.js\",\"177\",\"static/chunks/app/layout-745ca27ef8830f4f.js\"],\"YisiUiInspectorHost\"]\n6:I[31872,[],\"OutletBoundary\"]\n7:\"$Sreact.suspense\"\na:I[31872,[],\"ViewportBoundary\"]\nc:I[31872,[],\"MetadataBoundary\"]\ne:I[57567,[],\"default\",1]\n:HL[\"/_next/static/css/db96ae2e88545d96.css\",\"style\"]\n:HL[\"/_next/static/css/3b7982b41ed8eccd.css\",\"style\"]\n9:X\n0:{\"P\":null,\"c\":[\"\",\"_not-found\",\"\"],\"q\":\"\",\"i\":false,\"f\":[[[\"\",{\"children\":[\"_not-found\",{\"children\":[\"__PAGE__\",{},\"$undefined\",\"$undefined\",4608]},\"$undefined\",\"$undefined\",4608]},\"$undefined\",\"$undefined\",4624],[[\"$\",\"$1\",\"c\",{\"children\":[[[\"$\",\"link\",\"0\",{\"rel\":\"stylesheet\",\"href\":\"/_next/static/css/db96ae2e88545d96.css\",\"precedence\":\"next\",\"crossOrigin\":\"$undefined\",\"nonce\":\"$undefined\"}],[\"$\",\"link\",\"1\",{\"rel\":\"stylesheet\",\"href\":\"/_next/static/css/3b7982b41ed8eccd.css\",\"precedence\":\"next\",\"crossOrigin\":\"$undefined\",\"nonce\":\"$undefined\"}]],[\"$\",\"html\",null,{\"lang\":\"zh-CN\",\"children\":[\"$\",\"body\",null,{\"children\":[[\"$\",\"$L2\",null,{\"children\":[\"$\",\"$L3\",null,{\"parallelRouterKey\":\"children\",\"error\":\"$undefined\",\"errorStyles\":\"$undefined\",\"errorScripts\":\"$undefined\",\"template\":[\"$\",\"$L4\",null,{}],\"templateStyles\":\"$undefined\",\"templateScripts\":\"$undefined\",\"notFound\":\"$undefined\",\"forbidden\":\"$undefined\",\"unauthorized\":\"$undefined\"}]}],[\"$\",\"$L5\",null,{}]]}]}]]}],{\"children\":[[\"$\",\"$1\",\"c\",{\"children\":[null,[\"$\",\"$L3\",null,{\"parallelRouterKey\":\"children\",\"error\":\"$undefined\",\"errorStyles\":\"$undefined\",\"errorScripts\":\"$undefined\",\"template\":[\"$\",\"$L4\",null,{}],\"templateStyles\":\"$undefined\",\"templateScripts\":\"$undefined\",\"notFound\":\"$undefined\",\"forbidden\":\"$undefined\",\"unauthorized\":\"$undefined\"}]]}],{\"children\":[[\"$\",\"$1\",\"c\",{\"children\":[[[\"$\",\"title\",null,{\"children\":\"404: This page could not be found.\"}],[\"$\",\"div\",null,{\"style\":{\"fontFamily\":\"system-ui,\\\"Segoe UI\\\",Roboto,Helvetica,Arial,sans-serif,\\\"Apple Color Emoji\\\",\\\"Segoe UI Emoji\\\"\",\"height\":\"100vh\",\"textAlign\":\"center\",\"display\":\"flex\",\"flexDirection\":\"column\",\"alignItems\":\"center\",\"justifyContent\":\"center\"},\"children\":[\"$\",\"div\",null,{\"children\":[[\"$\",\"style\",null,{\"dangerouslySetInnerHTML\":{\"__html\":\"body{color:#000;background:#fff;margin:0}.next-error-h1{border-right:1px solid rgba(0,0,0,.3)}@media (prefers-color-scheme:dark){body{color:#fff;background:#000}.next-error-h1{border-right:1px solid rgba(255,255,255,.3)}}\"}}],[\"$\",\"h1\",null,{\"className\":\"next-error-h1\",\"style\":{\"display\":\"inline-block\",\"margin\":\"0 20px 0 0\",\"padding\":\"0 23px 0 0\",\"fontSize\":24,\"fontWeight\":500,\"verticalAlign\":\"top\",\"lineHeight\":\"49px\"},\"children\":404}],[\"$\",\"div\",null,{\"style\":{\"display\":\"inline-block\"},\"children\":[\"$\",\"h2\",null,{\"style\":{\"fontSize\":14,\"fontWeight\":400,\"lineHeight\":\"49px\",\"margin\":0},\"children\":\"This page could not be found.\"}]}]]}]}]],null,[\"$\",\"$L6\",null,{\"children\":[\"$\",\"$7\",null,{\"name\":\"Next.MetadataOutlet\",\"children\":\"$@8\"}]}]]}],{},null,false,null]},null,false,\"$9\"]},null,false,null],[\"$\",\"$1\",\"h\",{\"children\":[[\"$\",\"meta\",null,{\"name\":\"robots\",\"content\":\"noindex\"}],[\"$\",\"$La\",null,{\"children\":\"$Lb\"}],[\"$\",\"div\",null,{\"hidden\":true,\"children\":[\"$\",\"$Lc\",null,{\"children\":[\"$\",\"$7\",null,{\"name\":\"Next.Metadata\",\"children\":\"$Ld\"}]}]}],null]}],false]],\"m\":\"$undefined\",\"G\":[\"$e\",[]],\"S\":true,\"h\":null,\"r\":\"$undefined\",\"s\":\"$undefined\",\"a\":\"$undefined\",\"l\":\"$undefined\",\"p\":\"$undefined\",\"d\":\"$undefined\",\"b\":\"TV-jgcACg6HANZAMZTE2S\"}\n9:C\nb:[[\"$\",\"meta\",\"0\",{\"charSet\":\"utf-8\"}],[\"$\",\"meta\",\"1\",{\"name\":\"viewport\",\"content\":\"width=device-width, initial-scale=1\"}]]\n8:null\nd:[[\"$\",\"title\",\"0\",{\"children\":\"以形塑形\"}],[\"$\",\"meta\",\"1\",{\"name\":\"description\",\"content\":\"使用基础图形规划画面重心、主体占比与视觉方向。\"}]]\n"])</script></body></html>

package/web/out/__next.__PAGE__.txt

@@ -0,0 +1,26 @@
+1:"$Sreact.fragment"
+2:I[1076,[],"ClientPageRoot"]
+3:I[11119,["460","static/chunks/83607670-bc1279370476e59f.js","746","static/chunks/c3f2cda1-9e279dab137b7272.js","20","static/chunks/20-0801fc297cda2a7a.js","248","static/chunks/248-d4a79649dae2a3f8.js","678","static/chunks/678-1305cadf8254d814.js","130","static/chunks/130-9fadd0432daff55d.js","974","static/chunks/app/page-0027378a269a6168.js"],"default"]
+6:I[31872,[],"OutletBoundary"]
+7:"$Sreact.suspense"
+b:I[31872,[],"ViewportBoundary"]
+c:I[31872,[],"MetadataBoundary"]
+e:I[84954,["20","static/chunks/20-0801fc297cda2a7a.js","678","static/chunks/678-1305cadf8254d814.js","177","static/chunks/app/layout-745ca27ef8830f4f.js"],"AppI18nProvider"]
+f:I[91133,[],""]
+10:I[4297,[],""]
+11:I[66999,["20","static/chunks/20-0801fc297cda2a7a.js","678","static/chunks/678-1305cadf8254d814.js","177","static/chunks/app/layout-745ca27ef8830f4f.js"],"YisiUiInspectorHost"]
+:HL["/_next/static/css/8c3843f4951fa9f6.css","style"]
+:HL["/_next/static/css/db96ae2e88545d96.css","style"]
+:HL["/_next/static/css/3b7982b41ed8eccd.css","style"]
+a:X
+0:{"buildId":"TV-jgcACg6HANZAMZTE2S","data":[{"rsc":["$","$1","c",{"children":[["$","$L2",null,{"Component":"$3","serverProvidedParams":{"searchParams":{},"params":{},"promises":["$@4","$@5"]}}],[["$","link","0",{"rel":"stylesheet","href":"/_next/static/css/8c3843f4951fa9f6.css","precedence":"next"}]],["$","$L6",null,{"children":["$","$7",null,{"name":"Next.MetadataOutlet","children":"$@8"}]}]]}],"isPartial":"$@9","staleTime":"$a","varyParams":null},{"rsc":["$","$1","h",{"children":[null,["$","$Lb",null,{"children":[["$","meta","0",{"charSet":"utf-8"}],["$","meta","1",{"name":"viewport","content":"width=device-width, initial-scale=1"}]]}],["$","div",null,{"hidden":true,"children":["$","$Lc",null,{"children":["$","$7",null,{"name":"Next.Metadata","children":[["$","title","0",{"children":"以形塑形"}],["$","meta","1",{"name":"description","content":"使用基础图形规划画面重心、主体占比与视觉方向。"}]]}]}]}],null]}],"isPartial":"$@d","staleTime":"$a","varyParams":null},{"rsc":["$","$1","c",{"children":[[["$","link","0",{"rel":"stylesheet","href":"/_next/static/css/db96ae2e88545d96.css","precedence":"next"}],["$","link","1",{"rel":"stylesheet","href":"/_next/static/css/3b7982b41ed8eccd.css","precedence":"next"}]],["$","html",null,{"lang":"zh-CN","children":["$","body",null,{"children":[["$","$Le",null,{"children":["$","$Lf",null,{"parallelRouterKey":"children","template":["$","$L10",null,{}],"notFound":[[["$","title",null,{"children":"404: This page could not be found."}],["$","div",null,{"style":{"fontFamily":"system-ui,\"Segoe UI\",Roboto,Helvetica,Arial,sans-serif,\"Apple Color Emoji\",\"Segoe UI Emoji\"","height":"100vh","textAlign":"center","display":"flex","flexDirection":"column","alignItems":"center","justifyContent":"center"},"children":["$","div",null,{"children":[["$","style",null,{"dangerouslySetInnerHTML":{"__html":"body{color:#000;background:#fff;margin:0}.next-error-h1{border-right:1px solid rgba(0,0,0,.3)}@media (prefers-color-scheme:dark){body{color:#fff;background:#000}.next-error-h1{border-right:1px solid rgba(255,255,255,.3)}}"}}],["$","h1",null,{"className":"next-error-h1","style":{"display":"inline-block","margin":"0 20px 0 0","padding":"0 23px 0 0","fontSize":24,"fontWeight":500,"verticalAlign":"top","lineHeight":"49px"},"children":404}],["$","div",null,{"style":{"display":"inline-block"},"children":["$","h2",null,{"style":{"fontSize":14,"fontWeight":400,"lineHeight":"49px","margin":0},"children":"This page could not be found."}]}]]}]}]],[]]}]}],["$","$L11",null,{}]]}]}]]}],"isPartial":"$@12","staleTime":"$a","varyParams":null}],"isUpgradeableISRFallback":false,"a":"$@13","rootVaryParams":null,"needsRuntimeRequest":"$@14"}
+4:{}
+5:"$0:data:0:rsc:props:children:0:props:serverProvidedParams:params"
+8:null
+a:300
+14:true
+a:C
+13:0
+d:"$undefined"
+12:"$undefined"
+9:"$undefined"

package/web/out/__next._full.txt

@@ -0,0 +1,21 @@
+1:"$Sreact.fragment"
+2:I[84954,["20","static/chunks/20-0801fc297cda2a7a.js","678","static/chunks/678-1305cadf8254d814.js","177","static/chunks/app/layout-745ca27ef8830f4f.js"],"AppI18nProvider"]
+3:I[91133,[],""]
+4:I[4297,[],""]
+5:I[66999,["20","static/chunks/20-0801fc297cda2a7a.js","678","static/chunks/678-1305cadf8254d814.js","177","static/chunks/app/layout-745ca27ef8830f4f.js"],"YisiUiInspectorHost"]
+6:I[1076,[],"ClientPageRoot"]
+7:I[11119,["460","static/chunks/83607670-bc1279370476e59f.js","746","static/chunks/c3f2cda1-9e279dab137b7272.js","20","static/chunks/20-0801fc297cda2a7a.js","248","static/chunks/248-d4a79649dae2a3f8.js","678","static/chunks/678-1305cadf8254d814.js","130","static/chunks/130-9fadd0432daff55d.js","974","static/chunks/app/page-0027378a269a6168.js"],"default"]
+a:I[31872,[],"OutletBoundary"]
+b:"$Sreact.suspense"
+d:I[31872,[],"ViewportBoundary"]
+f:I[31872,[],"MetadataBoundary"]
+11:I[57567,[],"default",1]
+:HL["/_next/static/css/db96ae2e88545d96.css","style"]
+:HL["/_next/static/css/3b7982b41ed8eccd.css","style"]
+:HL["/_next/static/css/8c3843f4951fa9f6.css","style"]
+0:{"P":null,"c":["",""],"q":"","i":false,"f":[[["",{"children":["__PAGE__",{},"$undefined","$undefined",4608]},"$undefined","$undefined",4624],[["$","$1","c",{"children":[[["$","link","0",{"rel":"stylesheet","href":"/_next/static/css/db96ae2e88545d96.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}],["$","link","1",{"rel":"stylesheet","href":"/_next/static/css/3b7982b41ed8eccd.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}]],["$","html",null,{"lang":"zh-CN","children":["$","body",null,{"children":[["$","$L2",null,{"children":["$","$L3",null,{"parallelRouterKey":"children","error":"$undefined","errorStyles":"$undefined","errorScripts":"$undefined","template":["$","$L4",null,{}],"templateStyles":"$undefined","templateScripts":"$undefined","notFound":[[["$","title",null,{"children":"404: This page could not be found."}],["$","div",null,{"style":{"fontFamily":"system-ui,\"Segoe UI\",Roboto,Helvetica,Arial,sans-serif,\"Apple Color Emoji\",\"Segoe UI Emoji\"","height":"100vh","textAlign":"center","display":"flex","flexDirection":"column","alignItems":"center","justifyContent":"center"},"children":["$","div",null,{"children":[["$","style",null,{"dangerouslySetInnerHTML":{"__html":"body{color:#000;background:#fff;margin:0}.next-error-h1{border-right:1px solid rgba(0,0,0,.3)}@media (prefers-color-scheme:dark){body{color:#fff;background:#000}.next-error-h1{border-right:1px solid rgba(255,255,255,.3)}}"}}],["$","h1",null,{"className":"next-error-h1","style":{"display":"inline-block","margin":"0 20px 0 0","padding":"0 23px 0 0","fontSize":24,"fontWeight":500,"verticalAlign":"top","lineHeight":"49px"},"children":404}],["$","div",null,{"style":{"display":"inline-block"},"children":["$","h2",null,{"style":{"fontSize":14,"fontWeight":400,"lineHeight":"49px","margin":0},"children":"This page could not be found."}]}]]}]}]],[]],"forbidden":"$undefined","unauthorized":"$undefined"}]}],["$","$L5",null,{}]]}]}]]}],{"children":[["$","$1","c",{"children":[["$","$L6",null,{"Component":"$7","serverProvidedParams":{"searchParams":{},"params":{},"promises":["$@8","$@9"]}}],[["$","link","0",{"rel":"stylesheet","href":"/_next/static/css/8c3843f4951fa9f6.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}]],["$","$La",null,{"children":["$","$b",null,{"name":"Next.MetadataOutlet","children":"$@c"}]}]]}],{},null,false,null]},null,false,null],["$","$1","h",{"children":[null,["$","$Ld",null,{"children":"$Le"}],["$","div",null,{"hidden":true,"children":["$","$Lf",null,{"children":["$","$b",null,{"name":"Next.Metadata","children":"$L10"}]}]}],null]}],false]],"m":"$undefined","G":["$11",[]],"S":true,"h":null,"r":"$undefined","s":"$undefined","a":"$undefined","l":"$undefined","p":"$undefined","d":"$undefined","b":"TV-jgcACg6HANZAMZTE2S"}
+8:{}
+9:"$0:f:0:1:1:children:0:props:children:0:props:serverProvidedParams:params"
+e:[["$","meta","0",{"charSet":"utf-8"}],["$","meta","1",{"name":"viewport","content":"width=device-width, initial-scale=1"}]]
+c:null
+10:[["$","title","0",{"children":"以形塑形"}],["$","meta","1",{"name":"description","content":"使用基础图形规划画面重心、主体占比与视觉方向。"}]]

package/web/out/__next._tree.txt

@@ -0,0 +1,4 @@
+:HL["/_next/static/css/db96ae2e88545d96.css","style"]
+:HL["/_next/static/css/3b7982b41ed8eccd.css","style"]
+:HL["/_next/static/css/8c3843f4951fa9f6.css","style"]
+0:{"tree":{"name":"","param":null,"prefetchHints":4176,"slots":{"children":{"name":"__PAGE__","param":null,"prefetchHints":4256,"slots":null}}},"staleTime":300,"buildId":"TV-jgcACg6HANZAMZTE2S"}