create-filegrc 0.2.0 → 0.3.1

package/template/README.md

@@ -1,18 +1,18 @@
-# FileGRC
+# filegrc
+
+![filegrc, run a SOC 2 program as files in Git](docs/filegrc-social-preview.png)
 
 Run a SOC 2 program as files in Git.
 
-FileGRC gives a founder-led engineering team one place to adopt policies, implement controls, test External Evidence collection, run recurring compliance work, and prepare an audit. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history.
+filegrc gives a founder-led engineering team one place to adopt policies, implement controls, test External Evidence collection, run recurring compliance work, and prepare an audit. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history.
 
 There is no separate application database. The repository is the program, so engineers and agents can use the same data through the web app, a text editor, or the CLI.
 
-![FileGRC SOC 2 program overview](docs/filegrc-home.png)
-
 ## Why it exists
 
 SOC 2 work tends to scatter across documents, calendars, tickets, screenshots, and the auditor’s request list. That makes it hard to answer basic questions: What is due? Which policy requires it? What changed during the audit period? Is the evidence complete?
 
-FileGRC keeps that work connected:
+filegrc keeps that work connected:
 
 - A starter Security program links criteria references, policies, planned controls, owners, and schedules.
 - Work Queue turns policy timing into upcoming, due, and overdue work.
@@ -34,20 +34,22 @@ npm run validate
 npm run serve
 ```
 
-Setup asks for the company name, the initial policy owner, and a security contact email. It initializes Git when needed. The first local run then defines the initial service boundary and an optional program goal. A Type 2 choice records management intent, not an audit engagement. Completing onboarding opens Step 1 so you can confirm the starter people and oversight team, criteria, commitments, vendors, and systems before moving on.
+The default `security` starter builds the full proposed SOC 2 Security program. Use `--starter foundation` to create only the five structural records when you want to select a framework and program content later. Company and service values can also be supplied together through `create-filegrc --config setup.json`.
+
+Setup asks for the legal organization name, the initial policy owner and their email, a security reporting address, and the program timezone. It initializes Git when needed. The first local run then defines the initial service boundary and an optional program goal. A Type 2 choice records management intent, not an audit engagement. Completing onboarding opens Step 1 so you can add the real reviewers and operators, finish the oversight team, and confirm the criteria, commitments, vendors, and systems before moving on.
 
 Open the printed local URL. You can commit locally from Repository without configuring a remote. Add a remote when the team is ready to share the workspace, then the browser can pull with rebase and push reviewed commits.
 
-The creation summary reports the resolved engine version, install result, and whether the target joined an existing Git worktree. Generated workspaces receive an organization-specific README with their engine version, validation commands, and remaining setup work.
+The creation summary reports the resolved engine version, program timezone, starter record counts, install result, and whether the target joined an existing Git worktree. Generated workspaces receive an organization-specific README with their engine version, validation commands, and remaining setup work.
 
 ## How it works
 
 1. Confirm the program’s people and oversight team, applicable criteria, commitments, material vendors, and in-scope systems.
 2. Review and activate the policies with a separate management reviewer, who is usually internal and may be external.
 3. Tailor the starter controls, add each owner, actual procedure, scope, cadence, evidence source, and implementation date, and confirm any linked Work Queue schedules are enabled. Marking a control implemented starts eligible schedules. Then record any complementary customer or subservice controls.
-4. Open each generated External Evidence draft, choose its authoritative source System, collect the named artifact, and have another person verify it.
-5. Start the management candidate period, maintain risk assessments and risks, update controls when needed, work the FileGRC queue, and preserve dated evidence.
-6. Engage a CPA firm, record the separate firm-agreed period, review FileGRC Evidence and External Evidence, prepare fieldwork, and generate the evidence packet.
+4. After confirming the applicable controls and authoritative source Systems, preview the proposed External Evidence drafts with `npx filegrc evidence-test-drafts --preview --json`. Create only the relevant drafts, collect each named artifact, and have another person verify it.
+5. Start the management candidate period, maintain risk assessments and risks, update controls when needed, work the filegrc queue, and preserve dated evidence.
+6. Engage a CPA firm, record the separate firm-agreed period, review filegrc Evidence and External Evidence, prepare fieldwork, and generate the evidence packet.
 
 Long-form policies, procedures, plans, minutes, training, assertions, and audit responses are Markdown companions beside their JSON records. Screenshots, signed acknowledgements, reports, and fixed exports are attachments linked through evidence records.
 
@@ -57,7 +59,9 @@ Third-party software is usually both a System and a Vendor. The application is t
 
 Use Overview to follow one six-step path: define scope, approve policies, implement controls, test External Evidence, operate the program, then complete the audit. Steps 1 through 4 and Step 6 open an overview with instructions, record links, progress, and completion status. Step 5 opens Policy Events and the Work Queue because operation is ongoing rather than a one-time checklist. The progress tracker opens the first incomplete step.
 
-Use Work Queue for recurring work, Policy Event tasks, and other assigned follow-up. Trigger a Policy Event when the underlying change occurs, and FileGRC adds its required actions to the queue with their owners and deadlines. Create a separate Action Item only when follow-up needs its own assignee, deadline, and completion proof. Each queue item shows its due window or deadline. Link dated proof to close the work.
+![filegrc SOC 2 program overview](docs/filegrc-home.png)
+
+Use Work Queue for recurring work, Policy Event tasks, and other assigned follow-up. Trigger a Policy Event when the underlying change occurs, and filegrc adds its required actions to the queue with their owners and deadlines. Create a separate Action Item only when follow-up needs its own assignee, deadline, and completion proof. Each queue item shows its due window or deadline. Link dated proof to close the work.
 
 Use the resource pages to maintain systems, people, vendors, risks, controls, tests, incidents, training, meetings, and External Evidence. The question-mark guide on each list explains what the record type is for, which policies call for it, and when to update it.
 
@@ -69,7 +73,7 @@ npx filegrc program-path --json
 npx filegrc scaffold risk-assessment --title "2026 Annual Risk Assessment"
 npx filegrc list risk --json
 npx filegrc obligations --json
-npx filegrc program-readiness --json
+npx filegrc program-readiness --summary --json
 npx filegrc complete obligation-id completion-record.json
 npx filegrc trigger person-started --occurred-on 2026-07-25 --subject person-id
 npx filegrc complete-action action-item-id completion-record.json --completed-on 2026-07-25
@@ -77,7 +81,7 @@ npx filegrc complete-event obligation-event-id --completed-on 2026-07-25
 npx filegrc search "access review"
 ```
 
