filegrc 0.7.1 → 0.9.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -4,7 +4,7 @@ filegrc is a zero-dependency Node.js engine for Git-native GRC workspaces. It va
4
4
 
5
5
  Program Readiness checks management-owned scope, policy adoption, control implementation, and authoritative evidence mapping without requiring an audit record. Audit Readiness starts after CPA engagement and checks the firm-agreed date or period, engagement-specific management documents, operating evidence, and Type 2 population completeness.
6
6
 
7
- Controls linked to filegrc obligations show whether their Work Queue schedules are waiting for policy approval, ready for implementation, running, paused, or mixed. Marking a fully configured control implemented starts its enabled schedules when their governing policies are effective.
7
+ Controls linked to filegrc Obligations show whether their scheduled work is waiting for policy approval, ready for implementation, running, paused, or mixed. Marking a fully configured Control implemented starts its enabled work when the governing content is effective.
8
8
 
9
9
  Most users should create a complete workspace:
10
10
 
@@ -44,13 +44,13 @@ npx filegrc policy-library
44
44
 
45
45
  The command shows an exact diff only when the current text still matches the prior starter default. It skips customized, approved, active, superseded, and retired Policy content. Accept one named proposal revision only with the command printed by the review, which includes `--accept`, `--proposal-revision`, and `--yes`. Acceptance fails if the proposal changed after review. It changes only the listed defaults and does not approve a Policy, activate it, or mark a Control implemented.
46
46
 
47
- The normal runtime uses data model v4. Start a model v3 upgrade with a read-only preview:
47
+ The normal runtime uses data model v6. Start a model v5 upgrade with a read-only preview:
48
48
 
49
49
  ```sh
50
- npx filegrc migrate --to-model 4 --preview --json
50
+ npx filegrc migrate --to-model 6 --preview --json
51
51
  ```
52
52
 
53
- Review every automatic, review-required, and unsupported item. A v3 System may represent either a bounded System or a Component, so ambiguous records need an explicit decisions file. Resolve unsupported items before applying the same migration with `--yes`. The [model v4 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v4.md) documents the decisions shape and migration result.
53
+ Review every automatic, review-required, and unsupported item. Model v6 gives Training the same separate approval and activation lifecycle as other governed content. It preserves active model v5 Training with a visible legacy basis and removes Training schedule fields, because Obligations now own assignment timing. Resolve unsupported items before applying the same migration with `--yes`. The [model v6 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v6.md) documents the review.
54
54
 
55
55
  A model v2 workspace must migrate to v3 first:
56
56
 
@@ -58,7 +58,7 @@ A model v2 workspace must migrate to v3 first:
58
58
  npx filegrc migrate --to-model 3 --preview --json
59
59
  ```
60
60
 
61
- The migration writes one atomic batch, validates model v3, changes no Git history, and is safe to rerun. The [model v3 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v3.md) explains every migration class and the review that follows. Apply it before previewing model v4.
61
+ The migration writes one atomic batch, validates model v3, changes no Git history, and is safe to rerun. The [model v3 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v3.md) explains every migration class and the review that follows. Apply it before previewing models v4, v5, and v6 in order.
62
62
 
63
63
  A model v1 workspace must migrate to v2 first:
64
64
 
@@ -66,7 +66,7 @@ A model v1 workspace must migrate to v2 first:
66
66
  npx filegrc migrate --to-model 2 --preview --json
67
67
  ```
68
68
 
