@awak-app/simy-cli 0.4.0 → 0.5.1

package/src/codex-plugins/simy/.codex-plugin/plugin.json

@@ -0,0 +1,26 @@
+{
+  "name": "simy",
+  "version": "0.1.0",
+  "description": "Run SIMY quality, delivery, and pull request review workflows from the current Codex thread.",
+  "author": {
+    "name": "Specialist Doctors Inc.",
+    "url": "https://github.com/SpecialistDoctors-Inc"
+  },
+  "repository": "https://github.com/SpecialistDoctors-Inc/simy-cli",
+  "license": "UNLICENSED",
+  "keywords": ["simy", "sqm", "delivery", "pull-request"],
+  "skills": "./skills/",
+  "interface": {
+    "displayName": "SIMY",
+    "shortDescription": "Quality, delivery, and PR workflows for SIMY.",
+    "longDescription": "SIMY turns the current Codex thread into a bounded quality check, a full evidence-driven delivery loop, or a read-only pull request review.",
+    "developerName": "Specialist Doctors Inc.",
+    "category": "Developer Tools",
+    "capabilities": ["Quality", "Delivery", "Review"],
+    "defaultPrompt": [
+      "Run the SIMY SQM Loop for the current thread.",
+      "Run the SIMY Delivery Loop for the current thread.",
+      "Review the current pull request with SIMY."
+    ]
+  }
+}

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