-`program-path` reports the same six steps, current status, page order, exact Instructions, Use, Policy Basis, and next actions shown in the renderer. `guide` reports that same page guidance for one resource, plus timing, required fields, valid values, relationship candidates, and Markdown locations. `scaffold` produces the same JSON and Markdown mutation shape used by the browser. Read `AGENTS.md` and `data/AGENTS.md` for the full headless workflow.
+`program-path` reports the same six steps, current status, page order, exact Instructions, Use, Policy Basis, and next actions shown in the renderer. `program-readiness --summary --json` reports compact stage counts and next actions; omit `--summary` when you need every readiness item. `guide` reports that same page guidance for one resource, plus timing, required fields, valid values, relationship candidates, and Markdown locations. `scaffold` produces the same JSON and Markdown mutation shape used by the browser. Read `AGENTS.md` and `data/AGENTS.md` for the full headless workflow.
 
 ## Start the evidence period
 
@@ -88,17 +92,17 @@ npx filegrc program-readiness --json
 npx filegrc program-readiness --require-ready
 ```
 
-The Evidence Ready gate requires defined scope, effective policies, implemented controls, configured authoritative systems, and verified collection for external evidence that does not already have a dedicated Step 5 record. Put scan reports, backup output, and other fixed artifacts in External Evidence records, then link them from the applicable Step 5 operating records. Starter obligations remain enabled proposals until their governing policies are effective and at least one linked control is implemented. A FileGRC-managed control cannot be implemented while one of its linked Work Queue schedules is paused or waiting for policy approval.
+The Evidence Ready gate requires defined scope, effective policies, implemented controls, configured authoritative systems, and verified collection for external evidence that does not already have a dedicated Step 5 record. Put scan reports, backup output, and other fixed artifacts in External Evidence records, then link them from the applicable Step 5 operating records. Starter obligations remain enabled proposals until their governing policies are effective and at least one linked control is implemented. A filegrc-managed control cannot be implemented while one of its linked Work Queue schedules is paused or waiting for policy approval.
 
 When the gate passes, record `candidatePeriodStart` on the workspace on the date reliable collection begins. This is management’s candidate Type 2 period. Do not backdate it. The later audit record keeps the separate period agreed with the CPA firm.
 
 ## Prepare the audit
 
-After engaging a CPA firm, create the audit record with the firm, scope, and exact agreed date or period. Audit Readiness checks the program foundation, engagement, formal scope and dates, management documents, FileGRC Evidence, External Evidence, and Type 2 populations.
+After engaging a CPA firm, create the audit record with the firm, scope, and exact agreed date or period. Audit Readiness checks the program foundation, engagement, formal scope and dates, management documents, filegrc Evidence, External Evidence, and Type 2 populations.
 
-![FileGRC audit readiness](docs/filegrc-audit.png)
+![filegrc audit readiness](docs/filegrc-audit.png)
 
-For a Type 2 audit, reconcile each complete period population to its authoritative system after the period closes. A zero-item population still needs its source export and query. FileGRC Evidence consists of dated operating records and their Markdown and Git history. External Evidence consists of verified exports, reports, screenshots, signed files, and approved external references. The packet compiles both paths with the selected records, attachments, indexes, historical versions, and SHA-256 checksums.
+For a Type 2 audit, reconcile each complete period population to its authoritative system after the period closes. A zero-item population still needs its source export and query. filegrc Evidence consists of dated operating records and their Markdown and Git history. External Evidence consists of verified exports, reports, screenshots, signed files, and approved external references. The packet compiles both paths with the selected records, attachments, indexes, historical versions, and SHA-256 checksums.
 
 ```sh
 npx filegrc prepare-audit audit-id
