create-filegrc 0.16.17 → 0.16.19

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-filegrc",
-  "version": "0.16.17",
+  "version": "0.16.19",
   "description": "Create a filegrc workspace for a SOC 2 program",
   "license": "MIT",
   "repository": {

package/src/index.js

@@ -524,13 +524,13 @@ async function runCombinedSetup(target, input) {
 async function writeMinimalLockfile(target, name, versionRange) {
   const lock = {
     name,
-    version: "0.16.17",
+    version: "0.16.19",
     lockfileVersion: 3,
     requires: true,
     packages: {
       "": {
         name,
-        version: "0.16.17",
+        version: "0.16.19",
         dependencies: { filegrc: versionRange }
       }
     }

package/template/AGENTS.md

@@ -6,6 +6,12 @@
 
 Using this repository does not establish compliance by itself. Records must match actual practice and evidence must prove that controls operated during the audit period.
 
+## How to work with the user
+
+Own the FileGRC work. Inspect the repository, linked records, policy text, Git history, and any available systems; draft and update records, run previews, validate, and review the result yourself. A next action is your work to carry forward, not a list of commands or fields for the user to fill.
+
+Work through Control implementations one at a time. For the current Control, do everything you can establish from available sources before asking the user. If progress depends on a material fact, real-world action, approval, or management decision you cannot establish, ask exactly what you need, name what you checked, and explain what the answer will let you finish. Do not ask for vague confirmation or facts already recorded. After the answer, finish that Control and continue the requested workflow without another handoff. Do not invent business events, approvals, dates, or evidence.
+
 ## Agent quick start
 
 Do not guess a resource type, field name, enum value, relationship, or file path. Start every unfamiliar task with the installed model:
@@ -21,7 +27,7 @@ npx filegrc program-amendment SOURCE_RESOURCE_ID --json
 
 `program-path --next --json` gives agents the current step and first action. Use `--summary` for all five step statuses or `--current` for the current step’s page summaries, detailed guidance fields, commands, and next actions. The general guide lists every supported action and record type. A type guide adds the checks needed for that resource, including timing, required and conditional fields, current relationship candidates, JSON location, and Markdown slots.
 
-Before proposing a new process or record for a Control, inspect the current Control, its linked Policy and Markdown, Obligations, operating records, Components, and Evidence with `get`, `list`, `search`, and `references`. Read `get CONTROL_ID --workflow --json` and the relevant type guides to find the actual gap. Reuse an existing rule or workflow when it covers the requirement. If the design exists but operation is unproven, ask for the real event, actors, dates, and evidence needed to record it; do not ask management to design the process again. Ask users only for decisions or facts that the repository and available sources cannot verify. Never infer that a Policy or planned Obligation proves the Control operated.
+For a Control, inspect its linked Policy and Markdown, Obligations, operating records, Components, and Evidence with `get`, `list`, `search`, and `references`. Read `get CONTROL_ID --workflow --json` and the relevant type guides to find the actual gap. Reuse an existing rule or workflow when it covers the requirement. Separate setup from later operation: record the working configuration, owner, scope, procedure, source, and an enabled Obligation when its operation pattern needs one before marking the Control Implemented. An enabled schedule does not prove a cycle occurred. If the design exists but operation is unproven, inspect dated work and available evidence; ask only for the specific real event, actor, date, or artifact you cannot establish. Never infer that a Policy or planned Obligation proves the Control operated.
 
 For a new record, generate a mutation envelope:
 

package/template/data/AGENTS.md

@@ -20,6 +20,8 @@ Use `program-path --next --json` for the current lifecycle step. Use `workflow -
 
 Before creating a record or asking for a new procedure, inspect matching records and their links with `list`, `search`, `get RESOURCE_ID --workflow --json`, and `references RESOURCE_ID --json`. Read the linked Policy and companion Markdown, Control, Obligations, operating records, Components, and Evidence as applicable. Reuse the authoritative record and update it when needed. Separate a documented design or enabled schedule from proof that work actually occurred. Ask for only the missing business facts, decisions, or external evidence that you cannot verify; do not invent an event or ask for facts already recorded here.
 
+Do the discoverable work yourself: inspect current sources, draft the mutation, fill fields supported by those sources, preview it, validate it, and check the next action. When an answer from management or an external operator is necessary, ask for the exact material fact or decision and say what it will let you finish. Do not ask the user to run FileGRC commands, copy IDs, fill routine fields, or vaguely confirm a record. Continue the mutation and remaining workflow after the answer without another handoff. Keep approval and other acts reserved for the named person separate from agent-prepared drafts.
+
 In `get RESOURCE_ID --workflow --json`, inspect `workflow.recommended.context.existing` before using `scaffold`. The listed records are relationship candidates, not proof that work occurred.
 
 After changing a lifecycle fact directly, review `reconcile --preview --json`. A candidate asks whether the change represents a real policy event. Supply the actual event date or timestamp, departure risk when relevant, and explicit confirmation before applying it. If it is a false positive, use `reconcile --dismiss` with the exact candidate fingerprint, a Person reviewer, the review date, a rationale, and `--yes`. The immutable dismissal suppresses only that fingerprint.
@@ -105,6 +107,8 @@ When `guide` returns a collection review requirement, review the listed type-spe
 
 Use Retention Schedule records as the structured rows of the Data Retention Schedule. Keep a row `planned` until management has approved its Information Types, scope, cutoff, period, disposition action, instructions, sources, approver, date, and reviewed source revisions. Run `npx filegrc program-readiness --json` after changing an information use, source-coverage record, Commitment, Policy, or other source. FileGRC may identify missing or stale decisions, but it must never infer an organization-specific period or deletion behavior.
 
+When a row or Commitment relies on one section of a consolidated Policy or Document, set `sourceSectionHeadings` to map the source ID to its exact Markdown heading. Then run `npx filegrc review-bindings ROW_ID --json` for a row and record the returned revisions after reviewing that section. An edit elsewhere in the source leaves the decision current; a change to the selected section requires review. Omit a section heading when the whole source governs the decision. A pending Policy amendment remains a proposal until its revised content is approved.
+
 Store a relationship only on its authoritative record. Control Tests store `auditId`; Evidence Artifacts store `auditIds`; Commitments store `systemIds` and `controlIds`; Controls store `policyIds`, `requirementIds`, `systemIds`, `componentIds`, and `evidenceSourceComponentIds`; Risks store `controlIds`; Components store their `vendorId` and `systemUses`; Reporting Channel Sets store the normal and fallback ways people send a report, the rules requiring them, and the responsible role. Use `references` to inspect derived inbound links.
 
 Use explicit business dates. Git records when a file changed, but it does not replace `occurredOn`, `scheduledFor`, `completedOn`, `approvedOn`, or similar fields.
@@ -117,10 +121,12 @@ Status is an assertion. Before moving a record to a completed, approved, impleme
 2. Write the actual work and conclusion in Markdown when recommended.
 3. Link source Components, Evidence Artifacts, risks, findings, exceptions, and actions that support the result.
 4. Use the real completion or approval date.
-5. Confirm the named people performed and reviewed the work.
+5. Check the source for who performed and reviewed the work. Ask the named people only when their actual participation or approval cannot be established.
 
 Do not mark a control implemented because a policy says it should exist. Do not mark evidence verified because it was merely collected. Do not mark a task done without the completion record type requested by its obligation.
 
+For a Control, complete setup from the actual configuration, scope, owner, procedure, evidence source, and enabled work rules when its operation pattern needs them. Use the real implementation date when those conditions hold. Record a later operating cycle or event with its actor, date, result, and proof only after it occurs. Do not ask for operating proof to finish setup, and do not treat setup as proof of later operation.
+
 Policy, program Document, and Training approval in Step 2 accepts the reviewed requirements, intended values, and exact content revisions. It does not prove implementation or start governed work. A required program Document has `workflowScope: program`, and Training stays `approved`, until linked Controls and Obligations are ready. In Step 3, run `activate-content --scaffold` and record the active Person who performs the cutover, actual activation date, and effective date; FileGRC binds activation to each unchanged approved revision. Then run `activate-policies --scaffold`, review the approved Policies together, select the cutover set, and record the real effective date. Operate the program and collect Evidence in Step 4. Create Audit Documents with `workflowScope: engagement` only in the Step 5 workflow. After each Audit Document is complete, record approval first, then activate the unchanged approved revision in a separate update with its actor, actual activation date, and effective date.
 
 ## Delete and replace

package/template/data/audit-populations/AGENTS.md

@@ -4,7 +4,7 @@ Use one `audit-population` for one complete Type 2 population produced by one au
 
 Reconcile after the period closes:
 
-1. Confirm the exact audit period and related controls.
+1. Read the exact formal period and selected Controls from the Audit; ask the engagement owner only if the agreed scope is missing.
 2. Select the cataloged source Component whose `evidenceSourceKinds` covers the population.
 3. Export the complete population with fixed parameters and timezone.
 4. Create a verified `population-export` Evidence Artifact with the same source Component, period, query, generation time, count, completeness check, and accuracy check.

package/template/data/audits/AGENTS.md

@@ -1,6 +1,6 @@
 # Audit Instructions
 
-Create one `audit` record for one real CPA engagement. Define the audit kind, framework, exact firm-agreed Type 1 date or Type 2 period, scope, owners, auditor, and report status from facts supplied by management or the engagement team.
+Create one `audit` record for one real CPA engagement. Read the accepted engagement terms and current Program first, then fill the audit kind, framework, exact firm-agreed Type 1 date or Type 2 period, scope, owners, auditor, and report status from those sources. Ask management or the engagement team only for the exact agreed fact that remains unavailable.
 
 Keep management’s candidate Type 2 dates on `workspace`. Do not copy them into the audit record until the CPA firm agrees to those dates. Preserve both sets when the formal period differs.
 
@@ -22,7 +22,7 @@ Select a framework containing every CC1.1 through CC9.2 Security Common Criterio
 Review both evidence paths for the exact formal date or period:
 
 1. filegrc Evidence consists of dated Step 4 operating records. Complete the record, link it to the applicable Controls, record the result in its fields or Markdown, and link any external artifact needed to support that result.
-2. Evidence Artifacts are verified `evidence` records from source Components. Confirm the source Component, date or period, Control links, collector, verifier, and fixed attachment or approved external reference.
+2. Evidence Artifacts are verified `evidence` records from source Components. Read each artifact and its linked records to check the source Component, date or period, Control links, collector, verifier, and fixed attachment or approved external reference. Ask only for a missing source fact or independent verification.
 
 The packet compiles both paths. It includes FileGRC records and Markdown with Git history, plus Evidence Artifacts, retained attachments, delivery indexes, and checksums.
 

package/template/data/obligations/AGENTS.md

@@ -8,7 +8,7 @@ An obligation is a reusable policy schedule or event template. It is not the rec
 - Split the work only when a member needs its own queue owner, deadline, conclusion, or follow-up lifecycle.
 - Keep completed occurrences in `completionResourceIds`. Do not replace prior links when a new period starts.
 - Configure and enable Obligations during Step 3. An enabled Obligation remains dormant until every governing Policy and required program Document is active and effective and, when it names Controls, at least one linked Control is implemented. FileGRC starts calendar work from the latest Policy or governed Document effective date, so pre-cutover periods do not become overdue work.
-- Calendar Obligations generated with `status: proposed` contain suggested starting cadences. Review the scope and risk, edit the cadence when needed, and change the Obligation to `active` only when management accepts that schedule. A proposed Obligation never counts as a configured schedule.
+- Calendar Obligations generated with `status: proposed` contain suggested starting cadences. Compare the linked Policy, Control, scope, and risk records; prepare any supported edits and ask management for a specific cadence choice only when those sources do not settle it. Change the Obligation to `active` only when management accepts that schedule. A proposed Obligation never counts as a configured schedule.
 - When an approved cadence changes, update its authoritative Obligation schedule. Keep the durable required outcome in the Policy and the implementation fact in the Control instead of copying the cadence across all three records.
 - Pause or retire a template only when the underlying policy work no longer applies. Do not delete historical templates that explain prior periods.
 

package/template/package.json

@@ -1,6 +1,6 @@
 {
   "name": "{{project_name}}",
-  "version": "0.16.17",
+  "version": "0.16.19",
   "private": true,
   "description": "filegrc workspace for a SOC 2 program",
   "type": "module",