project-tiny-context-harness 0.6.1 → 0.6.2

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.
@@ -9,7 +9,7 @@ description: Author, preflight, execute, resume, verify, or close one complete S
9
9
 
10
10
  Use one current native Goal, one repository, one selected workspace, one complete Contract and one Final Gate. Never create a scheduler, model worker, agent runtime, App Server, branch, worktree, merge, push, PR, deployment, Campaign/SFC/Packet/Wave chain, matrix, verdict or second Contract plan. Never activate from task size alone.
11
11
 
12
- The host and user own model selection. The workflow has exactly one user-choice checkpoint after the first Authority Lock and before implementation; Harness neither switches the model nor persists model-routing/checkpoint state. No checkpoint file, acknowledgement state, model route, model-tier scheduler or automatic model switch is created. Outside that boundary, do not pause a healthy Goal solely to change or downgrade the model. Capability-related drift is handled by targeted repair plus the Final Gate. Never proactively spawn, assign or coordinate parallel subagents. Platform-native internal delegation, if it occurs, is opaque and non-authoritative and must converge into the unified current workspace snapshot before verification can count.
12
+ The host and user own model selection. The workflow has exactly one user-choice checkpoint after the first Authority Lock and before implementation; Harness neither switches the model nor persists model-routing/checkpoint state. No checkpoint file, acknowledgement state, model route, model-tier scheduler or automatic model switch is created. Outside that boundary, do not pause a healthy Goal solely to change or downgrade the model. Do not create a separate approval checkpoint for a defensible recommended plan choice. A targeted pre-Authority clarification is still required when a missing user preference could materially change research or selection; genuine Source conflicts or choices the user explicitly reserves may likewise require a decision before Authority Lock. Capability-related drift is handled by targeted repair plus the Final Gate. Never proactively spawn, assign or coordinate parallel subagents. Platform-native internal delegation, if it occurs, is opaque and non-authoritative and must converge into the unified current workspace snapshot before verification can count.
13
13
 
14
14
  `long-task-delivery-v2` is the only active Contract schema. `delivery-contract.yaml` is the root authoring file. New authoring uses inline Outcomes; existing `outcome_files` are physical compatibility only. `delivery-set` is retired and non-executing.
15
15
 
@@ -48,10 +48,11 @@ A Draft Outcome is an Outcome in that pre-Authority-Lock Draft, not a new schema
48
48
  3. Otherwise author one complete Delivery Contract for the whole selected delivery. Do not create a second Contract plan, matrix or top-level Contract split.
49
49
  4. Preserve at least one real `source_path`. Wrap every material Source item in its original Markdown with non-rendering `ty-source-item:start/end` markers without rewriting the text; marked Source Item keys and `source_claim` keys are exactly equal.
50
50
  5. An ordinary prose plan or optional Source Plan remains valid Source after marker-only enumeration and does not need to match the recommended Source Plan structure. Preserve stable semantic keys and Markdown anchors where practical.