@@ -106,15 +110,15 @@ npx filegrc audit-readiness audit-id --json
 npx filegrc evidence-packet --audit audit-id
 ```
 
-FileGRC checks management preparation and packet integrity. The independent CPA firm still selects samples, tests controls, evaluates exceptions, decides whether evidence is sufficient, and issues the SOC 2 report.
+filegrc checks management preparation and packet integrity. The independent CPA firm still selects samples, tests controls, evaluates exceptions, decides whether evidence is sufficient, and issues the SOC 2 report.
 
 Early CPA engagement remains available when a customer deadline, unusual scope, or other timing risk needs input before the program reaches Evidence Ready. It is optional, not the default first action.
 
 ## What belongs elsewhere
 
-FileGRC does not replace workforce, identity, source-control, deployment, infrastructure, monitoring, endpoint, backup, vulnerability, training, signature, procurement, contract, or vendor-risk systems.
+filegrc does not replace workforce, identity, source-control, deployment, infrastructure, monitoring, endpoint, backup, vulnerability, training, signature, procurement, contract, or vendor-risk systems.
 
-Catalog each authoritative system in FileGRC, record how to export from it, and attach or reference the fixed evidence when Audit Readiness asks for it. The generated external-delivery index identifies files that still need to be supplied through an auditor portal or another approved channel.
+Catalog each authoritative system in filegrc, record how to export from it, and attach or reference the fixed evidence when Audit Readiness asks for it. The generated external-delivery index identifies files that still need to be supplied through an auditor portal or another approved channel.
 
 The starter uses the SOC 2 Security category and does not include licensed criteria text. Add Availability, Processing Integrity, Confidentiality, or Privacy only when they are in scope.
 

package/template/WORKSPACE.md

@@ -1,8 +1,8 @@
-# {{company_name}} SOC 2 Program
+# {{program_title}}
 
-This private workspace holds {{company_name}}'s SOC 2 program records and audit evidence. JSON under `data/` stores structured records, Markdown stores long-form work, and Git records reviewed changes.
+{{program_summary}}
 
-The workspace uses FileGRC {{filegrc_version}} through the dependency range `{{filegrc_version_range}}`.
+The workspace uses filegrc {{filegrc_version}} through the dependency spec `{{filegrc_version_range}}`.
 
 ## Work locally
 
@@ -27,15 +27,6 @@ npx filegrc validate --json
 
 Read `AGENTS.md` and `data/AGENTS.md` before broad changes.
 
-## Finish initial setup
+{{starter_setup}}
 
-The starter policies, controls, and obligations are proposals. They do not state that {{company_name}} operates the described controls.
-
-1. Use browser onboarding or `npx filegrc setup --help` to record the initial service and goal, then finish Step 1 by confirming the people and oversight team, applicable criteria, commitments, material vendors, and in-scope systems.
-2. Review the starter policies, appoint a reviewer who is separate from the policy owner, and activate only the policies that match current practice. The reviewer will usually be another person in the organization, but may be external.
-3. Review the starter control set, implement each applicable control with its actual procedure, scope, cadence, evidence sources, and implementation date, and confirm any linked Work Queue schedules are enabled. Marking a control implemented starts eligible schedules. Then record any complementary customer or subservice controls.
-4. Open each generated External Evidence draft, choose its authoritative source System, collect the named artifact, and have another person verify it.
-5. Run `npx filegrc program-readiness --require-ready`, record the management candidate period start when reliable evidence collection begins, maintain risk assessments and risks, update controls when needed, use Work Queue for scheduled work, and trigger Policy Events when changes create required actions. `npx filegrc obligations` previews every event task, owner, deadline, and requested proof before the trigger creates anything.
-6. Engage a CPA firm, record the separate firm-agreed period in an audit record, review FileGRC Evidence and External Evidence, and prepare fieldwork.
-
-FileGRC manages GRC records and audit evidence. It does not replace infrastructure logging, monitoring, identity, backup, endpoint, or incident-detection systems.
+filegrc manages GRC records and audit evidence. It does not replace infrastructure logging, monitoring, identity, backup, endpoint, or incident-detection systems.

package/template/data/AGENTS.md

@@ -1,4 +1,4 @@
-# FileGRC Data Instructions
+# filegrc Data Instructions
 
 These instructions apply to every file under `data/`. The root `AGENTS.md` explains the program and Git workflow. A collection-level `AGENTS.md`, when present, adds rules for that resource.
 
@@ -24,7 +24,7 @@ Use `program-path` to find the current lifecycle step and see the renderer’s e
 - Work required on a schedule or event belongs in `obligation`.
 - A dated instance of work belongs in its activity type, such as `meeting`, `risk-assessment`, `access-review`, `vulnerability-scan`, `backup-test`, or `exercise`.
 - A fact that may change over time belongs in an inventory record, such as `person`, `system`, `asset`, `vendor`, or `access-grant`.
-- A dated Step 5 operating record proves that FileGRC-managed work occurred. Put each fixed external artifact in an `evidence` record and link it from the operating record; never add an unexplained attachment.
+- A dated Step 5 operating record proves that filegrc-managed work occurred. Put each fixed external artifact in an `evidence` record and link it from the operating record; never add an unexplained attachment.
 - Follow-up work belongs in `action-item`. A gap belongs in `finding`, a known threat belongs in `risk`, and an approved temporary departure belongs in `exception`.
 - An auditor request belongs in `audit-request`; the engagement itself belongs in `audit`.
 
@@ -61,7 +61,7 @@ npx filegrc create /tmp/filegrc-mutation.json
 npx filegrc validate --json
 ```
 