@@ -0,0 +1,154 @@
+---
+name: agentic-delivery-loop
+description: Drive complex repository changes from a frozen success charter and failing reproduction through bounded repair loops, local verification, production-like containers, Codex-controlled Chrome user journeys, PR and integration gates, authorized merge and deployment, exact-revision live verification, cleanup, and a completion receipt. Use when implementation must converge autonomously with real user-facing evidence. Do not use for read-only reviews or one-shot low-risk edits.
+---
+
+# Agentic Delivery Loop
+
+Use one Codex task as the controller for the complete delivery lifecycle. Shell,
+browser, API, log, database, and artifact operations may all run in the same
+task. Treat implementer, user actor, evidence collector, and verifier as logical
+roles; they do not require separate agents.
+
+## Freeze the delivery charter
+
+Before material action, record:
+
+- objective and user-visible success conditions;
+- repositories, latest base branches, dedicated worktrees, environments, and
+  the exact user journey;
+- required evidence and applicable change boundaries;
+- exclusions and authority boundaries, especially merge, deployment,
+  production writes, paid APIs, external messages, and fixture cleanup;
+- attempt, time, and cost budgets. Default to at most three evaluated repair
+  attempts when the user has not set a budget.
+
+Do not silently weaken explicit conditions. Add discoveries as a charter patch.
+A scope or success-condition change needs user direction when it materially
+changes the requested result.
+
+## Keep delivery states distinct
+
+Track and report the highest state actually proven:
+
+`chartered -> reproduction_verified -> implemented -> locally_verified -> pr_ci_green -> integration_verified -> user_like_local_verified -> merged -> deployed_exact_revision -> health_verified -> live_verified -> cleanup_verified -> done`
+
+Mark a non-applicable gate explicitly with a reason. Never infer a later state
+from an earlier one. In particular:
+
+- local or container evidence is not deployed evidence;
+- green PR CI is not integration verification;
+- merge is not deployment;
+- a healthy deployment is not a verified user journey;
+- a locally verified Chrome journey is `user_like_local_verified`, not
+  `live_verified`;
+- lack of merge authority ends at `ready_waiting_authority`, not `done`.
+
+## Run one controlled loop
+
+For each attempt:
+
+1. **Observe:** load the current snapshot and revision-bound evidence.
+2. **Evaluate:** identify progress, missing evidence, goal drift, or a repeated
+   failure fingerprint.
+3. **Decide:** apply deterministic policy for `continue`, `retry_current`,
+   `propose_replan`, `request_hil`, `abort`, or `complete`.
+4. **Act:** execute one complete, smallest coherent candidate or verification
+   action.
+5. **Verify:** inspect evidence independent of the action's success claim.
+6. **Reduce:** append a typed receipt and atomically advance the snapshot.
+
+An LLM may propose hypotheses, repairs, or verdicts, but it must not directly
+override state transitions, retry budgets, authorization, or evidence gates.
+Only the controller promotes a candidate or terminalizes the run.
+
+Read [state and receipts](references/state-and-receipts.md) when the task has
+multiple attempts, resumes a prior run, spans repositories, or performs merge,
+deployment, paid, external, or concurrent operations.
+
+## Execute the delivery phases
+
+### 1. Reproduce the real failure
+
+Prefer the real payload, logs, persisted state, browser sequence, environment,
+and user identity. Preserve a failure receipt that distinguishes the original
+boundary from a simplified unit fixture.
+
+### 2. Isolate and implement
+
+Start from the latest required base in a dedicated worktree. Preserve user
+changes. Build the smallest behaviorally correct patch and add a regression
+that fails against the pre-fix behavior at the escaped boundary.
+
+### 3. Verify locally by change boundary
+
+Run focused regression tests first, then formatting, lint, type checking, unit
+tests, and the actual affected runtime. Apply only the relevant lanes from
+[the change-boundary matrix](references/change-boundary-matrix.md).
+
+For medium/high-risk work, run an independent blocker/P1 review after local
+verification. Fix findings narrowly and re-review only the fixes and directly
+affected behavior.
+
+### 4. Coordinate through Draft PR and integration state
+
+Record reproduction, tests, evidence, companion revisions, skipped checks, and
+remaining gates in the Draft PR. Before Ready or merge, combine the latest base
+with required companion and parallel changes, rerun the affected path, and
+confirm current CI and mergeability. Without combined-state proof, report
+`pr_only_verified`, not `integration_verified`.
+
+### 5. Run the Codex-controlled Chrome user journey
+
+For user-facing or browser-mediated behavior, build and start the complete
+production-like local stack from exact candidate revisions, use real APIs when
+the charter permits, then have Codex operate the user's Chrome through the
+browser extension as a normal user. Do not replace this gate with direct API
+calls or a fixed selector-only test.
+
+Read [Codex Chrome user verification](references/chrome-user-verification.md)
+before running this phase.
+
+### 6. Merge and deploy only with authority
+
+After authorization, use the repository's required merge method and verify the
+remote merge result. Wait until the target environment reports the exact merge
+revision or a verifiably derived image digest. Confirm health and runtime
+identity before live verification.
+
+### 7. Verify the deployed user journey
+
+Repeat the relevant Chrome journey against the deployed environment. Include
+refresh, session return, delayed responses, follow-up lineage, authorization,
+and artifact download/open checks when applicable. Capture screenshots and
+video when visible or timing-dependent behavior matters.
+
+If this fails, retain `merged` and `deployed_exact_revision`; do not reset
+history or claim `done`. Save the exact revision, environment, input, Run ID,
+timestamps, visible state, network evidence, and logs, then add a boundary
+regression before re-entering implementation.
+
+### 8. Clean up and issue the receipt
+
+Remove scoped fixtures and prove the residual count is zero. Deliver a compact
+completion receipt containing repository revisions, PR and CI, independent
+review, container/runtime results, local Chrome evidence, merge and deployment
+identity, deployed Chrome evidence, artifacts, cleanup, skipped gates, and
+residual risk.
+
+## Stop deliberately
+
+Use exactly one disposition:
+
+- `verified_complete`: every applicable gate passed with evidence;
+- `best_available`: the bounded loop produced a safe useful result but named
+  criteria remain unmet;
+- `blocked`: missing authority, input, dependency, or safety precondition
+  prevents progress;
+- `failed`: no safe useful candidate remains within budget;
+- `cancelled`: the user stopped or replaced the task.
+
+Stop after the attempt budget, two consecutive non-improving candidates, or an
+A-B-A failure pattern without a materially different safe repair. Deliver the
+best verified candidate, not merely the latest attempt.
+

