lattice-cli 0.1.0__py3-none-any.whl

lattice/resources/codex/lattice-workflow/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: lattice-workflow
+description: Use when planning or testing behavior or variant surfaces with interacting states, roles, permissions, feature flags, modes, providers, optional fields, component props, rendering branches, template variants, config matrices, lifecycle states, combinatorial edge cases, pairwise coverage, or t-way coverage. Extract a Lattice schema, run the local Lattice CLI, and use generated rows to strengthen plans, tests, fixtures, rendered variants, or review matrices.
+---
+
+# Lattice Workflow
+
+Use this skill to keep the agent on the extraction and interpretation work while Lattice handles the combinatorics.
+
+## When To Use It
+
+Use this skill when the task is any of:
+
+- derive a combinatorial model from a feature or PRD
+- derive a test matrix from existing code
+- derive a variant matrix from a component, partial, template, design-system story, or config surface
+- convert edge cases into explicit parameter/value constraints
+- generate pairwise or 3-way scenarios without hand-enumerating combinations
+- render a compact visual review matrix instead of every possible variant
+- review a plan involving roles, permissions, modes, providers, feature flags, optional fields, component props, rendering branches, template variants, config matrices, or lifecycle states
+- find coverage gaps where bugs are likely to hide in interactions rather than single branches
+
+Do not use this skill to invent pairwise combinations manually. The schema is the contract. The generated rows are the source of truth. The schema file is optional transport.
+
+## Preflight
+
+Before using this skill, check whether `lattice` is already installed:
+
+```bash
+command -v lattice >/dev/null 2>&1 && lattice --help >/dev/null
+```
+
+If that succeeds, use the installed command.
+
+If it fails and you know the path to the Lattice source checkout, install it into the current Python environment:
+
+```bash
+python3 -m pip install -e /path/to/lattice
+```
+
+To install or refresh this skill from the installed package:
+
+```bash
+lattice agent bootstrap
+```
+
+If the skill was copied from a Lattice checkout, the agent setup page is available at `docs/install.md` in that checkout.
+
+In this repository, the development fallback remains:
+
+```bash
+cat schema.json | PYTHONPATH=src python3 -m lattice validate
+cat schema.json | PYTHONPATH=src python3 -m lattice generate
+```
+
+## Workflow
+
+1. Extract the schema.
+   First choose the scope. A schema should usually describe one coherent interaction surface: one feature, one workflow, one service behavior, one endpoint family, one rendering surface, one component's variant space, one template family, one config matrix, or one data-model interaction surface. Then choose parameters that represent independent decisions or state partitions inside that scope. Choose values that are meaningful partitions, not every literal in the codebase.
+2. Encode constraints.
+   Prefer the smallest constraint type that matches the rule. Lattice supports exclusion-style constraints, not only conditional parameters: use `invalid_pair` when two assignments cannot coexist and `higher_order` when a combination only becomes invalid with multiple antecedents. Use `conditional` instead of hand-writing `N/A` values.
+3. Validate before generation.
+   Prefer the installed `lattice` command with JSON or YAML on stdin:
+
+   ```bash
+   cat schema.json | lattice validate
+   ```
+
+   If you are working inside this repository and the package is not installed yet, the fallback is:
+
+   ```bash
+   cat schema.json | PYTHONPATH=src python3 -m lattice validate
+   ```
+
+   Use a temp file only if the harness needs one for debugging or tool interop.
+4. Generate deterministic scenarios.
+
+   ```bash
+   cat schema.json | lattice generate
+   ```
+
+   The development fallback in this repo is:
+
+   ```bash
+   cat schema.json | PYTHONPATH=src python3 -m lattice generate
+   ```
+
+   Default to pairwise unless the user explicitly asks for a higher strength.
+5. Interpret the output.
+   In plan mode, turn rows into plan revisions, missing decisions, and review scenarios. In test mode, diff the rows against the existing tests and write the missing cases. In variant mode, turn rows into fixtures, rendered variants, screenshots, contact sheets, visual diff inputs, or review checklists.
+
+   In test mode, source expected behavior from intent — the user's request, a spec, a PRD, a ticket, or explicit reasoning about what the system *should* do. The code under test is evidence, not truth. If intent is ambiguous for a row, stop and ask the user. Do not silently encode current behavior and hedge with `bug_signal:`-style annotations: that produces characterization tests, which lock in the implementation (bugs included) instead of catching divergence from intent. The asymmetries Lattice is designed to expose disappear when the test suite mirrors the same mental model as the code.
+
+## Modeling Rules
+
+- Scope one schema to one interaction surface. Do not default to the whole app unless the app is genuinely small and the behavior or rendering surface is still coherent.
+- Keep parameter names stable and implementation-adjacent.
+- Use value partitions such as `present` and `absent`, not brittle prose.
+- Avoid derived duplicate parameters. If one field is determined by another, represent that as a constraint.
+- Add constraints only for true business or system rules. Do not use them to encode preferences.
+- Do not strip true constraints to make generation easier, and do not generate nonsensical rows just to mark them invalid later. Encoding constraints changes the coverage universe to valid interactions, which is the point of using Lattice.
+- If two assignments cannot coexist, use `invalid_pair`.
+- If a parameter only matters under a parent value, use `conditional`.
+- If a scenario must appear at least once, use `forced`.
+- If a rule only breaks under multiple antecedents, use `higher_order`.
+
+Read [references/modeling-rules.md](references/modeling-rules.md) when you need extraction heuristics or constraint selection guidance.
+
+## Output Discipline
+
+- Run `validate` before `generate`.
+- Prefer stdin and JSON because another agent step usually consumes the output.
+- Do not add or remove rows after generation.
+- If validation fails, fix the schema instead of weakening the generation step.
+- If generation emits rows that are impossible in the target system, stop and add the missing constraint rather than filtering or annotating those rows downstream.
+- In test mode, assertions must reflect intended behavior, not observed behavior. Read intent from the spec, PRD, ticket, or user — never from the code under test. If intent is ambiguous, stop and ask.
+
+Read [references/worked-examples.md](references/worked-examples.md) for concrete examples in this repo.

