@amistio/cli 0.1.49 → 0.1.50
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/README.md +1 -1
- package/dist/index.js +4 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -84,7 +84,7 @@ When `--tool codex` uses the Codex SDK, intermediate progress can be quiet until
|
|
|
84
84
|
|
|
85
85
|
The runner advertises its supported work kinds in heartbeats. Current runners can claim read-only `projectContextRefresh` jobs from the workspace Context panel and create due runner-driven refreshes when no fresh approved map exists. Context refreshes inspect the paired checkout locally without modifying files and submit only bounded summaries, slices, entities, relations, safe citations, confidence, freshness, and repo-relative paths. If a submitted context refresh contains unsafe evidence, unsafe paths, or a map too large to store safely, Amistio marks the refresh failed with a safe reason instead of storing the rejected raw result. Approved maps are reused as context packs for source-aware assistant and impact-preview work. Current runners can also claim read-only issue diagnosis jobs from the web Issues panel, generate root-cause analysis and a proposed fix, and submit that result without modifying source. They can claim manual read-only `appEvaluationScan` jobs from the workspace Evaluate panel and create at most one due hourly evaluation during normal watch/background polling when app evaluation is enabled for the repository link. Evaluation results contain bounded summaries, safe evidence, suggested actions, lifecycle proposals, and repo-relative paths only. Current runners can also claim manual read-only `securityPostureScan` jobs from the workspace Security panel and create due daily posture checks during normal watch/background polling. Security scan results contain bounded summaries, standard references, safe evidence, and repo-relative paths only. Current runners can claim manual read-only `testQualityScan` jobs from the workspace Test panel and create one due daily Test scan per repository when Test quality is enabled. Test scans run only existing lint, typecheck, test, coverage, build, or verify commands and submit bounded command summaries, coverage summaries, safe findings, blocked reasons, warnings, and repo-relative paths. Missing tests, missing coverage, low coverage, failing checks, flaky tests, and test gaps create reviewable plan-backed findings in the app. Current runners also claim `implementationTestGate` jobs before implementation completion, PR handoff, or runner-managed push; a passing gate is required unless the web Test panel records an audited override. Blocked implementation Test gates submit structured Test findings, such as `blockedEnvironment`, with safe evidence, a suggested action, and a verification plan. Current runners can claim read-only `implementationVerification` jobs from Tasks to prove whether completed implementation work actually landed; verification submits bounded acceptance-criteria evidence, checks, gaps, outcome, and recommendation without mutating source. Source, secrets, environment variables, command lines, process lists, credentials, provider sessions, and arbitrary local paths stay local. Implementation or cleanup is queued separately only after the user approves an issue analysis, app evaluation finding, security remediation plan, or Test quality plan in the app.
|
|
86
86
|
|
|
87
|
-
Approved implementation work uses Git as the handoff boundary. During worktree preflight, the runner locally copies eligible ignored root dotenv files such as `.env.local` or `.env.test.local` from the paired checkout into the implementation worktree when the target is missing and ignored, so local tests can use the same machine configuration. Dotenv values, variable names, file contents, and local paths are not uploaded to Amistio, and copied dotenv files stay ignored so PR handoff does not commit them. Before local AI/tool execution starts, implementation work checks PR handoff readiness: GitHub remote support, default-branch fetch, Git commit identity, local `gh` authentication, and repository visibility. After the local tool completes successfully, the runner materializes approved Markdown, MDX, and HTML project-brain artifacts for the same work scope into the isolated worktree before final Git status, then classifies the final diff. Source-implementation work must include source, config, test, or other implementation-affecting changes before the runner opens or reuses a PR. If only project-brain or documentation artifacts changed, Amistio
|
|
87
|
+
Approved implementation work uses Git as the handoff boundary. During worktree preflight, the runner locally copies eligible ignored root dotenv files such as `.env.local` or `.env.test.local` from the paired checkout into the implementation worktree when the target is missing and ignored, so local tests can use the same machine configuration. Dotenv values, variable names, file contents, and local paths are not uploaded to Amistio, and copied dotenv files stay ignored so PR handoff does not commit them. Before local AI/tool execution starts, implementation work checks PR handoff readiness: GitHub remote support, default-branch fetch, Git commit identity, local `gh` authentication, and repository visibility. After the local tool completes successfully, the runner materializes approved Markdown, MDX, and HTML project-brain artifacts for the same work scope into the isolated worktree before final Git status, then classifies the final diff. Source-implementation work must include source, config, test, or other implementation-affecting changes before the runner opens or reuses a PR. If only project-brain or documentation artifacts changed, Amistio completes the work as no implementation produced instead of opening a misleading implementation PR. App-evaluation proof and lifecycle-cleanup actions are queued with explicit docs-only expected outcomes, so safe proof notes and plan metadata updates can create docs-only PRs without being mislabeled as source implementation. Other explicit docs-only work can also create docs-only PRs. No-change completion requires no source changes and no approved artifact changes, and runner-created no-change worktrees are removed after final clean checks. Prepare the runner machine with Git commit identity, fetch/push permission to the linked remote, and `gh auth status`. If artifact materialization, commit, fetch/rebase, push, or PR creation fails, the work item is blocked with safe recovery choices; source files and patches are not uploaded to Amistio. The Work panel can queue scoped Retry handoff or Retry cleanup commands only to the runner that owns the preserved worktree for the same work item, branch, and worktree key. Retry handoff can publish a clean preserved local-only implementation commit without rerunning the implementation prompt. Rebase conflicts capture bounded repo-relative conflict files and try `git rebase --abort` so the implementation branch can be retried or manually reviewed without leaving an active rebase. Dirty, unmerged, or ambiguous worktrees are preserved rather than discarded.
|
|
88
88
|
|
|
89
89
|
Failed or stale work can be requeued from the web Tasks panel. Requeue creates a new linked work attempt and preserves the original terminal attempt for audit history; Requeue safe sends one backend batch that recomputes safe candidates, reports already-active and skipped rows, and still uses linked attempts. Requeue is blocked while equivalent work is already active, when the paired runner does not advertise the needed work kind, or when the latest linked attempt repeats the same sanitized blocker fingerprint. Repeated runner setup, handoff, policy, verification, and worktree blockers require root-cause repair before another linked attempt. Completed implementation status is separate from proof: queue `implementationVerification` from Tasks when a plan needs source-aware evidence before cleanup or implementation status decisions.
|
|
90
90
|
|
package/dist/index.js
CHANGED
|
@@ -9711,6 +9711,9 @@ import path18 from "node:path";
|
|
|
9711
9711
|
import { promisify as promisify6 } from "node:util";
|
|
9712
9712
|
var execFileAsync6 = promisify6(execFile6);
|
|
9713
9713
|
var DEFAULT_IMPLEMENTATION_EXPECTED_OUTCOME = "sourceImplementation";
|
|
9714
|
+
function workStatusFromImplementationHandoff(handoff) {
|
|
9715
|
+
return handoff.status === "prReady" || handoff.status === "noChanges" || handoff.status === "noImplementationProduced" ? "completed" : "blocked";
|
|
9716
|
+
}
|
|
9714
9717
|
async function checkImplementationHandoffReadiness(input) {
|
|
9715
9718
|
const run = input.commandRunner ?? defaultCommandRunner;
|
|
9716
9719
|
const headBranch = input.worktreeIsolation?.branch ?? input.workItem.executionBranch;
|
|
@@ -12300,7 +12303,7 @@ async function runNextWorkItem({
|
|
|
12300
12303
|
worktreePath: executionRoot
|
|
12301
12304
|
});
|
|
12302
12305
|
}
|
|
12303
|
-
finalStatus = implementationHandoff
|
|
12306
|
+
finalStatus = workStatusFromImplementationHandoff(implementationHandoff);
|
|
12304
12307
|
finalMessage = implementationHandoff.message ?? "Implementation handoff finished.";
|
|
12305
12308
|
finalError = implementationHandoff.error;
|
|
12306
12309
|
}
|