@probelabs/visor 0.1.124 → 0.1.126

package/dist/docs/testing/cli.md

@@ -5,37 +5,79 @@ Run integration tests for your Visor config using the built-in `test` subcommand
 ## Commands
 
 - Discover tests file and list cases
-  - `visor test --list [--config defaults/.visor.tests.yaml]`
+  - `visor test --list [--config defaults/visor.tests.yaml]`
 - Run cases
-  - `visor test [--config defaults/.visor.tests.yaml] [--only <substring>] [--bail]`
+  - `visor test [--config defaults/visor.tests.yaml] [--only <substring>] [--bail]`
 - Validate tests YAML without running
-  - `visor test --validate [--config defaults/.visor.tests.yaml]`
+  - `visor test --validate [--config defaults/visor.tests.yaml]`
+
+## Auto-Discovery
+
+When no `--config` is provided, the test runner searches for test files in the following order:
+
+1. `defaults/visor.tests.yaml` or `defaults/visor.tests.yml`
+2. `.visor.tests.yaml` or `.visor.tests.yml` in the project root
+
+You can also pass a directory or glob pattern as a positional argument to discover multiple test suites:
+
+```bash
+visor test defaults/           # Run all suites in defaults/
+visor test "**/*.tests.yaml"   # Run all matching suites
+```
 
 ## Flags
 
-- `--config <path>`: Path to `.visor.tests.yaml` (auto-discovers `.visor.tests.yaml` or `defaults/.visor.tests.yaml`).
+### Core Flags
+
+- `--config <path>`: Path to `.visor.tests.yaml` (auto-discovers if not specified).
 - `--only <filter>`: Run cases whose `name` contains the substring (case-insensitive).
- - `--only <filter>`: Run cases whose `name` contains the substring (case-insensitive).
-   - Stage filter: append `#<stage>` to run only a flow stage.
-     - Examples: `--only pr-review-e2e-flow#facts-invalid`, `--only pr-review-e2e-flow#3` (1‑based index)
+  - Stage filter: append `#<stage>` to run only a flow stage.
+    - Examples: `--only pr-review-e2e-flow#facts-invalid`, `--only pr-review-e2e-flow#3` (1-based index)
 - `--bail`: Stop on first failure.
-- `--json <path|->`: Write a minimal JSON summary.
-- `--report junit:<path>`: Write a minimal JUnit XML.
-- `--summary md:<path>`: Write a minimal Markdown summary.
-- `--progress compact|detailed`: Progress verbosity (parsing supported; detailed view evolves over time).
-- `--max-parallel <N>`: Run up to N cases concurrently.
+- `--list`: List discovered test cases without running them.
+- `--validate`: Validate tests YAML syntax without running.
+
+### Parallelism
+
+- `--max-parallel <N>`: Run up to N test cases concurrently within a suite (default: 1).
+- `--max-suites <N>`: Run up to N test suites concurrently when discovering multiple files (default: number of CPUs).
+
+### Output & Reporting
+
+- `--json <path|->`: Write a minimal JSON summary (`-` for stdout).
+- `--report junit:<path>`: Write a JUnit XML report.
+- `--summary md:<path>`: Write a Markdown summary.
+- `--progress compact|detailed`: Progress verbosity (default: compact).
 - `--prompt-max-chars <N>`: Truncate captured prompt text to N characters.
 
+### Debugging
+
+- `--debug`: Enable debug mode for verbose output (equivalent to `VISOR_DEBUG=true`).
+- `--no-mocks`: Run tests without mock injection. Real providers execute and outputs are printed as suggested mocks.
+
 ## Output
 
 - Per-case PASS/FAIL lines
 - Coverage table (expected vs actual step runs)
-- Summary totals
+- Summary totals (Jest-style format)
 
 ## Tips
 
 - Use `--validate` when iterating on tests to catch typos early.
 - Keep `strict: true` in `tests.defaults` to surface missing `expect` quickly.
 - For large suites, increase `--max-parallel` to improve throughput.