lattice/resources/codex/lattice-workflow/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Lattice Workflow"
+  short_description: "Generate pairwise coverage for plans, tests, and variants"
+  default_prompt: "Use $lattice-workflow to model interacting states or variant dimensions, extract a Lattice schema, validate it, generate pairwise rows, and use the rows to strengthen the plan, tests, fixtures, or visual review."
+
+policy:
+  allow_implicit_invocation: true

lattice/resources/codex/lattice-workflow/references/modeling-rules.md

@@ -0,0 +1,52 @@
+# Modeling Rules
+
+Use this file when you are extracting a schema from code or prose and need tighter guardrails than the main skill body provides.
+
+## Parameter Selection
+
+- Scope one schema to one coherent behavior or rendering surface.
+  Good scopes: one feature, one service behavior, one workflow, one endpoint family, one state-machine slice, one component's variant space, one template family.
+  Bad default scope: the whole app.
+- Model the decisions that change behavior, not every field in a payload.
+- Prefer parameters that are visible in tests, UI branches, rendering branches, validation logic, template variants, component props, or feature flags.
+- Split large raw domains into behavioral partitions.
+  Good: `pay_range = present|absent`
+  Bad: every exact salary string
+- Avoid separate parameters for values that are already implied by another parameter unless the implication is partial and needs a constraint.
+
+## Value Selection
+
+- Values should be mutually exclusive and collectively useful for testing.
+- Keep domains small and meaningful. Most parameters should land in the 2-5 value range.
+- Normalize booleans as `true` and `false`.
+- For optional subordinate parameters, let `conditional` introduce `N/A`. Do not hand-add `N/A` unless the schema genuinely needs it as a first-class value.
+
+## Constraint Choice
+
+- `invalid_pair`: two assignments cannot coexist
+- `bidirectional`: one-to-one pairing; if A then B and if B then A
+- `forward_dep`: A requires B, but B may appear elsewhere
+- `conditional`: a child parameter only applies for some parent values
+- `forced`: this assignment set must appear in at least one generated row
+- `higher_order`: the invalid rule only appears when two or more antecedents are true
+
+Choose the smallest expressive type. If a rule can be represented as `invalid_pair`, do not use `higher_order`.
+
+Do not strip true constraints to get a smaller or easier unconstrained run. Do not generate nonsensical rows and mark them invalid downstream. Lattice's coverage accounting should run over valid interactions, so impossible combinations belong in the schema as `invalid_pair`, `forward_dep`, `bidirectional`, `conditional`, or `higher_order` constraints.
+
+## Extraction Process
+
+1. Choose the behavior or rendering surface you are modeling.
+2. Start from branches, validations, and business rules inside that scope.
+3. Convert prose like "only when", "must", "cannot", and "except" into candidate constraints.
+4. Remove cosmetic parameters that do not affect behavior.
+5. Check whether a missing value is really a separate partition or just noise.
+6. Validate the schema.
+7. Only after validation, generate scenarios.
+
+## Interpretation
+
+- Plan mode: each row becomes a review scenario or a missing decision in the plan.
+- Test mode: each row becomes a candidate setup matrix. Source the expected behavior from intent — user request, spec, PRD, or ticket — not from the code under test. If you cannot determine intent for a row, stop and surface the ambiguity to the user. Do not encode the current behavior and label it `bug_signal:` to hedge: characterization tests pass for the wrong reasons and hide the asymmetries Lattice is designed to expose. Example: if a mailbox accepts a spoofed `From:` header today, the assertion is still "rejects spoofed sender" — let the test fail and fix the code, do not invert the assertion to match the bug.
+- Variant mode: each row becomes a rendered variant, fixture, screenshot, visual diff input, contact-sheet item, or review checklist item.
+- Generated rows are not test names by themselves. The agent still needs to map them to application-specific assertions.

