create-filegrc 0.16.15 → 0.16.17

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-filegrc",
-  "version": "0.16.15",
+  "version": "0.16.17",
   "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.15",
+    version: "0.16.17",
     lockfileVersion: 3,
     requires: true,
     packages: {
       "": {
         name,
-        version: "0.16.15",
+        version: "0.16.17",
         dependencies: { filegrc: versionRange }
       }
     }

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

@@ -182,10 +182,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/package.json

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