-- Enable debug logs by setting `VISOR_DEBUG=true`.
-  - Example: `VISOR_DEBUG=true visor test --config defaults/.visor.tests.yaml --only pr-review-e2e-flow#facts-invalid`
+- Use `--no-mocks` to capture real provider outputs, then copy the suggested mocks into your test case.
+- Enable debug logs with `--debug` or `VISOR_DEBUG=true`:
+  ```bash
+  visor test --debug --config defaults/visor.tests.yaml --only pr-review-e2e-flow#facts-invalid
+  ```
+
+## Related Documentation
+
+- [Getting Started](./getting-started.md) - Introduction to the test framework
+- [DSL Reference](./dsl-reference.md) - Complete test YAML schema
+- [Assertions](./assertions.md) - Available assertion types
+- [Fixtures and Mocks](./fixtures-and-mocks.md) - Managing test data
+- [Flows](./flows.md) - Multi-stage test flows
+- [CI Integration](./ci.md) - Running tests in CI pipelines
+- [Troubleshooting](./troubleshooting.md) - Common issues and solutions

package/dist/docs/testing/cookbook.md

@@ -86,70 +86,93 @@ Copy‑pasteable recipes for common scenarios.
   fixture: gh.issue_comment.visor_help
   env: { ENABLE_FACT_VALIDATION: "true" }
   mocks:
-    comment-assistant: { text: "We rely on defaults/.visor.yaml line 11 for max_parallelism=4.", intent: comment_reply }
+    comment-assistant: { text: "We rely on defaults/visor.yaml line 11 for max_parallelism=4.", intent: comment_reply }
     extract-facts:
       - { id: f1, category: Configuration, claim: "max_parallelism defaults to 4", verifiable: true }
     validate-fact[]:
-      - { fact_id: f1, is_valid: true, confidence: high, evidence: "defaults/.visor.yaml:11" }
+      - { fact_id: f1, claim: "max_parallelism defaults to 4", is_valid: true, confidence: high, evidence: "defaults/visor.yaml:11" }
   expect:
     calls:
+      - step: comment-assistant
+        exactly: 1
       - step: extract-facts
         exactly: 1
       - step: validate-fact
         at_least: 1
-      - step: aggregate-validations
-        exactly: 1
 ```
 
 ## 6) Facts invalid (correction reply)
 
+When a fact is invalid, the correction flow triggers a re-run. Due to goto forward-running dependents, `extract-facts` and `validate-fact` also run again.
+
 ```yaml
 - name: facts-invalid
   event: issue_comment
   fixture: gh.issue_comment.visor_help
   env: { ENABLE_FACT_VALIDATION: "true" }
+  routing:
+    max_loops: 1
   mocks:
-    comment-assistant: { text: "We rely on defaults/.visor.yaml line 11 for max_parallelism=4.", intent: comment_reply }
+    comment-assistant: { text: "We rely on defaults/visor.yaml line 11 for max_parallelism=4.", intent: comment_reply }
     extract-facts:
       - { id: f1, category: Configuration, claim: "max_parallelism defaults to 4", verifiable: true }
     validate-fact[]:
-      - { fact_id: f1, is_valid: false, confidence: high, evidence: "defaults/.visor.yaml:11", correction: "max_parallelism defaults to 3" }
+      - { fact_id: f1, claim: "max_parallelism defaults to 4", is_valid: false, confidence: high, evidence: "defaults/visor.yaml:11 does not set 4", correction: "max_parallelism defaults to 3" }
   expect:
     calls:
       - step: comment-assistant
         exactly: 2
-      - step: aggregate-validations
+      - step: extract-facts
+        exactly: 2
+      - step: validate-fact
+        exactly: 2
+      - step: aggregate
         exactly: 1
-    prompts:
-      - step: comment-assistant
-        index: last
-        contains: ["<previous_response>", "Correction: max_parallelism defaults to 3"]
+    outputs:
+      - step: validate-fact
+        where: { path: fact_id, equals: f1 }
+        path: correction
+        equals: "max_parallelism defaults to 3"
 ```
 
 ## 7) Two facts (one invalid)
 
+With two facts extracted where only one is invalid, the correction pass runs for the invalid fact. Due to goto forward-running dependents, `extract-facts` and `validate-fact` run again on retry.
+
 ```yaml
 - name: facts-two-items
   event: issue_comment
   fixture: gh.issue_comment.visor_help
   env: { ENABLE_FACT_VALIDATION: "true" }