lattice/resources/codex/lattice-workflow/references/worked-examples.md

@@ -0,0 +1,59 @@
+# Worked Examples
+
+These examples live in the repo-level `examples/` directory.
+
+## `examples/plan-mode-saved-search`
+
+Use when the agent starts from a feature discussion or PRD and needs a review checklist.
+
+- Input: `feature.md`
+- Schema transport: `model.yaml`
+- Output: `scenarios.json`
+
+## `examples/test-mode-checkout`
+
+Use when the agent starts from code and an existing test surface and needs missing cases.
+
+- Input: `code-notes.md`
+- Schema transport: `model.json`
+- Output: `scenarios.json`
+
+## `examples/three-way-notifications`
+
+Use when pairwise is not enough and the user explicitly wants 3-way coverage.
+
+- Input: `brief.md`
+- Schema transport: `model.yaml`
+- Output: `scenarios.json`
+
+## `examples/component-variant-matrix`
+
+Use when the agent starts from a visual component, rendering surface, template, or design-system story and needs compact review variants instead of every possible combination.
+
+- Input: `brief.md`
+- Schema transport: `model.yaml`
+- Output: `scenarios.json`
+
+## `examples/lattice-self-test`
+
+Use when you want a meta example of the harness extracting a schema for Lattice's own CLI surface and then using generated rows to drive CLI smoke tests.
+
+- Input: `brief.md`
+- Schema transport: `model.yaml`
+- Output: `scenarios.json`
+
+## `examples/agent-bootstrap-matrix`
+
+Use when you want a meta example of Lattice testing its own agent skill bootstrap behavior across harness detection, force/skip directives, target modes, and output formats.
+
+- Input: `brief.md`
+- Schema transport: `model.yaml`
+- Output: `scenarios.json`
+
+## `examples/schema-guidance-matrix`
+
+Use when you want a meta example of Lattice testing its own schema-discoverability guidance across help text, agent instructions, installed skill files, and validation errors.
+
+- Input: `brief.md`
+- Schema transport: `model.yaml`
+- Output: `scenarios.json`

