project-tiny-context-harness 0.7.5 → 0.7.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -21
- package/README.md +353 -345
- package/assets/README.md +537 -529
- package/assets/README.zh-CN.md +301 -293
- package/assets/agents/.gitkeep +1 -1
- package/assets/agents/AGENTS_CORE.md +52 -52
- package/assets/context_templates/architecture.md +33 -33
- package/assets/context_templates/area.md +39 -39
- package/assets/context_templates/context.toml +30 -30
- package/assets/context_templates/deployment.md +35 -35
- package/assets/context_templates/global.md +51 -51
- package/assets/context_templates/product-surface-contract.md +58 -58
- package/assets/context_templates/verification.md +32 -32
- package/assets/github/.gitkeep +1 -1
- package/assets/github/harness.yml +41 -41
- package/assets/make/.gitkeep +1 -1
- package/assets/make/ty-context.mk +48 -48
- package/assets/skills/context_development_engineer/SKILL.md +89 -89
- package/assets/skills/context_full_project_export/SKILL.md +70 -70
- package/assets/skills/context_harness_upgrade/SKILL.md +60 -60
- package/assets/skills/context_product_plan/SKILL.md +74 -74
- package/assets/skills/context_surface_contract/SKILL.md +165 -165
- package/assets/skills/context_uiux_design/SKILL.md +92 -92
- package/assets/skills/design-resource-authoring/SKILL.md +68 -0
- package/assets/skills/design-resource-authoring/references/downstream-handoff.md +138 -0
- package/assets/skills/design-resource-authoring/references/open-design-provider.md +112 -0
- package/assets/skills/design-resource-authoring/references/resource-selection.md +166 -0
- package/assets/skills/long-task-workflow/SKILL.md +82 -81
- package/assets/skills/long-task-workflow/agents/openai.yaml +4 -4
- package/assets/skills/long-task-workflow/references/authority-lifecycle.md +56 -56
- package/assets/skills/long-task-workflow/references/contract-authoring.md +88 -88
- package/assets/skills/long-task-workflow/references/evidence-design.md +69 -69
- package/assets/skills/normal-long-task/SKILL.md +12 -12
- package/assets/skills/source-plan-authoring/SKILL.md +291 -291
- package/dist/lib/profiles.js +1 -0
- package/migrations/README.md +15 -15
- package/package.json +1 -1
- package/source-mappings.yaml +25 -25
|
@@ -1,75 +1,75 @@
|
|
|
1
|
-
# Evidence Design Reference
|
|
2
|
-
|
|
3
|
-
Read this only while designing or repairing Contract Checks and proof.
|
|
4
|
-
|
|
5
|
-
## General Proof Rules
|
|
6
|
-
|
|
7
|
-
- Every Outcome has at least one executable Check and one non-Result atomic Claim.
|
|
8
|
-
- Required proof surfaces are non-empty, unique and all-of. Claim-bearing Assertions use explicit comparable Observations and expected values.
|
|
9
|
-
- `truthy`/`falsy` are diagnostic-only. `exists` proves only implementation-structure obligations. Missing or type-incomparable Observation never proves a Claim; negative proof uses an explicit value such as `equals: false`.
|
|
10
|
-
- Claim and Population proof is emitted only after the entire Check passes. Exit failure, missing artifact, failed population, failed Assertion or invalid Counterfactual yields no Claim proof.
|
|
11
|
-
- Verification inputs include entrypoints, helpers, fixtures/config, package scripts and lockfiles and cannot overlap implementation carriers.
|
|
12
|
-
- Runners receive the minimum environment whitelist plus only declared environment requirements. Never expose actual secret values in findings.
|
|
13
|
-
|
|
14
|
-
## Runner And Observation Identity
|
|
15
|
-
|
|
16
|
-
Evidence adapter is derived from runner kind. Only Playwright may prove `ui_browser`; structured runners prove non-browser surfaces. Raw Execution identity binds frozen runner identity and canonical declared Environment Requirements, not actual values.
|
|
17
|
-
|
|
18
|
-
Across all Checks sharing a Raw Execution, one Claim-bearing Observation belongs to one Assertion. Shared setup may execute once only when independent per-Check observations and artifacts remain unambiguous.
|
|
19
|
-
|
|
20
|
-
## Scenario And Evidence Capabilities
|
|
21
|
-
|
|
22
|
-
- Every Check declares non-empty keyed `scenario.given` and `scenario.when` steps. One Check covers one materially coherent journey; a different success path belongs in another Check or vertical Outcome.
|
|
23
|
-
- Every Assertion declares a non-empty all-of `evidence_capabilities` set. `presence` proves static existence only and cannot alone prove a behavioral Claim. Each other capability requires exactly one typed current-execution record bound to the declared Assertion key; missing, duplicate, unknown or undeclared records fail closed.
|
|
24
|
-
- `interaction_trace` names the exact target plus the declared Given keys and ordered action keys. Playwright derives it only from an executed declared AC carrying matching `[given:<key>]` and `[action:<key>]` steps; `[ac:<assertion-key>]` remains the AC binding.
|
|
25
|
-
- `state_delta` requires different before/after hashes and named changed fields. `durable_readback` requires independent write/read sessions with equal state hashes. `cross_surface_consistency` requires at least two distinct surface refs, known target refs and one state hash.
|
|
26
|
-
- `boundary_invocation` and `external_side_effect` require the Check itself to execute on the named observer target. `failure_injection` requires an observed fault and recovery state; `visual_render` binds a declared artifact hash; `target_runtime` binds exact target/root/current session and requires a cold start for a root journey; `input_variation` requires at least two distinct inputs, differing propagated outputs and an observed failure case.
|
|
27
|
-
- Structured runners emit `long-task-check-result-v3` for capability records. V2 payloads remain decodable only for presence-only compatibility; they cannot satisfy a declared non-presence capability. Evidence records contain bounded hashes/ids/refs, not unrestricted raw payloads.
|
|
28
|
-
|
|
29
|
-
## Live Target Runtime Evidence
|
|
30
|
-
|
|
31
|
-
- For a target-runtime Claim, the accepting Check must exercise the exact declared required target during the current runner invocation and derive structured Observations from the same runtime session. Browser target runtime is proved only by Playwright; Native/Desktop target runtime is proved only by the project binary. Rerunning a parser for a tracked or generated status report reruns the parser, not the target.
|
|
32
|
-
- A proxy surface may prove its own Claim but cannot substitute when proxy and target can fail independently. Static source/config shape proves structure only. The existence of a build, installation, started process or clean fatal-error scan proves only those exact assertions.
|
|
33
|
-
- If the declared result includes a runnable product surface or interaction, observe a stable product-owned sentinel or the declared interaction in the target session. A generic process/activity/window, development shell or absence of errors is insufficient for that broader Claim.
|
|
34
|
-
- Historical reports, screenshots, binaries and logs are review material. Current-run screenshots/logs may accompany a Check as Artifacts, but the accepting Observation must come from the live runner execution and cannot be imported from historical state.
|
|
35
|
-
- Bind every runtime-affecting implementation surface through `input_paths` and relevant Binding carriers; keep runner/helper/config files in `verification_inputs`. This lets existing Progress freshness identify when rolling feedback is stale without a new trigger registry.
|
|
36
|
-
|
|
37
|
-
## Causal Boundary Review After Revision
|
|
38
|
-
|
|
39
|
-
- When a rolling blocker causes a semantic or proof revision, review only the affected weak-observability or high-risk Outcomes before adoption. Ask whether a cheaper proxy, fixed response or self-reported success could pass while the declared result still fails at a farther independent boundary.
|
|
40
|
-
- Evidence must reach the furthest independently failing boundary named by the Claim. A proxy may prove its own result, but it cannot prove a downstream state or effect merely by reporting success.
|
|
41
|
-
- For a behavioral Claim, prefer a Counterfactual that disrupts the claimed causal capability when removing a carrier would prove only file dependence. `replace_file` may supply a declared inert/failing implementation fixture; `remove_paths` remains valid when carrier existence is itself the claimed boundary.
|
|
42
|
-
- Keep this risk-proportional and internal. Do not create an evidence matrix, product-effect taxonomy, universal restart/end-to-end suite, new mutation type or persistent review state.
|
|
43
|
-
|
|
44
|
-
For semantic Product Conformance, require one separate read-only Global `conformance` Check only when `weak_observability` combines with multiple Stages or multiple required product runtime families. It starts from a required root product target, includes `target_runtime`, uses a Raw Execution identity independent of Outcome Checks and runs inside the existing Final Gate. Single-Stage/single-family weak work keeps the existing same-Check sensitivity path and does not pay this extra runtime cost.
|
|
45
|
-
|
|
46
|
-
## Playwright
|
|
47
|
-
|
|
48
|
-
Claim-bearing Playwright proof is only `playwright.case.<ac-key>.passed equals true`. `[ac:<assertion-key>]` binds one declared AC per Test Instance; ordinary tags are ignored and legacy `[<key>]` binds only a declared key.
|
|
49
|
-
|
|
50
|
-
Missing, skipped, flaky, unexpected, timed-out, interrupted, failed, multi-AC and duplicate-within-project cases fail closed. The same AC across distinct projects aggregates all-of. Aggregate status/count fields are diagnostic-only.
|
|
51
|
-
|
|
52
|
-
Standard frozen Playwright verifier content is trusted. Weak-observability Outcomes require same-Check AC/Claim sensitivity. A weak Playwright Counterfactual may accept exit one only when every unexpected instance is uniquely a designated executed AC failure and there are no root, unbound, extra, missing, skipped, flaky, timeout, interruption, artifact, population, environment or other evidence failures. Ordinary Baseline Checks require exit zero.
|
|
53
|
-
|
|
1
|
+
# Evidence Design Reference
|
|
2
|
+
|
|
3
|
+
Read this only while designing or repairing Contract Checks and proof.
|
|
4
|
+
|
|
5
|
+
## General Proof Rules
|
|
6
|
+
|
|
7
|
+
- Every Outcome has at least one executable Check and one non-Result atomic Claim.
|
|
8
|
+
- Required proof surfaces are non-empty, unique and all-of. Claim-bearing Assertions use explicit comparable Observations and expected values.
|
|
9
|
+
- `truthy`/`falsy` are diagnostic-only. `exists` proves only implementation-structure obligations. Missing or type-incomparable Observation never proves a Claim; negative proof uses an explicit value such as `equals: false`.
|
|
10
|
+
- Claim and Population proof is emitted only after the entire Check passes. Exit failure, missing artifact, failed population, failed Assertion or invalid Counterfactual yields no Claim proof.
|
|
11
|
+
- Verification inputs include entrypoints, helpers, fixtures/config, package scripts and lockfiles and cannot overlap implementation carriers.
|
|
12
|
+
- Runners receive the minimum environment whitelist plus only declared environment requirements. Never expose actual secret values in findings.
|
|
13
|
+
|
|
14
|
+
## Runner And Observation Identity
|
|
15
|
+
|
|
16
|
+
Evidence adapter is derived from runner kind. Only Playwright may prove `ui_browser`; structured runners prove non-browser surfaces. Raw Execution identity binds frozen runner identity and canonical declared Environment Requirements, not actual values.
|
|
17
|
+
|
|
18
|
+
Across all Checks sharing a Raw Execution, one Claim-bearing Observation belongs to one Assertion. Shared setup may execute once only when independent per-Check observations and artifacts remain unambiguous.
|
|
19
|
+
|
|
20
|
+
## Scenario And Evidence Capabilities
|
|
21
|
+
|
|
22
|
+
- Every Check declares non-empty keyed `scenario.given` and `scenario.when` steps. One Check covers one materially coherent journey; a different success path belongs in another Check or vertical Outcome.
|
|
23
|
+
- Every Assertion declares a non-empty all-of `evidence_capabilities` set. `presence` proves static existence only and cannot alone prove a behavioral Claim. Each other capability requires exactly one typed current-execution record bound to the declared Assertion key; missing, duplicate, unknown or undeclared records fail closed.
|
|
24
|
+
- `interaction_trace` names the exact target plus the declared Given keys and ordered action keys. Playwright derives it only from an executed declared AC carrying matching `[given:<key>]` and `[action:<key>]` steps; `[ac:<assertion-key>]` remains the AC binding.
|
|
25
|
+
- `state_delta` requires different before/after hashes and named changed fields. `durable_readback` requires independent write/read sessions with equal state hashes. `cross_surface_consistency` requires at least two distinct surface refs, known target refs and one state hash.
|
|
26
|
+
- `boundary_invocation` and `external_side_effect` require the Check itself to execute on the named observer target. `failure_injection` requires an observed fault and recovery state; `visual_render` binds a declared artifact hash; `target_runtime` binds exact target/root/current session and requires a cold start for a root journey; `input_variation` requires at least two distinct inputs, differing propagated outputs and an observed failure case.
|
|
27
|
+
- Structured runners emit `long-task-check-result-v3` for capability records. V2 payloads remain decodable only for presence-only compatibility; they cannot satisfy a declared non-presence capability. Evidence records contain bounded hashes/ids/refs, not unrestricted raw payloads.
|
|
28
|
+
|
|
29
|
+
## Live Target Runtime Evidence
|
|
30
|
+
|
|
31
|
+
- For a target-runtime Claim, the accepting Check must exercise the exact declared required target during the current runner invocation and derive structured Observations from the same runtime session. Browser target runtime is proved only by Playwright; Native/Desktop target runtime is proved only by the project binary. Rerunning a parser for a tracked or generated status report reruns the parser, not the target.
|
|
32
|
+
- A proxy surface may prove its own Claim but cannot substitute when proxy and target can fail independently. Static source/config shape proves structure only. The existence of a build, installation, started process or clean fatal-error scan proves only those exact assertions.
|
|
33
|
+
- If the declared result includes a runnable product surface or interaction, observe a stable product-owned sentinel or the declared interaction in the target session. A generic process/activity/window, development shell or absence of errors is insufficient for that broader Claim.
|
|
34
|
+
- Historical reports, screenshots, binaries and logs are review material. Current-run screenshots/logs may accompany a Check as Artifacts, but the accepting Observation must come from the live runner execution and cannot be imported from historical state.
|
|
35
|
+
- Bind every runtime-affecting implementation surface through `input_paths` and relevant Binding carriers; keep runner/helper/config files in `verification_inputs`. This lets existing Progress freshness identify when rolling feedback is stale without a new trigger registry.
|
|
36
|
+
|
|
37
|
+
## Causal Boundary Review After Revision
|
|
38
|
+
|
|
39
|
+
- When a rolling blocker causes a semantic or proof revision, review only the affected weak-observability or high-risk Outcomes before adoption. Ask whether a cheaper proxy, fixed response or self-reported success could pass while the declared result still fails at a farther independent boundary.
|
|
40
|
+
- Evidence must reach the furthest independently failing boundary named by the Claim. A proxy may prove its own result, but it cannot prove a downstream state or effect merely by reporting success.
|
|
41
|
+
- For a behavioral Claim, prefer a Counterfactual that disrupts the claimed causal capability when removing a carrier would prove only file dependence. `replace_file` may supply a declared inert/failing implementation fixture; `remove_paths` remains valid when carrier existence is itself the claimed boundary.
|
|
42
|
+
- Keep this risk-proportional and internal. Do not create an evidence matrix, product-effect taxonomy, universal restart/end-to-end suite, new mutation type or persistent review state.
|
|
43
|
+
|
|
44
|
+
For semantic Product Conformance, require one separate read-only Global `conformance` Check only when `weak_observability` combines with multiple Stages or multiple required product runtime families. It starts from a required root product target, includes `target_runtime`, uses a Raw Execution identity independent of Outcome Checks and runs inside the existing Final Gate. Single-Stage/single-family weak work keeps the existing same-Check sensitivity path and does not pay this extra runtime cost.
|
|
45
|
+
|
|
46
|
+
## Playwright
|
|
47
|
+
|
|
48
|
+
Claim-bearing Playwright proof is only `playwright.case.<ac-key>.passed equals true`. `[ac:<assertion-key>]` binds one declared AC per Test Instance; ordinary tags are ignored and legacy `[<key>]` binds only a declared key.
|
|
49
|
+
|
|
50
|
+
Missing, skipped, flaky, unexpected, timed-out, interrupted, failed, multi-AC and duplicate-within-project cases fail closed. The same AC across distinct projects aggregates all-of. Aggregate status/count fields are diagnostic-only.
|
|
51
|
+
|
|
52
|
+
Standard frozen Playwright verifier content is trusted. Weak-observability Outcomes require same-Check AC/Claim sensitivity. A weak Playwright Counterfactual may accept exit one only when every unexpected instance is uniquely a designated executed AC failure and there are no root, unbound, extra, missing, skipped, flaky, timeout, interruption, artifact, population, environment or other evidence failures. Ordinary Baseline Checks require exit zero.
|
|
53
|
+
|
|
54
54
|
## Visual UI Evidence
|
|
55
55
|
|
|
56
56
|
- When external design resources are Source, prove only selected exact-target/constraint conditions that the Contract explicitly adopts. Candidate comparison, a Figma link or an isolated prototype run is authoring/review material and cannot become product acceptance. Resolve each acceptance-affecting resource through a stable locator plus immutable path/version/hash and declared condition coverage before Compile.
|
|
57
57
|
- Use Playwright for every declared `ui_browser` visual AC and bind each independently falsifiable AC to its own `[ac:<assertion-key>]` Test Instance. A broad screenshot or one passing page case does not silently prove separate viewport, theme, state, content-stress, layout or accessibility claims.
|
|
58
|
-
- Make the test environment deterministic enough for its claim: freeze the relevant browser/project, viewport, theme/mode, locale/timezone, font loading, fixtures/data and animation/motion policy in declared verifier inputs or configuration.
|
|
59
|
-
- Any reviewed screenshot baseline that affects pass/fail must exist for the accepting Compile and be included in `verification_inputs`. Generated screenshots, diffs and reports are Artifacts and review material; they are not editable acceptance authority. Creating or replacing a baseline after Authority Lock is verifier-material revision and must never be silently auto-updated to make a failure pass.
|
|
60
|
-
- Confirm that each baseline is a selected `exact-target` for the named surface/viewport/theme/state or implements a named `constraint`; an inspiration reference cannot become a fidelity oracle merely because it is available. The implementation's current screenshot is never its own target.
|
|
58
|
+
- Make the test environment deterministic enough for its claim: freeze the relevant browser/project, viewport, theme/mode, locale/timezone, font loading, fixtures/data and animation/motion policy in declared verifier inputs or configuration.
|
|
59
|
+
- Any reviewed screenshot baseline that affects pass/fail must exist for the accepting Compile and be included in `verification_inputs`. Generated screenshots, diffs and reports are Artifacts and review material; they are not editable acceptance authority. Creating or replacing a baseline after Authority Lock is verifier-material revision and must never be silently auto-updated to make a failure pass.
|
|
60
|
+
- Confirm that each baseline is a selected `exact-target` for the named surface/viewport/theme/state or implements a named `constraint`; an inspiration reference cannot become a fidelity oracle merely because it is available. The implementation's current screenshot is never its own target.
|
|
61
61
|
- Screenshot comparison proves only the named visual similarity claim. Pair it with explicit DOM/layout/accessibility assertions when the Contract separately claims no overflow, action visibility, focus behavior, target size, semantic state, reduced motion or other observable behavior.
|
|
62
62
|
- Keep evidence aligned with stable surface/control/target keys. Visual similarity, interaction/navigation, validation/recovery, permission behavior, accessibility and target-runtime conformance are independently failing claims and need their own Assertions/capabilities when declared; one broad screenshot or UI pass cannot prove all Control fields.
|
|
63
|
-
- Run checks against production components or real product routes. A detached kit/mock harness is acceptable only when the Contract explicitly makes that artifact the product surface; otherwise it cannot substitute for the production carrier.
|
|
64
|
-
- Keep subjective visual quality and approval external. A new visual direction or baseline that needs human judgment remains an explicit external confirmation even when all machine checks pass.
|
|
65
|
-
- `ui_browser` proves browser UI only. When a native/mobile/desktop UI can fail independently, browser output is proxy evidence; require a project-owned live target-runtime Check that truthfully fits an existing proof surface or keep the device/simulator review external.
|
|
66
|
-
|
|
67
|
-
## Structured Evidence And Sensitivity
|
|
68
|
-
|
|
69
|
-
Every claim-bearing `structured_json_v2` Check needs same-Check Claim-related Counterfactual sensitivity unless the Claim is covered by that same Check's Population proof; weak observability removes that Population exemption. Artifacts and another Check never substitute for sensitivity.
|
|
70
|
-
|
|
71
|
-
Outcome Counterfactual V2 names an Outcome `binding_key`; Global Counterfactual V2 resolves an Outcome-owned `binding_ref`. A Counterfactual mutates only a proven subset of implementation carriers, never Source, Context, runners or verification inputs, and accepts only designated `assertion_value_mismatch` findings.
|
|
72
|
-
|
|
73
|
-
An `existing` mutation target must exist at Preflight/Compile. A `planned` target may be absent until implementation but must exist at Final Gate; once created, its changes stale targeted Progress. Population V2 proves exact eligible = observed + valid exclusions by entity id.
|
|
74
|
-
|
|
75
|
-
Artifacts remain review material. They do not prove Claim sensitivity by themselves.
|
|
63
|
+
- Run checks against production components or real product routes. A detached kit/mock harness is acceptable only when the Contract explicitly makes that artifact the product surface; otherwise it cannot substitute for the production carrier.
|
|
64
|
+
- Keep subjective visual quality and approval external. A new visual direction or baseline that needs human judgment remains an explicit external confirmation even when all machine checks pass.
|
|
65
|
+
- `ui_browser` proves browser UI only. When a native/mobile/desktop UI can fail independently, browser output is proxy evidence; require a project-owned live target-runtime Check that truthfully fits an existing proof surface or keep the device/simulator review external.
|
|
66
|
+
|
|
67
|
+
## Structured Evidence And Sensitivity
|
|
68
|
+
|
|
69
|
+
Every claim-bearing `structured_json_v2` Check needs same-Check Claim-related Counterfactual sensitivity unless the Claim is covered by that same Check's Population proof; weak observability removes that Population exemption. Artifacts and another Check never substitute for sensitivity.
|
|
70
|
+
|
|
71
|
+
Outcome Counterfactual V2 names an Outcome `binding_key`; Global Counterfactual V2 resolves an Outcome-owned `binding_ref`. A Counterfactual mutates only a proven subset of implementation carriers, never Source, Context, runners or verification inputs, and accepts only designated `assertion_value_mismatch` findings.
|
|
72
|
+
|
|
73
|
+
An `existing` mutation target must exist at Preflight/Compile. A `planned` target may be absent until implementation but must exist at Final Gate; once created, its changes stale targeted Progress. Population V2 proves exact eligible = observed + valid exclusions by entity id.
|
|
74
|
+
|
|
75
|
+
Artifacts remain review material. They do not prove Claim sensitivity by themselves.
|
|
@@ -1,12 +1,12 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: normal-long-task
|
|
3
|
-
description: Retired compatibility pointer for users who explicitly invoke /normal-long-task. Direct them to /long-task-workflow and do not create legacy checklist, prompt, audit, matrix, verdict, or plan artifacts.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Retired: Normal Long Task
|
|
7
|
-
|
|
8
|
-
`/normal-long-task` no longer defines a second long-task artifact workflow.
|
|
9
|
-
|
|
10
|
-
Use `/long-task-workflow` for one Canonical Delivery Contract, the current platform-native Goal, rolling implementation in the current workspace, targeted repair verification, a same-snapshot Final Gate and Stop freshness.
|
|
11
|
-
|
|
12
|
-
Do not create a preserved-source/checklist pair, target-mode prompt, Local Audit, matrix, verdict or second plan from this compatibility invocation.
|
|
1
|
+
---
|
|
2
|
+
name: normal-long-task
|
|
3
|
+
description: Retired compatibility pointer for users who explicitly invoke /normal-long-task. Direct them to /long-task-workflow and do not create legacy checklist, prompt, audit, matrix, verdict, or plan artifacts.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Retired: Normal Long Task
|
|
7
|
+
|
|
8
|
+
`/normal-long-task` no longer defines a second long-task artifact workflow.
|
|
9
|
+
|
|
10
|
+
Use `/long-task-workflow` for one Canonical Delivery Contract, the current platform-native Goal, rolling implementation in the current workspace, targeted repair verification, a same-snapshot Final Gate and Stop freshness.
|
|
11
|
+
|
|
12
|
+
Do not create a preserved-source/checklist pair, target-mode prompt, Local Audit, matrix, verdict or second plan from this compatibility invocation.
|