package/src/codex-plugins/simy/skills/agentic-delivery-loop/agents/openai.yaml

@@ -0,0 +1,5 @@
+interface:
+  display_name: "Agentic Delivery Loop"
+  short_description: "Converge code changes through real live proof"
+  default_prompt: "Use $agentic-delivery-loop to take this change from reproduction through verified delivery."
+

package/src/codex-plugins/simy/skills/agentic-delivery-loop/references/change-boundary-matrix.md

@@ -0,0 +1,67 @@
+# Change-Boundary Verification Matrix
+
+Apply only the lanes touched by the change, plus shared boundaries needed to
+prove the user outcome.
+
+## Common foundation
+
+- Preserve a failing reproduction or explain why it cannot be captured.
+- Run focused regressions, formatting, lint, type checks, unit tests, and the
+  real affected build/runtime in that order when available.
+- Inspect the final diff for scope, secrets, generated files, and unrelated
+  churn.
+- Use current source and dependency revisions in every evidence receipt.
+
+## UI and user-state changes
+
+- Render the actual UI in a browser.
+- Exercise refresh during and after completion, back/forward navigation,
+  another session and return, delayed stream/poll responses, and stale-cache or
+  replica responses where relevant.
+- Verify follow-up and parent/child lineage, optimistic state reconciliation,
+  authorization, and tenant separation.
+- Capture and inspect screenshots; capture video for streaming, recovery,
+  animation, or timing-dependent behavior.
+
+## Generated artifacts
+
+- Download through the user-facing path.
+- Verify non-empty bytes, expected type, stable hash, and ownership/tenant.
+- Open with the real consumer. Render every page/slide/sheet when layout
+  matters and inspect the rendered output.
+- Confirm final-result metadata and artifact storage agree.
+
+## Runtime and packaging
+
+- Build the exact production Dockerfile/image, not only a development image.
+- Start the real entrypoint and execute a representative app-server turn.
+- Check required binaries, fonts, renderers, runtime dependencies, health,
+  signals, and restart behavior inside the image.
+- Record the image digest and bind later evidence to it.
+
+## Backend, database, and asynchronous work
+
+- Apply migrations against an isolated representative database and verify
+  rollback/compatibility expectations where required.
+- Exercise the real API, authentication, authorization/RLS, persistence,
+  replay/idempotency, retries, concurrency, queue/worker delivery, and late
+  updates.
+- Confirm visible state against persisted rows and runtime logs using the same
+  Run ID.
+
+## Cross-repository changes
+
+- Pin every repository and contract revision.
+- Identify required merge/deploy order and backward-compatibility window.
+- Compose companion and parallel changes before Ready.
+- Run the user journey against the combined revisions and record all SHAs and
+  image digests.
+
+## External providers
+
+- Use real APIs only when the charter permits cost and side effects.
+- Prefer scoped sandbox accounts, dedicated users/tenants, unique Run IDs, and
+  explicit cleanup.
+- Require human authorization for production messages, destructive writes, or
+  other consequential effects not already authorized.
+

package/src/codex-plugins/simy/skills/agentic-delivery-loop/references/chrome-user-verification.md

