create-filegrc 0.16.16 → 0.16.18

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-filegrc",
-  "version": "0.16.16",
+  "version": "0.16.18",
   "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.16",
+    version: "0.16.18",
     lockfileVersion: 3,
     requires: true,
     packages: {
       "": {
         name,
-        version: "0.16.16",
+        version: "0.16.18",
         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/README.md

@@ -51,7 +51,7 @@ A Policy says what the company commits to do by the date it takes effect. Approv
 
 FileGRC does not infer technical implementation from Policy prose. Configuration facts belong in Controls, Components, Systems, Obligations, and Evidence. A Control may be implemented while its governing Policy, required program Document, or Training is approved but inactive. Enabled Obligations remain dormant until all of their governing content is active and effective.
 
-Control implementation includes evidence-source and Obligation readiness. Use `npx filegrc program-readiness --json` to review the five Step 3 work areas. When they are ready, one eligible reviewer records the implemented Control collection review. Management then activates the unchanged approved program Documents and Training with `npx filegrc activate-content --scaffold`, followed by the approved Policies with `npx filegrc activate-policies --scaffold`. Evidence Readiness requires a current Control collection review and active required content before the candidate period can begin. Create Evidence during Step 4 only after operation produces a real record or artifact. Create engagement terms, management assertions, representation letters, and other Audit Documents in Step 5, link each to one Audit, approve it, then activate it with `npx filegrc activate-documents --audit AUDIT_ID --scaffold`.
+Control implementation includes evidence-source and Obligation readiness. Use `npx filegrc program-readiness --json` to see each Control's launch state and next practical check. Implemented means the control works now for its named scope, with a real owner, procedure, usable evidence source, and enabled work rules. It does not claim a future cycle or event has already happened. When the five Step 3 work areas are ready, one eligible reviewer records the implemented Control collection review. Management then activates the unchanged approved program Documents and Training with `npx filegrc activate-content --scaffold`, followed by the approved Policies with `npx filegrc activate-policies --scaffold`. Evidence Readiness requires a current Control collection review and active required content before the candidate period can begin. Create Evidence during Step 4 only after operation produces a real record or artifact. Create engagement terms, management assertions, representation letters, and other Audit Documents in Step 5, link each to one Audit, approve it, then activate it with `npx filegrc activate-documents --audit AUDIT_ID --scaffold`.
 
 The Program Overview shows what is done, what is blocked, and what to do next.
 

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.
@@ -117,10 +119,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
@@ -182,10 +186,10 @@ The Control stage reports Control implementation items, evidence-family source c
 2. Set the Component to `active`, connect it to each bounded System through `systemUses` with the `evidence-source` role and a rationale, add the matching `evidenceSourceKinds`, and name current `evidenceOwnerIds`.
 3. Put the exact report, filters, date range, timezone, export format, and reconciliation steps in the Component’s Record Markdown.
 4. Add the Component ID to `evidenceSourceComponentIds` on every Control in the family that it supports.
-5. Finish the Control’s owner, procedure, scope, operation pattern, mappings, and implementation date. Put every calendar or event schedule in an Obligation.
+5. Finish the Control’s owner, actual procedure, scope, operation pattern, mappings, and evidence sources. Check the real systems and work named in its `program-readiness --json` launch actions. Mark it Implemented with its actual start date only when that practice works. This asserts readiness to operate, not that a future schedule or event has already produced proof.
 6. Enable each required Obligation. It stays dormant while a governing Policy or required program Document is inactive. The first operating window starts from the latest applicable effective date, so FileGRC does not create overdue work for a period before cutover.
 7. Run `program-readiness --json`. When the Control, Evidence Sources, and Obligation work areas are ready, use `review-collection control --scaffold` to record one independent review of the implemented Controls.
-8. Use `activate-content --scaffold` to activate the unchanged approved program Documents and Training. Then use `activate-policies --scaffold` to activate the selected approved Policies at cutover. Check `program-readiness --json` again; a candidate period can start only after Evidence Ready passes.
+8. Use `activate-content --scaffold` to activate the unchanged approved program Documents and Training. Then use `activate-policies --scaffold` to activate the selected approved Policies at cutover. Check `program-readiness --json` again; a candidate period can start only after Evidence Ready passes. Trigger event work only for a real event after its governing content is effective, and collect dated proof when the work occurs.
 
 Use `get RESOURCE_ID --mutation` and `update` so JSON and Markdown change together. `evidence-map --json` remains available when you want only the evidence-family checks. Do not create an Evidence Artifact while designing or implementing a Control. Create one during Step 4 only when the real export, report, screenshot, signed file, or approved external reference exists.
 

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.16",
+  "version": "0.16.18",
   "private": true,
   "description": "filegrc workspace for a SOC 2 program",
   "type": "module",