lattice/resources/generic/lattice-workflow/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: lattice-workflow
+description: Use when planning or testing behavior or variant surfaces with interacting states, roles, permissions, feature flags, modes, providers, optional fields, component props, rendering branches, template variants, config matrices, lifecycle states, combinatorial edge cases, pairwise coverage, or t-way coverage. Extract a Lattice schema, run the local Lattice CLI, and use generated rows to strengthen plans, tests, fixtures, rendered variants, or review matrices.
+---
+
+# Lattice Workflow
+
+Use this skill to keep the agent on the extraction and interpretation work while Lattice handles the combinatorics.
+
+## When To Use It
+
+Use this skill when the task is any of:
+
+- derive a combinatorial model from a feature or PRD
+- derive a test matrix from existing code
+- derive a variant matrix from a component, partial, template, design-system story, or config surface
+- convert edge cases into explicit parameter/value constraints
+- generate pairwise or 3-way scenarios without hand-enumerating combinations
+- render a compact visual review matrix instead of every possible variant
+- review a plan involving roles, permissions, modes, providers, feature flags, optional fields, component props, rendering branches, template variants, config matrices, or lifecycle states
+- find coverage gaps where bugs are likely to hide in interactions rather than single branches
+
+Do not use this skill to invent pairwise combinations manually. The schema is the contract. The generated rows are the source of truth. The schema file is optional transport.
+
+## Preflight
+
+Before using this skill, check whether `lattice` is already installed:
+
+```bash
+command -v lattice >/dev/null 2>&1 && lattice --help >/dev/null
+```
+
+If that succeeds, use the installed command.
+
+If it fails and you know the path to the Lattice source checkout, install it into the current Python environment:
+
+```bash
+python3 -m pip install -e /path/to/lattice
+```
+
+To install or refresh a generic copy of this skill from the installed package:
+
+```bash
+lattice agent install-skill /path/to/harness/skills/lattice-workflow
+```
+
+For harnesses that do not use skill directories, copy the output of:
+
+```bash
+lattice agent instructions
+```
+
+into the harness memory, system instruction, rule file, or project instruction mechanism.
+
+In this repository, the development fallback remains:
+
+```bash
+cat schema.json | PYTHONPATH=src python3 -m lattice validate
+cat schema.json | PYTHONPATH=src python3 -m lattice generate
+```
+
+## Workflow
+
+1. Extract the schema.
+   First choose the scope. A schema should usually describe one coherent interaction surface: one feature, one workflow, one service behavior, one endpoint family, one rendering surface, one component's variant space, one template family, one config matrix, or one data-model interaction surface. Then choose parameters that represent independent decisions or state partitions inside that scope. Choose values that are meaningful partitions, not every literal in the codebase.
+2. Encode constraints.
+   Prefer the smallest constraint type that matches the rule. Lattice supports exclusion-style constraints, not only conditional parameters: use `invalid_pair` when two assignments cannot coexist and `higher_order` when a combination only becomes invalid with multiple antecedents. Use `conditional` instead of hand-writing `N/A` values.
+3. Validate before generation.
+   Prefer the installed `lattice` command with JSON or YAML on stdin:
+
+   ```bash
+   cat schema.json | lattice validate
+   ```
+
+   If you are working inside this repository and the package is not installed yet, the fallback is:
+
+   ```bash
+   cat schema.json | PYTHONPATH=src python3 -m lattice validate
+   ```
+
+   Use a temp file only if the harness needs one for debugging or tool interop.
+4. Generate deterministic scenarios.
+
+   ```bash
+   cat schema.json | lattice generate
+   ```
+
+   The development fallback in this repo is:
+
+   ```bash
+   cat schema.json | PYTHONPATH=src python3 -m lattice generate
+   ```
+
+   Default to pairwise unless the user explicitly asks for a higher strength.
+5. Interpret the output.
+   In plan mode, turn rows into plan revisions, missing decisions, and review scenarios. In test mode, diff the rows against the existing tests and write the missing cases. In variant mode, turn rows into fixtures, rendered variants, screenshots, contact sheets, visual diff inputs, or review checklists.
+
+   In test mode, source expected behavior from intent — the user's request, a spec, a PRD, a ticket, or explicit reasoning about what the system *should* do. The code under test is evidence, not truth. If intent is ambiguous for a row, stop and ask the user. Do not silently encode current behavior and hedge with `bug_signal:`-style annotations: that produces characterization tests, which lock in the implementation (bugs included) instead of catching divergence from intent. The asymmetries Lattice is designed to expose disappear when the test suite mirrors the same mental model as the code.
+
+## Modeling Rules
+
+- Scope one schema to one interaction surface. Do not default to the whole app unless the app is genuinely small and the behavior or rendering surface is still coherent.
+- Keep parameter names stable and implementation-adjacent.
+- Use value partitions such as `present` and `absent`, not brittle prose.
+- Avoid derived duplicate parameters. If one field is determined by another, represent that as a constraint.
+- Add constraints only for true business or system rules. Do not use them to encode preferences.
+- Do not strip true constraints to make generation easier, and do not generate nonsensical rows just to mark them invalid later. Encoding constraints changes the coverage universe to valid interactions, which is the point of using Lattice.
+- If two assignments cannot coexist, use `invalid_pair`.
+- If a parameter only matters under a parent value, use `conditional`.
+- If a scenario must appear at least once, use `forced`.
+- If a rule only breaks under multiple antecedents, use `higher_order`.
+
+Read [references/modeling-rules.md](references/modeling-rules.md) when you need extraction heuristics or constraint selection guidance.
+
+## Output Discipline
+
+- Run `validate` before `generate`.
+- Prefer stdin and JSON because another agent step usually consumes the output.
+- Do not add or remove rows after generation.
+- If validation fails, fix the schema instead of weakening the generation step.
+- If generation emits rows that are impossible in the target system, stop and add the missing constraint rather than filtering or annotating those rows downstream.
+- In test mode, assertions must reflect intended behavior, not observed behavior. Read intent from the spec, PRD, ticket, or user — never from the code under test. If intent is ambiguous, stop and ask.
+
+Read [references/worked-examples.md](references/worked-examples.md) for concrete examples in this repo.