+  routing:
+    max_loops: 1
   mocks:
-    comment-assistant: { text: "We rely on defaults/.visor.yaml for concurrency defaults.", intent: comment_reply }
+    comment-assistant: { text: "We rely on defaults/visor.yaml for concurrency defaults.", intent: comment_reply }
     extract-facts:
       - { id: f1, category: Configuration, claim: "max_parallelism defaults to 4", verifiable: true }
       - { id: f2, category: Feature,       claim: "Fast mode is enabled by default", verifiable: true }
     validate-fact[]:
-      - { fact_id: f1, is_valid: false, confidence: high, evidence: "defaults/.visor.yaml:11", correction: "max_parallelism defaults to 3" }
-      - { fact_id: f2, is_valid: true,  confidence: high, evidence: "src/config.ts:FAST_MODE=true" }
+      - { fact_id: f1, claim: "max_parallelism defaults to 4", is_valid: false, confidence: high, evidence: "defaults/visor.yaml:11", correction: "max_parallelism defaults to 3" }
+      - { fact_id: f2, claim: "Fast mode is enabled by default", is_valid: true,  confidence: high, evidence: "src/config.ts:FAST_MODE=true" }
   expect:
     calls:
-      - step: validate-fact
-        exactly: 2
-    prompts:
       - step: comment-assistant
-        index: last
-        contains: ["max_parallelism defaults to 4", "Correction: max_parallelism defaults to 3"]
-        not_contains: ["Fast mode is enabled by default"]
+        exactly: 2
+      - step: extract-facts
+        exactly: 2
+      - step: validate-fact
+        exactly: 4
+      - step: aggregate
+        exactly: 1
+    outputs:
+      - step: validate-fact
+        where: { path: fact_id, equals: f1 }
+        path: is_valid
+        equals: false
+      - step: validate-fact
+        where: { path: fact_id, equals: f2 }
+        path: is_valid
+        equals: true
 ```
 
 ## 8) GitHub negative mode
@@ -170,3 +193,13 @@ Copy‑pasteable recipes for common scenarios.
       message_contains: "github/op_failed"
 ```
 
+## Related Documentation
+
+- [Getting Started](./getting-started.md) - Introduction to the test framework
+- [DSL Reference](./dsl-reference.md) - Complete test YAML schema
+- [Assertions](./assertions.md) - Available assertion types
+- [Fixtures and Mocks](./fixtures-and-mocks.md) - Managing test data
+- [Flows](./flows.md) - Multi-stage test flows
+- [CLI](./cli.md) - Test runner command line options
+- [CI Integration](./ci.md) - Running tests in CI pipelines
+- [Troubleshooting](./troubleshooting.md) - Common issues and solutions

package/dist/docs/testing/dsl-reference.md

@@ -11,9 +11,17 @@ tests:
     strict: true                # default strict mode
     ai_provider: mock           # force AI provider to mock
     prompt_max_chars: 16000     # truncate captured prompts (optional)
+    ai_include_code_context: false  # include PR diff/context in AI prompts (default: false)
+    fail_on_unexpected_calls: false # fail if unexpected provider calls occur
+    frontends: ["github"]       # enable specific frontends during tests
     github_recorder:            # optional negative modes
       error_code: 0             # e.g., 429
       timeout_ms: 0             # e.g., 1000
+    macros:                     # reusable expect blocks (see Reusable Macros)
+      basic-check:
+        calls:
+          - step: overview
+            at_least: 1
     # Optional: include/exclude checks by tags (same semantics as main CLI)
     tags: "local,fast"         # or [local, fast]
     exclude_tags: "experimental,slow"  # or [experimental, slow]
@@ -24,16 +32,20 @@ tests:
     - name: <string>
       description: <markdown>
       skip: false|true
+      ai_include_code_context: false  # per-case override
 
       # Single-event case
       event: pr_opened | pr_updated | pr_closed | issue_opened | issue_comment | manual
       fixture: <builtin|{ builtin, overrides }>
       env: { <KEY>: <VALUE>, ... }
       mocks: { <step>: <value>, <step>[]: [<value>...] }