-Creation is atomic. If JSON, Markdown, relationships, or validation fail, FileGRC rolls back the write. IDs are globally unique and immutable after commit.
+Creation is atomic. If JSON, Markdown, relationships, or validation fail, filegrc rolls back the write. IDs are globally unique and immutable after commit.
 
 ## Read and update
 
@@ -77,7 +77,7 @@ Edit the exported mutation, then run:
 npx filegrc update RESOURCE_TYPE RESOURCE_ID /tmp/filegrc-mutation.json
 ```
 
-The mutation includes the complete record, current Markdown, and revision hashes. FileGRC rejects the update if another person or agent changed either source after export. Reload and reapply the intended change instead of overwriting it.
+The mutation includes the complete record, current Markdown, and revision hashes. filegrc rejects the update if another person or agent changed either source after export. Reload and reapply the intended change instead of overwriting it.
 
 To update JSON and Markdown together, pass `{ "record": {...}, "content": {...}, "revision": "...", "contentRevisions": {...} }`. To change one Markdown slot:
 
@@ -121,7 +121,7 @@ Delete only an uncommitted draft or a mistake:
 npx filegrc delete RESOURCE_TYPE RESOURCE_ID --yes
 ```
 
-FileGRC rejects deletion that breaks references and removes owned Markdown with the JSON. Retire, close, cancel, supersede, or replace committed records that explain historical operation.
+filegrc rejects deletion that breaks references and removes owned Markdown with the JSON. Retire, close, cancel, supersede, or replace committed records that explain historical operation.
 
 ## Evidence and attachments
 
@@ -148,7 +148,7 @@ Remove a local attachment explicitly before deleting its evidence record:
 npx filegrc detach EVIDENCE_ID source-export.csv --yes
 ```
 
-FileGRC will not delete an evidence record that still has local attachments.
+filegrc will not delete an evidence record that still has local attachments.
 
 Never invent evidence, dates, approvals, results, people, or source-system details. If a required fact is unavailable, leave the record in a non-final state and report the missing input.
 
@@ -167,13 +167,13 @@ Run `obligations` before `trigger` to preview every Policy Event task, owner, de
 ## Audit work
 
 ```sh
