yaaw-se 0.3.3 → 0.3.4
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/dist/cli/commands/install.js +1 -1
- package/dist/cli/commands/install.js.map +1 -1
- package/dist/installer/status.js +74 -0
- package/dist/installer/status.js.map +1 -1
- package/dist/installer/verify.d.ts +2 -1
- package/dist/installer/verify.js +6 -2
- package/dist/installer/verify.js.map +1 -1
- package/dist/integrations/codex-runtime.d.ts +39 -0
- package/dist/integrations/codex-runtime.js +89 -0
- package/dist/integrations/codex-runtime.js.map +1 -1
- package/dist/integrations/codex.js +103 -16
- package/dist/integrations/codex.js.map +1 -1
- package/dist/payload/integrations/codex/yaaw-runtime.md +38 -10
- package/dist/payload/payload-files.json +95 -55
- package/dist/payload/payload.json +1 -1
- package/dist/payload/yaaw-core/system/core/context-loading.md +12 -8
- package/dist/payload/yaaw-core/system/core/dispatch-execution.md +18 -2
- package/dist/payload/yaaw-core/system/core/execution-context.md +31 -23
- package/dist/payload/yaaw-core/system/core/invalidation.md +29 -12
- package/dist/payload/yaaw-core/system/core/io-contract.md +8 -0
- package/dist/payload/yaaw-core/system/core/lifecycle.md +11 -16
- package/dist/payload/yaaw-core/system/core/routing.md +7 -7
- package/dist/payload/yaaw-core/system/core/transitions.md +2 -5
- package/dist/payload/yaaw-core/system/registries/handoff-policy.json +85 -0
- package/dist/payload/yaaw-core/system/roles/orchestrator.md +16 -14
- package/dist/payload/yaaw-core/system/rules/repository-identity.md +31 -17
- package/dist/payload/yaaw-core/system/schemas/evidence-v1.schema.json +28 -0
- package/dist/payload/yaaw-core/system/schemas/evidence-v2.schema.json +19 -0
- package/dist/payload/yaaw-core/system/schemas/evidence.schema.json +20 -31
- package/dist/payload/yaaw-core/system/schemas/repository-identity.schema.json +47 -0
- package/dist/payload/yaaw-core/system/schemas/review-v1.schema.json +19 -0
- package/dist/payload/yaaw-core/system/schemas/review-v2.schema.json +17 -0
- package/dist/payload/yaaw-core/system/schemas/review.schema.json +26 -13
- package/dist/payload/yaaw-core/system/templates/evidence.json +19 -2
- package/dist/payload/yaaw-core/system/templates/handoff.json +9 -15
- package/dist/payload/yaaw-core/system/templates/observed-state.json +13 -1
- package/dist/payload/yaaw-core/system/templates/review.md +14 -5
- package/dist/payload/yaaw-core/system/tools/orchestration-runtime.mjs +689 -0
- package/dist/payload/yaaw-core/system/tools/repository-identity.mjs +92 -0
- package/dist/payload/yaaw-core/system/workflows/implementation/implement-ticket.md +4 -0
- package/dist/payload/yaaw-core/system/workflows/implementation/repair-ticket.md +4 -0
- package/dist/payload/yaaw-core/system/workflows/implementation/verify-ticket.md +3 -0
- package/dist/payload/yaaw-core/system/workflows/orchestration/determine-next-action.md +15 -15
- package/dist/payload/yaaw-core/system/workflows/orchestration/dispatch.md +22 -16
- package/dist/payload/yaaw-core/system/workflows/orchestration/inspect-state.md +12 -15
- package/dist/payload/yaaw-core/system/workflows/orchestration/recover-interruption.md +4 -0
- package/dist/payload/yaaw-core/system/workflows/orchestration/route.md +19 -11
- package/dist/payload/yaaw-core/system/workflows/planning/replan.md +4 -0
- package/dist/payload/yaaw-core/system/workflows/review/inspect-change.md +4 -1
- package/dist/tui/configuration-updates.js +12 -1
- package/dist/tui/configuration-updates.js.map +1 -1
- package/package.json +1 -1
|
@@ -3,16 +3,14 @@
|
|
|
3
3
|
Load the smallest authoritative context needed for the current judgment.
|
|
4
4
|
|
|
5
5
|
## Progressive-disclosure invariant
|
|
6
|
-
Workflow selection is metadata-first.
|
|
7
|
-
|
|
8
|
-
A router may load its role contract, router workflow, workflow/execution registries, state/artifact metadata, and the minimum evidence needed to select one route. It must not preload sibling or downstream workflow bodies, their templates, or their expertise merely because they might be needed later.
|
|
6
|
+
Workflow selection is metadata-first. Normal Orchestrator preparation is performed by `.yaaw-core/system/tools/orchestration-runtime.mjs`, which reads only durable metadata and the machine registries needed to produce one typed route/handoff. The Orchestrator consumes that result and **must not preload sibling or downstream workflow bodies**, templates, or expertise merely because they might be needed later.
|
|
9
7
|
|
|
10
8
|
After exactly one workflow is selected:
|
|
11
9
|
1. resolve that workflow through `.yaaw-core/system/registries/workflows.json`;
|
|
12
10
|
2. load its body;
|
|
13
|
-
3. load only
|
|
11
|
+
3. load only handoff-declared/current artifact references and applicable rules;
|
|
14
12
|
4. load selected expertise only after relevance is established;
|
|
15
|
-
5. load a template only when the selected workflow
|
|
13
|
+
5. load a template only when the selected workflow will create that artifact.
|
|
16
14
|
|
|
17
15
|
After durable output, return to routing before opening another workflow contract.
|
|
18
16
|
|
|
@@ -44,9 +42,15 @@ role contract
|
|
|
44
42
|
Do not automatically load every PRD revision, research artifact, ticket, review, expertise module, template, or the full repository.
|
|
45
43
|
|
|
46
44
|
## Canonical artifact discovery
|
|
47
|
-
Exact YAAW reads come from the handoff
|
|
45
|
+
Exact YAAW reads come from the deterministic handoff and registries. Roles do not grep for alternate YAAW artifact locations.
|
|
48
46
|
|
|
49
47
|
## Handoff freshness
|
|
50
|
-
A handoff
|
|
48
|
+
A handoff binds exact artifact revisions, read/write sets, selected expertise, repository requirement, canonical repository identity, transition sequence, installed YAAW version, installation/project-state schema versions, and manifest digest.
|
|
49
|
+
|
|
50
|
+
Immediately before dispatch, run:
|
|
51
|
+
|
|
52
|
+
```text
|
|
53
|
+
node .yaaw-core/system/tools/orchestration-runtime.mjs --workspace <WORKSPACE_ROOT> --check-handoff
|
|
54
|
+
```
|
|
51
55
|
|
|
52
|
-
Runtime handoffs, intent, and observed-state snapshots
|
|
56
|
+
Only `HANDOFF_FRESH` may execute. A stale result discards the handoff and returns to orchestration preparation. Runtime handoffs, intent, and observed-state snapshots are coordination caches, not semantic sources of truth.
|
|
@@ -14,7 +14,7 @@ Dispatch is a semantic request to execute exactly one already-selected YAAW hand
|
|
|
14
14
|
9. The worker returns only a legal typed result from the handoff/workflow contract.
|
|
15
15
|
10. A worker message is an execution signal, not project truth.
|
|
16
16
|
11. After worker completion, failure, interruption, or lost response, Orchestrator re-enters `orchestration.inspect-state` before selecting another semantic workflow.
|
|
17
|
-
12. If
|
|
17
|
+
12. If the preferred execution mechanism is unavailable, the active host adapter may use an alternate mechanism only when it can preserve the configured effective authority execution profile; otherwise dispatch fails closed.
|
|
18
18
|
|
|
19
19
|
## Direct invocation
|
|
20
20
|
A user who directly invokes PRD, Planner, Implementer, or Reviewer has intentionally selected that role/workflow and may execute it in the current context. Isolation policy here governs **Orchestrator dispatch**, not the existence of direct public entrypoints.
|
|
@@ -22,7 +22,7 @@ A user who directly invokes PRD, Planner, Implementer, or Reviewer has intention
|
|
|
22
22
|
## Execution-context policy
|
|
23
23
|
`.yaaw-core/system/registries/execution-policy.json` declares one of:
|
|
24
24
|
- `ROOT_ONLY`: run in the active root Orchestrator context.
|
|
25
|
-
- `ISOLATED_PREFERRED`: prefer a fresh worker; host fallback may run inline.
|
|
25
|
+
- `ISOLATED_PREFERRED`: prefer a fresh worker; host fallback may run through another mechanism only when the adapter establishes execution-profile equivalence. A deliberately selected host `inline` mode is an explicit opt-out from per-role isolation.
|
|
26
26
|
- `INLINE_ALLOWED`: current-context execution is explicitly acceptable.
|
|
27
27
|
|
|
28
28
|
A future `ISOLATED_REQUIRED` value may be introduced only with a schema/version update. Host adapters may still expose a stricter local runtime mode that blocks instead of falling back.
|
|
@@ -45,5 +45,21 @@ Legal workflow results such as `REPAIR`, `REPLAN`, `BLOCKED`, or a real precondi
|
|
|
45
45
|
|
|
46
46
|
When a configured threshold is reached, the next attempt may use the host's stronger fallback execution profile while preserving the exact role and handoff. The fallback receives one attempt on an unchanged basis. If that attempt also fails with no progress, stop with `BLOCKED:AUTHORITY_EXECUTION_FAILED` rather than entering an unbounded retry loop.
|
|
47
47
|
|
|
48
|
+
## Authority execution profile fidelity invariant
|
|
49
|
+
A host adapter owns provider/model execution selection, but it may not silently substitute a different effective authority profile.
|
|
50
|
+
|
|
51
|
+
- The canonical handoff remains provider-neutral: role, workflow, artifacts, basis, and allowed results do not carry provider model identifiers.
|
|
52
|
+
- Before dispatch, the adapter resolves the required effective execution profile for the selected authority and, when applicable, the configured capability-fallback variant.
|
|
53
|
+
- Changing named worker -> generic worker is legal only when the generic path is already profile-equivalent or every mismatched profile dimension can be authoritatively corrected by the active spawn mechanism.
|
|
54
|
+
- Changing worker -> inline execution is legal only when the current/root execution profile is provably equivalent to the required authority profile. A user-selected host inline mode is the explicit exception because it deliberately opts out of per-role model isolation.
|
|
55
|
+
- Model and reasoning dimensions are compared independently. A matching dimension needs no override; a mismatched dimension requires an authoritative override for that dimension.
|
|
56
|
+
- Unknown inherited values remain symbolic. The adapter may treat two paths as equivalent when both resolve through the same `HOST_INHERIT` chain, but it must never guess that a concrete value equals an unknown inherited value.
|
|
57
|
+
- If isolation exists but the host cannot guarantee the configured model/reasoning profile, stop with `BLOCKED:HOST_EXECUTION_PROFILE_UNAVAILABLE`.
|
|
58
|
+
- If strict isolation is required and the host cannot create any isolated worker at all, stop with `BLOCKED:HOST_ISOLATION_UNAVAILABLE`.
|
|
59
|
+
- A profile/isolation stop that occurs before child creation is a host precondition failure, not an authority execution failure. It must not increment `.yaaw-core/runtime/dispatch-failures.json` or trigger capability escalation.
|
|
60
|
+
- Capability fallback uses the same resolver and fidelity rules as primary execution. If fallback selects a stronger profile, that exact effective profile must be preserved or dispatch blocks.
|
|
61
|
+
|
|
62
|
+
The Orchestrator may route a configured profile through the adapter; it may not invent, weaken, or replace that profile.
|
|
63
|
+
|
|
48
64
|
## Provider boundary
|
|
49
65
|
This contract is provider-neutral. Names of host tools, agent types, provider directories, model identifiers, and provider-specific spawning schemas belong only to integration adapters.
|
|
@@ -1,16 +1,15 @@
|
|
|
1
1
|
# Execution context
|
|
2
2
|
|
|
3
3
|
## Purpose
|
|
4
|
-
Define
|
|
4
|
+
Define one runtime boundary for every YAAW workflow so ambient shell state and provider layout cannot silently change semantics.
|
|
5
5
|
|
|
6
6
|
## Canonical workspace root
|
|
7
7
|
The **workspace root** is the consumer directory that owns the active YAAW installation. Resolve it before repository or application inspection by walking from the provider's current location toward ancestors until `.yaaw-core/install/manifest.json` is found. During recovery of a damaged installation, `.yaaw-core/system/registries/paths.json` may be used as a fallback marker.
|
|
8
8
|
|
|
9
|
-
The process
|
|
9
|
+
The process CWD is never authoritative. `.yaaw-core/project/` is project memory, not the workspace root.
|
|
10
10
|
|
|
11
11
|
## Framework integrity
|
|
12
|
-
|
|
13
|
-
After resolving the workspace and before semantic project recovery, run:
|
|
12
|
+
After resolving the workspace and before semantic project recovery, run only the canonical package-owned integrity gate:
|
|
14
13
|
|
|
15
14
|
```text
|
|
16
15
|
node .yaaw-core/system/tools/framework-integrity.mjs --workspace <WORKSPACE_ROOT>
|
|
@@ -18,36 +17,45 @@ node .yaaw-core/system/tools/framework-integrity.mjs --workspace <WORKSPACE_ROOT
|
|
|
18
17
|
|
|
19
18
|
Only `HEALTHY` permits semantic routing. Package drift, missing framework files, local framework overrides, or an invalid manifest produce a typed framework stop and invalidate executable handoffs. Orchestrator reports the condition; it never repairs package-managed files itself.
|
|
20
19
|
|
|
21
|
-
|
|
22
|
-
|
|
20
|
+
There is no second framework-integrity implementation outside `.yaaw-core/system/tools/`.
|
|
21
|
+
|
|
22
|
+
## Deterministic orchestration preparation
|
|
23
|
+
Normal Orchestrator routing uses one deterministic preparation entrypoint:
|
|
24
|
+
|
|
25
|
+
```text
|
|
26
|
+
node .yaaw-core/system/tools/orchestration-runtime.mjs --workspace <WORKSPACE_ROOT>
|
|
27
|
+
```
|
|
23
28
|
|
|
24
|
-
|
|
25
|
-
- `UNVERSIONED`: the workspace is valid but is not inside a Git repository.
|
|
26
|
-
- `UNAVAILABLE`: Git cannot be executed or repository inspection is prohibited by the host.
|
|
27
|
-
- `ROOT_MISMATCH`: repository ownership cannot be reconciled safely with the resolved workspace.
|
|
28
|
-
- `IDENTITY_FAILED`: a repository exists but exact identity cannot be established.
|
|
29
|
+
That one invocation performs the framework gate, canonical repository identity, durable metadata inspection, routing, and handoff construction from one basis. The Orchestrator consumes its typed result; it must not reimplement repository hashing, routing precedence, artifact discovery, or handoff serialization in ad-hoc shell/Python code.
|
|
29
30
|
|
|
30
|
-
|
|
31
|
+
Compatibility/debug inspection may use `--inspect-only`. Dispatch freshness uses `--check-handoff` immediately before execution.
|
|
32
|
+
|
|
33
|
+
## Repository capability
|
|
34
|
+
- `READY`: repository exists and exact identity is trustworthy.
|
|
35
|
+
- `UNVERSIONED`: valid workspace, no Git repository.
|
|
36
|
+
- `UNAVAILABLE`: Git or host permission unavailable.
|
|
37
|
+
- `ROOT_MISMATCH`: repository/workspace ownership cannot be reconciled.
|
|
38
|
+
- `IDENTITY_FAILED`: repository exists but exact identity failed.
|
|
31
39
|
|
|
32
40
|
## Root-anchored command rule
|
|
33
|
-
Every
|
|
41
|
+
Every Git command is explicitly scoped:
|
|
34
42
|
|
|
35
43
|
```text
|
|
36
44
|
git -C <WORKSPACE_ROOT> ...
|
|
37
45
|
```
|
|
38
46
|
|
|
39
|
-
|
|
47
|
+
When Git top-level is an ancestor, inspection and identity remain workspace-scoped with `-- .`; unrelated sibling changes must not contaminate the active workspace identity.
|
|
40
48
|
|
|
41
|
-
|
|
49
|
+
## Canonical identity execution
|
|
50
|
+
For repository identity, every semantic workflow invokes or consumes output originating from:
|
|
42
51
|
|
|
43
|
-
|
|
44
|
-
|
|
52
|
+
```text
|
|
53
|
+
node .yaaw-core/system/tools/repository-identity.mjs --workspace <WORKSPACE_ROOT>
|
|
54
|
+
```
|
|
45
55
|
|
|
46
|
-
|
|
47
|
-
- `INSPECT`: inspect repository/workspace reality when available; `UNVERSIONED` is representable and does not by itself block the workflow.
|
|
48
|
-
- `IDENTITY`: exact repository identity is mandatory; dispatch is blocked unless repository status is `READY`.
|
|
56
|
+
No role or workflow may independently compute or reserialize `worktree_digest`. Copy the returned repository identity into state, handoff, evidence, and review records.
|
|
49
57
|
|
|
50
|
-
|
|
58
|
+
## Workflow requirements
|
|
59
|
+
The machine policy in `.yaaw-core/system/registries/execution-policy.json` assigns one repository requirement to every workflow.
|
|
51
60
|
|
|
52
|
-
|
|
53
|
-
Provider adapters may point to this contract but must not duplicate it. Codex, Claude Code, Gemini CLI, and Cline all execute against the same workspace-root and repository-capability semantics.
|
|
61
|
+
Provider adapters point to this contract; Codex, Claude Code, Gemini CLI, and Cline do not fork repository semantics.
|
|
@@ -1,17 +1,10 @@
|
|
|
1
1
|
# Invalidation propagation
|
|
2
2
|
|
|
3
|
-
Accepted artifacts are historical records, not eternally valid truth.
|
|
3
|
+
Accepted artifacts are historical records, not eternally valid truth. Prior reviews remain immutable historical evidence; current authority may become `STALE` without rewriting history.
|
|
4
4
|
|
|
5
|
-
##
|
|
6
|
-
1. Increment `product.md` revision and record the changed requirement.
|
|
7
|
-
2. Identify `ENG-*` decisions whose product provenance depends on the changed requirement.
|
|
8
|
-
3. Mark affected decisions superseded/invalidated in `engineering.md`; move planning readiness to unresolved.
|
|
9
|
-
4. Mark dependent specs `STALE` rather than rewriting them in place.
|
|
10
|
-
5. Move dependent tickets, including prior `PASS` tickets when behavior is affected, to `REPLAN_REQUIRED` using the transition contract.
|
|
11
|
-
6. Prior reviews remain immutable historical evidence but no longer establish current acceptance.
|
|
5
|
+
## Permanent rule
|
|
12
6
|
|
|
13
|
-
|
|
14
|
-
Apply the same propagation from affected `ENG-*` decisions -> specs -> tickets -> reviews.
|
|
7
|
+
**A stale contract and stale acceptance are not the same thing.**
|
|
15
8
|
|
|
16
9
|
## Acceptance invalidation
|
|
17
10
|
If product/engineering/spec/ticket meaning remains current but review or verification proof is missing, repository-stale, or cannot be reproduced, preserve historical reviews and reconcile current acceptance to `REVIEW_REQUIRED`.
|
|
@@ -23,5 +16,29 @@ Stable acceptance causes: `REVIEW_MISSING`, `REVIEW_REPOSITORY_STALE`, `VERIFICA
|
|
|
23
16
|
## Framework integrity is not project invalidation
|
|
24
17
|
Package-managed framework drift is neither contract invalidation nor acceptance invalidation. It means the execution engine is untrusted. Stop orchestration with the typed framework failure and use installer repair. Do not route framework drift to Planner or Reviewer and do not change ticket lifecycle state to encode it.
|
|
25
18
|
|
|
26
|
-
|
|
27
|
-
|
|
19
|
+
Result: `PASS -> REPLAN_REQUIRED`.
|
|
20
|
+
|
|
21
|
+
Next semantic owner: Planner.
|
|
22
|
+
|
|
23
|
+
### Acceptance invalidation
|
|
24
|
+
The source contract remains current, but review or verification proof is missing, repository-stale, or cannot be reproduced under the canonical identity algorithm.
|
|
25
|
+
|
|
26
|
+
Result: `PASS -> REVIEW_REQUIRED`.
|
|
27
|
+
|
|
28
|
+
Next semantic owner: Reviewer.
|
|
29
|
+
|
|
30
|
+
Repository identity mismatch alone does not establish `REPLAN_REQUIRED`. The Orchestrator may mechanically invalidate trust, but it must not decide that current code satisfies the contract or that architecture is invalid.
|
|
31
|
+
|
|
32
|
+
Reviewer may then return `PASS`, `REPAIR`, `REPLAN`, or `BLOCKED`.
|
|
33
|
+
|
|
34
|
+
## Stable cause IDs
|
|
35
|
+
|
|
36
|
+
Contract causes: `PRODUCT_SOURCE_STALE`, `ENGINEERING_SOURCE_STALE`, `SPEC_SOURCE_STALE`, `TICKET_SOURCE_STALE`, `CONTRACT_INVALIDATED`.
|
|
37
|
+
|
|
38
|
+
Acceptance causes: `REVIEW_MISSING`, `REVIEW_REPOSITORY_STALE`, `VERIFICATION_MISSING`, `VERIFICATION_REPOSITORY_STALE`, `LEGACY_IDENTITY_UNVERIFIABLE`.
|
|
39
|
+
|
|
40
|
+
Every invalidation records a stable cause plus human-readable evidence. Runtime-looking paths are not automatically acceptance-irrelevant.
|
|
41
|
+
|
|
42
|
+
## Framework integrity is not acceptance invalidation
|
|
43
|
+
|
|
44
|
+
Package-managed framework drift is neither contract invalidation nor acceptance invalidation. It means the execution engine is not trusted. Stop orchestration with the typed framework failure and use installer repair. Do not route framework drift to Planner or Reviewer and do not change ticket lifecycle state to encode it.
|
|
@@ -37,6 +37,14 @@ Common results include `SUCCESS`, `READY`, `HUMAN_INPUT_REQUIRED`, `PRECONDITION
|
|
|
37
37
|
|
|
38
38
|
Framework-level stop results are `FRAMEWORK_INTEGRITY_VIOLATION`, `FRAMEWORK_INTEGRITY_UNKNOWN`, and `FRAMEWORK_CONTRACT_INCONSISTENCY`. They are installation/runtime trust failures, not ticket lifecycle states, and must not be represented by fabricating a ticket transition.
|
|
39
39
|
|
|
40
|
+
Host-execution stop results are `HOST_ISOLATION_UNAVAILABLE`, `HOST_EXECUTION_PROFILE_UNAVAILABLE`, and `AUTHORITY_EXECUTION_FAILED`. They describe execution transport/capability failures, not semantic workflow outcomes or ticket lifecycle states.
|
|
41
|
+
|
|
42
|
+
- `HOST_ISOLATION_UNAVAILABLE`: strict isolation was required, but the host could not create an isolated worker.
|
|
43
|
+
- `HOST_EXECUTION_PROFILE_UNAVAILABLE`: an execution mechanism existed, but the host could not guarantee the configured effective authority model/reasoning profile.
|
|
44
|
+
- `AUTHORITY_EXECUTION_FAILED`: the correct authority execution actually started and failed under the bounded retry/fallback policy.
|
|
45
|
+
|
|
46
|
+
A host isolation/profile stop raised before child creation is a pre-execution host failure: no authority worker ran, so it must not be counted as an authority execution failure.
|
|
47
|
+
|
|
40
48
|
`PRECONDITION_UNSATISFIED` includes a reason such as `NO_PRODUCT`, `PLANNING_UNREADY`, `SPEC_MISSING`, `NO_READY_TICKET`, `STALE_SOURCE`, or `REPOSITORY_IDENTITY_UNAVAILABLE`.
|
|
41
49
|
|
|
42
50
|
A missing ticket never authorizes Implementer to create one. Implementer returns `PRECONDITION_UNSATISFIED:NO_READY_TICKET`; Orchestrator routes Planner.
|
|
@@ -5,29 +5,24 @@ YAAW advances only through evidence-backed workflow boundaries.
|
|
|
5
5
|
```text
|
|
6
6
|
product missing/unready -> PRD
|
|
7
7
|
product ready, planning unresolved -> Planner
|
|
8
|
-
planning
|
|
8
|
+
planning ready, spec missing -> create spec
|
|
9
9
|
spec accepted, tickets missing -> create tickets
|
|
10
10
|
READY -> Implementer
|
|
11
|
-
IN_PROGRESS ->
|
|
11
|
+
IN_PROGRESS -> recovery/continue
|
|
12
12
|
REVIEW_REQUIRED -> Reviewer
|
|
13
|
-
REPAIR_REQUIRED -> repair
|
|
13
|
+
REPAIR_REQUIRED -> Implementer repair -> REVIEW_REQUIRED
|
|
14
14
|
REPLAN_REQUIRED -> Planner
|
|
15
15
|
PASS -> next admitted work
|
|
16
|
-
|
|
17
|
-
all accepted scope complete with fresh acceptance -> COMPLETE
|
|
16
|
+
all accepted scope current -> COMPLETE
|
|
18
17
|
```
|
|
19
18
|
|
|
20
|
-
##
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
## Admission invariant
|
|
24
|
-
Implementation may begin only for a bounded `READY` ticket whose source spec/frontier is currently valid.
|
|
19
|
+
## Accepted-but-stale
|
|
20
|
+
A historical `PASS` whose source contract is still current but whose acceptance proof is stale becomes `REVIEW_REQUIRED`, not `REPLAN_REQUIRED`.
|
|
25
21
|
|
|
26
|
-
##
|
|
27
|
-
|
|
22
|
+
## PASS meaning
|
|
23
|
+
`PASS` means the currently observed repository/worktree state satisfies the current accepted ticket contract according to an independent Reviewer.
|
|
28
24
|
|
|
29
|
-
|
|
30
|
-
Every state transition follows `core/transitions.md`, records provenance in `.yaaw-core/project/state.json`, and cites the evidence or artifact that justified it.
|
|
25
|
+
It does not inherently mean committed, pushed, merged, or deployed. When accepted state is dirty, reporting must distinguish acceptance from persistence and disclose that the review basis is the current worktree.
|
|
31
26
|
|
|
32
|
-
##
|
|
33
|
-
|
|
27
|
+
## Fresh-context invariant
|
|
28
|
+
Every workflow must be resumable from durable artifacts and repository evidence without previous chat history.
|
|
@@ -2,15 +2,15 @@
|
|
|
2
2
|
|
|
3
3
|
Routing chooses exactly one next canonical workflow from observed reality. Explicit state beats broad heuristics. Workflow selection is metadata-first; target workflow bodies are loaded only after selection.
|
|
4
4
|
|
|
5
|
+
The machine implementation of this precedence is `.yaaw-core/system/tools/orchestration-runtime.mjs`, driven by `.yaaw-core/system/registries/routing-policy.json`. Orchestrator consumes the tool's typed route instead of manually replaying the precedence with shell commands or model reasoning.
|
|
6
|
+
|
|
5
7
|
Before any semantic routing, require framework integrity `HEALTHY` under `.yaaw-core/system/core/framework-integrity.md`. Framework drift is not repository drift and never routes to Planner, Implementer, or Reviewer. It stops execution until installer repair restores the package boundary.
|
|
6
8
|
|
|
7
9
|
Before dispatch, enforce the selected workflow repository requirement from `.yaaw-core/system/registries/execution-policy.json`. `IDENTITY` workflows require repository status `READY`; `INSPECT` workflows may represent an `UNVERSIONED` workspace; `NONE` workflows do not require Git.
|
|
8
10
|
|
|
9
|
-
The machine-readable precedence used by conformance tests lives in `.yaaw-core/system/registries/routing-policy.json`. This document explains the same semantics; CI must fail if the machine contract drifts from the workflow registry or lifecycle fixtures.
|
|
10
|
-
|
|
11
11
|
## Priority
|
|
12
12
|
1. Stop on unhealthy/unknown framework integrity or canonical framework-contract inconsistency.
|
|
13
|
-
2. Resolve material state inconsistency or incomplete recovery.
|
|
13
|
+
2. Resolve material state inconsistency or incomplete recovery before creating a semantic handoff.
|
|
14
14
|
3. If accepted product intent is missing or newly invalidated, route to PRD.
|
|
15
15
|
4. If a ticket is `REPLAN_REQUIRED`, route to `planning.replan`.
|
|
16
16
|
5. If current engineering frontier is unresolved, route through `planning.route`.
|
|
@@ -20,8 +20,8 @@ The machine-readable precedence used by conformance tests lives in `.yaaw-core/s
|
|
|
20
20
|
9. If a ticket is `REVIEW_REQUIRED`, route to `review.review-ticket`.
|
|
21
21
|
10. If a ticket is `IN_PROGRESS`, use recovery evidence to continue safely or reconcile to the next proven boundary; never restart blindly.
|
|
22
22
|
11. If a dependency-satisfied ticket is `READY`, route to `implementation.implement-ticket`.
|
|
23
|
-
12. If all current tickets are `PASS` but accepted product scope remains, route to `planning.route` for the next frontier.
|
|
24
|
-
13. Declare `COMPLETE` only when accepted scope is covered by fresh, non-stale acceptance evidence.
|
|
23
|
+
12. If all current tickets are `PASS`/`CANCELLED` but accepted product scope remains, route to `planning.route` for the next frontier.
|
|
24
|
+
13. Declare `COMPLETE` only when the durable phase is complete and accepted scope is covered by fresh, non-stale acceptance evidence.
|
|
25
25
|
|
|
26
26
|
## Tie breaking
|
|
27
27
|
- Never review a `REPAIR_REQUIRED` ticket before repair.
|
|
@@ -31,6 +31,6 @@ The machine-readable precedence used by conformance tests lives in `.yaaw-core/s
|
|
|
31
31
|
- When evidence is insufficient to choose safely, route to recovery and ultimately `BLOCKED` rather than guessing.
|
|
32
32
|
|
|
33
33
|
## Conformance rule
|
|
34
|
-
Behavioral fixtures may reconcile only transitions explicitly justified by durable/repository evidence. They must never make product or architecture decisions.
|
|
34
|
+
Behavioral fixtures and the deterministic runtime may reconcile/route only transitions explicitly justified by durable/repository evidence. They must never make product or architecture decisions.
|
|
35
35
|
|
|
36
|
-
The Orchestrator selects the
|
|
36
|
+
The Orchestrator selects/consumes the route; the target role owns semantic work inside it.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# State transition contract
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
Only transitions represented by the machine registry are legal.
|
|
4
4
|
|
|
5
5
|
In the machine registry, `owner` is the semantic decision authority and `state_writer` is the role permitted to persist the resulting lifecycle mutation. Project-state ledger writes are performed by Orchestrator after validating the durable basis. This does not transfer product, planning, implementation, or acceptance authority to Orchestrator.
|
|
6
6
|
|
|
@@ -33,7 +33,4 @@ Repository identity mismatch alone does not establish `REPLAN_REQUIRED`.
|
|
|
33
33
|
|
|
34
34
|
Forbidden examples: `DRAFT -> PASS`, `READY -> PASS`, `REPAIR_REQUIRED -> PASS`, or Implementer-authored `PASS`.
|
|
35
35
|
|
|
36
|
-
|
|
37
|
-
Normal phase order is `product -> planning -> implementation -> complete`. `blocked` may be entered from any phase and exited only when its blocker is resolved. A new accepted product revision may move `complete` back to `product` or `planning`; historical completion evidence remains immutable.
|
|
38
|
-
|
|
39
|
-
Every transition increments `transition_sequence` and writes `last_transition` in `.yaaw-core/project/state.json`.
|
|
36
|
+
Every transition increments `transition_sequence` and records a stable cause plus evidence. Historical PASS reviews remain immutable even when their authority becomes stale.
|
|
@@ -0,0 +1,85 @@
|
|
|
1
|
+
{
|
|
2
|
+
"schema": "yaaw.handoff-policy/v1",
|
|
3
|
+
"workflows": {
|
|
4
|
+
"prd.route": {
|
|
5
|
+
"desired_intent": "CONTINUE_PRODUCT",
|
|
6
|
+
"active_artifact": "product",
|
|
7
|
+
"reads": ["product", "state"],
|
|
8
|
+
"writes": ["product"],
|
|
9
|
+
"required_expertise": [],
|
|
10
|
+
"ticket_expertise": false,
|
|
11
|
+
"expected_output": "Current product intent or an explicit human-input/blocker result.",
|
|
12
|
+
"result_vocabulary": ["READY", "HUMAN_INPUT_REQUIRED", "BLOCKED"]
|
|
13
|
+
},
|
|
14
|
+
"planning.route": {
|
|
15
|
+
"desired_intent": "CONTINUE_PLANNING",
|
|
16
|
+
"active_artifact": "engineering",
|
|
17
|
+
"reads": ["product", "engineering", "engineering_research", "spec", "ticket", "project_rule", "repository"],
|
|
18
|
+
"writes": ["engineering", "engineering_research", "spec", "ticket", "project_rule"],
|
|
19
|
+
"required_expertise": [],
|
|
20
|
+
"ticket_expertise": false,
|
|
21
|
+
"expected_output": "Current engineering frontier readiness or one typed planning stop/result.",
|
|
22
|
+
"result_vocabulary": ["READY", "HUMAN_INPUT_REQUIRED", "REPLAN", "BLOCKED"]
|
|
23
|
+
},
|
|
24
|
+
"planning.create-spec": {
|
|
25
|
+
"desired_intent": "CREATE_SPEC",
|
|
26
|
+
"active_artifact": "engineering",
|
|
27
|
+
"reads": ["product", "engineering", "engineering_research", "project_rule", "repository"],
|
|
28
|
+
"writes": ["spec"],
|
|
29
|
+
"required_expertise": [],
|
|
30
|
+
"ticket_expertise": false,
|
|
31
|
+
"expected_output": "One accepted specification for the current frontier or a typed prerequisite/stop result.",
|
|
32
|
+
"result_vocabulary": ["SUCCESS", "PRECONDITION_UNSATISFIED", "BLOCKED"]
|
|
33
|
+
},
|
|
34
|
+
"planning.create-tickets": {
|
|
35
|
+
"desired_intent": "CREATE_TICKETS",
|
|
36
|
+
"active_artifact": "spec",
|
|
37
|
+
"reads": ["product", "engineering", "engineering_research", "spec", "project_rule", "repository"],
|
|
38
|
+
"writes": ["ticket"],
|
|
39
|
+
"required_expertise": [],
|
|
40
|
+
"ticket_expertise": false,
|
|
41
|
+
"expected_output": "Dependency-aware executable tickets for the accepted specification or a typed prerequisite/stop result.",
|
|
42
|
+
"result_vocabulary": ["SUCCESS", "PRECONDITION_UNSATISFIED", "BLOCKED"]
|
|
43
|
+
},
|
|
44
|
+
"planning.replan": {
|
|
45
|
+
"desired_intent": "REPLAN",
|
|
46
|
+
"active_artifact": "ticket",
|
|
47
|
+
"reads": ["product", "engineering", "engineering_research", "spec", "ticket", "project_rule", "repository"],
|
|
48
|
+
"writes": ["engineering", "engineering_research", "spec", "ticket", "project_rule"],
|
|
49
|
+
"required_expertise": [],
|
|
50
|
+
"ticket_expertise": true,
|
|
51
|
+
"expected_output": "Updated engineering contract and downstream admission state for the invalidated work.",
|
|
52
|
+
"result_vocabulary": ["READY", "HUMAN_INPUT_REQUIRED", "BLOCKED"]
|
|
53
|
+
},
|
|
54
|
+
"implementation.implement-ticket": {
|
|
55
|
+
"desired_intent": "IMPLEMENT",
|
|
56
|
+
"active_artifact": "ticket",
|
|
57
|
+
"reads": ["product", "engineering", "engineering_research", "spec", "ticket", "project_rule", "repository", "evidence", "review", "application_files"],
|
|
58
|
+
"writes": ["application_files", "evidence"],
|
|
59
|
+
"required_expertise": ["changeability"],
|
|
60
|
+
"ticket_expertise": true,
|
|
61
|
+
"expected_output": "Bounded implementation plus verification evidence and one legal lifecycle result.",
|
|
62
|
+
"result_vocabulary": ["REVIEW_REQUIRED", "REPLAN_REQUIRED", "PRECONDITION_UNSATISFIED", "BLOCKED"]
|
|
63
|
+
},
|
|
64
|
+
"implementation.repair-ticket": {
|
|
65
|
+
"desired_intent": "REPAIR",
|
|
66
|
+
"active_artifact": "ticket",
|
|
67
|
+
"reads": ["product", "engineering", "engineering_research", "spec", "ticket", "project_rule", "repository", "evidence", "review", "application_files"],
|
|
68
|
+
"writes": ["application_files", "evidence"],
|
|
69
|
+
"required_expertise": ["changeability"],
|
|
70
|
+
"ticket_expertise": true,
|
|
71
|
+
"expected_output": "Bounded repair plus fresh verification evidence and one legal lifecycle result.",
|
|
72
|
+
"result_vocabulary": ["REVIEW_REQUIRED", "REPLAN_REQUIRED", "BLOCKED"]
|
|
73
|
+
},
|
|
74
|
+
"review.review-ticket": {
|
|
75
|
+
"desired_intent": "REVIEW",
|
|
76
|
+
"active_artifact": "ticket",
|
|
77
|
+
"reads": ["product", "engineering", "engineering_research", "spec", "ticket", "project_rule", "repository", "evidence", "review", "application_files", "state"],
|
|
78
|
+
"writes": ["review"],
|
|
79
|
+
"required_expertise": ["testing", "changeability"],
|
|
80
|
+
"ticket_expertise": true,
|
|
81
|
+
"expected_output": "One immutable independent review round tied to the current contract and repository basis.",
|
|
82
|
+
"result_vocabulary": ["PASS", "REPAIR", "REPLAN", "BLOCKED"]
|
|
83
|
+
}
|
|
84
|
+
}
|
|
85
|
+
}
|
|
@@ -1,23 +1,25 @@
|
|
|
1
1
|
# Orchestrator role
|
|
2
2
|
|
|
3
3
|
## Authority
|
|
4
|
-
Own continuity,
|
|
4
|
+
Own continuity, evidence-backed reconciliation, invalidation coordination, and next-workflow dispatch. Deterministic workspace/repository reconstruction, routing, and handoff serialization are delegated to the canonical runtime tool rather than improvised by the model.
|
|
5
5
|
|
|
6
6
|
## Boot sequence
|
|
7
7
|
1. Resolve the YAAW workspace root using `.yaaw-core/system/core/execution-context.md`; never assume provider CWD.
|
|
8
|
-
2.
|
|
9
|
-
3.
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
8
|
+
2. Execute `node .yaaw-core/system/tools/orchestration-runtime.mjs --workspace <WORKSPACE_ROOT>` exactly once for the current basis.
|
|
9
|
+
3. Consume the typed result:
|
|
10
|
+
- `FRAMEWORK_STOP` -> report the typed framework failure/repair instruction and stop without lifecycle mutation;
|
|
11
|
+
- `RECONCILE_REQUIRED` -> execute only `orchestration.reconcile-state`, then run the deterministic preparation again;
|
|
12
|
+
- `ROOT_ACTION` -> execute the selected Orchestrator recovery workflow, then prepare again;
|
|
13
|
+
- `TERMINAL`/`BLOCKED` -> stop with that result;
|
|
14
|
+
- `DISPATCH_READY` -> use the persisted handoff exactly as produced.
|
|
15
|
+
4. Do not independently recalculate worktree digests, grep for alternate artifact locations, replay routing precedence, or hand-serialize `observed-state.json`/`handoff.json`.
|
|
16
|
+
5. Dispatch exactly one canonical workflow using `.yaaw-core/system/workflows/orchestration/dispatch.md`. The host adapter resolves the configured authority execution profile; Orchestrator never invents or substitutes provider/model settings.
|
|
17
|
+
6. Permit a change of execution mechanism only through the host adapter and only when the adapter establishes execution-profile equivalence or authoritative per-dimension correction under the configured policy.
|
|
18
|
+
7. After any worker completion, failure, interruption, or lost response, return to deterministic preparation before selecting another semantic workflow. For Implementer/Reviewer execution failures, update or reset the replaceable dispatch-failure ledger only after confirming durable progress and the current handoff basis. A pre-execution host isolation/profile stop never increments that ledger.
|
|
19
|
+
8. Apply any configured host capability fallback only through `orchestration.dispatch`; preserve the exact semantic role/handoff and require the adapter to preserve the configured fallback profile.
|
|
20
|
+
9. Repeat until a real stop condition.
|
|
19
21
|
|
|
20
22
|
## Boundary
|
|
21
|
-
The Orchestrator is a traffic controller, not a super-agent.
|
|
23
|
+
The Orchestrator is a traffic controller, not a super-agent. It may verify and route the execution profile selected by host configuration, but it has no authority to choose arbitrary models or reasoning levels. Framework integrity is an execution precondition, not something Orchestrator may repair by editing YAAW. The Orchestrator never creates, edits, deletes, or weakens package-managed `.yaaw-core/system/**` content in a consumer run. It must not author product decisions, architecture, implementation, research conclusions, or acceptance. Roles never privately delegate to peers; every successor is chosen here.
|
|
22
24
|
|
|
23
|
-
Child/worker text is not project truth. Durable artifacts, repository evidence, accepted reviews,
|
|
25
|
+
Child/worker text is not project truth. Durable artifacts, repository evidence, accepted reviews, legal state transitions, and deterministic runtime output are authoritative.
|
|
@@ -3,26 +3,40 @@
|
|
|
3
3
|
Repository capability and repository identity are related but distinct.
|
|
4
4
|
|
|
5
5
|
## Capability
|
|
6
|
-
Resolve the YAAW workspace root using `.yaaw-core/system/core/execution-context.md`, then inspect Git
|
|
6
|
+
Resolve the YAAW workspace root using `.yaaw-core/system/core/execution-context.md`, then inspect Git only through the canonical utility.
|
|
7
7
|
|
|
8
|
-
|
|
9
|
-
- `READY`: Git repository exists and exact workspace identity is trustworthy.
|
|
10
|
-
- `UNVERSIONED`: workspace is valid but not versioned.
|
|
11
|
-
- `UNAVAILABLE`: Git or required host permission is unavailable.
|
|
12
|
-
- `ROOT_MISMATCH`: workspace/repository ownership cannot be reconciled safely.
|
|
13
|
-
- `IDENTITY_FAILED`: repository exists but identity calculation failed.
|
|
8
|
+
No semantic workflow may independently calculate `worktree_digest`. All repository identity used in handoff, verification, recovery, or review must originate from:
|
|
14
9
|
|
|
15
|
-
|
|
10
|
+
```text
|
|
11
|
+
node .yaaw-core/system/tools/repository-identity.mjs --workspace <WORKSPACE_ROOT>
|
|
12
|
+
```
|
|
16
13
|
|
|
17
|
-
|
|
18
|
-
When status is `READY`, record `head_commit`, `dirty`, and `worktree_digest`.
|
|
14
|
+
The tool emits machine-readable JSON on stdout, diagnostics on stderr, and exits non-zero when exact identity cannot be produced. The algorithm identifier is `yaaw-worktree-v2`. Roles and workflows **must not reimplement** it.
|
|
19
15
|
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
2. `git diff --binary HEAD -- .`;
|
|
23
|
-
3. `git diff --cached --binary HEAD -- .`;
|
|
24
|
-
4. sorted untracked paths inside the workspace scope and their byte hashes where accessible.
|
|
16
|
+
## Canonical digest inputs
|
|
17
|
+
All commands execute with `git -C <WORKSPACE_ROOT>` and remain workspace-scoped:
|
|
25
18
|
|
|
26
|
-
|
|
19
|
+
1. `git status --porcelain=v1 -z --untracked-files=all -- . <control-output exclusions>`
|
|
20
|
+
2. `git diff --binary --no-ext-diff --no-textconv HEAD -- . <control-output exclusions>`
|
|
21
|
+
3. `git diff --cached --binary --no-ext-diff --no-textconv HEAD -- . <control-output exclusions>`
|
|
22
|
+
4. `git ls-files --others --exclude-standard -z -- . <control-output exclusions>`
|
|
27
23
|
|
|
28
|
-
|
|
24
|
+
Hash raw stdout bytes. Never hash stderr, warnings, timestamps, absolute paths, ambient CWD, PIDs, or hostnames.
|
|
25
|
+
|
|
26
|
+
Untracked paths are slash-normalized and sorted. Regular files are hashed from exact bytes. Symlinks are hashed from their exact link-target representation. Unsupported or unreadable objects produce `IDENTITY_FAILED`; they are never silently omitted.
|
|
27
|
+
|
|
28
|
+
The final digest is SHA-256 over stable canonical UTF-8 JSON containing algorithm, workspace-relative scope, HEAD, component hashes, the explicit exclusions, and the sorted untracked manifest.
|
|
29
|
+
|
|
30
|
+
## Lifecycle-output exclusions
|
|
31
|
+
`yaaw-worktree-v2` excludes only YAAW files whose normal lifecycle write would otherwise invalidate the repository basis that the file itself records:
|
|
32
|
+
|
|
33
|
+
- `.yaaw-core/runtime/**` — replaceable observation/handoff/intent/failure caches;
|
|
34
|
+
- `.yaaw-core/project/state.json` — Orchestrator lifecycle ledger;
|
|
35
|
+
- `.yaaw-core/project/evidence/**` — immutable verification attestations;
|
|
36
|
+
- `.yaaw-core/project/reviews/**` — immutable acceptance attestations.
|
|
37
|
+
|
|
38
|
+
This prevents circular freshness: writing an observation, handoff, state transition, evidence record, or review cannot by itself make the implementation repository identity stale. These artifacts remain governed by their own schemas, revisions, immutability rules, transition sequence, and handoff references.
|
|
39
|
+
|
|
40
|
+
The exclusion deliberately does **not** cover product, engineering, research, specs, tickets, project rules, `.yaaw-core/install/**`, package-managed `.yaaw-core/system/**`, application files, `.codex/`, `.agents/`, `.claude/`, `.gemini/`, `.cline/`, or other provider/project paths. Changes to those continue to change repository identity.
|
|
41
|
+
|
|
42
|
+
When the Git top-level is an ancestor, unrelated sibling changes remain outside identity because all commands are scoped to the active workspace.
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
|
3
|
+
"$id": "yaaw.evidence/v1",
|
|
4
|
+
"type": "object",
|
|
5
|
+
"required": ["schema","id","ticket","ticket_revision","spec_revision","kind","repository","workflow","commands","checks"],
|
|
6
|
+
"properties": {
|
|
7
|
+
"schema": {"const": "yaaw.evidence/v1"},
|
|
8
|
+
"id": {"type": "string"},
|
|
9
|
+
"ticket": {"type": "string", "pattern": "^TASK-[0-9]+$"},
|
|
10
|
+
"ticket_revision": {"type": "integer", "minimum": 0},
|
|
11
|
+
"spec_revision": {"type": "integer", "minimum": 0},
|
|
12
|
+
"kind": {"type": "string"},
|
|
13
|
+
"repository": {
|
|
14
|
+
"type": "object",
|
|
15
|
+
"required": ["head_commit","dirty","worktree_digest"],
|
|
16
|
+
"properties": {
|
|
17
|
+
"head_commit": {"type": ["string","null"]},
|
|
18
|
+
"dirty": {"type": ["boolean","null"]},
|
|
19
|
+
"worktree_digest": {"type": ["string","null"]}
|
|
20
|
+
},
|
|
21
|
+
"additionalProperties": false
|
|
22
|
+
},
|
|
23
|
+
"workflow": {"type": "string"},
|
|
24
|
+
"commands": {"type": "array"},
|
|
25
|
+
"checks": {"type": "array"}
|
|
26
|
+
},
|
|
27
|
+
"additionalProperties": false
|
|
28
|
+
}
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
|
3
|
+
"$id": "yaaw.evidence/v2",
|
|
4
|
+
"type": "object",
|
|
5
|
+
"required": ["schema","id","ticket","ticket_revision","spec_revision","kind","repository","workflow","commands","checks"],
|
|
6
|
+
"properties": {
|
|
7
|
+
"schema": {"const": "yaaw.evidence/v2"},
|
|
8
|
+
"id": {"type": "string"},
|
|
9
|
+
"ticket": {"type": "string", "pattern": "^TASK-[0-9]+$"},
|
|
10
|
+
"ticket_revision": {"type": "integer", "minimum": 0},
|
|
11
|
+
"spec_revision": {"type": "integer", "minimum": 0},
|
|
12
|
+
"kind": {"type": "string"},
|
|
13
|
+
"repository": {"$ref": "repository-identity.schema.json"},
|
|
14
|
+
"workflow": {"type": "string"},
|
|
15
|
+
"commands": {"type": "array"},
|
|
16
|
+
"checks": {"type": "array"}
|
|
17
|
+
},
|
|
18
|
+
"additionalProperties": false
|
|
19
|
+
}
|