project-tiny-context-harness 0.2.85 → 0.6.0

package/assets/skills/composite-long-task-workflow/SKILL.md

@@ -1,245 +0,0 @@
----
-name: composite-long-task-workflow
-description: Use when directly invoked for Superpowers-backed composite long-task workflow execution.
----
-
-# Composite Long-Task Workflow Skill
-
-中文显示名：多组合长程任务工作流 Skill
-
-## Package-Managed Boundary
-
-This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `composite-long-task-workflow` Skill directly in a consumer project.
-
-This Skill is a Tiny Context-owned composite workflow adapter for Superpowers-backed long-task execution. It is aligned to official Superpowers skills while remaining Tiny Context-owned rather than an upstream-owned schema. It may wrap Superpowers with authority, conformance and acceptance gates. It must not redefine, duplicate or fork official Superpowers execution mechanics.
-
-## Direct Invocation
-
-Use this Skill through explicit invocation:
-
-```text
-/composite-long-task-workflow
-```
-
-Do not rely on broad automatic keyword routing. `/normal-long-task` remains useful for ordinary acceptance preparation, but this Skill does not require it when Product / Architecture Source, Technical Realization Plan and Acceptance Checklist already exist.
-
-## Purpose
-
-This Skill combines three existing upstream inputs into a state-backed execution entry:
-
-- Product / Architecture Source: intent, scope, non-goals, product and architecture boundaries.
-- Technical Realization Plan: PI implementation blueprint, executable plan items and plan conformance.
-- Acceptance Checklist: AC completion semantics, proof layers, invalid evidence rules and final acceptance.
-
-It outputs the task workdir entry artifacts:
-
-- `workflow-protocol.md`: frozen package protocol snapshot for this task.
-- `execution-binding.md`: this task's concrete source, state, command and completion binding.
-- `goal-objective.txt`: thin Codex Goal objective that names what to read, which sources are authoritative, and when completion is allowed.
-- `task-state.json`, `events.ndjson` and generated `derived/**` views remain the canonical state kernel and generated reading views.
-
-Goal objective text is an output capability, not the whole responsibility of this Skill.
-
-## Expected Runtime Effect / 预期实现效果
-
-This Skill makes long-running implementation work explicit and recoverable. It does not ask an agent to freely merge many soft constraints. It writes the fusion order into the workflow:
-
-```text
-Tiny Context Workflow Contract
--> three-input source authority
--> task-state.json compilation
--> Superpowers implementation slices
--> canonical state and evidence updates
--> generated derived/** views
--> slice / epoch gates
--> final-gate computes product_goal_complete
--> completion-output resolver emits accept / reject / blocked
-```
-
-The runtime effect is one temporary Codex Goal workflow that combines:
-
-- Tiny Context Workflow Contract: Context Priority Ladder, Context Delta, Source-to-Context Coverage, Context-to-Implementation Binding, Contract Conformance and Context drift check.
-- Project Context: `project_context/global.md`, `project_context/architecture.md`, `project_context/context.toml`, relevant `project_context/areas/**/*` and `DESIGN.md` when applicable.
-- Three upstream authorities: Product / Architecture Source, Technical Realization Plan and Acceptance Checklist.
-- Workflow entry artifacts: `workflow-protocol.md`, `execution-binding.md` and `goal-objective.txt`.
-- Official Superpowers execution layer: `superpowers:subagent-driven-development`, `superpowers:executing-plans`, `superpowers:test-driven-development` and `superpowers:verification-before-completion`.
-- State and audit kernel: `task-state.json`, `events.ndjson`, generated `derived/**`, `task-state.evidence[]`, assertion results / negative evidence scans, and slice / epoch / final gates.
-
-This Skill is not the Tiny Context Workflow Contract itself, not a business fact source, not a normal target-mode prompt generator, and not a Superpowers fork. Superpowers manages efficient implementation execution; Tiny Context gates check source authority, plan conformance, assertion-backed acceptance evidence, state consistency and final completion.
-
-## Required Three-Input Packet
-
-Use this Skill only after all three inputs already exist or are pasted in full:
-
-- Product / Architecture Source.
-- Technical Realization Plan.
-- Acceptance Checklist.
-
-The Technical Realization Plan must already be equivalent to a Superpowers-ready Markdown implementation plan. Do not generate, derive, or infer the Technical Realization Plan. Do not generate, derive, rewrite, strengthen, or repair the full checklist.
-
-If only a product/architecture source plus checklist exists, stop with missing Technical Realization Plan. If required fields are missing, return a Missing Fields Report and do not render the workflow entry artifacts.
-
-Strict input grammar:
-
-- Product / Architecture Source is a single document-level object using fixed `key: value`, indented-list or `key: |` fields.
-- Technical Realization Plan item definitions are only Markdown headings like `## PI-001: ...`.
-- Acceptance Checklist item definitions are only Markdown headings like `## AC-001: ...`.
-- Plain prose, lists, tables, mapping previews and `related_*` fields that mention PI/AC IDs are references, not definitions.
-- Legacy list-style definitions such as `- PI-001: ...` or `- AC-001: ...` followed by delivery fields are invalid.
-
-Strict V2 canonical fields are code-owned by `superpowers-task-fields.ts` and must be present in the three sources. Product Source includes Scope Fit fields such as `scope_fit_decision`, `selected_scope_fit_slice`, `owner_boundary`, `primary_capability_path`, `non_completing_outcomes` and `assertion_policy`. PI items include owner/trigger/state/observable/assertion fields such as `owner_boundary`, `primary_capability_path`, `trigger_contract`, `state_transition_contract`, `observable_result_contract`, `assertion_support`, `required_assertion_commands` and `invalid_implementation_shortcuts`. ACs include assertion-gate fields such as `assertion_command`, `assertion_artifacts`, `positive_assertions`, `negative_assertions`, `machine_blocking`, `invalid_completion_signals` and `assertion_result_required`. Unknown fields, duplicate fields, table fields and missing canonical fields fail compile; this Skill must not infer, repair or backfill them.
-
-## Authority Model
-
-- Product / Architecture Source owns intent, scope and boundaries.
-- Technical Realization Plan owns plan items, execution blueprint and plan conformance.
-- Acceptance Checklist owns ACs, completion semantics and proof layers.
-- `task-state.json` is the only execution state source.
-- `events.ndjson` is append-only.
-- `derived/**` is generated and must not be hand-edited as authority.
-- State, generated views, validator output and auditor reports cannot narrow, rewrite or replace the upstream sources.
-- Machine-verifiable proof layers require passed assertion reports and no negative evidence contradiction; derived matrix/verdict rows can summarize those results but cannot replace them.
-
-Capability-first delivery boundaries stay inside the same three inputs. Source, PI items and ACs must distinguish reusable system capability build, representative sample validation, full population operation and out-of-scope backlog. `scope_conflict_requires_decision` blocks completion.
-
-## Workflow Protocol
-
-The detailed workflow lives in `references/composite-long-task-workflow-protocol.md` and is copied into each task workdir as `workflow-protocol.md` with protocol name, version, SHA-256, generation time and source asset metadata.
-
-The protocol snapshot defines:
-
-- Authority Model.
-- Required Bootstrap.
-- Tiny Context Contract Layer.
-- Superpowers Execution Binding.
-- Slice Protocol.
-- Epoch Protocol.
-- Evidence Protocol.
-- Progress Accounting.
-- Final Gate Protocol.
-- Completion State Machine.
-- Forbidden Shortcuts.
-- Blocker Protocol.
-
-`workflow-protocol.md` is execution protocol, not durable project Context, and must not be registered in `project_context/context.toml`.
-
-## Execution Binding
-
-`execution-binding.md` records the current workdir, protocol hash, goal objective path, the three authority files, canonical state paths and required commands:
-
-```text
-ty-context composite-long-task init <workdir>
-ty-context composite-long-task compile <workdir>
-ty-context composite-long-task apply-slice-delta <workdir> <slice-delta.json>
-ty-context composite-long-task derive <workdir>
-ty-context composite-long-task slice-gate <workdir> --slice <id>
-ty-context composite-long-task epoch-gate <workdir> --epoch <id>
-ty-context composite-long-task final-gate <workdir>
-ty-context composite-long-task next-slices <workdir> --limit 5
-ty-context composite-long-task render-goal <workdir>
-ty-context validate-superpowers-state <workdir>
-ty-context validate-plan-acceptance <workdir>
-```
-
-The validator name `validate-superpowers-state` remains valid because it checks the Superpowers-backed state schema.
-
-Strict completion also exposes current-attempt evidence commands:
-
-```text
-ty-context composite-long-task start-attempt <workdir> [--mode product_task|harness_task]
-ty-context composite-long-task run-assertion <workdir> --ac AC-001 --proof-layer ui_browser -- <command>
-ty-context composite-long-task record-evidence <workdir> --from <artifact> --command-run-id <id>
-```
-
-`compile [--mode product_task|harness_task]` derives required command specs from AC proof layers, assertion commands, assertion artifacts, required test ids, positive/negative assertions, invalid completion signals and final evidence expectation. `start-attempt` records the current source bundle, git/worktree identity, mode and changed files. `run-assertion` records command runs for the current attempt. `record-evidence` registers artifacts as EvidenceRecordV2 only when attempt/source/product/plan/checklist/worktree/command/artifact/assertion target fields are present.
-
-## Official Superpowers Binding
-
-Bind to official Superpowers skills only after the full checklist and executable Technical Realization Plan exist:
-
-- Prefer `superpowers:subagent-driven-development` when subagents are available.
-- Use `superpowers:executing-plans` otherwise.
-- Plan or AC behavior gap -> `superpowers:test-driven-development`.
-- Before completion claims use `superpowers:verification-before-completion`, `ty-context validate-superpowers-state`, `ty-context validate-plan-acceptance`, auditor checks when available and final gate.
-
-Superpowers review and verification remain useful execution checks, but they cannot override Tiny Context gates.
-
-## Goal Objective Rules
-
-`goal-objective.txt` must be deterministic, fit the 3850-character practical budget and be more than a single read-file pointer. It must preserve:
-
-- workdir.
-- required files to read.
-- three-input authority model.
-- `task-state.json`, `events.ndjson` and `derived/**` semantics.
-- `workflow-protocol.md` as detailed workflow.
-- `execution-binding.md` as task binding.
-- `product_goal_complete` only by final gate.
-- `completion_output_status` only by final-gate completion-output resolver.
-- `blocker_triage` category and next action when final gate fails.
-- `audit_task_complete` not equal to product acceptance.
-- assertion-backed machine-verifiable proof layers and negative evidence scan.
-- forbidden shortcuts.
-- blocker protocol.
-
-## Completion State
-
-Agents must not hand-set `product_goal_complete` or `completion_output_status`. Implementation / execution goals may use an unqualified accept/completion answer only when final gate computes `product_goal_complete=true` and the completion-output resolver emits `completion_output_status=accept`.
-
-Final completion is current-attempt-only and owned by the Trusted Evidence Kernel shared by final gate, `validate-superpowers-state`, state-backed `validate-plan-acceptance` and derived completion views. Legacy v1 evidence, old attempt evidence, stale passed assertion JSON, historical `events.ndjson` completion events, stale `derived/**` views, matrix/verdict/evidence-index/final-summary rows, validator passes, final cards, auditor prose, AC summary-only proof, unregistered temporary JSON and hand-written status files are audit material only. They cannot complete machine-blocking ACs. Current failed command runs, Playwright/JUnit/test-result artifacts, owner DOM forbidden states, source/worktree drift, task-state false/partial status or derived/state mismatch invalidate older positive proof for the same AC/layer.
-
-The final gate recomputes in this order: load the three inputs, recompute source hashes, load task state, snapshot previous final/gates/meta transient bookkeeping as audit-only, resolve the current attempt, load required command specs, load command-run records, load registered EvidenceRecords, discard stale evidence, scan unregistered assertion JSON, run contradiction scan, run AC-010 bootstrap prevention, run under-specified AC checks, run Harness Drift Lock, run protected baseline guard, validate scope conflicts, recompute every AC, recompute every PI, recompute `acceptance_target_status`, recompute `product_goal_complete`, build the current candidate state, resolve candidate `completion_output_status`, regenerate current `derived/**`, scan generated output in the current candidate mode, classify blockers with `blocker_triage`, perform at most one self-recovery pass for transient bookkeeping or regenerable generated-output mismatch, then write current final state and append an event.
-
-Canonical proof layers are `code`, `api_schema`, `worker_runtime`, `data_artifact`, `integration`, `ui_browser`, `security_redaction`, `all_provider_all_runner`, `cleanup_stale_scan` and `test`; legacy source aliases map `runtime -> worker_runtime`, `browser -> ui_browser`, `api -> api_schema`, `data -> data_artifact` and `security -> security_redaction`. `code` cannot complete a machine-backed AC by itself. For UI/browser/API/worker/data/integration/security/test/all-provider/cleanup proof layers, do not mark ACs complete from screenshots, final cards, validator passes, matrix/verdict rows or prose evidence. Required machine-verifiable layers need passed `assertion_result`, zero command/assertion exit codes, target AC/PI/layer coverage, passed positive and negative assertions, no invalid completion signal, reviewable artifacts and passed `negative_evidence_scan` with matching target proof layers. Machine-blocking ACs with missing assertion command/artifacts/assertions/invalid signals, manual-only tests, generated-only final evidence, impossible assertion results or UI proof without browser/e2e/smoke/trace evidence are `under_specified`, block the related PI and force `product_goal_complete=false`.
-
-AC-010 / final-gate summary ACs can only summarize fresh EvidenceRecordV2 proof for the other ACs. If AC-010 passes while another required AC is missing, failed, stale or under-specified, invalidate AC-010 with `final_gate_cannot_bootstrap_from_summary_only`.
-
-Harness Drift Lock: `product_task` cannot complete if it changed Playwright specs, tests, assertion generators, AC010 helpers, evidence writers, final-gate, validator, derive, task-state reducer, this workflow Skill/protocol or related Makefile/package test targets. Report `harness_drift_detected`, `acceptance_target_status=blocked`, `product_goal_complete=false` and exactly: `本轮修改了验收工具链或测试本身，不能用被修改后的验收证明同一轮产品完成。请拆成独立 harness_task。` A `harness_task` must have adversarial fixtures with expected final-gate outcomes and a happy-path fixture; it proves harness behavior only and must not declare product completion. HFC-003 is the durable false-completion regression suite, and HFC-004 is the durable final-gate blocker-triage suite covering old transient self-lock, candidate-driven scanner mode, blocker categories, next actions and one-pass self-recovery. `protected-harness-baseline.json` protects final-gate, validator, derive, evidence registration, assertion schema, fixture expected outcomes, workflow protocol, Skill markdown and test runner scripts; product task baseline changes are blocked, harness task baseline changes require a reason and fixture verification.
-
-If `audit_task_complete` is true but `acceptance_target_status` is not complete, report:
-
-```text
-Audit workflow completed; acceptance target not complete.
-```
-
-Do not use unqualified `Goal achieved` or `update_goal(status="complete")` as product acceptance in that case.
-
-If final-gate has not run, the required final answer is `blocked`. If final-gate runs but `product_goal_complete=false` or `acceptance_target_status` is not accepted, the required final answer is `reject` or `blocked` and must include blocker triage category plus next action. Validator pass, matrix/verdict row completion, final cards, local audit or stale generated text must never promote the final answer to `accept`.
-
-## Forbidden Behaviors
-
-Do not execute the generated workflow inside this Skill.
-
-Do not interpret the composite workflow as the Tiny Context Workflow Contract itself.
-
-Do not register `workflow-protocol.md` in `project_context/context.toml`.
-
-Do not treat `workflow-protocol.md` as a business fact source.
-
-Do not let `derived/**`, local audit, matrix, verdict, validator output or auditor report rewrite Product / Architecture Source, Technical Realization Plan or Acceptance Checklist.
-
-Do not treat local audit as product-quality proof.
-
-Do not treat Superpowers review as plan conformance or AC acceptance.
-
-Do not treat sample evidence as full-population proof.
-
-Do not treat screenshots, final cards, validator passes, matrix/verdict rows or prose as proof for machine-verifiable layers without assertion-backed evidence.
-
-Do not continue claiming full implementation when `Context Delta: required` is unresolved.
-
-Do not claim full alignment while Source-to-Context Coverage or Context-to-Implementation Binding has unresolved gaps.
-
-Do not hand-write `product_goal_complete`.
-
-Do not hand-write `completion_output_status`.
-
-Do not call an implementation / execution Goal complete before final-gate computes `product_goal_complete=true` and `completion_output_status=accept`.
-
-Do not generate, derive, or infer the Technical Realization Plan.
-
-Do not generate, derive, rewrite, strengthen, or repair the full checklist.
-
-Do not put `workflow-protocol.md`, `execution-binding.md`, `goal-objective.txt`, local audit, generated views, temporary evidence or one-off logs into `project_context/**`.
-
-Do not include business-domain logic, concrete provider names, API names, UI names, artifact schemas or one-off project details in this package-managed Skill.