-npx filegrc program-readiness --json
+npx filegrc program-readiness --summary --json
 npx filegrc prepare-audit AUDIT_ID
 npx filegrc audit-readiness AUDIT_ID --json
 npx filegrc evidence-packet --audit AUDIT_ID --preview --json
 ```
 
-Run Program Readiness before creating the normal audit engagement. It checks scope, effective policies, implemented controls, evidence sources, and test captures without an audit ID. Fix readiness errors in source records. Do not edit packet output under `.filegrc/`. A delivery-ready FileGRC packet means the management checks passed; the engagement team still judges evidence and performs the examination.
+Run Program Readiness before creating the normal audit engagement. It checks scope, effective policies, implemented controls, evidence sources, and test captures without an audit ID. Fix readiness errors in source records. Do not edit packet output under `.filegrc/`. A delivery-ready filegrc packet means the management checks passed; the engagement team still judges evidence and performs the examination.
 
 ## Finish every change
 

package/template/data/action-items/AGENTS.md

@@ -1,6 +1,6 @@
 # Action Item Instructions
 
-Create an Action Item only when follow-up needs its own assignee, deadline, and completion proof. Keep simpler remediation on the Finding or other source record. Set `sourceResourceId` to the record that created the work; FileGRC derives the backlink and adds every open Action Item to Work Queue. Keep the assignee, due date or policy window, blockers, completion records, and evidence explicit.
+Create an Action Item only when follow-up needs its own assignee, deadline, and completion proof. Keep simpler remediation on the Finding or other source record. Set `sourceResourceId` to the record that created the work; filegrc derives the backlink and adds every open Action Item to Work Queue. Keep the assignee, due date or policy window, blockers, completion records, and evidence explicit.
 
 For an event-generated action, do not weaken or extend its policy deadline by hand. Create the requested completion resource and close the action atomically:
 
@@ -8,4 +8,4 @@ For an event-generated action, do not weaken or extend its policy deadline by ha
 npx filegrc complete-action ACTION_ITEM_ID completion-mutation.json --completed-on YYYY-MM-DD
 ```
 
-FileGRC rejects the wrong completion type. Mark ordinary Action Items `done` only after the work occurred, set `completedOn`, and link the completion record or evidence. Use `blocked` while a named dependency prevents work, and link that dependency with `blockingResourceIds`.
+filegrc rejects the wrong completion type. Mark ordinary Action Items `done` only after the work occurred, set `completedOn`, and link the completion record or evidence. Use `blocked` while a named dependency prevents work, and link that dependency with `blockingResourceIds`.

package/template/data/audits/AGENTS.md

@@ -17,10 +17,10 @@ Preparation creates engagement-specific management documents and, for Type 2, po
 
 Review both evidence paths for the exact formal date or period:
 
-1. FileGRC Evidence consists of dated Step 5 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.
+1. filegrc Evidence consists of dated Step 5 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. External Evidence consists of verified `evidence` records from other Systems. Confirm the source System, date or period, Control links, collector, verifier, and fixed attachment or approved external reference.
 
-The packet compiles both paths. It includes FileGRC records and Markdown with Git history, plus External Evidence records, retained attachments, delivery indexes, and checksums.
+The packet compiles both paths. It includes filegrc records and Markdown with Git history, plus External Evidence records, retained attachments, delivery indexes, and checksums.
 
 Run readiness repeatedly and fix source records. Preview the packet before writing it:
 