@@ -0,0 +1,136 @@
+# Codex Chrome User Verification
+
+Read this before running a local production-like or deployed user journey with
+Codex controlling the user's Chrome through the browser extension.
+
+## Meaning of this gate
+
+This is goal-driven user simulation, not a direct API test and not merely a
+fixed selector script. Codex receives a user outcome, perceives the real page,
+and operates Chrome through normal visible interactions. Deterministic checks
+then judge the resulting evidence.
+
+Use distinct claims:
+
+- `user_like_local_verified`: the exact candidate revisions passed in a local
+  production-like stack through Chrome;
+- `live_verified`: the exact deployed revision passed in the target shared or
+  production environment through Chrome.
+
+## Prepare the local environment
+
+Prefer a Compose-style environment bundle over one monolithic container. Use
+the production Dockerfiles and exact candidate revisions for applicable
+services such as:
+
+```text
+web
+API / orchestration
+backend or edge functions
+agent runtime
+database and authentication
+queue and workers
+object storage
+supporting renderers or processors
+```
+
+Run Chrome on the host and route it to the environment through stable local
+URLs. Account for container networking: `127.0.0.1` inside a container is not
+the host. Use the platform's supported host gateway or service DNS and record
+the resolved endpoints.
+
+Start services, apply migrations and seeds, verify health, and record service
+SHAs plus image digests before opening the user journey.
+
+## Connect Codex to Chrome
+
+Use the Chrome/browser-control skill available in the current environment. The
+user's Chrome profile must have the ChatGPT browser extension installed and
+connected through the desktop app's Computer Use settings. Use the explicitly
+selected Chrome surface; do not silently substitute another browser.
+
+Use a dedicated verification profile and allowlist only the required local,
+dev, and external-provider domains. Do not inspect cookies, passwords, browser
+history, or profile storage. If authentication blocks the task, ask the user to
+sign in in the selected Chrome profile and resume from the same journey.
+
+## Define the user scenario
+
+Give the browser actor a natural-language goal and observable success criteria,
+not internal API steps. Example shape:
+
+```text
+Open the application, complete <real user objective>, wait for completion,
+refresh the page, leave and return through another session, follow up on the
+result, download the final artifact, and open it.
+```
+
+The actor should use visible UI interactions. Direct API, database, and log
+access are secondary evidence and diagnosis channels, not substitutes for the
+browser journey.
+
+## Use real APIs safely
+
+When permitted, use the actual model/provider and real integration APIs to
+exercise streaming, tool calls, latency, rate limits, and output variability.
+Require:
+
+- sandbox or dedicated verification accounts;
+- scoped credentials and tenant/user fixtures;
+- unique Run IDs and timestamps;
+- attempt, time, and spend caps;
+- dedicated Slack/Gmail/calendar or other external destinations;
+- reconciliation before retrying an ambiguous external effect;
+- recorded cleanup and residual count zero.
+
+Do not broaden existing authority. External messages, production writes,
+destructive operations, and new paid effects still require the applicable
+authorization.
+
+## Execute and collect evidence
+
+Codex may orchestrate the full sequence in one task:
+
+1. Build/start/restart services from the shell.
+2. Confirm health and runtime identity.
+3. Operate the application through Chrome.
+4. Capture screenshots and video when supported and relevant.
+5. Record visible messages, navigation, refresh/session behavior, download
+   paths, browser console/network failures, and timestamps.
+6. Correlate the visible result with backend logs, persisted state, Run IDs,
+   queue/worker activity, and artifact hashes.
+7. Evaluate the evidence against the frozen charter.
+8. On failure, classify the boundary, add a pre-fix regression, patch the
+   smallest surface, rebuild changed images, and repeat within budget.
+
+The same Codex task may perform actor and verifier phases, but the verifier must
+use recorded observable evidence rather than accepting the actor's completion
+claim.
+
+## Default acceptance predicate
+
+Tailor this to the charter:
+
+```text
+chrome_user_journey_passed =
+  visible_result_confirmed
+  && refresh_persistence_confirmed
+  && session_return_confirmed
+  && follow_up_lineage_confirmed_when_applicable
+  && backend_run_id_matched
+  && no_unexpected_console_or_network_failure
+  && artifact_download_open_hash_confirmed_when_applicable
+  && fixture_cleanup_confirmed
+```
+
+Save the browser profile label, target URL/environment, source revisions, image
+digests, user/tenant fixture, Run ID, start/end time, screenshots/video,
+download hashes, and skipped checks in the receipt.
+
+## After deployment
+
+First verify that the target environment serves the exact merge revision or
+derived image digest. Then repeat the smallest user journey that still crosses
+the changed boundary. A preview, local environment, or healthy endpoint cannot
+establish `live_verified` for another deployed environment.
+

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