package/assets/skills/composite-long-task-workflow/assets/execution-binding.template.md

@@ -1,62 +0,0 @@
-# Composite Long-Task Execution Binding
-
-workdir: {{workdir}}
-protocol: workflow-protocol.md
-protocol_sha256: {{protocol_sha256}}
-goal_objective: goal-objective.txt
-
-authorities:
-  product_architecture_source: product-architecture-source.md
-  technical_realization_plan: technical-realization-plan.md
-  acceptance_checklist: acceptance-checklist.md
-
-canonical_state:
-  task_state: task-state.json
-  events: events.ndjson
-  derived_dir: derived/
-
-required_commands:
-  init: ty-context composite-long-task init <workdir>
-  compile: ty-context composite-long-task compile <workdir>
-  start_attempt: ty-context composite-long-task start-attempt <workdir>
-  run_assertion: ty-context composite-long-task run-assertion <workdir> --ac <AC-ID> --proof-layer <layer> -- <command>
-  record_evidence: ty-context composite-long-task record-evidence <workdir> --from <artifact> --command-run-id <id>
-  derive: ty-context composite-long-task derive <workdir>
-  apply_slice_delta: ty-context composite-long-task apply-slice-delta <workdir> <slice-delta.json>
-  slice_gate: ty-context composite-long-task slice-gate <workdir> --slice <id>
-  epoch_gate: ty-context composite-long-task epoch-gate <workdir> --epoch <id>
-  state_validator: ty-context validate-superpowers-state <workdir>
-  acceptance_validator: ty-context validate-plan-acceptance <workdir>
-  final_gate: ty-context composite-long-task final-gate <workdir>
-
-completion_gate:
-  product_goal_complete_source: final_gate
-  completion_output_status_source: final_gate_completion_output_resolver
-  allowed_final_answers:
-    - accept
-    - reject
-    - blocked
-  final_answer_accept_requires_product_goal_complete_true: true
-  final_answer_accept_requires_completion_output_status_accept: true
-  final_gate_not_run_outputs_blocked: true
-  final_gate_false_outputs_reject_or_blocked: true
-  validator_pass_never_authorizes_accept: true
-  matrix_verdict_final_card_never_authorizes_accept: true
-  audit_task_complete_never_authorizes_accept: true
-  generated_output_mismatch_blocks_accept: true
-  final_gate_uses_current_candidate_before_scanner: true
-  old_transient_bookkeeping_is_audit_only: true
-  blocker_triage_category_required_on_failure: true
-  blocker_triage_next_action_required_on_failure: true
-  self_recoverable_generated_output_mismatch_retries_once: true
-  cannot_hand_set_product_goal_complete: true
-  cannot_hand_set_completion_output_status: true
-  includes_ac_evidence_assertion_gate: true
-  includes_negative_evidence_scan_gate: true
-  current_attempt_only: true
-  trusted_evidence_kernel: true
-  harness_drift_lock: true
-  protected_harness_baseline: true
-  under_specified_machine_ac_blocks_completion: true
-  ac010_cannot_bootstrap_summary_only: true
-  derived_events_validators_never_proof: true