@@ -29,4 +29,4 @@ npx filegrc evidence-packet --audit AUDIT_ID --preview --json
 npx filegrc evidence-packet --audit AUDIT_ID
 ```
 
-Do not state that an auditor accepted evidence, selected a sample, cleared an exception, or issued a report unless that fact came from the engagement team. FileGRC tracks management preparation; the CPA firm owns examination judgments and the report.
+Do not state that an auditor accepted evidence, selected a sample, cleared an exception, or issued a report unless that fact came from the engagement team. filegrc tracks management preparation; the CPA firm owns examination judgments and the report.

package/template/data/documents/document-business-continuity-disaster-recovery.json

@@ -6,7 +6,6 @@
   "status": "draft",
   "documentKind": "plan",
   "ownerIds": ["person-policy-owner"],
-  "approverIds": ["person-independent-approver"],
   "version": "1.0",
   "effectiveOn": "{{effective_date}}",
   "reviewCadence": {

package/template/data/documents/document-contractor-policy-acknowledgement.json

@@ -6,7 +6,6 @@
   "status": "draft",
   "documentKind": "attestation-template",
   "ownerIds": ["person-policy-owner"],
-  "approverIds": ["person-independent-approver"],
   "version": "1.0",
   "effectiveOn": "{{effective_date}}",
   "reviewCadence": {

package/template/data/documents/document-contractor-training-acknowledgement.json

@@ -6,7 +6,6 @@
   "status": "draft",
   "documentKind": "attestation-template",
   "ownerIds": ["person-policy-owner"],
-  "approverIds": ["person-independent-approver"],
   "version": "1.0",
   "effectiveOn": "{{effective_date}}",
   "reviewCadence": {

package/template/data/documents/document-data-retention-schedule.json

@@ -6,7 +6,6 @@
   "status": "draft",
   "documentKind": "schedule",
   "ownerIds": ["person-policy-owner"],
-  "approverIds": ["person-independent-approver"],
   "version": "1.0",
   "effectiveOn": "{{effective_date}}",
   "reviewCadence": {

package/template/data/documents/document-employee-handbook-acknowledgement.json

@@ -6,7 +6,6 @@
   "status": "draft",
   "documentKind": "attestation-template",
   "ownerIds": ["person-policy-owner"],
-  "approverIds": ["person-independent-approver"],
   "version": "1.0",
   "effectiveOn": "{{effective_date}}",
   "reviewCadence": {

package/template/data/documents/document-employee-policy-acknowledgement.json

@@ -6,7 +6,6 @@
   "status": "draft",
   "documentKind": "attestation-template",
   "ownerIds": ["person-policy-owner"],
-  "approverIds": ["person-independent-approver"],
   "version": "1.0",
   "effectiveOn": "{{effective_date}}",
   "reviewCadence": {

package/template/data/documents/document-employee-training-acknowledgement.json

@@ -6,7 +6,6 @@
   "status": "draft",
   "documentKind": "attestation-template",
   "ownerIds": ["person-policy-owner"],
-  "approverIds": ["person-independent-approver"],
   "version": "1.0",
   "effectiveOn": "{{effective_date}}",
   "reviewCadence": {

package/template/data/documents/document-incident-response-plan.json

@@ -6,7 +6,6 @@
   "status": "draft",
   "documentKind": "plan",
   "ownerIds": ["person-policy-owner"],
-  "approverIds": ["person-independent-approver"],
   "version": "1.0",
   "effectiveOn": "{{effective_date}}",
   "reviewCadence": {

package/template/data/documents/document-soc2-management-assertion.json

@@ -9,9 +9,6 @@
   "ownerIds": [
     "person-policy-owner"
   ],
-  "approverIds": [
-    "person-independent-approver"
-  ],
   "version": "0.1",
   "classification": "Confidential"
 }

package/template/data/documents/document-soc2-management-representation.json

@@ -9,9 +9,6 @@
   "ownerIds": [
     "person-policy-owner"
   ],
-  "approverIds": [
-    "person-independent-approver"
-  ],
   "version": "0.1",
   "classification": "Confidential"
 }

package/template/data/documents/document-soc2-period-completeness.json

@@ -9,9 +9,6 @@
   "ownerIds": [
     "person-policy-owner"
   ],
-  "approverIds": [
-    "person-independent-approver"
-  ],
   "version": "0.1",
   "classification": "Confidential"
 }

package/template/data/documents/document-soc2-period-completeness.md

@@ -6,7 +6,7 @@ Reporting period: [start date] through [end date]
 
 Management reconciled every audit-population record linked to this engagement to its authoritative source and included every item relevant to the in-scope system and controls. The generated `population-index.csv` is incorporated into this statement by reference and records each population ID, source system, query, timezone, count, validation, reviewer, conclusion, and fixed export.
 
-| Population | FileGRC population ID | Result or exception |
+| Population | filegrc population ID | Result or exception |
 | --- | --- | --- |
 | Workforce starts, role changes, and departures | [Population ID] | [Result] |
 | Access grants, changes, reviews, and removals | [Population ID] | [Result] |
@@ -27,6 +27,6 @@ For a population with zero items, retain the source-system export or report that
 
 ## Management Confirmation
 
-To the best of management's knowledge after the reconciliations above, FileGRC and the linked evidence contain the complete populations and reportable events relevant to the engagement period.
+To the best of management's knowledge after the reconciliations above, filegrc and the linked evidence contain the complete populations and reportable events relevant to the engagement period.
 
 [Identify the responsible signer, title, signature or approval method, and date.]

package/template/data/documents/document-soc2-system-description.json

@@ -9,9 +9,6 @@
   "ownerIds": [
     "person-policy-owner"
   ],
-  "approverIds": [
-    "person-independent-approver"
-  ],
   "version": "0.1",
   "classification": "Internal"
 }

package/template/data/documents/document-soc2-system-description.md

@@ -1,6 +1,6 @@
 # {{company_name}} SOC 2 System Description
 
-> Draft preparation document. Complete every bracketed item, reconcile it to the FileGRC records, and have the service auditor review the final presentation.
+> Draft preparation document. Complete every bracketed item, reconcile it to the filegrc records, and have the service auditor review the final presentation.
 
 ## Reporting Period and Scope
 
@@ -16,7 +16,7 @@
 
 ## DC2: Service Commitments and System Requirements
 
-[Summarize customer commitments, contractual security promises, internal objectives, and the system requirements needed to meet them. Link the FileGRC commitment records.]
+[Summarize customer commitments, contractual security promises, internal objectives, and the system requirements needed to meet them. Link the filegrc commitment records.]
 
 ## DC3: System Components
 
@@ -46,7 +46,7 @@
 
 ## DC5: Applicable Criteria and Controls
 
-[Reference the selected criteria and control matrix generated by FileGRC.]
+[Reference the selected criteria and control matrix generated by filegrc.]
 
 ## DC6: Complementary User Entity Controls
 

package/template/data/evidence/AGENTS.md

@@ -2,14 +2,14 @@
 
 An evidence record explains what a proof item is, where it came from, what period it supports, who collected it, and which records or controls it supports. The attachment alone is not enough.
 
-Completing onboarding creates draft collection tests only for evidence that must come from systems outside FileGRC and does not already have a dedicated Step 5 record. Risk assessments, meetings, vendor reviews, attestations, vulnerability scans, penetration tests, backup tests, exercises, exceptions, and findings do not need a separate test. When one of those operating records needs a fixed external artifact, create or update an External Evidence record for the artifact and link its ID from the operating record. Keep a generated collection test as `draft` until the artifact has actually been captured. Set it to `collected` only after selecting the source System, attaching or referencing the result, and recording the source, date, classification, and collector. Set it to `verified` only after another named person checks it.
+Onboarding does not create collection tests. After confirming applicable controls and authoritative source Systems, preview proposed tests with `npx filegrc evidence-test-drafts --preview --json`, then explicitly create the missing drafts. Risk assessments, meetings, vendor reviews, attestations, vulnerability scans, penetration tests, backup tests, exercises, exceptions, and findings do not need a separate test. When one of those operating records needs a fixed external artifact, create or update an External Evidence record for the artifact and link its ID from the operating record. Keep a created collection test as `draft` until the artifact has actually been captured. Set it to `collected` only after selecting the source System, attaching or referencing the result, and recording the source, date, classification, and collector. Set it to `verified` only after another named person checks it.
 
 ## Create evidence
 
 1. Run `npx filegrc guide evidence --json`.
 2. Use one evidence record for one coherent proof item or fixed export.
 3. Put local attachments under `data/evidence/EVIDENCE_ID/` and list their data-relative paths in `filePaths`.
-4. Use `externalReference` only when the file must remain in an approved external system. FileGRC never fetches it.
+4. Use `externalReference` only when the file must remain in an approved external system. filegrc never fetches it.
 5. Link `sourceResourceIds`, `controlIds`, and `auditIds` as applicable. Use `sourceCommit` when the evidence represents repository state.
 6. Name the actual collector. A `verified` record also needs the actual verifier and verification date.
 
@@ -21,7 +21,7 @@ npx filegrc attach EVIDENCE_ID /path/to/source-file --name auditor-facing-name.c
 
 The command never overwrites an existing attachment.
 
-Use `npx filegrc detach EVIDENCE_ID FILE_NAME --yes` when removing a mistaken attachment. FileGRC will not delete an evidence record while local attachments remain.
+Use `npx filegrc detach EVIDENCE_ID FILE_NAME --yes` when removing a mistaken attachment. filegrc will not delete an evidence record while local attachments remain.
 
 For a rendered page capture, record the route, filters, audit period, exact Git commit, capture time and method, source resource IDs, and screenshot. A current screenshot cannot prove an earlier state unless it is rendered from or bound to that revision.
 

package/template/data/obligation-events/AGENTS.md

@@ -15,4 +15,4 @@ Complete each action with the requested resource type and proof. Then close the
 npx filegrc complete-event OBLIGATION_EVENT_ID --completed-on YYYY-MM-DD
 ```
 