+      workflow_input: { <key>: <value>, ... }  # inputs for workflow testing
       expect: <expect-block>
       strict: true|false         # overrides defaults.strict
       tags: "security,fast"     # optional per-case include filter
       exclude_tags: "slow"      # optional per-case exclude filter
+      github_recorder:           # per-case recorder overrides
+        error_code: 429
 
       # OR flow case
       flow:
@@ -42,23 +54,31 @@ tests:
           fixture: ...
           env: ...
           mocks: ...             # merged with flow-level mocks
+          routing:               # per-stage routing overrides
+            max_loops: 10
           expect: <expect-block>
           strict: true|false     # per-stage fallback to case/defaults
           tags: "security"       # optional per-stage include filter
           exclude_tags: "slow"   # optional per-stage exclude filter
+          github_recorder:       # per-stage recorder overrides
+            error_code: 500
 ```
 
 ## Fixtures
 
-- Built-in GitHub fixtures: `gh.pr_open.minimal`, `gh.pr_sync.minimal`, `gh.issue_open.minimal`, `gh.issue_comment.standard`, `gh.issue_comment.visor_help`, `gh.issue_comment.visor_regenerate`.
+- Built-in GitHub fixtures: `gh.pr_open.minimal`, `gh.pr_sync.minimal`, `gh.pr_closed.minimal`, `gh.issue_open.minimal`, `gh.issue_comment.standard`, `gh.issue_comment.visor_help`, `gh.issue_comment.visor_regenerate`.
 - Use `overrides` to tweak titles, numbers, payload slices.
 
+See [Fixtures and Mocks](./fixtures-and-mocks.md) for details.
+
 ## Mocks
 
 - Keys are step names; for forEach children use `step[]` (e.g., `validate-fact[]`).
 - AI mocks may be structured JSON if a schema is configured for the step; otherwise use `text` and optional fields used by templates.
 - Command/HTTP mocks emulate provider shape (`stdout`, `exit_code`, or HTTP body/status headers) and bypass real execution.
 
+See [Fixtures and Mocks](./fixtures-and-mocks.md) for detailed mock examples.
+
 Inline example (AI with schema + list mocks):
 
 ```yaml
@@ -78,13 +98,20 @@ mocks:
 
 ```yaml
 expect:
+  use: [macro-name]           # reference macros from tests.defaults.macros
+
   calls:
-    - step: <name> | provider: github + op: <rest.op>
+    - step: <name>
+      exactly|at_least|at_most: <number>
+    - provider: github|slack   # provider-level calls
+      op: <rest.op>            # e.g., labels.add, chat.postMessage
       exactly|at_least|at_most: <number>
-      args: { contains: [..], not_contains: [..] }   # provider args matching
+      args: { contains: [..] }   # provider args matching
 
   no_calls:
-    - step: <name> | provider: github + op: <rest.op>
+    - step: <name>
+    - provider: github|slack
+      op: <rest.op>
 
   prompts:
     - step: <name>
@@ -97,7 +124,7 @@ expect:
 
   outputs:
     - step: <name>
-      index: first|last|<N>     # or
+      index: first|last|<N>
       where: { path: <expr>, equals|matches: <v> }
       path: <expr>              # dot/bracket, e.g. tags['review-effort']
       equals: <primitive>
@@ -105,12 +132,29 @@ expect:
       matches: <regex>
       contains_unordered: [..]
 
+  workflow_output:              # assert on workflow-level outputs (for workflow testing)
+    - path: <output-name>       # path into workflow outputs object
+      equals: <primitive>
+      equalsDeep: <object>
+      matches: <regex>
+      contains: <string|[..]>   # substring check
+      not_contains: <string|[..]>
+      contains_unordered: [..]
+      where: { path: <expr>, equals|matches: <v> }
+
   fail:
     message_contains: <string>  # assert overall case failure message
 
   strict_violation:             # assert strict failure for a missing expect on a step
     for_step: <name>
     message_contains: <string>
+```
+
+**Supported providers for `calls` and `no_calls`:**
+- `github`: GitHub API operations (`labels.add`, `issues.createComment`, `pulls.createReview`, `checks.create`, `checks.update`)
+- `slack`: Slack API operations (`chat.postMessage`)
+
+See [Assertions](./assertions.md) for detailed assertion syntax and examples.
 
 Inline example (calls + prompts + outputs):
 
