create-filegrc 0.13.5 → 0.15.0

package/package.json

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

package/src/defaults.js

@@ -10,6 +10,7 @@ const INFORMATION_SECURITY_POLICY_ID = "policy-information-security";
 const RETENTION_SCHEDULE_ID = "document-data-retention-schedule";
 const SECURITY_PLAN_ID = "document-security-incident-recovery-plan";
 const FILEGRC_INFORMATION_TYPE_ID = "information-type-grc-records";
+const FILEGRC_RETENTION_ITEM_ID = "retention-schedule-item-filegrc-records";
 const FILEGRC_SOURCE_FAMILIES = [
   "training-acknowledgement",
   "exception-finding",
@@ -1172,7 +1173,7 @@ export function baselineRecordFiles(effectiveDate, starter = "security") {
       ownerIds: [POLICY_OWNER_APPOINTMENT_ID],
       ...(filegrcManaged ? {
         collectionCadence: "Record work when it occurs and export the complete population for the audit period.",
-        retentionScheduleItemIds: [`retention-schedule-item-source-${sourceFamilyId}`],
+        retentionScheduleItemIds: [FILEGRC_RETENTION_ITEM_ID],
         reconciliationMethod: "Export the complete filegrc source-family population, compare it with related in-scope records and Work Queue activity, and investigate omissions or duplicates.",
         validFrom: effectiveDate
       } : {})
@@ -1187,18 +1188,21 @@ export function baselineRecordFiles(effectiveDate, starter = "security") {
     classificationId: "confidential",
     description: "Structured program records, approvals, work history, and evidence indexes stored in the FileGRC repository."
   };
-  const retentionScheduleItems = SOURCE_FAMILIES.map(([sourceFamilyId, title]) => ({
-    id: `retention-schedule-item-source-${sourceFamilyId}`,
+  const retentionScheduleItems = [{
+    id: FILEGRC_RETENTION_ITEM_ID,
     type: "retention-schedule-item",
-    title: `${title} retention review`,
+    title: "Governance, risk, compliance, and audit records retention",
     status: "planned",
     description: "Management must select the covered Information Types, cutoff, retention period, and disposition behavior before activation.",
-    informationTypeIds: FILEGRC_SOURCE_FAMILIES.includes(sourceFamilyId) ? [FILEGRC_INFORMATION_TYPE_ID] : [],
-    scopeResourceIds: [`source-coverage-${sourceFamilyId}`],
+    informationTypeIds: [FILEGRC_INFORMATION_TYPE_ID],
+    scopeResourceIds: [
+      "program-soc-2",
+      ...FILEGRC_SOURCE_FAMILIES.map((sourceFamilyId) => `source-coverage-${sourceFamilyId}`)
+    ],
     scheduleDocumentId: RETENTION_SCHEDULE_ID,
     sourceResourceIds: [INFORMATION_SECURITY_POLICY_ID, RETENTION_SCHEDULE_ID],
     ownerIds: [POLICY_OWNER_APPOINTMENT_ID]
-  }));
+  }];
 
   const foundation = [
     recordFile("information-types", informationType),

package/src/index.js

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

package/template/AGENTS.md

@@ -119,7 +119,7 @@ npx filegrc migrate --to-model 8 --preview --json
 
 Older workspaces migrate one version at a time. Review every preview’s automatic, review-required, and unsupported classifications before applying it with the same options and `--yes`. The v8 migration preserves legacy retention prose as notes, renames Component processing operations, and creates no retention periods or disposition behavior.
 
-The [model v10 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v10.md) explains Reporting Channel Sets and the legacy-route review. The [model v9 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v9.md) explains rolled-up Obligation occurrences, reviewed schedule rules, and temporal Collection Reviews.
+The [model v11 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v11.md) explains owner-recorded Control implementation and periodic Control collection oversight. The [model v10 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v10.md) explains Reporting Channel Sets and the legacy-route review.
 
 Run these commands when working with records:
 
@@ -227,13 +227,13 @@ The Evidence Ready gate requires:
 
 1. A management goal, selected systems, criteria, and controls.
 2. Policies, required program Documents, and Training independently approved in Step 2, with approval dates and exact approved content revisions.
-3. Implemented Controls with an owner, actual procedure, scope, operation pattern, mappings, implementation date, and every required linked Obligation enabled. Required program Documents and Training must then be activated in Step 3 with separate activation dates and exact activation revisions.
+3. Implemented Controls with an owner, actual procedure, scope, operation pattern, mappings, implementation date, and every required linked Obligation enabled. Review the implemented Control collection once as a batch, then activate required program content at cutover.
 4. Every selected Control mapped to active authoritative Components with the required evidence source roles, current access owners, and repeatable extraction instructions in Record Markdown.
 5. Required governed content active and effective, with no unresolved activation blockers. Audit Documents remain in Step 5 and do not satisfy this program gate.
 
 A Policy says what the company commits to do by the date it takes effect. Approval means the company accepts those commitments. It does not prove the work is done. Controls and operating records describe how the company meets them and provide the proof. A Control may be implemented against an approved inactive Policy, required program Document, or Training record. Enabled Obligations remain dormant until all of their governing content is active and effective.
 
-Review `documentActivations`, `trainingActivations`, and `policyActivations` in Program Readiness before cutover. Approve Policies, program Documents, and Training in Step 2. Define schedules as Obligations and implement the linked Controls in Step 3, then use `npx filegrc activate-content --scaffold` to record the active Person and actual activation and effective dates against each unchanged approved revision. Use the Controls-page review or `npx filegrc activate-policies --scaffold` to choose which approved Policies take effect. Evidence Readiness remains incomplete until every required program artifact is active and operating. Operate and collect Evidence in Step 4. Keep engagement terms, management assertions, representation letters, and other Audit Documents in Step 5. Approve and activate each Audit Document there as separate writes after its engagement facts are complete.
+Review the five Step 3 work areas in Program Readiness. Approve Policies, program Documents, and Training in Step 2. Define schedules as Obligations and implement the linked Controls in Step 3. When those work areas are ready, record one independent Control collection review, then activate unchanged approved program content. Evidence Readiness remains incomplete until that review is current and every required program artifact is active and operating. Operate and collect Evidence in Step 4. Keep engagement terms, management assertions, representation letters, and other Audit Documents in Step 5. Approve and activate each Audit Document there as separate writes after its engagement facts are complete.
 
 Onboarding does not create Evidence Artifacts. Complete authoritative source Components as part of Control implementation. For every incomplete family in Program Readiness, update the Control with its authoritative `evidenceSourceComponentIds`, then give each source Component the required evidence role, current access owners, and repeatable retrieval instructions in Record Markdown. Use `npx filegrc evidence-map --json` when you want only those source checks. During Step 4, create an Evidence Artifact only when a real artifact exists. Select its `sourceComponentId`, attach or reference the result, link the Controls and operating record it supports, record its collector and Classification, then have another person verify it before audit use.
 

package/template/README.md

@@ -19,7 +19,7 @@ npm run serve
 
 Requires Node.js 20 or newer and Git.
 
-Existing model v9 workspaces must run `npx filegrc migrate --to-model 10 --preview --json` after installing a model v10 package. The migration preserves prior Reporting Routes as legacy facts and asks management to create one reviewed Reporting Channel Set: the normal and fallback ways people send a report for one purpose. It does not infer missing Program, channel pairing, authority, or event-time facts. Older workspaces migrate one model version at a time. See the [model v10 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v10.md).
+Existing model v10 workspaces must run `npx filegrc migrate --to-model 11 --preview --json` after installing a model v11 package. The migration removes the old per-Control implementation review fields. Owners can record implementation directly, while periodic Control oversight uses a Collection Review. Independent Policy, Document, and Training approvals do not change. Older workspaces migrate one model version at a time. See the [model v11 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v11.md).
 
 ## How it works
 
@@ -49,7 +49,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, Obligation, and governed-content readiness. Use `npx filegrc program-readiness --json` to review incomplete Control or Component records plus `documentActivations`, `trainingActivations`, and `policyActivations`. Activate ready program Documents and Training with `npx filegrc activate-content --scaffold`; name the active Person who performs activation, and keep approval and activation as separate dates and content-revision bindings. Then use the Controls-page review or `npx filegrc activate-policies --scaffold` to choose which approved Policies take effect. Evidence Readiness requires active Policies, required program Documents, Training, implemented Controls, configured evidence sources, and enabled Obligations 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 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`.
 
 The Program Overview shows what is done, what is blocked, and what to do next.
 

package/template/data/AGENTS.md

@@ -99,7 +99,7 @@ If `guide` marks a Markdown slot recommended, fill it before treating the delive
 
 When `guide` returns a collection review requirement, review the listed type-specific criteria and use `npx filegrc review-collection RESOURCE_TYPE --scaffold`. Fill the management conclusion, rationale, reviewer, and date, then preview and apply the payload. Do not invent `collectionRevision`; FileGRC calculates it from the current records and material Program scope. Any later change makes the confirmation stale and requires another review.
 
-Use Retention Schedule Items 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.
+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.
 
 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.
 

package/template/data/workspace.json

@@ -1,5 +1,5 @@
 {
-  "dataModelVersion": "10",
+  "dataModelVersion": "11",
   "id": "workspace",
   "type": "workspace",
   "title": "{{program_title}}",

package/template/package.json

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