51
- 6. Continue reading repository, Source and Context and revise the same Draft. Return for a real decision when requirements conflict, critical semantics are missing, multiple materially different product designs remain, the user must choose a product rule or no falsifiable acceptance standard can be formed.
52
- 7. Contract expansion is limited to meaning-preserving structural decomposition and repository binding supported by real repository and Context evidence. A product choice already authored in Source under a recorded explicit user delegation is Source meaning: preserve it, but do not extend that delegation. Any other new business rule, default, threshold, recovery behavior, permission or platform/data scope is `decision_required` and must not be silently added.
53
- 8. Run read-only `ty-context long-task preflight <workdir>`, repair every error and `decision_required` finding in the same Draft, then formally Compile only when ready.
54
- 9. When the first Compile returns `execution_model_checkpoint.required: true`, stop before implementation and ask the user to choose `continue_current_model` or switch models and then resume the active Long-Task. A task-specific choice already stated explicitly satisfies the checkpoint. Later revisions return `required: false` and do not repeat it.
51
+ 6. Continue reading repository, Source and Context and revise the same Draft. A request to synthesize, refine, complete, implement or use judgment delegates plan-level authoring, but it does not invent the user's tradeoff priorities. Before comparative research or a material product, technical, architecture or provider selection, identify the criteria that could change the research scope, candidate set or recommendation. Infer them only from the user's words, Source, Context or controlling constraints. If quality versus cost, speed, reliability, privacy, lock-in, operational burden or another material priority is unknown or ambiguous, stop before that research or selection and ask one concise targeted clarification. Do not impose a questionnaire, re-ask known preferences or interrupt minor reversible choices whose recommendation would not change.
52
+ 7. Once the material preference envelope is clear, decide what research is needed. Use current authoritative or primary evidence for external capability, pricing, quota, license, compatibility, region, security posture or support claims. When one recommendation is then defensible, record it in real Source with the authoring instruction, preference/evidence basis and exact added meaning instead of pausing for approval. Append the delegated item without rewriting the user's original text when ordinary prose is the Source. Return only when authoritative requirements conflict, the user explicitly reserves the choice, a material preference remains unknown, critical semantics have no defensible recommendation or no falsifiable acceptance standard can be formed.
53
+ 8. Contract expansion remains limited to meaning-preserving structural decomposition, evidence-backed repository binding and choices first recorded as delegated real Source. Never place a new product rule, default, threshold, recovery behavior, permission or platform/data scope only in Contract YAML. Default plan delegation authorizes meaning, not action: payment, contracting, production deployment or publication, destructive production mutation, real permission grants, sensitive-data transmission and required legal/security/human approval remain named external confirmations. Any conflicting, user-reserved, missing-preference or unsupported semantic remains `decision_required`.
54
+ 9. Run read-only `ty-context long-task preflight <workdir>`, repair every error and `decision_required` finding in the same Draft, then formally Compile only when ready.
55
+ 10. When the first Compile returns `execution_model_checkpoint.required: true`, stop before implementation and ask the user to choose `continue_current_model` or switch models and then resume the active Long-Task. A task-specific choice already stated explicitly satisfies the checkpoint. Later revisions return `required: false` and do not repeat it.
55
56
 
56
57
  Architecture quality uses the existing authority model, not a new gate: when Source or controlling Context declares an architecture invariant, encode it as a Source-backed technical obligation/global constraint/forbidden shortcut plus owner/path/Binding boundaries and a project-owned executable Check. Functional acceptance cannot substitute when the architecture claim can fail independently. An unverifiable design preference remains task-local, durable Context or `decision_required`; it must not be promoted into false proof.
57
58
 
