create-filegrc 0.9.1 → 0.10.0

package/package.json

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

package/src/index.js

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

package/template/AGENTS.md

@@ -41,6 +41,7 @@ Read `data/AGENTS.md` before changing records. More specific instructions inside
 
 - Read `README.md` and run `npm run validate` before broad changes.
 - Treat `data/` as the source of truth. Do not hand-edit `.filegrc/` output.
+- Keep compliance records focused on business facts, decisions, scope, Controls, and Evidence. Do not mention filegrc versions, migrations, or workflow mechanics unless filegrc itself is the subject.
 - Use UTF-8 JSON for structured records and Markdown for long-form work.
 - Keep one resource in each JSON file.
 - Let the local app generate IDs from each record’s name or title. When editing JSON directly, keep IDs globally unique, human-readable, and lowercase kebab-case.
@@ -56,7 +57,7 @@ Read `data/AGENTS.md` before changing records. More specific instructions inside
 
 The JSON and Markdown under `data/`, the installed model, policy content, and Git history are the inputs to FileGRC’s shared workflow calculation. Source files hold facts, decisions, relationships, dates, status, and evidence references. They do not each need a copy of the generic audit-readiness instructions or calculated TODO list.
 
-Use `npx filegrc workflow --json` for the complete derived checklist, named readiness assessments, blockers, Work Items, and recommended next action. `guide`, `list --workflow`, `get --workflow`, mutation previews, the HTTP API, and the browser consume the same calculation. Resolve a derived finding by changing its source facts, recording a reviewed applicability decision, accepting an allowed Exception, or completing authoritative assigned work. Never add a separate TODO file or UI-only completion flag for calculated work.
+Start with `npx filegrc program-path --next --json` for the current step and next action. Use `npx filegrc workflow --json` when you need the complete derived checklist, named readiness assessments, blockers, and Work Items. `guide`, `list --workflow`, `get --workflow`, mutation previews, the HTTP API, and the browser consume the same calculation. Resolve a derived finding by changing its source facts, recording a reviewed applicability decision, accepting an allowed Exception, or completing authoritative assigned work. Never add a separate TODO file or UI-only completion flag for calculated work.
 
 FileGRC marks an item `blocked` only when named prerequisite records must be resolved first. A missing record, editable error, or management decision is `ready` when you can act on it now, even when it prevents a readiness assessment from passing.
 
@@ -100,12 +101,12 @@ Do not rewrite or remove committed records that explain prior audit periods. Clo
 If the installed CLI reports that this workspace uses an unsupported model, start with:
 
 ```sh
-npx filegrc migrate --to-model 6 --preview --json
+npx filegrc migrate --to-model 7 --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 v6 migration separates Training approval from activation, preserves existing active Training with a visible `legacy-v5` activation basis, and removes Training schedule fields because Obligations now own assignment timing.
+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 v7 migration keeps issued historical Audit Documents neutral, returns legacy Training to approved until management records a current activation, and makes old applicability confirmations stale for one scoped review.
 
-The [model v6 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v6.md) explains the Training lifecycle and Obligation review.
+The [model v7 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v7.md) explains the record-purity change.
 
 Run these commands when working with records:
 

package/template/README.md

@@ -19,7 +19,7 @@ npm run serve
 
 Requires Node.js 20 or newer and Git.
 
-Existing model v5 workspaces must run `npx filegrc migrate --to-model 6 --preview --json` after installing a model v6 package. The migration gives Training separate approval and activation facts, preserves active model v5 Training with a visible legacy basis, and removes Training schedule fields because Obligations now own assignment timing. Review the result and confirm or create each Training Obligation in Step 3. Older workspaces migrate one model version at a time. See the [model v6 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v6.md).
+Existing model v6 workspaces must run `npx filegrc migrate --to-model 7 --preview --json` after installing a model v7 package. The migration keeps issued historical Audit Documents neutral, returns legacy Training to approved until management records a current activation, and makes old applicability confirmations stale for one scoped review. Older workspaces migrate one model version at a time. See the [model v7 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v7.md).
 
 ## How it works
 
@@ -74,8 +74,8 @@ The browser is helpful, but it is not required. An agent can discover the model,
 
 ```sh
 npx filegrc program-path --next --json
-npx filegrc workflow --json
 npx filegrc reconcile --preview --json
+npx filegrc workflow --json # full checklist when needed
 npx filegrc period-health --require-healthy --json
 npx filegrc review-applicability decisions.json --preview --json
 npx filegrc review-collection person --scaffold

package/template/data/AGENTS.md

@@ -8,16 +8,15 @@ Treat the installed model as the authority. Do not infer a schema from a nearby
 
 ```sh
 npx filegrc guide --json
-npx filegrc workflow --json
-npx filegrc reconcile --preview --json
 npx filegrc program-path --next --json
+npx filegrc reconcile --preview --json
 npx filegrc types --json
 npx filegrc guide RESOURCE_TYPE --json
 npx filegrc list RESOURCE_TYPE --json
 npx filegrc search "TERM" --json
 ```
 
-Use `workflow --json` to get the shared assessments, complete checklist, Work Items, blockers, and recommended next action. Use `program-path --next --json` for the current lifecycle step. Use `guide` before any unfamiliar create or status transition. It reports required fields, fields required by a status, enum values, relationship types and candidates, Markdown slots, timing, and exact paths. Use `describe` only when you need the raw model definition.
+Use `program-path --next --json` for the current lifecycle step. Use `workflow --json` when you need the full shared assessments, complete checklist, Work Items, and blockers. Use `guide` before any unfamiliar create or status transition. It reports required fields, fields required by a status, enum values, relationship types and candidates, Markdown slots, timing, and exact paths. Use `describe` only when you need the raw model definition.
 
 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.
 

package/template/data/documents/AGENTS.md

@@ -10,7 +10,7 @@ Set `workflowScope` to `program` for reusable plans, schedules, charters, proced
 
 Required program Documents follow `draft → approved → active`. Step 2 records the independent approver, `approvedOn`, and the exact `approvedContentRevisions`. After the linked requirements are implemented, Step 3 records `activationBasis: recorded`, the active Person in `activatedByIds`, `activatedOn`, `effectiveOn`, and the unchanged `activatedContentRevisions`. Approval and activation are separate writes even when they happen on the same calendar date. Editing bound Markdown requires a new approval and activation.
 
-Engagement Documents use the same separate events inside Step 5. Link each approved or active engagement Document to exactly one Audit, and do not reuse it as a Policy or Obligation document. Activate ready engagement Documents with `npx filegrc activate-documents --audit AUDIT_ID --scaffold`. Approval and activation facts become immutable after their event; return the Document to draft or approved and record a new lifecycle event when the content or decision changes. `activationBasis: legacy-v4` is only for historical audit Documents preserved by the model v4 migration. Do not use it for new work.
+Engagement Documents use the same separate events inside Step 5. Link each approved or active engagement Document to exactly one Audit, and do not reuse it as a Policy or Obligation document. Activate ready engagement Documents with `npx filegrc activate-documents --audit AUDIT_ID --scaffold`. Approval and activation facts become immutable after their event; return the Document to draft or approved and record a new lifecycle event when the content or decision changes. `activationBasis: historical` is only for an imported historical audit Document whose source did not record approval and activation as separate events. Do not use it for new work.
 
 Keep resource links in the Document JSON and supporting records. In the Markdown, describe the underlying business fact in ordinary terms. For example, use “management's control matrix,” “authoritative-source export,” or “signed letter reference” instead of a FileGRC record type or ID.
 

package/template/data/workspace.json

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

package/template/package.json

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