Submission execution

Focused reading

• Start from the selected submission route and existing checkpoint. Read a guidance file once while it is unchanged and its relevant contents remain available; after a handoff, reload only the missing instructions for the next step.

• Resolve checkout roles once. A short README section, applicable repository instructions, and origin usually suffice. Read layout, task, report, native-analysis, or CI documentation only to answer a concrete unresolved question.

• Do not load the consumer-facing STIG skills for routine submission orchestration. A task such as stigGenerateHtml appearing in the gate table does not require the general report workflow.

• Review the complete required change window in bounded groups. Start with filenames and diff statistics, then read each relevant diff. Record reviewed ranges and source states; a summary does not replace review of the changes.

• Keep tool results scoped. A normal status result should be a few lines; start a failure investigation with roughly 80 relevant lines or 2,000 tokens. Expand when needed for the diagnosis. Avoid dumping whole manuals, transcripts, or logs and then requesting the same content again because the tool output was truncated.

• Use a scoped Graphify query for an actual codebase question, not to rediscover the known submission guide.

Waiting for builds

Quiet waiting is the default for builds and supporting commands, both during submissions and when separately requested, including preparation and focused verification after a repair. Preserve complete stdout and stderr in a unique, announced log, using --console=plain --info for Gradle. Before launch, state the exact command, working directory, and a clickable absolute log link. Retain the process/session identifier and start time; use the submission checkpoint when one exists. A standalone build needs only a small command/result record, not a submission checkpoint.

Let a script supervise an already-authorized sequence of builds or experiments when the next steps are mechanical. It should retain the exact commands, working directories, complete logs, producer exit codes, elapsed time, and artifact paths; stop at a failed gate or required human/AI decision and return a bounded summary. The existing submission runner supplies this supervision for submission paths. Keep experiment conclusions and semantic review with the agent. Do not turn script-side waiting into repeated model-side liveness calls.

Prefer a tool or runner that returns on process completion. The subprocess may write its log continuously without sending that text to the model. Capture the producer's actual exit status; when using a pipeline, preserve it with pipefail. A success-looking line is not a substitute for the exit status.

Work from completion events: launch a command, wait, inspect its completed result, and continue or repair. The submission runner already waits for each child process and prints its log link. When the invocation exits, its STIG_SUBMIT_EVENT JSON line and event.json distinguish review_required, paused, complete, and failed. Review pauses exit 0; actual failures preserve their nonzero exit code. Await process completion and consume that terminal event instead of repeatedly opening the live log or checkpoint. Exit 0 alone is not submission completion. An AI executing a submission handles a review pause, records justified findings/approval, and resumes under the existing authorization; it does not hand off an unfinished run merely because a successful review pause was expected.

If completion notification is unavailable, check liveness every 15 minutes by default, or at the interval the user requested, such as 30 minutes. Check only process state and, when needed, log size/mtime or process activity. Read log contents after completion or when evidence suggests a stall. Silence or elapsed time alone does not justify killing or rerunning a build.

Report launch, completion, failures, and material changes. Do not implement a quiet wait as repeated short sleeps, model invocations, and unchanged-status messages. Use the host's supported wait/notification mechanism. An explicit request for live monitoring selects live output; use tee with pipefail and the requested cadence in that mode.

Completion and failure diagnostics

On completion, check the exit status and terminal event. A complete runner event is enough for routine gate status; a review_required or paused event still requires continuation. Do not reopen every successful log merely to restate it. For a standalone build, inspect its final summary once. Read warning/test reports when the summary flags a concern, a gate requires them, or the user requests them. Deduplicate repeated warnings while retaining the full log. On failure, identify the failed task and start with its specific error block, failing test report, or exception and relevant cause. Start with the runner's log link; read the producing source next and widen the log excerpt only when evidence requires it.

Filtering text for presentation must not hide an unsuccessful exit, unresolved warnings, or missing verification. An empty filtered result does not establish success. Keep the complete log accessible and report its link with the result. Diagnose and repair within the requested scope, record the cause and corrective action, and run the failed check plus any checks invalidated by the fix. Choose meaningful regression or contract checks when needed; reuse existing user decisions instead of asking for routine repair approval. Ask only when the fix needs an unresolved choice or additional authority.