@@ -1,4 +1,4 @@
1
- interface:
2
- display_name: "Long-Task Workflow"
3
- short_description: "Run one Delivery Contract in the current native Goal"
4
- default_prompt: "Use /long-task-workflow to prepare, execute, resume, verify, or close one Canonical Delivery Contract in the current workspace."
1
+ interface:
2
+ display_name: "Long-Task Workflow"
3
+ short_description: "Run one Delivery Contract in the current native Goal"
4
+ default_prompt: "Use /long-task-workflow to prepare, execute, resume, verify, or close one Canonical Delivery Contract in the current workspace."
@@ -7,10 +7,12 @@ Read this only while authoring or structurally revising the one `delivery-contra
7
7
  - Every declared Source file contains at least one Material Source Item. Mark items in original Markdown without rendering or changing meaning.
8
8
  - Marker keys and `source_claim` keys are set-equal and globally unique. `statement` preserves marked text after line-ending normalization, surrounding blank-line removal and trailing-space cleanup.
9
9
  - Typed dispositions keep Result, Requirement, Control, Technical Obligation, Non-completing Claim, Acceptance, Global Constraint/Non-goal, Forbidden Shortcut, Risk, External Confirmation and Decision distinct.
10
- - Every non-decision Source item owns exactly one same-kind, text-identical canonical target; no target may collapse multiple Source items. `out_of_scope` is not a resolution.
11
- - A Source AC maps criterion-identically to one named Assertion and proves at least one independently Source-backed non-Result Claim.
12
- - Missing recommended Source Plan headings or keys never blocks authoring. Missing mandatory Material Source Item markers does.
13
- - `delegated` in a Source Plan is provenance, not a Contract disposition or new Claim kind. When the plan records the explicit user instruction, basis and added meaning, preserve that keyed item as ordinary Source of its semantic kind. Do not use its delegation to invent further product choices during Contract authoring.
10
+ - Every non-decision Source item owns exactly one same-kind, text-identical canonical target; no target may collapse multiple Source items. `out_of_scope` is not a resolution.
11
+ - A Source AC maps criterion-identically to one named Assertion and proves at least one independently Source-backed non-Result Claim.
12
+ - Missing recommended Source Plan headings or keys never blocks authoring. Missing mandatory Material Source Item markers does.
13
+ - `delegated` in a Source Plan is provenance, not a Contract disposition or new Claim kind. An instruction to synthesize, refine, complete, implement or use judgment delegates plan-level authoring, but it does not invent material tradeoff preferences. Before comparative research or a material product, technical, architecture or provider selection, identify the criteria that could change the research scope, candidate set or recommendation. If such a preference is unknown or ambiguous, ask a concise targeted question before research or selection and keep the item `decision_required` until answered; do not impose a fixed questionnaire or re-ask preferences already supplied by the user, Source, Context or controlling constraints.
14
+ - Once the material preference envelope is clear, use current authoritative or primary evidence for external capability, price, quota, license, compatibility, region, security posture or support claims. When one defensible recommendation exists, record the authoring instruction, preference/evidence or conservative-default basis and exact added meaning in real Source, then preserve that keyed item as ordinary Source of its semantic kind. If ordinary prose is the Source, append the delegated item without rewriting the user's original text; never place the choice only in Contract YAML.
15
+ - A delegated plan choice is not action authorization. Payment, contracting, production deployment/publication, destructive production mutation, real permission grants, sensitive-data transmission and required legal/security/human approval remain named External Confirmations. Conflicting authority, an explicitly user-reserved choice, a missing material preference or the absence of a defensible recommendation remains `decision_required`; high impact or multiple options with known criteria alone does not.
14
16
 
15
17
  ## Outcome Boundary
16
18
 
@@ -28,7 +30,7 @@ For every Outcome declare:
28
30
 
29
31
  Global non-goals, constraints and forbidden shortcuts remain Global authority and use Global Checks/Assertions when machine proof is required.
30
32
 
31
- ## Architecture Closure
33
+ ## Architecture Closure
32
34
 
33
35
  Architecture protection is risk-triggered and project-specific. Use it when the delivery declares module ownership, unique source of truth, dependency direction, API/schema/data boundary, state lifecycle, persistence/recovery, security boundary, compatibility/migration or a forbidden bypass.
34
36
 
@@ -40,21 +42,21 @@ Represent the invariant with existing Contract fields:
40
42
  4. a project-owned executable architecture check, such as the repository's lint, AST, dependency or contract test;
41
43
  5. a separate Assertion when functional behavior could pass while the architecture invariant fails.
42
44
 
43
- Do not encode subjective “clean architecture” or generic quality prose as machine authority. If no reliable observation can falsify it, keep it as durable Context/review judgment or return `decision_required`. Harness routes the repository's architecture check; it does not become a language-generic dependency analyzer.
44
-
45
- ## Visual Delivery Authoring
46
-
47
- When Source or controlling Context declares a design system, redesign, high-fidelity UI or other material visual result, author it through existing Contract semantics:
48
-
49
- - derive a task-local, risk-proportional Visual Coverage Set from declared Source, `project_context/**` and `DESIGN.md`: production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions;
50
- - select representative combinations rather than silently creating a full Cartesian requirement; an omitted combination remains unproven, while Source that explicitly requires full coverage must retain that scope;
51
- - encode each independently falsifiable visual expectation as an atomic Requirement, applicable Control field or named AC Assertion. Name the surface, viewport, theme/state/content condition and observable result when they matter to the claim;
52
- - bind the declared result to the owning Context/`DESIGN.md`, one authored token source and generation direction, production component/route carriers, path envelopes and project-owned browser checks. Detached kits, mocks or marketing specimens may be references but not substitute implementation carriers;
53
- - keep subjective visual direction, taste or approval outside false machine proof. Resolve an undecided direction as `decision_required`; represent required human design or new-baseline approval as an explicit external confirmation.
54
-
55
- This guidance adds no visual Schema, Claim kind, risk level, lifecycle state, coverage artifact or Gate. It only makes visual meaning explicit enough for the existing Requirement/Control/Assertion and `ui_browser` mechanisms to verify what was actually declared.
56
-
57
- ## Compact Authoring
45
+ Do not encode subjective “clean architecture” or generic quality prose as machine authority. If no reliable observation can falsify it, keep it as durable Context/review judgment or return `decision_required`. Harness routes the repository's architecture check; it does not become a language-generic dependency analyzer.
46
+
47
+ ## Visual Delivery Authoring
48
+
49
+ When Source or controlling Context declares a design system, redesign, high-fidelity UI or other material visual result, author it through existing Contract semantics:
50
+
51
+ - derive a task-local, risk-proportional Visual Coverage Set from declared Source, `project_context/**` and `DESIGN.md`: production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions;
52
+ - select representative combinations rather than silently creating a full Cartesian requirement; an omitted combination remains unproven, while Source that explicitly requires full coverage must retain that scope;
53
+ - encode each independently falsifiable visual expectation as an atomic Requirement, applicable Control field or named AC Assertion. Name the surface, viewport, theme/state/content condition and observable result when they matter to the claim;
54
+ - bind the declared result to the owning Context/`DESIGN.md`, one authored token source and generation direction, production component/route carriers, path envelopes and project-owned browser checks. Detached kits, mocks or marketing specimens may be references but not substitute implementation carriers;
55
+ - keep subjective visual direction, taste or approval outside false machine proof. Resolve an undecided direction as `decision_required`; represent required human design or new-baseline approval as an explicit external confirmation.
56
+
57
+ This guidance adds no visual Schema, Claim kind, risk level, lifecycle state, coverage artifact or Gate. It only makes visual meaning explicit enough for the existing Requirement/Control/Assertion and `ui_browser` mechanisms to verify what was actually declared.
58
+
59
+ ## Compact Authoring
58
60
 
59
61
  Compact V2 may omit only deterministic defaults: empty optional arrays/nulls, `context_snapshot_mode: referenced`, `requested_level: auto`, runner `argv: []`, `cwd: .`, `timeout_ms: 30000`, `retry_policy: none`, `idempotent: false`, and empty output/artifact/assertion/environment lists.
60
62
 
@@ -17,24 +17,24 @@ Evidence adapter is derived from runner kind. Only Playwright may prove `ui_brow
17
17
 
18
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
19
 
20
- ## Playwright
20
+ ## Playwright
21
21
 
22
22
  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.
23
23
 
24
24
  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.
25
25
 
26
- 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.
27
-
28
- ## Visual UI Evidence
29
-
30
- - 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.
31
- - 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.
32
- - 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.
33
- - 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.
34
- - 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.
35
- - 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.
36
-
37
- ## Structured Evidence And Sensitivity
26
+ 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.
27
+
28
+ ## Visual UI Evidence
29
+
30
+ - 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.
31
+ - 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.
32
+ - 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.
33
+ - 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.
34
+ - 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.
35
+ - 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.
36
+
37
+ ## Structured Evidence And Sensitivity
38
38
 
39
39
  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.
40
40
 
@@ -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.