-FileGRC refuses to close an event with unfinished or unproved actions. Cancel an event only when the triggering event itself was entered in error or did not occur; explain the reason in related records or the commit message.
+filegrc refuses to close an event with unfinished or unproved actions. Cancel an event only when the triggering event itself was entered in error or did not occur; explain the reason in related records or the commit message.

package/template/data/people/person-policy-owner.json

@@ -4,7 +4,7 @@
   "type": "person",
   "title": "{{policy_owner_name}}",
   "status": "active",
-  "email": "{{security_contact_email}}",
+  "email": "{{policy_owner_email}}",
   "role": "Policy Owner",
   "teamIds": ["team-security-risk-oversight"]
 }

package/template/data/policies/policy-anti-bribery-corruption.json

@@ -5,7 +5,6 @@
   "title": "Anti-Bribery and Corruption Policy",
   "status": "draft",
   "ownerIds": ["person-policy-owner"],
-  "approverIds": ["person-independent-approver"],
   "policyKind": "corporate-conduct",
   "version": "1.0",
   "effectiveOn": "{{effective_date}}",

package/template/data/policies/policy-clear-desk-screen.json

@@ -5,7 +5,6 @@
   "title": "Clear Desk and Clear Screen Policy",
   "status": "draft",
   "ownerIds": ["person-policy-owner"],