@@ -131,7 +175,6 @@ expect:
       path: "tags['review-effort']"
       equals: 2
 ```
-```
 
 Note on dependencies: test execution honors your base config routing, including `depends_on`. You can express ANY‑OF groups using pipe syntax in the base config (e.g., `depends_on: ["issue-assistant|comment-assistant"]`). The runner mixes these with normal ALL‑OF deps.
 
@@ -152,6 +195,63 @@ Note on dependencies: test execution honors your base config routing, including
 - Run one case: `visor test --only label-flow`
 - Run one stage: `visor test --only pr-review-e2e-flow#facts-invalid`
 - JSON/JUnit/Markdown reporters: `--json`, `--report junit:<path>`, `--summary md:<path>`
+
+See [CLI Reference](./cli.md) for all available options.
+
+## Reusable Macros
+
+Define reusable assertion blocks in `tests.defaults.macros` and reference them with `use`:
+
+```yaml
+tests:
+  defaults:
+    macros:
+      basic-github-check:
+        calls:
+          - provider: github
+            op: checks.create
+            at_least: 1
+      overview-ran:
+        calls:
+          - step: overview
+            exactly: 1
+
+  cases:
+    - name: my-test
+      event: pr_opened
+      expect:
+        use: [basic-github-check, overview-ran]
+        calls:
+          - step: extra-step
+            exactly: 1
+```
+
+Macros are merged with inline expectations, allowing you to compose reusable assertion patterns.
+
+## Workflow Testing
+
+Test standalone workflows by providing `workflow_input` and asserting on `workflow_output`:
+
+```yaml
+tests:
+  cases:
+    - name: test-workflow
+      event: manual
+      workflow_input:
+        repo_url: "https://github.com/example/repo"
+        branch: "main"
+      mocks:
+        fetch-data:
+          status: 200
+          data: { items: [1, 2, 3] }
+      expect:
+        workflow_output:
+          - path: summary
+            contains: "completed"
+          - path: items_count
+            equals: 3
+```
+
 ## JavaScript in Tests and Routing (run_js, goto_js, value_js, transform_js)
 
 ### Tags default semantics in tests
@@ -184,8 +284,9 @@ Tips
 - Use `Array.prototype.at(-1)` to read the last item. Example: `const last = (outputs_history['validate-fact'] || []).at(-1) || [];`.
 - For reshaping small maps, `Object.entries` + `Object.fromEntries` is concise and readable.
 
-Example: wave‑scoped correction gate
-```
+Example: wave-scoped correction gate
+
+```yaml
 run_js: |
   const facts = (outputs_history['extract-facts'] || []).at(-1) || [];
   const ids = facts.map(f => String(f.id || '')).filter(Boolean);