@@ -0,0 +1,142 @@
+# State and Receipt Contract
+
+Read this reference for multi-attempt, resumable, cross-repository, concurrent,
+merge, deployment, paid, or externally mutating work.
+
+## Delivery snapshot
+
+Persist one controller-owned snapshot with at least:
+
+- `run_id`, `state`, monotonic `revision`, and terminal disposition;
+- immutable explicit conditions and their stable digest;
+- repository, base SHA, head SHA, companion SHAs, merge SHA, image digests, and
+  deployed revision;
+- target environments, user journey, user/tenant fixture identities, and
+  required artifacts;
+- applicable gates and their current status;
+- attempt number, retry/time/cost budgets, and failure fingerprints;
+- append-only receipt IDs, evidence references, timestamps, and cleanup state.
+
+Use compare-and-set or an equivalent single-writer protocol. Replaying the same
+receipt must be a no-op. Reusing an idempotency key with different content is
+an integrity failure.
+
+## Typed receipts
+
+Use the smallest applicable receipts rather than free-form completion claims:
+
+- `CharterReceipt`
+- `FailureReproductionReceipt`
+- `ImplementationReceipt`
+- `LocalVerificationReceipt`
+- `IndependentReviewReceipt`
+- `PRCIReceipt`
+- `IntegrationVerificationReceipt`
+- `ContainerEnvironmentReceipt`
+- `ChromeUserJourneyReceipt`
+- `MergeReceipt`
+- `DeploymentIdentityReceipt`
+- `HealthReceipt`
+- `LiveEvidenceReceipt`
+- `CleanupReceipt`
+- `CompletionReceipt`
+- `FailureReceipt`
+
+Each receipt should contain:
+
+- schema version, Run ID, module, result ID, input digest, idempotency key, and
+  production time;
+- `success`, `retryable_error`, or `terminal_error`;
+- source revisions and environment identity;
+- executed action and observed result;
+- evidence references such as commands, exit codes, logs, screenshots, video,
+  network traces, DB rows, artifact hashes, CI/deploy URLs, and timestamps;
+- a typed error category and retryability when unsuccessful.
+
+## Monitor verdict and policy action
+
+The semantic monitor may emit:
+
+```text
+status:
+  on_track
+  insufficient_evidence
+  goal_drift
+  retryable_failure
+  needs_hil
+  blocked
+  completed
+
+recommended_action:
+  continue
+  retry_current
+  propose_replan
+  request_hil
+  abort
+  complete
+```
+
+The deterministic policy gate checks authorization, applicable state routes,
+revision identity, evidence completeness, idempotency, retry budget, repeated
+failure fingerprints, and external-effect ambiguity before accepting the
+recommendation.
+
+Do not expose hidden chain-of-thought. Publish only the typed verdict, concise
+reason, selected action, and evidence references.
+
+## Evidence invalidation
+
+Evidence is revision-bound:
+
+| Change | Invalidate |
+|---|---|
+| Charter or explicit success conditions | All affected downstream gates |
+| Head SHA or generated source changes | Local, CI, integration, container, and live evidence |
+| Base SHA or companion revision changes | Integration and later evidence |
+| Container image digest changes | Container user journey and later runtime evidence |
+| Merge SHA changes | Deployment identity and live evidence |
+| Deployed revision changes | Health and live evidence |
+| Browser profile, tenant, or fixture changes | Affected user-journey evidence |
+
+Do not discard historical receipts; mark them superseded for the current gate.
+
+## Failure handling
+
+Classify failures before retrying:
+
+- code defect;
+- stale or wrong revision;
+- environment/configuration drift;
+- weak or contaminated fixture;
+- external provider, authorization, rate limit, or timeout;
+- contract/schema drift;
+- persistence, concurrency, projection, cache, or replica race;
+- evidence collection failure.
+
+Retry only when the classification and policy permit it. Reconcile ambiguous
+external effects before retrying. Preserve passing work and repair the smallest
+affected surface. Repeated fingerprints require root-cause repair, replan, or
+human input rather than identical retries.
+
+## Completion predicate
+
+For the full delivery mode:
+
+```text
+done =
+  reproduction_verified
+  && locally_verified
+  && pr_ci_green
+  && integration_verified
+  && user_like_local_verified
+  && merged
+  && deployed_exact_revision
+  && health_verified
+  && live_verified
+  && cleanup_verified
+  && completion_receipt_created
+```
+
+Remove only genuinely non-applicable terms and record why. If merge or deploy
+is outside current authority, stop at the highest proven pre-authority state.
+