-  "approverIds": ["person-independent-approver"],
   "policyKind": "information-security",
   "version": "1.0",
   "effectiveOn": "{{effective_date}}",

package/template/data/policies/policy-data-protection-handling.json

@@ -5,7 +5,6 @@
   "title": "Data Protection and Handling Policy",
   "status": "draft",
   "ownerIds": ["person-policy-owner"],
-  "approverIds": ["person-independent-approver"],
   "policyKind": "information-security",
   "version": "1.0",
   "effectiveOn": "{{effective_date}}",

package/template/data/policies/policy-employee-handbook.json

@@ -5,7 +5,6 @@
   "title": "Employee Handbook",
   "status": "draft",
   "ownerIds": ["person-policy-owner"],
-  "approverIds": ["person-independent-approver"],
   "policyKind": "workforce-conduct",
   "version": "1.0",
   "effectiveOn": "{{effective_date}}",

package/template/data/policies/policy-information-security.json

@@ -5,7 +5,6 @@
   "title": "Information Security Policy",
   "status": "draft",
   "ownerIds": ["person-policy-owner"],
-  "approverIds": ["person-independent-approver"],
   "policyKind": "information-security",
   "version": "1.0",
   "effectiveOn": "{{effective_date}}",

package/template/data/policies/policy-mobile-computing-communications.json

@@ -5,7 +5,6 @@
   "title": "Mobile Computing and Communications Policy",
   "status": "draft",
   "ownerIds": ["person-policy-owner"],
-  "approverIds": ["person-independent-approver"],
   "policyKind": "information-security",
   "version": "1.0",
   "effectiveOn": "{{effective_date}}",

package/template/data/systems/system-filegrc-program-repository.md

@@ -1,9 +1,9 @@
-# FileGRC Program Repository
+# filegrc Program Repository
 
-This Git repository is the system of record for FileGRC governance records and their revision history. It can supply the training and acknowledgement catalog, exception and finding populations, policy and document approvals, obligation history, Policy Event workflows, and management evidence indexes.
+This Git repository is the system of record for filegrc governance records and their revision history. It can supply the training and acknowledgement catalog, exception and finding populations, policy and document approvals, obligation history, Policy Event workflows, and management evidence indexes.
 
 ## Evidence Extraction
 
-Run FileGRC from a clean commit. Use resource dates and audit links to select the exact engagement date or period, save the query or agent instructions with the export, and retain the fixed result behind an evidence record. Record a zero count when the committed source query returns no relevant items.
+Run filegrc from a clean commit. Use resource dates and audit links to select the exact engagement date or period, save the query or agent instructions with the export, and retain the fixed result behind an evidence record. Record a zero count when the committed source query returns no relevant items.
 
 The repository is authoritative only for records stored here. Identity, workforce, source-control, deployment, monitoring, endpoint, backup, vulnerability, and vendor systems remain authoritative for the activity they perform.

package/template/data/workspace.json

@@ -3,10 +3,10 @@
   "dataModelVersion": "1",
   "id": "workspace",
   "type": "workspace",
-  "title": "{{company_name}} SOC 2 Program",
+  "title": "{{program_title}}",
   "organizationName": "{{company_name}}",
-  "timezone": "UTC",
-  "description": "SOC 2 Security program based on the AICPA Trust Services Criteria.",
+  "timezone": "{{timezone}}",
+  "description": "{{program_description}}",
   "riskMethodology": {
     "method": "5x5 likelihood and impact",
     "likelihoodScale": ["Rare", "Unlikely", "Possible", "Likely", "Almost certain"],

package/template/package.json

@@ -1,8 +1,8 @@
 {
   "name": "{{project_name}}",
-  "version": "0.2.0",
+  "version": "0.3.1",
   "private": true,
-  "description": "FileGRC workspace for a SOC 2 program",
+  "description": "filegrc workspace for a SOC 2 program",
   "type": "module",
   "scripts": {
     "serve": "filegrc serve",