69
- Follow the [model v2 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v2.md), then run the model v3 and v4 previews in order.
69
+ Follow the [model v2 upgrade guide](https://github.com/Alignbase/filegrc/blob/main/docs/upgrading-to-model-v2.md), then run the model v3, v4, v5, and v6 previews in order.
70
70
 
71
71
  `filegrc serve --help` prints bind, port, environment, and safety options without starting the server. The editable server prefers `127.0.0.1:8787` and chooses another available port when that port is occupied. Set `FILEGRC_HOST`, `FILEGRC_PORT`, or the matching flags when needed. In trunk mode, browser saves synchronize, commit, and push from the authoritative branch. Use `--allow-non-authoritative-writes` for local development in a task checkout; the override never commits or pushes.
72
72
 
@@ -76,7 +76,7 @@ Follow the [model v2 upgrade guide](https://github.com/Alignbase/filegrc/blob/ma
76
76
 
77
77
  `filegrc program-readiness` reports whether management can start a candidate Type 2 period. Add `--summary --json` for compact stage counts and next actions, or omit `--summary` for every readiness item. Use `--require-ready` in automation. Pass `--program PROGRAM_ID` when more than one active Program exists. The command does not require an Audit ID or CPA firm.
78
78
 
79
- Control implementation includes each selected Control family’s expected evidence, authoritative source Components, and source-readiness checks. `filegrc evidence-map --json` provides a focused read-only diagnostic for those checks. Fix gaps in the Control and Component records. During Step 4, create an Evidence Artifact only when a real export, report, screenshot, signed file, or approved external reference exists, then link it to the supporting operating record when applicable.
79
+ Step 2 uses one Policies page to review Policies, program Documents, and Training, while keeping their record types separate. Step 3 implements linked requirements, defines schedules as Obligations, and uses `filegrc activate-content --scaffold` to record the active Person, separate activation date, and revision for approved Documents and Training. Control implementation also checks expected evidence, authoritative source Components, and source readiness. During Step 4, create Evidence only when operation produces a real record or artifact. Keep engagement-scoped terms, management assertions, representation letters, and other Audit Documents in Step 5. Link each one to one Audit and use `filegrc activate-documents --audit AUDIT_ID --scaffold` after approval.
80
80
 
81
81
  `filegrc obligations` shows recurring work and a task-level preview for each Policy Event, including owners, deadlines, and requested proof. `filegrc trigger` adds the event and all of its Action Items to the Work Queue atomically, then prints the created task IDs and deadlines.
82
82
 
package/model/index.js CHANGED
@@ -1,14 +1,32 @@
1
1
  import { readFileSync } from "node:fs";
2
2
 
3
- export const ACTIVE_MODEL_VERSION = "4";
4
- export const SUPPORTED_MODEL_VERSIONS = Object.freeze(["2", "3", ACTIVE_MODEL_VERSION]);
3
+ export const ACTIVE_MODEL_VERSION = "6";
4
+ export const SUPPORTED_MODEL_VERSIONS = Object.freeze(["2", "3", "4", "5", ACTIVE_MODEL_VERSION]);
5
+ export const MODEL_CAPABILITY_VERSIONS = Object.freeze({
6
+ "guided-workflow": 3,
7
+ "program-scope": 4,
8
+ "component-sources": 4,
9
+ "evidence-artifacts": 4,
10
+ "governed-document-activation": 5,
11
+ "document-workflow-scope": 5,
12
+ "governed-training-activation": 6
13
+ });
14
+
15
+ export function modelSupports(modelOrVersion, capability) {
16
+ const introduced = MODEL_CAPABILITY_VERSIONS[capability];
17
+ if (!introduced) throw new Error(`Unknown model capability "${capability}".`);
18
+ const version = typeof modelOrVersion === "object"
19
+ ? modelOrVersion?.modelVersion
20
+ : modelOrVersion;
21
+ return Number(version || 0) >= introduced;
22
+ }
5
23
 
6
24
  export function loadModel(version = ACTIVE_MODEL_VERSION) {
7
25
  const requested = String(version);
8
26
  if (!SUPPORTED_MODEL_VERSIONS.includes(requested)) {
9
- const migrationTarget = requested === "1" ? "2" : requested === "2" ? "3" : "4";
27
+ const migrationTarget = requested === "1" ? "2" : requested === "2" ? "3" : requested === "3" ? "4" : requested === "4" ? "5" : "6";
10
28
  throw new Error(
11
- `Unsupported data model version "${requested}". This filegrc release supports models v2, v3, and v4. `
29
+ `Unsupported data model version "${requested}". This filegrc release supports models v2, v3, v4, v5, and v6. `
12
30
  + `Run \`npx filegrc migrate --to-model ${migrationTarget} --preview --json\` from the workspace root.`
13
31
  );
14
32
  }