package/src/codex-plugins/simy/skills/pr-review/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: pr-review
+description: Review the current or specified pull request for correctness, regressions, security, evidence gaps, and SIMY repository-policy violations. Use when the user asks SIMY to review a PR. Do not use for implementing fixes unless separately requested.
+---
+
+# SIMY pull request review
+
+Use the current Codex thread to resolve the intended behavior, then inspect the actual pull request and repository evidence.
+
+## Review contract
+
+- Resolve the PR from an explicit URL/number or the current branch. If it cannot be resolved unambiguously, ask for the smallest missing identifier.
+- Read applicable `AGENTS.md` instructions, the complete diff, changed-file context, tests, and current check state.
+- Focus on behaviorally meaningful findings: correctness, authorization and tenant boundaries, data loss, concurrency and retries, compatibility, security, and missing regression evidence.
+- Report findings first, ordered by severity, with precise file and line references. Explain impact and the smallest credible fix.
+- Distinguish verified defects from questions or residual risks. If there are no findings, say so and name the remaining verification gaps.
+- Do not edit code, post a review, approve, merge, deploy, or send external messages unless the user separately authorizes that action.
+- Never call a PR merged merely because auto-merge is enabled; verify its remote state and `mergedAt` when merge status matters.

package/src/codex-plugins/simy/skills/pr-review/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "SIMY PR Review"
+  short_description: "Review a pull request with SIMY evidence rules"
+  default_prompt: "Use $pr-review to review the current pull request."
+policy:
+  allow_implicit_invocation: true

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

@@ -0,0 +1,21 @@
+---
+name: sqm-loop
+description: Run the SIMY Software Quality Monitor against the repository and changes discussed in the current Codex thread. Use when the user asks SIMY to start SQM, quality-check the current work, or prepare a PR quality proof.
+---
+
+# SIMY SQM Loop
+
+Treat the current Codex thread, its attachments, and the active repository as the request context. Convert that context into explicit quality expectations, then verify the actual repository state; do not merely summarize the conversation.
+
+## Run the quality loop
+
+1. Identify the repository root and the user-visible behavior or incident discussed in the current thread.
+2. Preserve unrelated user changes and follow repository instructions.
+3. Run `simy sqm min-check` from the repository root.
+4. Run `simy sqm check --proof proof.json --signed-evidence proof.json.signed.json`.
+5. Read `proof.json` and require `outcome.status` to be `passed` before reporting success or proposing a pull request.
+6. Report the checked repository/revision, proof paths, outcome, blockers, and any evidence gap.
+
+If implementation is required before the check can pass, obtain or confirm the user's change authorization and make the smallest relevant repair. A request to run SQM alone does not authorize unrelated edits, a PR, merge, deployment, or external messages.
+
+Do not substitute an informal LLM review for SQM. If the CLI is unavailable, authentication is missing, or the proof is not passed, stop at the highest verified state and report the exact blocker.

package/src/codex-plugins/simy/skills/sqm-loop/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "SIMY SQM Loop"
+  short_description: "Run SQM from the current Codex thread"
+  default_prompt: "Use $sqm-loop to quality-check the work in this thread."
+policy:
+  allow_implicit_invocation: true