lattice/resources/generic/lattice-workflow/references/modeling-rules.md

@@ -0,0 +1,52 @@
+# Modeling Rules
+
+Use this file when you are extracting a schema from code or prose and need tighter guardrails than the main skill body provides.
+
+## Parameter Selection
+
+- Scope one schema to one coherent behavior or rendering surface.
+  Good scopes: one feature, one service behavior, one workflow, one endpoint family, one state-machine slice, one component's variant space, one template family.
+  Bad default scope: the whole app.
+- Model the decisions that change behavior, not every field in a payload.
+- Prefer parameters that are visible in tests, UI branches, rendering branches, validation logic, template variants, component props, or feature flags.
+- Split large raw domains into behavioral partitions.
+  Good: `pay_range = present|absent`
+  Bad: every exact salary string
+- Avoid separate parameters for values that are already implied by another parameter unless the implication is partial and needs a constraint.
+
+## Value Selection
+
+- Values should be mutually exclusive and collectively useful for testing.
+- Keep domains small and meaningful. Most parameters should land in the 2-5 value range.
+- Normalize booleans as `true` and `false`.
+- For optional subordinate parameters, let `conditional` introduce `N/A`. Do not hand-add `N/A` unless the schema genuinely needs it as a first-class value.
+
+## Constraint Choice
+
+- `invalid_pair`: two assignments cannot coexist
+- `bidirectional`: one-to-one pairing; if A then B and if B then A
+- `forward_dep`: A requires B, but B may appear elsewhere
+- `conditional`: a child parameter only applies for some parent values
+- `forced`: this assignment set must appear in at least one generated row
+- `higher_order`: the invalid rule only appears when two or more antecedents are true
+
+Choose the smallest expressive type. If a rule can be represented as `invalid_pair`, do not use `higher_order`.
+
+Do not strip true constraints to get a smaller or easier unconstrained run. Do not generate nonsensical rows and mark them invalid downstream. Lattice's coverage accounting should run over valid interactions, so impossible combinations belong in the schema as `invalid_pair`, `forward_dep`, `bidirectional`, `conditional`, or `higher_order` constraints.
+
+## Extraction Process
+
+1. Choose the behavior or rendering surface you are modeling.
+2. Start from branches, validations, and business rules inside that scope.
+3. Convert prose like "only when", "must", "cannot", and "except" into candidate constraints.
+4. Remove cosmetic parameters that do not affect behavior.
+5. Check whether a missing value is really a separate partition or just noise.
+6. Validate the schema.
+7. Only after validation, generate scenarios.
+
+## Interpretation
+
+- Plan mode: each row becomes a review scenario or a missing decision in the plan.
+- Test mode: each row becomes a candidate setup matrix. Source the expected behavior from intent — user request, spec, PRD, or ticket — not from the code under test. If you cannot determine intent for a row, stop and surface the ambiguity to the user. Do not encode the current behavior and label it `bug_signal:` to hedge: characterization tests pass for the wrong reasons and hide the asymmetries Lattice is designed to expose. Example: if a mailbox accepts a spoofed `From:` header today, the assertion is still "rejects spoofed sender" — let the test fail and fix the code, do not invert the assertion to match the bug.
+- Variant mode: each row becomes a rendered variant, fixture, screenshot, visual diff input, contact-sheet item, or review checklist item.
+- Generated rows are not test names by themselves. The agent still needs to map them to application-specific assertions.