The post-push CI snapshot on checked submissions is an observation, not a verification gate. Retain its actual command exit, structured result, and report/log paths; distinguish failed, running, missing, and unavailable CI from a successful pipeline. An observation error does not invalidate local gates or authorize automatic repair, retry, or resubmission. Follow the canonical CI observation policy for refresh and resume.

Verification state

Plan every required gate for the selected path, including the clean template and product-consumer gates. Record its exact command, checkout, input state, and result. A gate can be pending, running, passed, failed, stale, or explicitly waived by the user. Never treat a missing result or a clean working tree as a pass.

A handoff continues the same submission: preserve passed results when their relevant inputs are unchanged. After a fix, rebase, cleanup mutation, pin update, or checkout relocation, determine which results it invalidates. Rerun the failed gate and every affected later gate; retain other results with a concrete reason. If input relevance cannot be established, mark the result stale. Include local STIG/PhASAR dependency states when assessing consumer results.

Earlier submissions do not waive the gates of a newly requested submission. Let Gradle use its declared up-to-date and cache behavior; do not add blanket clean or --rerun-tasks. A documented input-tracking defect or explicit fresh-run request may require a task-local rerun; record that reason and fix the producing layer when in scope.

After required gates pass, add checks only for a new change, failure, unresolved concern, or explicit user request. Follow the repository's Graphify commit rules once. Changes confined to the graph do not invalidate Gradle gates; record them without restarting the build sequence.

Graphify before commits

After code edits, update the graph once before committing. PYTHONHASHSEED=0 graphify update . performs the AST-only refresh. On Latte-managed workstations, latte setup-graphify initializes or repairs the current scope, finishes any needed AST/semantic indexing through Codex, and validates the actual result. Use the same command in new clones or moved checkouts and after interrupted indexing; no manual handoff or finalization pass is needed.

Keep graphify-out/graph.json shared and stage it with the source change after review. Generated HTML, reports, manifests, labels and other clone-local metadata remain ignored. Scope setup removes old tracked generated files from the index while preserving their local copies. Preserve intentional saved findings under the project's policy.

Graphify's native post-commit and post-checkout rebuilds must remain disabled: they modify the shared graph after Git captured the commit and require an unnecessary follow-up commit. Latte removes only their managed blocks and keeps other hooks and the graph merge driver. IDEA's Commit and Push and ordinary Git need one commit after the refresh. The runner's GRAPHIFY_SKIP_HOOK=1 guard remains for older clones; it does not disable unrelated hooks. Path 0 disables hooks and skips Graphify work. Graph-only changes do not invalidate Gradle gates.

Compact checkpoint

Keep one small JSON or Markdown record outside the committed source tree, in a task-specific temporary or user-cache directory. Create temporary directories with mktemp -d. Record its absolute path in the first handoff and final summary. This is current run state, not another copy of the procedure or a transcript.

Update the checkpoint when a gate, source state, repair, decision, or submission result changes, and before a handoff. Do not rewrite it on every liveness check. Aim for roughly 1,000 tokens; link larger evidence instead of embedding it. Do not stage runtime logs, checkpoints, or copies of session transcripts.

On resume, read the checkpoint and verify the relevant repository/process state before continuing. Do not restart a recorded running command, repeat authorization questions already answered, reload unrelated manuals, or rerun passed gates merely because the conversation was compacted. If the checkpoint is missing or stale, recover only the necessary state from specific Git, process, and result records.

Final result and usage

Report submitted revisions, required gate outcomes, substantive repairs, remaining limitations, and the checkpoint path. Distinguish successful local submission from verified CI publication.

Collect usage only when the user requests it and the host exposes it cheaply. Take one cumulative snapshot at completion and save its timestamp using the known session's usage API or exact record. Do not search all session histories, install tools, or load product documentation just to read a counter. If requested but unavailable, say so. A requested price estimate is a separate billing question and requires the applicable provider, service tier, and current rates. Ordinary submissions and builds need no usage audit.

Cumulative input includes repeated context and can include cached-input/cache-write subsets; output includes reasoning where reported as a subset. Do not add those subsets twice or sum successive cumulative snapshots. Preserve the raw field names and identify the session and cutoff. The final response may postdate the snapshot.