drydock-cli 3.0.170__tar.gz → 3.1.2__tar.gz

{drydock_cli-3.0.170/drydock_cli.egg-info → drydock_cli-3.1.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: drydock-cli
-Version: 3.0.170
+Version: 3.1.2
 Summary: Drydock — a local, provider-agnostic terminal coding agent for local LLMs
 Author: Frank Bobe III
 License-Expression: Apache-2.0

{drydock_cli-3.0.170 → drydock_cli-3.1.2}/drydock/agent.py

@@ -236,6 +236,16 @@ def run(
         run_iteration += 1
         assistant_turn: AssistantTurn | None = None
 
+        # Keep the trajectory export current EVERY turn, not just at task end:
+        # a harness that kills a long task at its cutoff still gets the full
+        # transcript, and those hard/long tasks are exactly the ones whose
+        # trajectories are worth harvesting (2026-07-20: two verifier-PASSING
+        # tbench tasks lost their trajectories to this). record() overwrites
+        # and never raises, so the repeat write is safe and idempotent.
+        if config.get("trajectory_file") and state.turn_count > 1:
+            from drydock import trajectory as _traj
+            _traj.record(system_prompt, state, config)
+
         # Compact context if approaching limit
         maybe_compact(state, config)
 

drydock_cli-3.1.2/drydock/builtin_skills/fiar-assess.md

@@ -0,0 +1,33 @@
+---
+name: fiar-assess
+description: Test the next un-tested FIAR control objective against real evidence
+---
+Test FIAR control objectives in the engagement at: $ARGS
+
+Do exactly ONE control per run (loop it — /loop N /fiar-assess <path> — for the
+whole matrix):
+
+1. Call FiarControls with that path and status=not_tested. If none remain, say the
+   control matrix is fully tested and STOP without calling other tools.
+2. Take the FIRST not_tested control. Call FiarControl (path + id) to read its
+   control objective, assertions, required Key Supporting Documents (KSDs), and
+   test procedure.
+3. You MUST examine real evidence before deciding — do NOT guess. Follow the test
+   procedure: Read the actual KSD the control names (obligating document, receiving
+   report, invoice, reconciliation workpaper, SF-50, access-recert listing, …) or
+   run its check command (Bash). If the procedure says to sample, state your sample
+   size and how many exceptions you found. Reason step by step about whether the
+   evidence satisfies the control objective for its assertion(s).
+4. Call FiarAssess (path + id) with:
+   - status = effective ONLY if the evidence clearly shows the control operated;
+              deficient if the evidence shows it did not (any un-remediated
+              exception makes the control deficient);
+              not_applicable if the control does not apply to this entity;
+   - evidence = the exact KSDs you examined and what they showed (quote the line);
+   - sample_size and exceptions when you tested a sample.
+5. If you set deficient, immediately call FiarFinding to record the NFR: condition
+   (what you observed), criteria (the policy/standard/GAAP requirement), cause
+   (root cause), effect (impact on the assertion/balance), recommendation, and a
+   severity (deficiency / significant_deficiency / material_weakness).
+
+Give a one-line summary: control id, the KSD evidence, and the status you set.

drydock_cli-3.1.2/drydock/builtin_skills/fiar-cap.md

@@ -0,0 +1,26 @@
+---
+name: fiar-cap
+description: Draft a Corrective Action Plan for the open FIAR findings (NFRs)
+---
+Draft Corrective Action Plans for the open findings in the FIAR engagement at: $ARGS
+
+1. Call FiarControls (path only) to see the engagement, then read the findings by
+   listing deficient controls (FiarControls status=deficient) and, for each, its
+   recorded NFR. If there are no findings, say so and STOP.
+2. Take ONE finding at a time (worst severity first: material_weakness, then
+   significant_deficiency, then deficiency). For it, draft a CAP that is specific
+   and testable:
+   - root_cause: the underlying reason the control failed (people / process /
+     system / policy) — go past the symptom in the NFR condition;
+   - action: the concrete corrective action that will make the control operate;
+   - responsible: the organization / POC who owns it;
+   - target_date: a realistic milestone date;
+   - milestones: 2–4 dated, verifiable steps (e.g. "update SOP", "train preparers",
+     "re-test 25 samples with 0 exceptions").
+3. The CAP must close the specific assertion gap the NFR identified — tie the final
+   milestone to a re-test of the same control with zero exceptions. Note whether the
+   fix is a process change, a system change, or an ITGC (access / SoD / change
+   management) remediation, since those route to different owners.
+
+Present each CAP in the standard structure (finding → root cause → action →
+responsible → milestones), and end with which finding to remediate first and why.

drydock_cli-3.1.2/drydock/builtin_skills/fiar-evidence.md

@@ -0,0 +1,33 @@
+---
+name: fiar-evidence
+description: Trace the full FIAR evidence chain for a control before passing it
+---
+Substantively test ONE FIAR control by tracing the complete evidence chain, for the
+engagement + control id in: $ARGS
+
+A control cannot support a financial-statement assertion on a broken audit trail.
+You MUST trace all eight links before FiarAssess will let you mark it effective:
+
+  population → sample → source_transaction → authorization → supporting_document
+            → system_posting → gl_effect → assertion
+
+1. Call FiarControl (path + id) to read the objective, assertions and KSDs.
+2. Establish the POPULATION: the recorded universe (a GL detail, a transaction
+   register, an APSR listing). State how you know it is complete.
+3. SELECT a sample from that population and record exactly which item(s).
+4. For each sampled item, gather and Read the real evidence for each link:
+   - source_transaction: the transaction the item represents;
+   - authorization: the warranted/authorized approver (warrant, SF-50, delegation);
+   - supporting_document: the KSD (contract, receiving report, invoice, recon wp);
+   - system_posting: where it posted in the feeder/accounting system;
+   - gl_effect: the resulting general-ledger entry;
+   - assertion: the FS assertion it ultimately supports.
+5. Call FiarAssess with status=effective and a `chain` object whose keys are the
+   eight links above, each set to the specific evidence you found. If any link is
+   missing, FiarAssess will REFUSE and name the gap — go get that evidence, do not
+   force the status. If a link genuinely cannot be traced (e.g. no authorization on
+   file), the control is DEFICIENT: set status=deficient and record an NFR with
+   FiarFinding.
+
+Report the item you traced and, link by link, the evidence that supported it (or the
+link that broke the chain).

drydock_cli-3.1.2/drydock/builtin_skills/fiar-readiness.md

@@ -0,0 +1,28 @@
+---
+name: fiar-readiness
+description: Assess audit-readiness posture of a FIAR engagement and report gaps
+---
+Produce a Discover-phase audit-readiness assessment for the FIAR engagement at: $ARGS
+
+1. Call FiarControls (path only) to see the whole matrix: cycle, Wave, phase, and
+   the status counts. If the engagement JSON does not exist yet, tell the operator
+   to create one first: `python -m drydock.fiar new <path> <name> <cycle>` (cycles:
+   FBWT, P2P, PPE, INV, CIVPAY, REIM, FR, ITGC, or * for all).
+2. Call FiarControls with status=deficient and status=not_tested to enumerate the
+   gaps. For each DEFICIENT control, note the assertion(s) at risk and whether an
+   NFR already exists for it.
+3. Read the current readiness roll-up (the counts show tested vs effective). State,
+   in plain terms:
+   - percent of applicable controls tested, and of those, percent effective;
+   - the assertions (Existence, Completeness, Valuation, Presentation & Disclosure,
+     Rights & Obligations) that are NOT yet supported because a control covering
+     them is deficient or untested;
+   - open findings by severity (material weakness / significant deficiency /
+     deficiency) and whether each has a Corrective Action Plan.
+4. Recommend the highest-value next actions to move toward assertion, prioritizing
+   material weaknesses and untested key controls (FBWT reconciliation, three-way
+   match, access/SoD ITGCs). Do NOT claim the entity is audit-ready — readiness is
+   asserted by management and validated by an independent examination; your job is
+   to report the evidenced posture and the gaps.
+
+Report a short readiness summary (3–4 sentences) first, then the detail beneath it.