lattice/resources/generic/lattice-workflow/references/worked-examples.md

@@ -0,0 +1,59 @@
+# Worked Examples
+
+These examples live in the repo-level `examples/` directory.
+
+## `examples/plan-mode-saved-search`
+
+Use when the agent starts from a feature discussion or PRD and needs a review checklist.
+
+- Input: `feature.md`
+- Schema transport: `model.yaml`
+- Output: `scenarios.json`
+
+## `examples/test-mode-checkout`
+
+Use when the agent starts from code and an existing test surface and needs missing cases.
+
+- Input: `code-notes.md`
+- Schema transport: `model.json`
+- Output: `scenarios.json`
+
+## `examples/three-way-notifications`
+
+Use when pairwise is not enough and the user explicitly wants 3-way coverage.
+
+- Input: `brief.md`
+- Schema transport: `model.yaml`
+- Output: `scenarios.json`
+
+## `examples/component-variant-matrix`
+
+Use when the agent starts from a visual component, rendering surface, template, or design-system story and needs compact review variants instead of every possible combination.
+
+- Input: `brief.md`
+- Schema transport: `model.yaml`
+- Output: `scenarios.json`
+
+## `examples/lattice-self-test`
+
+Use when you want a meta example of the harness extracting a schema for Lattice's own CLI surface and then using generated rows to drive CLI smoke tests.
+
+- Input: `brief.md`
+- Schema transport: `model.yaml`
+- Output: `scenarios.json`
+
+## `examples/agent-bootstrap-matrix`
+
+Use when you want a meta example of Lattice testing its own agent skill bootstrap behavior across harness detection, force/skip directives, target modes, and output formats.
+
+- Input: `brief.md`
+- Schema transport: `model.yaml`
+- Output: `scenarios.json`
+
+## `examples/schema-guidance-matrix`
+
+Use when you want a meta example of Lattice testing its own schema-discoverability guidance across help text, agent instructions, installed skill files, and validation errors.
+
+- Input: `brief.md`
+- Schema transport: `model.yaml`
+- Output: `scenarios.json`