project-tiny-context-harness 0.8.4 → 0.8.6
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 +394 -363
- package/assets/README.md +570 -514
- package/assets/README.zh-CN.md +331 -300
- package/assets/agents/.gitkeep +1 -1
- package/assets/agents/AGENTS_CORE.md +45 -25
- package/assets/context_templates/architecture.md +26 -25
- package/assets/context_templates/area.md +32 -31
- package/assets/context_templates/context.toml +30 -24
- package/assets/context_templates/deployment.md +35 -35
- package/assets/context_templates/global.md +57 -57
- package/assets/context_templates/product-surface-contract.md +70 -70
- package/assets/context_templates/screen-contract.md +189 -189
- package/assets/context_templates/verification.md +31 -30
- package/assets/github/.gitkeep +1 -1
- package/assets/github/harness.yml +39 -39
- package/assets/make/.gitkeep +1 -1
- package/assets/make/ty-context.mk +48 -48
- package/assets/skills/context_development_engineer/SKILL.md +155 -122
- package/assets/skills/context_full_project_export/SKILL.md +28 -28
- package/assets/skills/context_harness_upgrade/SKILL.md +60 -60
- package/assets/skills/context_product_plan/SKILL.md +99 -79
- package/assets/skills/context_surface_contract/SKILL.md +191 -191
- package/assets/skills/context_uiux_design/SKILL.md +171 -171
- package/assets/skills/design-resource-authoring/SKILL.md +86 -84
- package/assets/skills/design-resource-authoring/references/downstream-handoff.md +138 -123
- package/assets/skills/design-resource-authoring/references/open-design-provider.md +132 -127
- package/assets/skills/design-resource-authoring/references/resource-selection.md +181 -154
- package/assets/skills/design-system-authoring/SKILL.md +57 -57
- package/assets/skills/design-system-authoring/agents/openai.yaml +6 -6
- package/assets/skills/design-system-authoring/references/authority-adoption.md +48 -48
- package/assets/skills/design-system-authoring/references/open-design-design-system-provider.md +110 -110
- package/assets/skills/long-task-workflow/SKILL.md +98 -92
- package/assets/skills/long-task-workflow/agents/openai.yaml +3 -1
- package/assets/skills/long-task-workflow/references/authority-lifecycle.md +72 -72
- package/assets/skills/long-task-workflow/references/contract-authoring.md +122 -101
- package/assets/skills/long-task-workflow/references/evidence-design.md +82 -61
- package/assets/skills/long-task-workflow/references/source-authoring.md +109 -90
- package/assets/skills/source-plan-authoring/SKILL.md +14 -14
- package/assets/tools/validate_context.py +442 -442
- package/dist/commands/long-task-authoring.js +27 -2
- package/dist/lib/context-default-footprint.js +2 -0
- package/dist/lib/context-manifest.js +6 -0
- package/dist/lib/context-templates.js +1 -1
- package/dist/lib/design-resource-fact-enums.d.ts +20 -0
- package/dist/lib/design-resource-fact-enums.js +170 -0
- package/dist/lib/design-resource-fact-locator-extractors.d.ts +8 -0
- package/dist/lib/design-resource-fact-locator-extractors.js +108 -0
- package/dist/lib/design-resource-fact-locator-resolver.d.ts +3 -0
- package/dist/lib/design-resource-fact-locator-resolver.js +112 -0
- package/dist/lib/design-resource-fact-locator-validation.d.ts +5 -0
- package/dist/lib/design-resource-fact-locator-validation.js +16 -0
- package/dist/lib/design-resource-fact-manifest-catalog.d.ts +4 -0
- package/dist/lib/design-resource-fact-manifest-catalog.js +249 -0
- package/dist/lib/design-resource-fact-manifest-model.d.ts +91 -0
- package/dist/lib/design-resource-fact-manifest-model.js +21 -0
- package/dist/lib/design-resource-fact-manifest-shape-axes.d.ts +6 -0
- package/dist/lib/design-resource-fact-manifest-shape-axes.js +159 -0
- package/dist/lib/design-resource-fact-manifest-shape-evidence.d.ts +4 -0
- package/dist/lib/design-resource-fact-manifest-shape-evidence.js +59 -0
- package/dist/lib/design-resource-fact-manifest-shape-facts.d.ts +4 -0
- package/dist/lib/design-resource-fact-manifest-shape-facts.js +109 -0
- package/dist/lib/design-resource-fact-manifest-shape-inspector.d.ts +5 -0
- package/dist/lib/design-resource-fact-manifest-shape-inspector.js +144 -0
- package/dist/lib/design-resource-fact-manifest-shape.d.ts +7 -0
- package/dist/lib/design-resource-fact-manifest-shape.js +75 -0
- package/dist/lib/design-resource-fact-manifest-types.d.ts +3 -0
- package/dist/lib/design-resource-fact-manifest-types.js +3 -0
- package/dist/lib/design-resource-fact-manifest-universe.d.ts +5 -0
- package/dist/lib/design-resource-fact-manifest-universe.js +50 -0
- package/dist/lib/design-resource-fact-manifest-validation.d.ts +3 -0
- package/dist/lib/design-resource-fact-manifest-validation.js +106 -0
- package/dist/lib/design-resource-fact-policy.d.ts +18 -0
- package/dist/lib/design-resource-fact-policy.js +72 -1
- package/dist/lib/design-resource-fact-property-methods.d.ts +3 -0
- package/dist/lib/design-resource-fact-property-methods.js +158 -0
- package/dist/lib/design-resource-fact-shape-primitives.d.ts +3 -0
- package/dist/lib/design-resource-fact-shape-primitives.js +18 -0
- package/dist/lib/design-resource-fact-types.d.ts +164 -0
- package/dist/lib/design-resource-fact-types.js +1 -0
- package/dist/lib/design-resource-fact-universe-assets.d.ts +4 -0
- package/dist/lib/design-resource-fact-universe-assets.js +71 -0
- package/dist/lib/design-resource-fact-universe-catalog.d.ts +4 -0
- package/dist/lib/design-resource-fact-universe-catalog.js +151 -0
- package/dist/lib/design-resource-fact-universe-conditions.d.ts +2 -0
- package/dist/lib/design-resource-fact-universe-conditions.js +92 -0
- package/dist/lib/design-resource-fact-universe-facts.d.ts +4 -0
- package/dist/lib/design-resource-fact-universe-facts.js +108 -0
- package/dist/lib/design-resource-fact-universe-helpers.d.ts +30 -0
- package/dist/lib/design-resource-fact-universe-helpers.js +167 -0
- package/dist/lib/design-resource-fact-universe-inspector.d.ts +7 -0
- package/dist/lib/design-resource-fact-universe-inspector.js +119 -0
- package/dist/lib/design-resource-fact-universe-proof.d.ts +4 -0
- package/dist/lib/design-resource-fact-universe-proof.js +113 -0
- package/dist/lib/design-resource-fact-universe-subjects.d.ts +5 -0
- package/dist/lib/design-resource-fact-universe-subjects.js +97 -0
- package/dist/lib/design-resource-fact-universe-variations.d.ts +2 -0
- package/dist/lib/design-resource-fact-universe-variations.js +75 -0
- package/dist/lib/design-resource-fact-value-validation.d.ts +2 -0
- package/dist/lib/design-resource-fact-value-validation.js +80 -0
- package/dist/lib/design-resource-handoff-file-primitives.js +2 -0
- package/dist/lib/design-resource-handoff-file-validation.js +13 -100
- package/dist/lib/design-resource-handoff-policy.d.ts +1 -0
- package/dist/lib/design-resource-handoff-policy.js +118 -11
- package/dist/lib/design-resource-handoff-shape-evidence.js +46 -3
- package/dist/lib/design-resource-handoff-shape-primitives.d.ts +5 -0
- package/dist/lib/design-resource-handoff-shape-primitives.js +28 -0
- package/dist/lib/design-resource-handoff-shape-structure.js +143 -22
- package/dist/lib/design-resource-handoff-shape.js +25 -0
- package/dist/lib/design-resource-handoff-types.d.ts +97 -21
- package/dist/lib/design-resource-handoff-types.js +22 -0
- package/dist/lib/design-resource-handoff-validation-coverage.d.ts +1 -1
- package/dist/lib/design-resource-handoff-validation-coverage.js +145 -118
- package/dist/lib/design-resource-handoff-validation-fact-cells.d.ts +2 -0
- package/dist/lib/design-resource-handoff-validation-fact-cells.js +60 -0
- package/dist/lib/design-resource-handoff-validation-fact-records.d.ts +2 -0
- package/dist/lib/design-resource-handoff-validation-fact-records.js +90 -0
- package/dist/lib/design-resource-handoff-validation-facts.js +10 -94
- package/dist/lib/design-resource-handoff-validation-proofs.d.ts +2 -0
- package/dist/lib/design-resource-handoff-validation-proofs.js +67 -0
- package/dist/lib/design-resource-handoff-validation-resource-closure.d.ts +3 -0
- package/dist/lib/design-resource-handoff-validation-resource-closure.js +88 -0
- package/dist/lib/design-resource-handoff-validation-structure.js +43 -14
- package/dist/lib/design-resource-handoff-validation.js +32 -0
- package/dist/lib/design-resource-handoff-web-dependency-validation.d.ts +2 -1
- package/dist/lib/design-resource-handoff-web-dependency-validation.js +67 -7
- package/dist/lib/execution-target-capabilities.d.ts +1 -1
- package/dist/lib/execution-target-capabilities.js +14 -0
- package/dist/lib/long-task-activation-validation.js +6 -2
- package/dist/lib/long-task-applicability-shape.js +3 -3
- package/dist/lib/long-task-authoring-authority-preview.js +1 -0
- package/dist/lib/long-task-authority-policy.d.ts +1 -0
- package/dist/lib/long-task-authority-policy.js +1 -0
- package/dist/lib/long-task-authority.js +13 -0
- package/dist/lib/long-task-claim-definitions.js +13 -1
- package/dist/lib/long-task-claims.js +23 -1
- package/dist/lib/long-task-contract-types.d.ts +3 -0
- package/dist/lib/long-task-delivery-compiler.js +1 -0
- package/dist/lib/long-task-delivery-parser.js +11 -1
- package/dist/lib/long-task-delivery-types.d.ts +1 -0
- package/dist/lib/long-task-delivery-types.js +1 -0
- package/dist/lib/long-task-delivery-validation.js +17 -0
- package/dist/lib/long-task-design-resource-handoff.js +62 -38
- package/dist/lib/long-task-design-target-capabilities.d.ts +14 -0
- package/dist/lib/long-task-design-target-capabilities.js +126 -0
- package/dist/lib/long-task-evidence-capability-codec.d.ts +94 -0
- package/dist/lib/long-task-evidence-capability-codec.js +395 -22
- package/dist/lib/long-task-evidence-capability-policy.js +18 -0
- package/dist/lib/long-task-evidence-capability-runtime.js +78 -0
- package/dist/lib/long-task-evidence-capability-types.d.ts +114 -1
- package/dist/lib/long-task-outcome-parser.js +4 -0
- package/dist/lib/long-task-playwright-capability-records.d.ts +5 -0
- package/dist/lib/long-task-playwright-capability-records.js +146 -0
- package/dist/lib/long-task-playwright-case-evidence.d.ts +3 -2
- package/dist/lib/long-task-playwright-case-evidence.js +10 -79
- package/dist/lib/long-task-playwright-case-primitives.d.ts +28 -0
- package/dist/lib/long-task-playwright-case-primitives.js +143 -0
- package/dist/lib/long-task-playwright-evidence.d.ts +1 -1
- package/dist/lib/long-task-playwright-evidence.js +10 -75
- package/dist/lib/long-task-runner-freeze.d.ts +2 -2
- package/dist/lib/long-task-runner-freeze.js +15 -1
- package/dist/lib/long-task-runtime-types.d.ts +4 -1
- package/dist/lib/long-task-semantic-contract-types.d.ts +1 -1
- package/dist/lib/long-task-semantic-drift-migration.js +2 -2
- package/dist/lib/long-task-semantic-fact-binding-types.d.ts +57 -0
- package/dist/lib/long-task-semantic-fact-binding-types.js +1 -0
- package/dist/lib/long-task-semantic-fact-closure-primitives.d.ts +5 -0
- package/dist/lib/long-task-semantic-fact-closure-primitives.js +43 -0
- package/dist/lib/long-task-semantic-fact-closure.d.ts +13 -0
- package/dist/lib/long-task-semantic-fact-closure.js +48 -0
- package/dist/lib/long-task-semantic-fact-contract-closure.d.ts +4 -0
- package/dist/lib/long-task-semantic-fact-contract-closure.js +24 -0
- package/dist/lib/long-task-semantic-fact-contract-facts.d.ts +4 -0
- package/dist/lib/long-task-semantic-fact-contract-facts.js +30 -0
- package/dist/lib/long-task-semantic-fact-contract-proofs.d.ts +4 -0
- package/dist/lib/long-task-semantic-fact-contract-proofs.js +97 -0
- package/dist/lib/long-task-semantic-fact-evidence.d.ts +21 -0
- package/dist/lib/long-task-semantic-fact-evidence.js +165 -0
- package/dist/lib/long-task-semantic-fact-input-closure.d.ts +4 -0
- package/dist/lib/long-task-semantic-fact-input-closure.js +101 -0
- package/dist/lib/long-task-semantic-fact-provenance-closure.d.ts +4 -0
- package/dist/lib/long-task-semantic-fact-provenance-closure.js +140 -0
- package/dist/lib/long-task-semantic-fact-shape.d.ts +3 -0
- package/dist/lib/long-task-semantic-fact-shape.js +89 -0
- package/dist/lib/long-task-semantic-fact-value-closure.d.ts +3 -0
- package/dist/lib/long-task-semantic-fact-value-closure.js +110 -0
- package/dist/lib/long-task-shape-primitives.d.ts +2 -1
- package/dist/lib/long-task-shape-primitives.js +7 -0
- package/dist/lib/long-task-source-item-parser.js +25 -6
- package/dist/lib/long-task-source-target-continuity.js +4 -1
- package/dist/lib/long-task-source-target-index.d.ts +1 -1
- package/dist/lib/long-task-source-target-index.js +5 -1
- package/dist/lib/long-task-ui-design-policy.js +8 -4
- package/dist/lib/long-task-ui-surface-shape.js +83 -1
- package/dist/lib/long-task-ui-surface-types.d.ts +29 -0
- package/dist/lib/modularity.js +7 -1
- package/dist/lib/semantic-fact-base-types.d.ts +14 -0
- package/dist/lib/semantic-fact-base-types.js +1 -0
- package/dist/lib/semantic-fact-catalog.d.ts +8 -0
- package/dist/lib/semantic-fact-catalog.js +191 -0
- package/dist/lib/semantic-fact-condition-shape.d.ts +48 -0
- package/dist/lib/semantic-fact-condition-shape.js +111 -0
- package/dist/lib/semantic-fact-input-shape.d.ts +34 -0
- package/dist/lib/semantic-fact-input-shape.js +111 -0
- package/dist/lib/semantic-fact-inventory-types.d.ts +147 -0
- package/dist/lib/semantic-fact-inventory-types.js +1 -0
- package/dist/lib/semantic-fact-manifest-shape.d.ts +4 -0
- package/dist/lib/semantic-fact-manifest-shape.js +135 -0
- package/dist/lib/semantic-fact-manifest-types.d.ts +58 -0
- package/dist/lib/semantic-fact-manifest-types.js +19 -0
- package/dist/lib/semantic-fact-policy-authority.d.ts +8 -0
- package/dist/lib/semantic-fact-policy-authority.js +79 -0
- package/dist/lib/semantic-fact-policy-census.d.ts +2 -0
- package/dist/lib/semantic-fact-policy-census.js +80 -0
- package/dist/lib/semantic-fact-policy-condition-references.d.ts +7 -0
- package/dist/lib/semantic-fact-policy-condition-references.js +19 -0
- package/dist/lib/semantic-fact-policy-conditions.d.ts +2 -0
- package/dist/lib/semantic-fact-policy-conditions.js +105 -0
- package/dist/lib/semantic-fact-policy-facts.d.ts +3 -0
- package/dist/lib/semantic-fact-policy-facts.js +73 -0
- package/dist/lib/semantic-fact-policy-primitives.d.ts +26 -0
- package/dist/lib/semantic-fact-policy-primitives.js +169 -0
- package/dist/lib/semantic-fact-policy-proofs.d.ts +2 -0
- package/dist/lib/semantic-fact-policy-proofs.js +75 -0
- package/dist/lib/semantic-fact-policy-properties.d.ts +3 -0
- package/dist/lib/semantic-fact-policy-properties.js +84 -0
- package/dist/lib/semantic-fact-policy-units.d.ts +4 -0
- package/dist/lib/semantic-fact-policy-units.js +103 -0
- package/dist/lib/semantic-fact-policy.d.ts +17 -0
- package/dist/lib/semantic-fact-policy.js +41 -0
- package/dist/lib/semantic-fact-proof-shape.d.ts +51 -0
- package/dist/lib/semantic-fact-proof-shape.js +121 -0
- package/dist/lib/semantic-fact-proof-types.d.ts +74 -0
- package/dist/lib/semantic-fact-proof-types.js +1 -0
- package/dist/lib/semantic-fact-property-shape.d.ts +29 -0
- package/dist/lib/semantic-fact-property-shape.js +77 -0
- package/dist/lib/semantic-fact-shape-constants.d.ts +3 -0
- package/dist/lib/semantic-fact-shape-constants.js +38 -0
- package/dist/lib/semantic-fact-shape-primitives.d.ts +15 -0
- package/dist/lib/semantic-fact-shape-primitives.js +68 -0
- package/dist/lib/semantic-fact-source-parser.d.ts +9 -0
- package/dist/lib/semantic-fact-source-parser.js +46 -0
- package/dist/lib/semantic-fact-support-shape.d.ts +21 -0
- package/dist/lib/semantic-fact-support-shape.js +59 -0
- package/dist/lib/semantic-fact-types.d.ts +5 -0
- package/dist/lib/semantic-fact-types.js +5 -0
- package/dist/lib/semantic-fact-unit-shape.d.ts +34 -0
- package/dist/lib/semantic-fact-unit-shape.js +89 -0
- package/dist/lib/semantic-fact-value-shape.d.ts +12 -0
- package/dist/lib/semantic-fact-value-shape.js +39 -0
- package/dist/schemas/long-task-delivery-v2/long-task-delivery-v2.schema.json +1339 -131
- package/migrations/README.md +15 -15
- package/package.json +84 -84
- package/source-mappings.yaml +25 -25
|
@@ -1,79 +1,100 @@
|
|
|
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. Every Claim-bearing Assertion proves exactly one Claim at one exact applicability profile and uses explicit comparable Observations and expected values; every Claim/applicability/proof-surface cell must be covered.
|
|
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.
|
|
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. Every Claim-bearing Assertion proves exactly one Claim at one exact applicability profile and uses explicit comparable Observations and expected values; every Claim/applicability/proof-surface cell must be covered.
|
|
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
11
|
- Verification inputs include entrypoints, helpers, fixtures/config, package scripts and lockfiles and cannot overlap implementation carriers. The frozen runner identity recursively includes the supported direct-literal local verifier module/config/data graph; runtime-owned Check inputs/outputs/artifacts are explicitly excluded from Oracle identity, while non-literal loaders, `createRequire` and package scripts without a recoverable static Node entry fail closed. Other indirect Oracle access must be declared or treated as named TCB.
|
|
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
|
-
|
|
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
16
|
Evidence adapter is derived from runner kind. Only Playwright may prove `ui_browser`; structured runners prove non-browser surfaces. Raw Execution identity binds the runner, its recursively frozen local dependency closure and canonical declared Environment Requirements, not actual values. Bare installed packages and the Harness/runtime remain named trusted-computing-boundary components rather than silently mutable project helpers.
|
|
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
|
-
|
|
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
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. A Claim-bearing Assertion's `applicability_ref` must match the Check target, journey role, duplicate-free atomic dimension assignments, all keyed Given refs and ordered When refs exactly.
|
|
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; `design_conformance` binds one compiled selected target, exact required product target, declared condition set and distinct current actual/comparison artifact paths; `design_method` binds one handoff verification method, its exact condition, exact handoff `fact_refs`, declared method-record path and declared primary-observation path. Runtime
|
|
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; `design_conformance` binds one compiled selected target, exact required product target, declared condition set and distinct current actual/comparison artifact paths; `design_method` binds one handoff verification method, its exact condition, exact handoff `fact_refs`, declared method-record path and declared primary-observation path. Runtime Fact refs and `fact_results` must be set-equal to the compiled cell, all property-required Fact × method obligations must be present, and all cells must conserve the complete target Fact set. Every result preserves subject/variation/property, attributable actual observation/environment, frozen expected/comparator/tolerance/mask/Oracle/environment authority and explicit verdict; every row must pass. Protected observations use the declared digest-only/redacted policy without persisting raw values. Missing, extra, duplicate, stale, failed, authority-drifted or reused/indistinguishable rows fail closed. Primary observations are pairwise unique by current path and digest across method/condition cells; `target_runtime` binds exact target/root/current session and requires a cold start for a root journey whose execution target declares the matching family, `cold-start` and `production-root` capabilities; `input_variation` requires at least two distinct inputs, differing propagated outputs and an observed failure case.
|
|
27
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
28
|
|
|
29
|
-
##
|
|
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
|
|
29
|
+
## Non-UI Semantic Fact Evidence
|
|
38
30
|
|
|
39
|
-
|
|
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
|
-
- Every behavioral Claim-bearing Assertion requires a same-Check claim-local semantic Counterfactual. Use `replace_json_value` or `replace_text` to alter only the asserted semantic field/fragment while preserving the production carrier; the designated Assertion must fail and a claimless target-runtime liveness Assertion in `preserved_assertions` must keep passing. `replace_file` remains compatibility-only and cannot establish semantic binding; `remove_paths` remains for non-behavioral existence/structure claims.
|
|
42
|
-
- Keep this risk-proportional and internal. Do not create an evidence matrix, product-effect taxonomy, universal restart/end-to-end suite 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.
|
|
31
|
+
Every machine `semantic_fact` proof binding compiles one immutable expectation row identified by manifest/digest, Outcome, Fact, proof method, Claim, applicability, subject/relation/population, exact condition and property. It freezes the Source-located expected value digest, sensitivity, comparator/mode/parameters/tolerance/mask, Oracle identity/version/digest/capabilities, environment identity/definition digest and observer refs. Runtime evidence cannot rewrite any of these fields.
|
|
45
32
|
|
|
46
|
-
|
|
33
|
+
The owning Check emits exactly one current `semantic_fact` result for every and only every expectation assigned to it. Each result records:
|
|
47
34
|
|
|
48
|
-
|
|
35
|
+
- exact assertion/manifest/Outcome/target/Fact/proof/method/subject/condition/property identity;
|
|
36
|
+
- an attributable actual-observation artifact, current digest, typed locator and value digest;
|
|
37
|
+
- an attributable actual-environment artifact, current digest, typed locator and value digest;
|
|
38
|
+
- the frozen expected located authority and comparison tuple, plus a current comparison artifact/locator/result digest;
|
|
39
|
+
- explicit `passed|failed` comparison and verdict;
|
|
40
|
+
- the exact Oracle/environment identity; and
|
|
41
|
+
- one result for every declared independent observer where applicable.
|
|
49
42
|
|
|
50
|
-
|
|
43
|
+
Exact mode requires the actual value digest to equal the expected digest; tolerance mode still freezes Fact-local tolerance and optional narrow mask as Source/verifier input. Global/widened runtime tolerances, implementation-generated expectations and self-baselines are invalid. Protected observations use the declared digest-only/redacted representation and policy identity with `raw_persisted: false`; secrets, tokens, personal or regulated values never enter Contract, logs, findings, Context or artifacts in raw form.
|
|
51
44
|
|
|
52
|
-
|
|
45
|
+
Result identities and primary observations are duplicate-free. One aggregate Boolean/report/log/screenshot, one reused artifact+locator+value tuple, one all-states row or one Check exit code cannot satisfy several Facts or methods. A Fact may legitimately require several independent methods/observers, and all must pass. Population/quantified Facts additionally prove exact expected universe = eligible = observed plus valid exclusions. Evidence must reach the furthest independently failing named boundary; parser/request/queue acceptance or implementation self-report does not prove storage, downstream delivery, recovery, security or external effect.
|
|
53
46
|
|
|
54
|
-
|
|
47
|
+
Final Gate requires exact expectation/result set equality on its one current snapshot and rejects missing, extra, duplicate, stale, failed, authority-drifted, environment-mismatched, proxy-only, reused or indistinguishable results. External-confirmation obligations emit no fabricated machine row and remain pending through terminal reporting. Manifest/preflight success, hashes, Census, schema validation, focused tests and Progress prove only their own input/integrity/intermediate claims.
|
|
55
48
|
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
-
|
|
59
|
-
- A
|
|
60
|
-
-
|
|
61
|
-
-
|
|
62
|
-
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
-
|
|
49
|
+
## Live Target Runtime Evidence
|
|
50
|
+
|
|
51
|
+
- 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.
|
|
52
|
+
- 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.
|
|
53
|
+
- 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.
|
|
54
|
+
- 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.
|
|
55
|
+
- 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.
|
|
56
|
+
|
|
57
|
+
## Causal Boundary Review After Revision
|
|
58
|
+
|
|
59
|
+
- 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.
|
|
60
|
+
- 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.
|
|
61
|
+
- Every behavioral Claim-bearing Assertion requires a same-Check claim-local semantic Counterfactual. Use `replace_json_value` or `replace_text` to alter only the asserted semantic field/fragment while preserving the production carrier; the designated Assertion must fail and a claimless target-runtime liveness Assertion in `preserved_assertions` must keep passing. `replace_file` remains compatibility-only and cannot establish semantic binding; `remove_paths` remains for non-behavioral existence/structure claims.
|
|
62
|
+
- Keep this risk-proportional and internal. Do not create an evidence matrix, product-effect taxonomy, universal restart/end-to-end suite or persistent review state.
|
|
63
|
+
|
|
64
|
+
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.
|
|
65
|
+
|
|
66
|
+
## Playwright
|
|
67
|
+
|
|
68
|
+
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.
|
|
69
|
+
|
|
70
|
+
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.
|
|
71
|
+
|
|
72
|
+
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.
|
|
73
|
+
|
|
74
|
+
## Visual UI Evidence
|
|
75
|
+
|
|
76
|
+
- A selected implementation handoff must already pass `ty-context design-resource preflight`, including frozen-Inspector Census, exact manifest↔handoff universe equality, complete per-resource/Fact Cell/Fact/proof closure, non-sampling/non-truncation and exact-target layout/pixel defaults. For each covered row, turn every property-required Fact × verification-method obligation into project-owned, independently failing observations in the target conformance Check: geometry/pixel/token/content, component state/interaction/gesture/scroll trace, motion/haptic/sound timeline, responsive reflow/input/localization/system UI, accessibility semantic/navigation/visual and asset integrity are different obligations. Each method maps to its own Assertion and typed `design_method` evidence; every exact condition declares Fact refs, full `fact_expectations`, a method record and a method-native primary observation whose current path and digest cannot be reused by another cell. Each current `fact_results` row repeats the exact identity and authority, records actual observation and render environment, compares under the frozen parameters/tolerance/mask and supplies its own pass/fail verdict. Playwright requires explicit record/observation attachments from every project instance. The strict index proves conservation relative to the named Inspector/Oracle TCB; it does not prove that an unsupported format was read or that the project verifier is semantically sound.
|
|
77
|
+
- Never accept an aggregate Boolean, screenshot pass or one `all-states` result in place of per-Fact rows. A legitimate tolerance/mask is canonical Fact-scoped verifier input and cannot be widened by runtime evidence. The expected target cannot be generated from the implementation under test. Plain observations remain attributable; protected observations retain canonical-source ownership while evidence stores only digest/redacted representation plus policy and `raw_persisted: false`.
|
|
78
|
+
- Keep `design_resource_integrity` and `design_implementation_conformance` distinct. Stable paths/hashes, provider/export success, manifest/registry membership and expected counts prove resource integrity; `visual_render` proves a current artifact exists. Neither proves the production implementation matches a selected target.
|
|
79
|
+
- When external design resources are Source, prove every selected exact-target/constraint condition that the Contract explicitly adopts. Candidate comparison, a mutable provider link, extraction success, metadata-only output, resource digest or an isolated prototype run is authoring/integrity material and cannot become product acceptance. Resolve each acceptance-affecting fact through a typed locator plus immutable path/hash and declared target/condition applicability before Compile. Include the handoff and every source-profile entry/dependency in `verification_inputs`; project-owned method-specific single-Claim design-conformance, interaction and target-runtime observations must still fail independently on the current production target.
|
|
80
|
+
- A `design_conformance` record is accepted only for the compiled target/Assertion/current Check target, an equal declared condition-key set and both declared actual/comparison artifacts collected by the current Check. Its Assertion applicability must also equal the adopted target, conditions, journey and input/state facts. Missing or swapped targets, conditions or artifacts fail closed; the implementation render cannot also be the comparison authority.
|
|
81
|
+
- 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; representative, sampled or pairwise coverage cannot waive an actual applicable cell.
|
|
82
|
+
- 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.
|
|
83
|
+
- 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.
|
|
84
|
+
- 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.
|
|
85
|
+
- Screenshot comparison proves only the named visual similarity claim. Pair it with explicit DOM/layout/accessibility/motion/responsive/input assertions whenever the handoff or Contract separately declares no overflow, action visibility, focus behavior, target size, semantic state, reduced motion or other observable behavior. One generic `design_conformance` record cannot erase distinct Source Claims or verification methods; every handoff method binds a separate Assertion and the trusted Check must fail if any asserted method fails.
|
|
86
|
+
- 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.
|
|
87
|
+
- Run checks against production components or real product routes. For each bound Control, the named root-entry journey must begin at the required product target root, execute the declared entry action and prove its navigation result—or interaction, trigger or location fallback—with `interaction_trace` plus `target_runtime`. A detached kit/mock/deep-link harness is acceptable only when the Contract explicitly makes that artifact the product surface; otherwise it cannot substitute for the production carrier or root journey.
|
|
67
88
|
- 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.
|
|
68
89
|
- `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.
|
|
69
90
|
- Preserve each handoff blocker's non-empty `required_capabilities`. A machine Claim closes it only on the exact execution target that declares every capability; physical device, sensor, camera, orientation, haptic, screen-reader, pixel-density, safe-area or comparable observations cannot be borrowed from a proxy target. If that runtime observation is unavailable or the Oracle cannot consume the target-owned acceptance criteria, keep the blocker as a target-blocking External Confirmation.
|
|
70
|
-
|
|
71
|
-
## Structured Evidence And Sensitivity
|
|
72
|
-
|
|
91
|
+
|
|
92
|
+
## Structured Evidence And Sensitivity
|
|
93
|
+
|
|
73
94
|
Every claim-bearing `structured_json_v2` Check needs same-Check Claim-related Counterfactual sensitivity. Population declares a real `universe_binding_key`; every universe carrier is an owning-Check `input_path`, and the current observation proves exact universe = eligible = observed plus valid exclusions by entity id. Population never substitutes for the claim-local narrow semantic witness and preserved target-runtime liveness required by a behavioral Claim. Artifacts and another Check never substitute for sensitivity.
|
|
74
|
-
|
|
95
|
+
|
|
75
96
|
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. Behavioral witnesses use claim-local `replace_json_value` or `replace_text`, list their designated Claim-bearing failure Assertions, and list the claimless liveness Assertions that must remain passing.
|
|
76
|
-
|
|
97
|
+
|
|
77
98
|
An `existing` mutation target must exist at Preflight/Compile and the JSON pointer/text fragment must resolve uniquely. A `planned` target may be absent until implementation but must exist at Final Gate; once created, its changes stale targeted Progress.
|
|
78
|
-
|
|
79
|
-
Artifacts remain review material. They do not prove Claim sensitivity by themselves.
|
|
99
|
+
|
|
100
|
+
Artifacts remain review material. They do not prove Claim sensitivity by themselves.
|
|
@@ -1,104 +1,123 @@
|
|
|
1
|
-
# Source-Bound Draft Input Reference
|
|
2
|
-
|
|
3
|
-
Read this alongside `contract-authoring.md` when raw, mixed, attachment-heavy or incomplete inputs need Source-quality repair while the same Contract Draft is being mapped. Inputs enter the Draft immediately; this reference is neither an earlier Source-authoring phase nor a standalone Source Plan stage or second lifecycle.
|
|
4
|
-
|
|
5
|
-
## Objective and boundary
|
|
6
|
-
|
|
7
|
-
Preserve every material user, product, technical, visual and acceptance constraint from the initial/revised proposal and supplied resources. Add only traceable necessary derivations, defensible delegated choices and evidence-backed repository facts. Make the real Source understandable without the original conversation before Preflight/Compile, while allowing Draft decomposition and repository binding to proceed incrementally.
|
|
8
|
-
|
|
9
|
-
Do not create a Source Plan schema, CLI, Preflight, Compile, Receipt, cache, authority, state or internal Source-authoring stage. Contract YAML cannot become the sole owner of a choice or missing semantic. Do not let current implementation silently redefine intent. A pre-existing Source Plan is simply one possible input.
|
|
10
|
-
|
|
11
|
-
## Input inventory
|
|
12
|
-
|
|
13
|
-
1. Assign every proposal, selected design resource, screenshot, document, diagram, table and other attachment a stable input ID.
|
|
14
|
-
2. Inspect all pages/frames/screens/tables/visible states; never silently sample a multi-part artifact. Every non-empty line in a declared Markdown Source file must ultimately belong to exactly one Material Source Item, one keyed and reasoned non-authoritative `ty-source-background:start/end` block, or the one validated `design-resource-handoff-v1` formal block.
|
|
1
|
+
# Source-Bound Draft Input Reference
|
|
2
|
+
|
|
3
|
+
Read this alongside `contract-authoring.md` when raw, mixed, attachment-heavy or incomplete inputs need Source-quality repair while the same Contract Draft is being mapped. Inputs enter the Draft immediately; this reference is neither an earlier Source-authoring phase nor a standalone Source Plan stage or second lifecycle.
|
|
4
|
+
|
|
5
|
+
## Objective and boundary
|
|
6
|
+
|
|
7
|
+
Preserve every material user, product, technical, visual and acceptance constraint from the initial/revised proposal and supplied resources. Add only traceable necessary derivations, defensible delegated choices and evidence-backed repository facts. Make the real Source understandable without the original conversation before Preflight/Compile, while allowing Draft decomposition and repository binding to proceed incrementally.
|
|
8
|
+
|
|
9
|
+
Do not create a Source Plan schema, CLI, Preflight, Compile, Receipt, cache, authority, state or internal Source-authoring stage. Contract YAML cannot become the sole owner of a choice or missing semantic. Do not let current implementation silently redefine intent. A pre-existing Source Plan is simply one possible input.
|
|
10
|
+
|
|
11
|
+
## Input inventory
|
|
12
|
+
|
|
13
|
+
1. Assign every proposal, selected design resource, screenshot, document, diagram, table and other attachment a stable input ID.
|
|
14
|
+
2. Inspect all pages/frames/screens/tables/visible states; never silently sample a multi-part artifact. Every non-empty line in a declared Markdown Source file must ultimately belong to exactly one Material Source Item, one keyed and reasoned non-authoritative `ty-source-background:start/end` block, or the one validated `design-resource-handoff-v1` formal block.
|
|
15
15
|
3. Classify each input as user instruction, product requirement, technical constraint, existing proposal, selected target, repository/Context evidence, constraint, inspiration or background. Background is a closed grammar: `markdown-structure` contains only text-free anchors or horizontal rules, and `provenance` contains only `ty-source-provenance input=<key> mode=<direct|derived|delegated|evidence-backed> [source=<key>] [sha256=<64-lowercase-hex>]` comments; non-direct modes require `source`. Text-bearing headings, free-form provenance and explanatory prose are material or unclassified even when intended as non-authoritative; background must never hide a qualifier, requirement, acceptance fact, architecture meaning, design meaning or other delivery authority.
|
|
16
|
-
4. For visual resources, preserve selection basis, classification (`exact-target`, `constraint` or `inspiration`), stable resource/surface/control/state/target keys, declared platform/viewport/mode/state/content applicability, source profile/canonical entry/dependency set, provider/project/run/entry provenance and immutable digest/snapshot, plus typed locators. A mutable link, metadata-only response, partial file set or prose locator is incomplete. Unselected candidates authorize no fidelity.
|
|
17
|
-
5. Record incorporated meaning and every unreadable, conflicting or intentionally unused part. Higher authority and user-stated precedence win; unresolved conflicts remain decisions.
|
|
18
|
-
|
|
19
|
-
## Preference and research gate
|
|
20
|
-
|
|
21
|
-
Before comparative research or a material product, technical, architecture or provider selection, identify decision-changing criteria such as fidelity versus cost, delivery speed, reliability/support, privacy/compliance, lock-in/control, operational burden, platform scope and extensibility.
|
|
22
|
-
|
|
23
|
-
Infer preferences only from user words, Source, Context or controlling constraints. If an unknown preference would materially change research or recommendation, ask one concise targeted clarification before proceeding. Do not impose a questionnaire, re-ask known preferences or pause for minor reversible choices with the same defensible recommendation.
|
|
24
|
-
|
|
25
|
-
Use current primary/authoritative evidence for changing external facts. Record source, scope and retrieval date. Preference clarification authorizes plan meaning, not payment, contracting, deployment/publication, destructive production mutation, permission grants, sensitive-data transmission or required legal/security/human approval; those remain typed external confirmations.
|
|
26
|
-
|
|
27
|
-
## Working strategies, not phases
|
|
28
|
-
|
|
29
|
-
Choose locally as needed while revising the same Draft; do not expose these as lifecycle stages or ask the user to choose:
|
|
30
|
-
|
|
31
|
-
- **refinement:** preserve and complete a substantially developed proposal;
|
|
32
|
-
- **synthesis:** build coherent Source from a goal plus mixed inputs;
|
|
33
|
-
- **hybrid:** use one proposal as backbone and fill gaps from other inputs.
|
|
34
|
-
|
|
35
|
-
A short request is sufficient when roles, goal and reference authority are recoverable. Reuse an authorized writable proposal as the real Source. If the delivery exists only in conversation, materialize exactly one project-native Markdown Source according to repository convention. Do not create a parallel planning artifact.
|
|
36
|
-
|
|
37
|
-
## Semantic authoring
|
|
38
|
-
|
|
39
|
-
For every material item, preserve one origin:
|
|
40
|
-
|
|
41
|
-
- `direct`: stated by user or controlling input, with all qualifiers;
|
|
42
|
-
- `derived`: unavoidable for completeness/falsifiability, identifies `Derived From`, states why necessary and changes no user capability, business rule or scope;
|
|
43
|
-
- `delegated`: a defensible choice requested by instructions to synthesize/refine/use judgment, records `Delegated By`, preference/evidence basis and exact added meaning;
|
|
44
|
-
- `evidence-backed`: repository/Context fact with exact source and no promotion of incidental code shape to product intent;
|
|
45
|
-
- `decision_required`: conflicting authority, explicitly user-reserved choice, missing material preference or no defensible recommendation.
|
|
16
|
+
4. For visual resources, preserve selection basis, classification (`exact-target`, `constraint` or `inspiration`), stable resource/surface/control/state/target keys, declared platform/viewport/mode/state/content applicability, source profile/canonical entry/dependency set, provider/project/run/entry provenance and immutable digest/snapshot, plus typed locators. A mutable link, metadata-only response, partial file set or prose locator is incomplete. Unselected candidates authorize no fidelity.
|
|
17
|
+
5. Record incorporated meaning and every unreadable, conflicting or intentionally unused part. Higher authority and user-stated precedence win; unresolved conflicts remain decisions.
|
|
18
|
+
|
|
19
|
+
## Preference and research gate
|
|
20
|
+
|
|
21
|
+
Before comparative research or a material product, technical, architecture or provider selection, identify decision-changing criteria such as fidelity versus cost, delivery speed, reliability/support, privacy/compliance, lock-in/control, operational burden, platform scope and extensibility.
|
|
22
|
+
|
|
23
|
+
Infer preferences only from user words, Source, Context or controlling constraints. If an unknown preference would materially change research or recommendation, ask one concise targeted clarification before proceeding. Do not impose a questionnaire, re-ask known preferences or pause for minor reversible choices with the same defensible recommendation.
|
|
24
|
+
|
|
25
|
+
Use current primary/authoritative evidence for changing external facts. Record source, scope and retrieval date. Preference clarification authorizes plan meaning, not payment, contracting, deployment/publication, destructive production mutation, permission grants, sensitive-data transmission or required legal/security/human approval; those remain typed external confirmations.
|
|
26
|
+
|
|
27
|
+
## Working strategies, not phases
|
|
28
|
+
|
|
29
|
+
Choose locally as needed while revising the same Draft; do not expose these as lifecycle stages or ask the user to choose:
|
|
30
|
+
|
|
31
|
+
- **refinement:** preserve and complete a substantially developed proposal;
|
|
32
|
+
- **synthesis:** build coherent Source from a goal plus mixed inputs;
|
|
33
|
+
- **hybrid:** use one proposal as backbone and fill gaps from other inputs.
|
|
34
|
+
|
|
35
|
+
A short request is sufficient when roles, goal and reference authority are recoverable. Reuse an authorized writable proposal as the real Source. If the delivery exists only in conversation, materialize exactly one project-native Markdown Source according to repository convention. Do not create a parallel planning artifact.
|
|
36
|
+
|
|
37
|
+
## Semantic authoring
|
|
38
|
+
|
|
39
|
+
For every material item, preserve one origin:
|
|
40
|
+
|
|
41
|
+
- `direct`: stated by user or controlling input, with all qualifiers;
|
|
42
|
+
- `derived`: unavoidable for completeness/falsifiability, identifies `Derived From`, states why necessary and changes no user capability, business rule or scope;
|
|
43
|
+
- `delegated`: a defensible choice requested by instructions to synthesize/refine/use judgment, records `Delegated By`, preference/evidence basis and exact added meaning;
|
|
44
|
+
- `evidence-backed`: repository/Context fact with exact source and no promotion of incidental code shape to product intent;
|
|
45
|
+
- `decision_required`: conflicting authority, explicitly user-reserved choice, missing material preference or no defensible recommendation.
|
|
46
|
+
|
|
47
|
+
High impact or several options is not itself a reason to pause when criteria support one recommendation. Keep real high-risk actions as external confirmations. Never introduce a requirement for the first time only inside acceptance criteria.
|
|
48
|
+
|
|
49
|
+
## Structure and stable keys
|
|
50
|
+
|
|
51
|
+
Use stable semantic lowercase-kebab keys and Markdown anchors where practical. Preserve keys when wording changes but meaning does not; never renumber for ordering or reuse a retired key for new meaning.
|
|
52
|
+
|
|
53
|
+
Define vertical Outcomes only when observable results are independently decidable and later verifiable. Do not split by response length, frontend/backend layer, module count, agent capacity or desired parallelism; do not merge distinct results merely for brevity.
|
|
54
|
+
|
|
55
|
+
Use only applicable semantic types:
|
|
56
|
+
|
|
57
|
+
- result/Outcome;
|
|
58
|
+
- Requirement (`REQ`);
|
|
59
|
+
- user-visible Control (`CTRL`);
|
|
60
|
+
- technical obligation (`OBL`);
|
|
61
|
+
- explicitly non-completing meaning (`NCOMP`);
|
|
62
|
+
- acceptance scenario (`AC`);
|
|
63
|
+
- global non-goal/constraint and forbidden shortcut;
|
|
64
|
+
- risk with exact Fact, Affected Outcome, Basis and Consequence;
|
|
65
|
+
- external confirmation (`EXT`);
|
|
66
|
+
- genuine decision (`DEC`);
|
|
67
|
+
- advisory implementation hint (`HINT`), which is not a material requirement.
|
|
46
68
|
|
|
47
|
-
|
|
69
|
+
## Non-UI semantic completeness
|
|
48
70
|
|
|
49
|
-
|
|
71
|
+
For every non-UI delivery, the authoring default is the finest independently decidable semantic Fact supported by direct Source, necessary logical derivation, explicit delegation or evidence-backed preservation. Do not stop at prose paragraphs, Requirements, Product Controls, user stories, broad acceptance scenarios, an `all-states`/`all-errors` catalogue or whatever fields current code happens to expose.
|
|
50
72
|
|
|
51
|
-
|
|
73
|
+
Before implementation and formal Compile:
|
|
52
74
|
|
|
53
|
-
|
|
75
|
+
1. Inventory every material request fragment, attachment, controlling Context unit, canonical schema/specification, selected external constraint, repository-preservation source and delegated instruction with stable identity, digest, disposition and basis. Ordinary Material Source is `non_ui_material` and must contribute Fact lineage. A validated design handoff may classify its independently closed visual facts as `ui_design`; `supporting_only` and `excluded_by_scope` need exact rationale/basis and cannot hide a requirement.
|
|
76
|
+
2. Explicitly disposition every standard semantic family for every Outcome and add custom families discovered from Source/repository/domain structure. The standard floor covers goal/scope/glossary; actors/roles/tenants/entitlements; business rules/calculations; data; operations/workflows/state/time; validation/output/error/API/protocol/event/job; persistence/cache/search/transactions/consistency/concurrency/idempotency; fault/retry/degradation/recovery/backup; configuration/flags/secrets; compatibility/migration/rollout; performance/capacity/cost/reliability/SLO; security/privacy/safety/compliance; observability/deployment/operations; integrations/notification/file/media/localization/commercial; hardware; AI/ML; architecture ownership/boundaries/debt.
|
|
77
|
+
3. Give every applicable outcome, actor, policy, entity/field/relation, operation, state/transition, interface/message/job, store/index/transaction/cache, configuration/migration/deployment/dependency, security/privacy boundary, SLO/signal/alert/runbook, device/AI/custom unit a stable subject/relation/population identity. Preserve hierarchy, owner, cardinality, causality, ordering, producer/consumer, source-of-truth and dependency relations. Static/dynamic populations need exact universe/partition/enumeration/exclusion identity.
|
|
78
|
+
4. Disposition every standard and custom condition axis. Enumerate each atomic applicable value and exact combination across actors/roles/tenants/jurisdictions/environments/regions/platforms/versions/features/configuration/entitlements/permissions/consent/sessions/states/input/boundary/data volume/locale/time/concurrency/repetition/dependency health/connectivity/failure/retry/consistency/freshness/migration/rollout/topology/threat/mode. Continuous domains use explicit ranges/boundaries; invariance/equivalence may share execution only while retaining distinct Fact identity and verdict. No aggregate, representative, pairwise or default-path substitute.
|
|
79
|
+
5. Disposition every standard and custom atomic property per unit and condition. One specified cell creates one Fact with typed value semantics, exact Source locator/digest, owner, quantifier, observation boundary, sensitivity and provenance. Every N/A/exclusion names exact affected identities, basis and rationale; `decision_required`, `unavailable`, unreadable or conflicting meaning remains blocking.
|
|
80
|
+
6. Expand every Fact into all required proof methods—exact/schema/decision-table/formula/invariant/transition/sequence/durable roundtrip/boundary/external effect/population/concurrency/idempotency/fault/recovery/migration/compatibility/performance/capacity/security/privacy/audit/observability/deployment/structure or custom TCB method. Freeze comparator, parameters, tolerance/mask, Oracle identity/capability, environment, observer and protected-value policy. Reach the furthest independently failing boundary; request issuance, parser success, self-reported success, artifact existence or a nearer proxy does not prove downstream persistence/effect/recovery.
|
|
81
|
+
7. Embed one complete `semantic-fact-manifest-v1` in declared Source. Its Inspector Census and collection counts/identity digests prove deterministic complete generation with no truncation or sampling. Require `Expected Semantic Facts = Source Indexed Facts`; later Contract authoring requires exact Fact and Fact×method projection. Values remain in Source/Context; Contract receives identities, located digests and comparison authority only.
|
|
54
82
|
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
- result/Outcome;
|
|
58
|
-
- Requirement (`REQ`);
|
|
59
|
-
- user-visible Control (`CTRL`);
|
|
60
|
-
- technical obligation (`OBL`);
|
|
61
|
-
- explicitly non-completing meaning (`NCOMP`);
|
|
62
|
-
- acceptance scenario (`AC`);
|
|
63
|
-
- global non-goal/constraint and forbidden shortcut;
|
|
64
|
-
- risk with exact Fact, Affected Outcome, Basis and Consequence;
|
|
65
|
-
- external confirmation (`EXT`);
|
|
66
|
-
- genuine decision (`DEC`);
|
|
67
|
-
- advisory implementation hint (`HINT`), which is not a material requirement.
|
|
83
|
+
This expansion cannot invent a real product/legal/security/commercial/safety choice. A defensible delegated choice must first become traceable Material Source; an unsupported or user-reserved choice remains a blocker or typed External Confirmation. The named Inspector/Oracle is an explicit trusted-computing boundary, and custom extensions are mandatory when the standard catalog cannot observe the domain.
|
|
68
84
|
|
|
69
85
|
## UI and control completeness
|
|
70
|
-
|
|
86
|
+
|
|
71
87
|
For each in-scope surface, record purpose, entry/exit/navigation, regions/overlays and included Control keys. For every real material interactive Control, close every canonical field independently:
|
|
72
|
-
|
|
73
|
-
`surface`, `region`, `location`, `control type`, `label/content`, `user task`, `visibility`, `availability`, `trigger`, `input`, `validation`, `default`, `interaction`, `navigation/result`, `loading`, `empty`, `success`, `failure`, `recovery`, `permission`, `feedback` and `accessibility`.
|
|
74
|
-
|
|
88
|
+
|
|
89
|
+
`surface`, `region`, `location`, `control type`, `label/content`, `user task`, `visibility`, `availability`, `trigger`, `input`, `validation`, `default`, `interaction`, `navigation/result`, `loading`, `empty`, `success`, `failure`, `recovery`, `permission`, `feedback` and `accessibility`.
|
|
90
|
+
|
|
75
91
|
For each field record concrete `specified` meaning, an explicit justified `not_applicable` statement, or blocking `unresolved`; omission is not non-applicability. Also preserve every material cross-Control and system relation—including shared state, ordering/dependency, mutual exclusion, navigation, permission, recovery, validation and feedback chains—and explicitly close the Outcome as `not_applicable` only when no such relation exists. Each specified or not-applicable fact, including relation closure, must name its actual target, atomic condition/input/state dimensions and Given/When journey applicability.
|
|
76
|
-
|
|
77
|
-
Do not invent controls for a non-interface delivery. A coarse frame or configured design system does not supply unshown states. Selected design resources and product/technical Source remain parallel: visuals cannot invent business/data/permission/algorithmic rules.
|
|
78
|
-
|
|
79
|
-
For every selected exact/constraint target, preserve the declared platform/viewport/mode/state/content conditions and identify which surface and Control keys it governs.
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
+
|
|
93
|
+
Do not invent controls for a non-interface delivery. A coarse frame or configured design system does not supply unshown states. Selected design resources and product/technical Source remain parallel: visuals cannot invent business/data/permission/algorithmic rules.
|
|
94
|
+
|
|
95
|
+
For every selected exact/constraint target, preserve the declared platform/viewport/mode/state/content conditions and identify which surface and Control keys it governs. A formal Web/App handoff also preserves its canonical Fact-manifest identity, frozen Inspector/Census and the exact handoff projection of condition axes/combinations, subject hierarchy, subject-local variations, atomic properties, Fact Cells/Facts, proof obligations, Oracles/environments, design-system lineage, assets and blockers. Product Controls and eight UI/UX dimensions are semantic/roll-up owners, not the Fact ceiling. Do not collapse a component instance or Anatomy Part into its family, several states into `all-states`, several conditions into one label, or several property/method obligations into one broad visual claim. Canonical resources retain exact values; Source and Contract retain stable Fact identities and located-digest/comparison authority rather than copied CSS.
|
|
96
|
+
|
|
97
|
+
Before Compile, confirm the formal handoff already proves `Expected Fact Universe = Canonical Resource Facts = Handoff Indexed Facts`, including explicit N/A/exclusion basis and non-sampling/non-truncation. Each covered Fact has all property-required verification methods, and each exact target condition has full-target layout and pixel Facts. Separately record any design-resource acceptance blocker supplied by the Source, including its exact Source items, verification methods and non-empty runtime-observation `required_capabilities`. Do not weaken a physical-device, sensor, camera, orientation, haptic, assistive-technology, pixel-density, safe-area or other target-local need into a generic browser/runtime label merely because the proxy is available. File identity, hashes, provider/export success, registry membership, Census counts and preflight are integrity/input-closure facts only; they do not state that a production owner, real-user journey or rendered interaction conforms.
|
|
98
|
+
|
|
99
|
+
## Acceptance and risk
|
|
100
|
+
|
|
101
|
+
Each AC has exactly one Given/When/Then scenario, names the REQ/CTRL/OBL/NCOMP meaning it accepts and introduces no undeclared product semantics. Keep representative/sample/framework checks distinct from full-population claims and partial delivery distinct from completion.
|
|
102
|
+
|
|
103
|
+
Use the Runtime's exact risk Fact names when marking risk. Data migration is `data_migration`; a weakly observable critical path is separate `critical_user_path` and `weak_observability` facts; preserve `multi_repository_change` in Source so Contract compilation can reject unsupported delivery honestly.
|
|
104
|
+
|
|
105
|
+
## Preflight/Compile convergence audit
|
|
106
|
+
|
|
107
|
+
Before Preflight/Compile confirm:
|
|
108
|
+
|
|
109
|
+
1. Every material original statement and qualifier is preserved.
|
|
92
110
|
2. Every supplied input is incorporated or has an explicit unreadable/unused/conflict disposition, and every non-empty Source line is owned by a Material Item, closed-grammar structure/provenance background block or validated formal block.
|
|
93
|
-
3. Distinct requirements and independently decidable Outcomes were not collapsed.
|
|
94
|
-
4. Every real Control has all 22 canonical fields closed as specified, justified not applicable or unresolved; every material cross-Control/shared-state/navigation/permission/recovery relation is specified or the Outcome explicitly declares that no such relation exists.
|
|
95
|
-
5. Every REQ, specified/not-applicable CTRL field and Control relation has exact applicability plus acceptance, external confirmation, decision or explicit exception; unresolved coverage blocks.
|
|
96
|
-
6. Derived/delegated/evidence-backed items have traceable basis and no hidden product expansion.
|
|
97
|
-
7. Non-goals, forbidden shortcuts, risks and recovery are concrete.
|
|
98
|
-
8. No unsupported number, threshold, metric or external claim appears.
|
|
99
|
-
9. Selected design resources retain stable identity and exact declared coverage; candidates remain non-authoritative.
|
|
100
|
-
10. Every material UI
|
|
111
|
+
3. Distinct requirements and independently decidable Outcomes were not collapsed.
|
|
112
|
+
4. Every real Control has all 22 canonical fields closed as specified, justified not applicable or unresolved; every material cross-Control/shared-state/navigation/permission/recovery relation is specified or the Outcome explicitly declares that no such relation exists.
|
|
113
|
+
5. Every REQ, specified/not-applicable CTRL field and Control relation has exact applicability plus acceptance, external confirmation, decision or explicit exception; unresolved coverage blocks.
|
|
114
|
+
6. Derived/delegated/evidence-backed items have traceable basis and no hidden product expansion.
|
|
115
|
+
7. Non-goals, forbidden shortcuts, risks and recovery are concrete.
|
|
116
|
+
8. No unsupported number, threshold, metric or external claim appears.
|
|
117
|
+
9. Selected design resources retain stable identity and exact declared coverage; formal Web/App handoffs retain manifest-backed atomic Fact/proof universes with no aggregate, sampled or truncated coverage; candidates remain non-authoritative.
|
|
118
|
+
10. Every material UI Fact and Control can be mapped to a production target/owner, real-user entry journey and independently attributable acceptance route, while every declared design blocker has an explicit machine or target-blocking external-confirmation disposition. Removing one from scope requires an explicit Source revision; Contract prose cannot waive it.
|
|
101
119
|
11. The Source is self-contained enough to own every mapped Draft semantic and names every still-required external artifact.
|
|
102
120
|
12. At least one marked `technical_obligation` carries `aspect=architecture`, preserves the selected owner/dependency/debt conclusion, and maps to an independently falsifiable architecture obligation rather than only a Result Claim.
|
|
103
|
-
|
|
121
|
+
13. The one `semantic-fact-manifest-v1` exactly inventories all material non-UI inputs and complete standard/custom family, unit/relation/population, condition, property, Fact and proof-obligation universes; every ordinary Material Source Item contributes exact Fact lineage, all generation collections have complete count/digest closure, and no aggregate/sample/ungrounded N/A/unresolved row is hidden.
|
|
122
|
+
|
|
104
123
|
Complete non-rendering `ty-source-item:start/end` markers in the real Markdown Source without rewriting direct text, wrap only recognized Markdown structure or structured provenance in uniquely keyed and reasoned `ty-source-background:start/end` blocks, retain at most one schema-valid `design-resource-handoff-v1` formal block, and finish the corresponding Contract mapping in the same loop. Unclassified text, arbitrary prose inside background, a background block used to hide material meaning, unresolved Control coverage or missing applicability blocks Preflight/Compile. Neither markers nor this audit delay opening the Draft.
|
|
@@ -1,14 +1,14 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: source-plan-authoring
|
|
3
|
-
description: Retired compatibility pointer for users who explicitly
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Retired: Source Plan Authoring
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
For an explicit long delivery,
|
|
11
|
-
|
|
12
|
-
For non-long work, give the proposal and selected resources directly to the current native Goal under the default Workflow Contract. If the user only wants an initial product or technical proposal, use the applicable proposal-authoring capability rather than recreating this retired intermediary.
|
|
13
|
-
|
|
14
|
-
A pre-existing Source Plan remains valid ordinary Source. Do not rewrite it merely for compatibility, create a new Source Plan artifact, invoke Long-Task automatically, or create a second plan, Contract Draft, Preflight, Compile, Receipt, Authority or state surface from this pointer.
|
|
1
|
+
---
|
|
2
|
+
name: source-plan-authoring
|
|
3
|
+
description: Retired compatibility pointer for users who explicitly select source-plan-authoring or request the former standalone Source Plan stage. Direct long deliveries to long-task-workflow, where raw or revised proposals, selected design resources and mixed attachments enter one Source-bound Contract Draft loop immediately. Do not create a legacy standalone Source Plan or internal Source-authoring stage, gate, schema, state or second plan.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Retired: Source Plan Authoring
|
|
7
|
+
|
|
8
|
+
`source-plan-authoring` no longer defines a separate handoff between the initial proposal and Long-Task execution.
|
|
9
|
+
|
|
10
|
+
For an explicit long delivery, select `$long-task-workflow` in Codex (or use the host's Skill selector) with the initial/revised proposal, selected immutable design resources and other attachments. They enter the same `delivery-contract.yaml` Draft immediately; input inventory, Source-quality synthesis/refinement, stable semantic keys, Product Control-level UI meaning, acceptance scenarios, research/delegation traceability, real Source marking, repository binding and Contract mapping converge in one Goal before Preflight/Compile. Product Control projection does not cap selected design-resource granularity: the active workflow separately preserves every supported complete observable design fact through the handoff and Contract. Likewise, a paragraph/Requirement/current-code shape does not cap non-UI granularity: the active workflow inventories all material inputs, expands the standard plus custom product/business/backend/architecture domain families into exact subjects/relations/populations, conditions, atomic properties, semantic Facts and Fact×method obligations, persists one Source `semantic-fact-manifest-v1`, and requires exact Contract/current-Final-Gate closure without aggregate or sampled substitution.
|
|
11
|
+
|
|
12
|
+
For non-long work, give the proposal and selected resources directly to the current native Goal under the default Workflow Contract. If the user only wants an initial product or technical proposal, use the applicable proposal-authoring capability rather than recreating this retired intermediary.
|
|
13
|
+
|
|
14
|
+
A pre-existing Source Plan remains valid ordinary Source. Do not rewrite it merely for compatibility, create a new Source Plan artifact, invoke Long-Task automatically, or create a second plan, Contract Draft, Preflight, Compile, Receipt, Authority or state surface from this pointer.
|