package/assets/skills/composite-long-task-workflow/assets/goal-objective.template.md

@@ -1,17 +0,0 @@
-/goal Execute the composite long-task workflow in {{workdir}}.
-
-Read and obey workflow-protocol.md, execution-binding.md, product-architecture-source.md, technical-realization-plan.md, acceptance-checklist.md, task-state.json and generated derived/** views.
-
-Persistent contract:
-Product / Architecture Source owns intent, scope, Scope Fit, owner boundaries and assertion policy. Technical Realization Plan owns PI implementation and plan conformance. Acceptance Checklist owns AC completion semantics and proof layers. task-state.json is the only execution state source; events.ndjson is append-only; derived/** is generated and must not be hand-edited as authority.
-
-Use workflow-protocol.md to combine Tiny Context gates with official Superpowers execution. It is not business Context and must not be registered in project_context/context.toml. Prefer superpowers:subagent-driven-development when subagents are available; otherwise use superpowers:executing-plans. Use TDD for behavior gaps and superpowers:verification-before-completion before completion claims.
-
-Forbidden shortcuts:
-Do not mark UI/worker/API/data/integration/test ACs complete from screenshots, final cards, validator passes, derived rows, historical complete events, auditor prose, AC summary proof, unregistered JSON or stale attempts. Required machine proof needs current-attempt EvidenceRecordV2, assertion_result.status=passed, zero command/assertion exit codes, target AC/layer coverage, passed positive and negative assertions, reviewable artifacts and no failed/stale negative_evidence_scan with matching target proof layers. Tests alone do not prove plan conformance. Superpowers review does not override Tiny Context gates. Sample evidence does not prove full population unless AC allows. Local audit cannot mark final completion. Do not claim full implementation while Context Delta is required but Context is not updated, or while Source-to-Context Coverage / Context-to-Implementation Binding has unresolved required gaps.
-
-Completion:
-Do not hand-set product_goal_complete or completion_output_status. Only final-gate computes product_goal_complete through the Trusted Evidence Kernel; resolver writes completion_output_status as accept, reject or blocked. Machine-blocking ACs missing assertion command/artifacts/assertions/invalid signals, manual-only proof, generated-only final evidence, impossible assertion_result or UI proof without browser/e2e/smoke/trace are under_specified and block completion. AC-010 cannot bootstrap missing, failed or stale ACs. product_task changing tests/harness/final-gate/validator/assertion generators/workflow protocol is harness_drift_detected and must split to harness_task; harness_task proves harness behavior only. Run AC Evidence Assertion Gate, Negative Evidence Scan Gate, validators, then final-gate. Require final-gate compute product_goal_complete=true and completion_output_status=accept before treating implementation as complete. If final-gate fails, use blocker_triage category/next_action; self-recoverable transient/generated-output mismatch may recover once, then rerun. Reject/blocked answers must not say Goal achieved, completed, accepted, done or call update_goal(status="complete"). If audit_task_complete is true but acceptance_target_status is not complete, report "Audit workflow completed; acceptance target not complete."
-
-Blocked:
-Use repo tools, local app/browser sessions, CLI auth and authorized elevation. Stop only for MFA, missing permission, external approval or unavailable credentials, then return minimal user action plus next agent step.