@@ -196,4 +297,4 @@ run_js: |
   return (event && event.name) === 'issue_opened' ? ['issue-assistant'] : ['comment-assistant'];
 ```
 
-This evaluates the last `extract-facts` wave, finds the corresponding `validate-fact` results, and schedules a single correction pass when any item is invalid or low‑confidence.
+This evaluates the last `extract-facts` wave, finds the corresponding `validate-fact` results, and schedules a single correction pass when any item is invalid or low-confidence.

package/dist/docs/testing/fixtures-and-mocks.md

@@ -13,6 +13,7 @@ Use via `fixture: gh.<name>` or `fixture: { builtin: gh.<name>, overrides: {...}
 - `gh.issue_comment.standard` — normal human comment on a PR/issue.
 - `gh.issue_comment.visor_help` — comment containing `/visor help`.
 - `gh.issue_comment.visor_regenerate` — `/visor Regenerate reviews`.
+- `gh.issue_comment.edited` — issue_comment edited action.
 
 Overrides allow tailored inputs:
 
@@ -57,7 +58,7 @@ mocks:
 
   # AI plain text schema
   comment-assistant:
-    text: "Sure, here’s how I can help."
+    text: "Sure, here's how I can help."
     intent: comment_reply
 
   # Array outputs (e.g., extract-facts)
@@ -68,8 +69,9 @@ mocks:
   unit-tests:
     stdout: '{"passed": 128, "failed": 0}'
     exit_code: 0
+```
 
-### Per‑call list mocks (for forEach children)
+### Per-call list mocks (for forEach children)
 
 When a step runs once per item (e.g., `validate-fact` depends on `extract-facts`), provide a list under the `[]` suffix:
 
@@ -83,9 +85,32 @@ mocks:
     - { fact_id: f2, is_valid: true,  confidence: high, evidence: "src/config.ts:FAST_MODE=true" }
 ```
 
-The runner distributes items in order; if the list is shorter than invocations, the last entry is reused. This fits any forEach‑style step you define (naming is up to you).
+The runner distributes items in order; if the list is shorter than invocations, the last entry is reused. This fits any forEach-style step you define (naming is up to you).
+
+### HTTP client mocks
+
+For `http-client` provider steps, mocks can specify HTTP response fields:
+
+```yaml
+mocks:
+  fetch-api-data:
+    status: 200
+    body: '{"items": [1, 2, 3]}'
+    headers:
+      content-type: application/json
 ```
 
 Notes:
 - No `returns:` key; provide values directly.
 - For HTTP/Command providers, mocks bypass real execution and are recorded for assertions.
+
+## Related Documentation
+
+- [Getting Started](./getting-started.md) - Introduction to the test framework
+- [DSL Reference](./dsl-reference.md) - Complete test YAML schema
+- [Assertions](./assertions.md) - Available assertion types
+- [Flows](./flows.md) - Multi-stage test flows
+- [Cookbook](./cookbook.md) - Copy-pasteable test recipes
+- [CLI](./cli.md) - Test runner command line options
+- [CI Integration](./ci.md) - Running tests in CI pipelines
+- [Troubleshooting](./troubleshooting.md) - Common issues and solutions

package/dist/docs/testing/flows.md

@@ -2,7 +2,7 @@
 
 > Model realistic user journeys across multiple external events in one case.
 
-A flow case defines a `flow:` array of stages. Each stage has its own `event`, `fixture`, optional `env` and `mocks`, plus `expect`.
+A flow case defines a `flow:` array of stages. Each stage has its own `event`, `fixture`, and optional settings like `env`, `mocks`, `routing`, `tags`, `github_recorder`, plus `expect`.
 
 ```yaml
 - name: pr-review-e2e-flow
@@ -35,8 +35,9 @@ A flow case defines a `flow:` array of stages. Each stage has its own `event`, `
 
 ## Stage selection and deltas
 
-- Run a single stage: `--only case#stage` (name substring) or `--only case#N` (1‑based index).
-- Coverage, prompts, outputs, and provider calls are computed per‑stage as deltas from the previous stage.
+- Run a single stage: `--only case#stage` (name substring match, case-insensitive) or `--only case#N` (1-based index).
+  - Examples: `--only pr-review-e2e-flow#facts-invalid`, `--only pr-review-e2e-flow#3`
+- Coverage, prompts, outputs, and provider calls are computed per-stage as deltas from the previous stage.
 - The same engine instance is reused across stages, so memory and output history carry over.
 
 ## Ordering and `on_finish`
@@ -81,12 +82,66 @@ flow:
           contains: ["<previous_response>", "Correction:"]
 ```
 
-## Stage-local mocks and env
+## Stage-local configuration
+
+### Mocks and env
 
 - Stage mocks override flow-level defaults: the runner merges `{...flow.mocks, ...stage.mocks}`.
 - `env:` applies only for the stage and is restored afterward.
 
+### Routing overrides
+
+Per-stage routing settings override the base config for that stage only:
+
+```yaml
+flow:
+  - name: correction-loop
+    event: issue_comment
+    routing:
+      max_loops: 10    # allow more iterations for this stage
+    # ...
+```
+
+### Tag filtering
+
+Tags can be specified at flow-level and/or per-stage. They are merged with suite defaults:
+
+```yaml
+- name: my-flow
+  tags: "github"          # flow-level include filter
+  exclude_tags: "slow"    # flow-level exclude filter
+  flow:
+    - name: stage-one
+      tags: "security"    # additional per-stage filter
+      # ...
+```
+
+### GitHub recorder overrides
+
+Simulate GitHub API errors or timeouts per-stage:
+
+```yaml
+flow:
+  - name: api-error-stage
+    event: pr_opened
+    github_recorder:
+      error_code: 429     # simulate rate limit
+    # ...
+```
+
 ## Debugging flows
 
 - Set `VISOR_DEBUG=true` to print stage headers, selected checks, and internal debug lines from the engine.
 - To reduce noise, limit the run to a stage: `VISOR_DEBUG=true visor test --only pr-review-e2e-flow#facts-invalid`.
+- Use the CLI `--debug` flag as a shorthand: `visor test --debug --only case#stage`.
+
+## Related Documentation
+
+- [Getting Started](./getting-started.md) - Introduction to the test framework
+- [DSL Reference](./dsl-reference.md) - Complete test YAML schema
+- [Assertions](./assertions.md) - Available assertion types
+- [Fixtures and Mocks](./fixtures-and-mocks.md) - Managing test data
+- [Cookbook](./cookbook.md) - Copy-pasteable test recipes
+- [CLI](./cli.md) - Test runner command line options
+- [CI Integration](./ci.md) - Running tests in CI pipelines
+- [Troubleshooting](./troubleshooting.md) - Common issues and solutions

package/dist/docs/testing/getting-started.md

@@ -4,10 +4,10 @@ This is the developer-facing guide for writing and running integration tests for
 
 ## TL;DR
 
-- Put your tests in `defaults/.visor.tests.yaml`.
+- Put your tests in `defaults/visor.tests.yaml`.
 - Reference your base config with `extends: ".visor.yaml"`.
 - Use built-in GitHub fixtures like `gh.pr_open.minimal`.
-- Run with `visor test --config defaults/.visor.tests.yaml`.
+- Run with `visor test --config defaults/visor.tests.yaml`.
 - Validate only with `visor test --validate`.
 
 ```yaml
@@ -78,16 +78,17 @@ Run `visor test --validate` to get precise YAML-path errors and suggestions:
 ```
 ❌ Tests file has 2 error(s):
    • tests.cases[0].expext: must NOT have additional properties (Did you mean "expect"?)
-   • tests.cases[3].event: must be equal to one of the allowed values (allowed: manual, pr_opened, pr_updated, pr_closed, issue_opened, issue_comment)
+   • tests.cases[3].event: must be equal to one of the allowed values (allowed: manual, pr_opened, pr_updated, pr_closed, issue_opened, issue_comment, schedule, webhook_received)
 ```
 
-Next steps:
-- Core reference: `docs/testing/dsl-reference.md`
-- Flows: `docs/testing/flows.md`
-- Mocks & fixtures: `docs/testing/fixtures-and-mocks.md`
-- Assertions: `docs/testing/assertions.md`
-- Cookbook: `docs/testing/cookbook.md`
-- CLI & reporters: `docs/testing/cli.md`
-- CI integration: `docs/testing/ci.md`
-- Troubleshooting: `docs/testing/troubleshooting.md`
-- Browse `defaults/.visor.tests.yaml` for full examples.
+## Next Steps
+
+- [DSL Reference](./dsl-reference.md) - Complete test YAML schema
+- [Flows](./flows.md) - Multi-stage test flows
+- [Fixtures and Mocks](./fixtures-and-mocks.md) - Managing test data
+- [Assertions](./assertions.md) - Available assertion types
+- [Cookbook](./cookbook.md) - Common patterns and recipes
+- [CLI and Reporters](./cli.md) - Command-line options and output formats
+- [CI Integration](./ci.md) - Running tests in CI pipelines
+- [Troubleshooting](./troubleshooting.md) - Common issues and solutions
+- Browse `defaults/visor.tests.yaml` for full examples.