@awak-app/simy-cli 0.5.13 → 0.5.14

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@awak-app/simy-cli",
-  "version": "0.5.13",
+  "version": "0.5.14",
   "description": "Local SIMY executor for non-coding Local Tasks and Agentic Loop runs.",
   "type": "module",
   "bin": {

package/src/cli-contract.js

@@ -13,7 +13,7 @@ import {
 } from "./durable-local-task-steps-contract.js";
 import { buildExecutionCapabilityContract } from "./execution-capability-contract.js";
 
-export const CLI_VERSION = "0.5.13";
+export const CLI_VERSION = "0.5.14";
 export const CLI_API_CONTRACT_VERSION = 10;
 
 export function withCliContract(

package/src/codex-plugins/simy/skills/agentic-delivery-loop/SKILL.md

@@ -229,6 +229,63 @@ Reuse this record in implementation and review. Recheck only affected entries
 when rules, scope, revisions, execution paths, or authority change; patch the
 charter and invalidate affected evidence under the existing receipt contract.
 
+## Check equivalent-purpose consistency
+
+Before changing behavior, contracts, validation, policy, or trust-boundary rules
+that affect users, API consumers, data integrity, or security, identify every
+relevant surface and execution path that serves the same user purpose. Group
+those paths by semantic intent, then record for each path its persona, current
+source of truth, precedence, fallback, enforcement location, and observed
+behavior. Include client and server paths, platform variants, account, tenant,
+app, device, or system preferences, caches, and legacy defaults when they can
+affect the result. Use code, configuration, schemas, tests, documentation, and
+runtime evidence; matching labels alone are not proof that the same rule is
+enforced.
+
+For each equivalent-purpose group, verify whether all paths consume one
+canonical rule with the same precedence and fallback semantics. When they do
+not, determine whether the divergence is intentional and supported by an
+authoritative product decision. Also check that tests cover the shared contract
+at every affected boundary. A language choice that follows the device or OS on
+one surface and an in-app preference on another is one instance of this class,
+not a language-specific exception. Input validation split between frontend and
+backend is another: identify the canonical validation contract separately from
+where it is enforced. Multiple enforcement points may be correct when the
+frontend provides timely feedback and the backend protects the trust boundary,
+but equivalent rules must not drift.
+
+If competing sources or behaviors exist and no authoritative choice resolves
+them, do not silently select the most common implementation or whichever path
+is easiest to change. Produce a human-decision packet containing:
+
+- the shared purpose, affected personas, surfaces, and current divergence;
+- each viable unification option, including preserving an intentional
+  divergence when that is genuinely valid;
+- for each option, user benefit, user and operational risk, compatibility and
+  migration effects, fallback behavior, reversibility, support and maintenance
+  cost, security and trust-boundary constraints, validation plan, and material
+  evidence gaps;
+- a recommendation and rationale when the evidence supports one, clearly
+  separated from the decision itself.
+
+Require an explicit human selection even when one option is recommended. Mark
+the affected decision `needs_hil` and the dependent implementation
+`partially_blocked`; continue independent authorized work, but do not implement
+the behavior choice, define its test oracle, migrate data, or advance the
+affected scope to Ready or merge. A timeout or missing response is not approval.
+Human choice does not override mandatory security, privacy, data-integrity, or
+external-contract constraints; exclude unsafe or non-compliant options from the
+viable set and explain why. For example, client-only validation is not viable
+when untrusted input reaches a server-side trust boundary.
+
+Record the selected option as a revision-bound `HumanDecisionReceipt` and patch
+the charter with the canonical source, precedence, fallback, affected consumers,
+migration and rollout constraints, enforcement locations, verification plan,
+and rollback condition. Then implement every affected path against that decision
+and add boundary tests that fail if the paths drift again. A later change to the
+decision or its canonical rule invalidates dependent evidence and requires a new
+decision when the trade-off materially changes.
+
 ## Keep delivery states distinct
 
 Track and report the highest state actually proven:

package/src/codex-plugins/simy/skills/agentic-delivery-loop/references/state-and-receipts.md

@@ -12,8 +12,9 @@ Persist one controller-owned snapshot with at least:
 - frozen experience-contract identities, their mapping to acceptance rows, and
   the current readable local-experience table path and digest;
 - acceptance-source identities and digests, architecture boundaries, applicable
-  rule decisions, risk tier, requested/effective delivery levels, the safety
-  ceiling reason, and chat-confirmation receipt;
+  rule decisions, human-decision receipt IDs, approved canonical sources and
+  their precedence and fallback semantics, risk tier, requested/effective
+  delivery levels, the safety ceiling reason, and chat-confirmation receipt;
 - repository, base SHA, head SHA, companion SHAs, merge SHA, image digests, and
   deployed revision;
 - target environments, user journey, user/tenant fixture identities, and
@@ -36,6 +37,7 @@ an integrity failure.
 Use the smallest applicable receipts rather than free-form completion claims:
 
 - `CharterReceipt`
+- `HumanDecisionReceipt`
 - `FailureReproductionReceipt`
 - `ImplementationReceipt`
 - `LocalVerificationReceipt`
@@ -66,6 +68,29 @@ Each receipt should contain:
   network traces, DB rows, artifact hashes, CI/deploy URLs, and timestamps;
 - a typed error category and retryability when unsuccessful.
 
+A `HumanDecisionReceipt` additionally stores or immutably references the exact
+decision packet presented to the human. Preserve the question and scope; every
+option's user benefit, user and operational risk, compatibility and migration
+effects, fallback behavior, reversibility, support and maintenance cost,
+security and trust-boundary constraints, validation plan, and material evidence
+gaps; any excluded unsafe or non-compliant option and its reason; and any
+recommendation separately from the decision. Record the selected option's exact
+text and stable ID or digest, conditions attached to the selection, decision
+maker, timestamp, and a stable approval reference such as a message or turn ID
+or an immutable transcript or artifact digest, with its channel and context when
+applicable. The selection may reference a viable presented option or an explicit
+user-authored modification or combination. When the user's decision is clear,
+executable, and introduces no undisclosed material trade-off, update the packet
+and record that same message as approval without requesting confirmation again.
+If the decision is ambiguous or introduces a material trade-off not yet explained,
+clarify only the unresolved point before proceeding with dependent work. Mandatory
+security, privacy, data-integrity, and external-contract constraints still apply.
+
+A successful `HumanDecisionReceipt` requires an explicit selection. Until then,
+store the pending decision packet in the snapshot and publish the monitor verdict
+`needs_hil` with action `request_hil`; never synthesize or infer approval from a
+recommendation, silence, or an implementation pattern.
+
 ## Monitor verdict and policy action
 
 The semantic monitor may emit:
@@ -104,6 +129,7 @@ Evidence is revision-bound:
 | Change | Invalidate |
 |---|---|
 | Charter or explicit success conditions | All affected downstream gates |
+| Human decision, canonical source, precedence, or fallback | All dependent implementation and verification evidence |
 | Acceptance source, test oracle, assertion, or CI/security gate changes | The affected gate and all dependent downstream evidence |
 | Head SHA or generated source changes | Local, CI, integration, container, and live evidence |
 | Base SHA or companion revision changes | Integration and later evidence |