create-filegrc 0.2.0 → 0.3.0

package/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 FileGRC contributors
+Copyright (c) 2026 filegrc contributors
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/README.md

@@ -1,6 +1,6 @@
 # create-filegrc
 
-Create a Git-native FileGRC workspace for a SOC 2 program:
+Create a Git-native filegrc workspace for a SOC 2 program:
 
 ```sh
 npx create-filegrc@latest company-grc
@@ -9,12 +9,12 @@ npm run validate
 npm run serve
 ```
 
-Setup asks for the company name, the initial policy owner, and a security contact email. The generated private project includes a starter Security program, Program Readiness, a policy-driven Work Queue, Policy Events that add linked tasks, later audit preparation, evidence packets, and one dependency: `filegrc`.
+Setup asks for the legal organization name, the initial policy owner and their email, a security reporting address, and the program timezone. The generated private project includes a starter Security program, Program Readiness, a policy-driven Work Queue, Policy Events that add linked tasks, later audit preparation, evidence packets, and one dependency: `filegrc`.
 
 Generated workspaces also include layered `AGENTS.md` instructions and model-driven headless commands. `filegrc program-path` gives agents the same six steps, exact page guidance, current status, and next actions shown in the renderer. Agents can define program scope, approve policies, implement controls, test External Evidence, complete policy work, trigger event tasks, and prepare later audit packets through the same domain functions used by the renderer.
 
 Git is initialized when needed. The browser can create local commits before a remote is configured.
 
-Creation output reports the resolved FileGRC version, whether installation ran, and whether the target joined an existing Git worktree or received a new repository.
+Creation output reports the resolved filegrc version, program timezone, starter record counts, whether installation ran, and whether the target joined an existing Git worktree or received a new repository.
 
 Use `npx create-filegrc@latest --help` for non-interactive options.

package/package.json

@@ -1,11 +1,11 @@
 {
   "name": "create-filegrc",
-  "version": "0.2.0",
-  "description": "Create a FileGRC workspace for a SOC 2 program",
+  "version": "0.3.0",
+  "description": "Create a filegrc workspace for a SOC 2 program",
   "license": "MIT",
   "repository": {
     "type": "git",
-    "url": "git+https://github.com/Sunpeak-AI/FileGRC.git"
+    "url": "git+https://github.com/Sunpeak-AI/filegrc.git"
   },
   "type": "module",
   "bin": {

package/src/cli.js

@@ -1,23 +1,35 @@
 import { readFile } from "node:fs/promises";
-import { createFileGRC } from "./index.js";
+import { createFilegrc } from "./index.js";
 
 export async function runCli(argv = process.argv.slice(2)) {
   const { target, options } = parseArgs(argv);
   if (options.help) return printHelp();
   if (options.version) return printVersion();
-  const result = await createFileGRC({ target, ...options });
+  const result = await createFilegrc({ target, ...options });
   console.log(`Created ${result.target}`);
-  console.log(`FileGRC ${result.engineVersion}: ${result.install === "installed" ? "installed" : "installation skipped"}`);
+  console.log(`filegrc ${result.engineVersion}: ${result.install === "installed" ? "installed" : "installation skipped"}`);
   console.log(`Git: ${result.gitMode === "existing-worktree" ? "joined existing worktree" : "initialized new repository"}`);
+  console.log(`Timezone: ${result.values.timezone}`);
+  console.log(
+    `Program baseline: ${result.resourceCounts.total} records, including ` +
+    `${result.resourceCounts.byType.requirement || 0} requirements, ` +
+    `${result.resourceCounts.byType.control || 0} controls, and ` +
+    `${result.resourceCounts.byType.obligation || 0} obligations.`
+  );
   console.log("");
-  console.log(`  cd ${result.target}`);
+  console.log(`  cd ${shellQuote(result.target)}`);
   if (options.install === false) console.log("  npm install");
+  console.log("  npx filegrc setup");
   console.log("  npm run validate");
   console.log("  npm run serve");
   console.log("");
   console.log("Review the starter drafts, then commit the approved baseline.");
 }
 
+function shellQuote(value) {
+  return `'${String(value).replaceAll("'", "'\\''")}'`;
+}
+
 function parseArgs(argv) {
   let target;
   const options = {};
@@ -36,7 +48,9 @@ function parseArgs(argv) {
     else if (name === "no-install") options.install = false;
     else if (name === "company-name") options.companyName = next();
     else if (name === "policy-owner-name") options.policyOwnerName = next();
+    else if (name === "policy-owner-email") options.policyOwnerEmail = next();
     else if (name === "security-contact-email") options.securityContactEmail = next();
+    else if (name === "timezone") options.timezone = next();
     else if (name === "filegrc-version") options.filegrcVersion = next();
     else throw new Error(`Unknown option "${value}".`);
   }
@@ -46,18 +60,20 @@ function parseArgs(argv) {
 function printHelp() {
   console.log(`create-filegrc [directory] [options]
 
-Create a FileGRC workspace for a SOC 2 program.
+Create a filegrc workspace for a SOC 2 program.
 
 Options:
-  --company-name <name>
-  --policy-owner-name <name>
-  --security-contact-email <email>
+  --company-name <legal-name>       Legal organization name
+  --policy-owner-name <name>        Initial policy owner
+  --policy-owner-email <email>      Policy owner's email address
+  --security-contact-email <email>  Security reporting address
+  --timezone <iana-timezone>        Program timezone, such as America/Chicago
   --filegrc-version <version>       Override resolved engine version
-  --no-install                   Write files and a preliminary lockfile only
-  --force                        Allow a non-empty target without overwriting files
-  --yes                          Use generic prompt defaults
-  --version                      Show the package version
-  --help                         Show this help`);
+  --no-install                      Write files and a preliminary lockfile only
+  --force                           Allow a non-empty target without overwriting files
+  --yes                             Use generic prompt defaults
+  --version                         Show the package version
+  --help                            Show this help`);
 }
 
 async function printVersion() {

package/src/defaults.js

@@ -4,7 +4,6 @@ import { mkdir, writeFile } from "node:fs/promises";
 const FRAMEWORK_ID = "framework-aicpa-trust-services-criteria";
 const DESCRIPTION_FRAMEWORK_ID = "framework-aicpa-soc2-description-criteria";
 const OWNER_ID = "person-policy-owner";
-const INDEPENDENT_APPROVER_ID = "person-independent-approver";
 const OVERSIGHT_TEAM_ID = "team-security-risk-oversight";
 const INFORMATION_SECURITY_POLICY_ID = "policy-information-security";
 const DATA_POLICY_ID = "policy-data-protection-handling";
@@ -963,21 +962,21 @@ export function baselineRecordFiles(effectiveDate) {
     id: OVERSIGHT_TEAM_ID,
     type: "team",
     title: "Security and Risk Oversight",
-    status: "active",
+    status: "inactive",
     purpose: "Provide independent oversight of the security program, risk register, incidents, findings, vendor and access reviews, policy changes, exercises, and overdue work. The chair must be separate from the policy owner and people who operate the controls under review.",
-    memberIds: [OWNER_ID, INDEPENDENT_APPROVER_ID],
-    chairIds: [INDEPENDENT_APPROVER_ID],
+    memberIds: [OWNER_ID],
+    chairIds: [],
     meetingCadence: calendar("month", 3, effectiveDate)
   };
   const programRepository = {
     schemaVersion: 1,
     id: "system-filegrc-program-repository",
     type: "system",
-    title: "FileGRC Program Repository",
+    title: "filegrc Program Repository",
     status: "active",
     criticality: "high",
     ownerIds: [OWNER_ID],
-    description: "The Git repository that is authoritative for FileGRC governance records, approvals, exceptions, findings, acknowledgements, evidence indexes, and their revision history.",
+    description: "The Git repository that is authoritative for filegrc governance records, approvals, exceptions, findings, acknowledgements, evidence indexes, and their revision history.",
     systemKind: "governance-system-of-record",
     environment: "Git repository",
     dataClassification: "Confidential",

package/src/index.js

@@ -10,14 +10,14 @@ const execute = promisify(execFile);
 const packageRoot = dirname(dirname(fileURLToPath(import.meta.url)));
 const textExtensions = new Set(["", ".json", ".md", ".txt", ".yml", ".yaml", ".gitignore"]);
 
-export async function createFileGRC(options = {}) {
+export async function createFilegrc(options = {}) {
   const parameterConfig = JSON.parse(await readFile(join(packageRoot, "template-parameters.json"), "utf8"));
   const target = resolve(options.target ?? "filegrc-program");
   await assertWritableTarget(target, Boolean(options.force));
   if (options.force) await assertNoTemplateCollisions(target);
 
   const prompted = await resolvePromptValues(parameterConfig.parameters, options);
-  const engineVersion = await resolveFileGRCVersion(options.filegrcVersion);
+  const engineVersion = await resolveFilegrcVersion(options.filegrcVersion);
   const values = {
     ...prompted,
     effective_date: options.effectiveDate ?? new Date().toISOString().slice(0, 10),
@@ -30,6 +30,7 @@ export async function createFileGRC(options = {}) {
   await copyTemplate(target);
   await renderTemplate(target, parameterConfig, values);
   await writeBaselineRecords(target, values.effective_date);
+  const resourceCounts = await summarizeResources(target);
 
   const installed = options.install !== false;
   if (installed) {
@@ -43,12 +44,13 @@ export async function createFileGRC(options = {}) {
     target,
     values,
     engineVersion,
+    resourceCounts,
     install: installed ? "installed" : "skipped",
     gitMode: joinedExistingWorktree ? "existing-worktree" : "initialized"
   };
 }
 
-export async function resolveFileGRCVersion(explicitVersion) {
+export async function resolveFilegrcVersion(explicitVersion) {
   if (explicitVersion) return cleanVersion(explicitVersion);
   try {
     const { stdout } = await execute("npm", ["view", "filegrc", "version", "--json"], {
@@ -67,7 +69,9 @@ async function resolvePromptValues(parameters, options) {
   const mapped = {
     company_name: options.companyName,
     policy_owner_name: options.policyOwnerName,
-    security_contact_email: options.securityContactEmail
+    policy_owner_email: options.policyOwnerEmail,
+    security_contact_email: options.securityContactEmail,
+    timezone: options.timezone
   };
   if (options.yes) {
     mapped.company_name ??= "Example Company";
@@ -77,21 +81,29 @@ async function resolvePromptValues(parameters, options) {
   for (const key of Object.keys(mapped)) {
     if (mapped[key] !== undefined && mapped[key] !== null) mapped[key] = String(mapped[key]).trim();
   }
-  const missing = parameters.filter(({ key, required }) => required && !mapped[key]);
-  if (missing.length) {
-    if (!process.stdin.isTTY || !process.stdout.isTTY) {
-      throw new Error(`Missing required values: ${missing.map(({ key }) => key).join(", ")}`);
-    }
+  if (process.stdin.isTTY && process.stdout.isTTY) {
     const prompt = createInterface({ input: process.stdin, output: process.stdout });
     try {
-      for (const parameter of missing) {
+      for (const parameter of parameters.filter(({ required, key }) => required && !mapped[key])) {
+        const defaultValue = parameterDefault(parameter, mapped);
+        const suffix = defaultValue ? ` [${defaultValue}]` : "";
         let value = "";
-        while (!value) value = (await prompt.question(`${parameter.prompt}: `)).trim();
+        while (!value) {
+          value = (await prompt.question(`${parameter.prompt}${suffix}: `)).trim() || defaultValue;
+        }
         mapped[parameter.key] = value;
       }
     } finally {
       prompt.close();
     }
+  } else {
+    for (const parameter of parameters.filter(({ required, key }) => required && !mapped[key])) {
+      mapped[parameter.key] = parameterDefault(parameter, mapped);
+    }
+  }
+  const missing = parameters.filter(({ key, required }) => required && !mapped[key]);
+  if (missing.length) {
+    throw new Error(`Missing required values: ${missing.map(({ key }) => key).join(", ")}`);
   }
   for (const key of ["company_name", "policy_owner_name"]) {
     if (/[\u0000-\u001f\u007f]/.test(mapped[key])) {
@@ -102,12 +114,39 @@ async function resolvePromptValues(parameters, options) {
       throw new Error(`${key} cannot contain template token syntax.`);
     }
   }
-  if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(mapped.security_contact_email)) {
-    throw new Error("Security contact email must be a valid email address.");
+  for (const [key, label] of [
+    ["policy_owner_email", "Policy owner email"],
+    ["security_contact_email", "Security contact email"]
+  ]) {
+    if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(mapped[key])) {
+      throw new Error(`${label} must be a valid email address.`);
+    }
   }
+  if (!isTimezone(mapped.timezone)) throw new Error("Program timezone must be a valid IANA time zone.");
   return mapped;
 }
 
+function parameterDefault(parameter, mapped) {
+  if (parameter.defaultFrom) return mapped[parameter.defaultFrom] || "";
+  if (parameter.defaultSource === "local-timezone") return localTimezone();
+  return "";
+}
+
+function localTimezone() {
+  const timezone = Intl.DateTimeFormat().resolvedOptions().timeZone;
+  return isTimezone(timezone) ? timezone : "UTC";
+}
+
+function isTimezone(value) {
+  if (!value) return false;
+  try {
+    new Intl.DateTimeFormat("en-US", { timeZone: value }).format();
+    return true;
+  } catch {
+    return false;
+  }
+}
+
 async function assertWritableTarget(target, force) {
   try {
     if ((await lstat(target)).isSymbolicLink()) {
@@ -213,16 +252,29 @@ async function collectFiles(directory) {
   return result;
 }
 
+async function summarizeResources(target) {
+  const counts = {};
+  let total = 0;
+  for (const path of await collectFiles(join(target, "data"))) {
+    if (extname(path) !== ".json") continue;
+    const record = JSON.parse(await readFile(path, "utf8"));
+    if (!record?.id || !record?.type || !record?.schemaVersion) continue;
+    total += 1;
+    counts[record.type] = (counts[record.type] || 0) + 1;
+  }
+  return { total, byType: counts };
+}
+
 async function writeMinimalLockfile(target, name, versionRange) {
   const lock = {
     name,
-    version: "0.2.0",
+    version: "0.3.0",
     lockfileVersion: 3,
     requires: true,
     packages: {
       "": {
         name,
-        version: "0.2.0",
+        version: "0.3.0",
         dependencies: { filegrc: versionRange }
       }
     }
@@ -251,7 +303,7 @@ async function run(command, args, cwd) {
 function cleanVersion(value) {
   const version = String(value ?? "").trim().replace(/^v/, "");
   if (!/^\d+\.\d+\.\d+(?:-[0-9A-Za-z.-]+)?$/.test(version)) {
-    throw new Error(`Could not resolve a valid FileGRC version from "${value}".`);
+    throw new Error(`Could not resolve a valid filegrc version from "${value}".`);
   }
   return version;
 }

package/template/AGENTS.md

@@ -1,8 +1,8 @@
-# FileGRC SOC 2 Workspace Instructions
+# filegrc SOC 2 Workspace Instructions
 
 ## Purpose
 
-This repository is {{company_name}}’s FileGRC workspace for its SOC 2 program. Engineers and agents maintain the source records under `data/`. The `filegrc` package validates, searches, edits, and renders those files.
+This repository is {{company_name}}’s filegrc workspace for its SOC 2 program. Engineers and agents maintain the source records under `data/`. The `filegrc` package validates, searches, edits, and renders those files.
 
 Using this repository does not establish compliance by itself. Records must match actual practice and evidence must prove that controls operated during the audit period.
 
@@ -15,7 +15,7 @@ npx filegrc guide --json
 npx filegrc program-path --json
 npx filegrc guide risk-assessment --json
 npx filegrc list person --json
-npx filegrc program-readiness --json
+npx filegrc program-readiness --summary --json
 ```
 
 `program-path` gives agents the same six-step order, exact page Instructions, Use, Policy Basis, commands, current state, and next actions shown in the renderer. The general guide lists every supported action and record type. A type guide repeats that page guidance and adds timing, required and conditional fields, current relationship candidates, JSON location, and Markdown slots.
@@ -46,7 +46,7 @@ Read `data/AGENTS.md` before changing records. More specific instructions inside
 - 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.
 - Use ISO 8601 dates and RFC 3339 timestamps.
 - Store relationships as resource IDs.
-- Put policies, plans, charters, procedures, meeting minutes, training, assertions, narratives, templates, and audit responses in Markdown beside their JSON records. FileGRC derives the Markdown name, so records do not contain file paths.
+- Put policies, plans, charters, procedures, meeting minutes, training, assertions, narratives, templates, and audit responses in Markdown beside their JSON records. filegrc derives the Markdown name, so records do not contain file paths.
 - Put signed forms, screenshots, third-party reports, and immutable exports behind evidence records. These files may be PDF, image, CSV, or another fixed format.
 - Never fetch an external evidence reference automatically.
 - Do not store secrets, credentials, session data, or personal data that may need to be erased from Git history.
@@ -95,7 +95,7 @@ Headless agents get the same protection by exporting an edit payload with `fileg
 
 `data/renderer.json` stores committed renderer preferences. New workspaces set `showOnboarding` to `true`. Completing or skipping onboarding sets it to `false`; the app does not commit that change.
 
-Onboarding explains the file and Git workflow, the program path, policy obligations, and Policy Events before covering report types and the final audit stage. It then collects the initial service boundary, owner, business criticality, highest data classification, internet exposure, and optional program goal. It creates or updates a `system` record and stores the management goal and program scope on `workspace`. Selecting Type 1 or Type 2 does not create an audit engagement. Completing onboarding opens the Step 1 overview so the user can confirm the starter people and oversight team, criteria, commitments, vendors, and systems before approving policies.
+Onboarding explains the file and Git workflow, the program path, policy obligations, and Policy Events before covering report types and the final audit stage. It then collects the initial service boundary, owner, business criticality, highest data classification, internet exposure, and optional program goal. It creates or updates a `system` record and stores the management goal and program scope on `workspace`. Selecting Type 1 or Type 2 does not create an audit engagement. Completing onboarding opens the Step 1 overview so the user can add the real reviewers and operators, finish the oversight team, and confirm the criteria, commitments, vendors, and systems before approving policies.
 
 The renderer is optional. Agents may set `showOnboarding` to `false` and maintain all records headlessly. Restart onboarding from Repository when useful. Read-only builds never run it.
 
@@ -111,7 +111,7 @@ The generated workspace starts with the SOC 2 Security category:
 - Recurring obligations for the reviews, scans, tests, training, and meetings required by the included policies
 - A default 5x5 risk method and Public, Internal, Confidential, and Restricted data classifications
 
-Treat every planned control as a proposal until its owner, actual procedure in Record Markdown, system scope, cadence, authoritative evidence sources, implementation date, and mappings match actual practice. For a control linked to FileGRC obligations, every non-retired Work Queue schedule must be enabled and its governing policies effective. Marking the control implemented starts eligible schedules. Do not mark a control implemented because a policy describes it. Add Availability, Processing Integrity, Confidentiality, or Privacy criteria only when they are in scope.
+Treat every planned control as a proposal until its owner, actual procedure in Record Markdown, system scope, cadence, authoritative evidence sources, implementation date, and mappings match actual practice. For a control linked to filegrc obligations, every non-retired Work Queue schedule must be enabled and its governing policies effective. Marking the control implemented starts eligible schedules. Do not mark a control implemented because a policy describes it. Add Availability, Processing Integrity, Confidentiality, or Privacy criteria only when they are in scope.
 
 The recurring obligations mirror the fixed cadences in the starter policies. They remain proposals until every governing policy is active and effective and, when they name controls, at least one linked control is implemented. Update the policy, control, and obligation together when an approved cadence changes. Create separate completion records, such as meetings, reviews, scans, tests, exercises, and attestations, for each period.
 
@@ -141,7 +141,7 @@ npx filegrc trigger person-started --occurred-on 2026-07-25 --subject person-new
 npx filegrc trigger person-ended --occurred-at 2026-07-25T16:30:00-05:00 --subject person-departing-worker --json
 ```
 
-Run `npx filegrc obligations` first to preview every task, owner, deadline, and requested proof for each available Policy Event. The trigger command creates one `obligation-event` and adds its full set of Action Items to the Work Queue in a single validated write. Its success output names the event, task count, task IDs, and deadlines. Hour-based deadlines require an RFC 3339 event timestamp so an immediate or 24-hour cutoff is exact. Day-based deadlines use the event’s calendar date. Link the requested completion resources and evidence to each action item, then mark the actions done and the event complete. Every generated action has a cutoff. FileGRC applies a 30-day deadline when a custom event obligation omits one.
+Run `npx filegrc obligations` first to preview every task, owner, deadline, and requested proof for each available Policy Event. The trigger command creates one `obligation-event` and adds its full set of Action Items to the Work Queue in a single validated write. Its success output names the event, task count, task IDs, and deadlines. Hour-based deadlines require an RFC 3339 event timestamp so an immediate or 24-hour cutoff is exact. Day-based deadlines use the event’s calendar date. Link the requested completion resources and evidence to each action item, then mark the actions done and the event complete. Every generated action has a cutoff. filegrc applies a 30-day deadline when a custom event obligation omits one.
 
 Complete an event action and link its new proof in one validated write:
 
@@ -150,7 +150,7 @@ npx filegrc complete-action action-item-id completion-record.json --completed-on
 npx filegrc complete-event obligation-event-id --completed-on 2026-07-25
 ```
 
-FileGRC rejects a completion resource whose type does not match the obligation. It will close the event only after every action has its requested proof.
+filegrc rejects a completion resource whose type does not match the obligation. It will close the event only after every action has its requested proof.
 
 ## Headless Markdown
 
@@ -161,7 +161,7 @@ npx filegrc content risk-assessment risk-assessment-2026 --json
 npx filegrc content risk-assessment risk-assessment-2026 --write updated-assessment.md
 ```
 
-Run `filegrc guide <type>` to get slot names. Policies use `content`, meetings use `agenda` and `minutes`, and implicit long-form work uses `record`. FileGRC derives the path and rejects content that does not belong to the record.
+Run `filegrc guide <type>` to get slot names. Policies use `content`, meetings use `agenda` and `minutes`, and implicit long-form work uses `record`. filegrc derives the path and rejects content that does not belong to the record.
 
 ## Program readiness and the candidate period
 
@@ -169,7 +169,7 @@ Prepare the management program before creating an audit engagement:
 
 ```sh
 npx filegrc program-readiness
-npx filegrc program-readiness --require-ready --json
+npx filegrc program-readiness --require-ready --summary --json
 ```
 
 The Evidence Ready gate requires:
@@ -178,15 +178,15 @@ The Evidence Ready gate requires:
 2. Active policies with completed text, separate management approval, real approval and effective dates, and linked controls.
 3. Implemented controls with an owner, actual procedure, scope, cadence, evidence source, mappings, implementation date, and every eligible linked Work Queue schedule running.
 4. Active authoritative systems with evidence source roles, access owners, and repeatable extraction instructions in Record Markdown.
-5. A verified `test-export` or `test-capture` evidence record for each selected control family that relies on evidence from outside FileGRC.
+5. A verified `test-export` or `test-capture` evidence record for each selected control family that relies on evidence from outside filegrc.
 
-Completing onboarding creates draft External Evidence records only for evidence that must come from other systems and does not already have a dedicated Step 5 record. FileGRC-managed records, such as risk assessments, meetings, vendor reviews, attestations, vulnerability scans, penetration tests, backup tests, exercises, exceptions, and findings, do not need a separate collection test. Put any fixed external artifact in an External Evidence record and link it from the operating record. For each generated draft, choose its authoritative source System, attach or reference the real result, record its collector and classification, then have another person verify it. Run `npx filegrc evidence-test-drafts` to create any drafts needed after the control set changes.
+Completing onboarding creates draft External Evidence records only for evidence that must come from other systems and does not already have a dedicated Step 5 record. filegrc-managed records, such as risk assessments, meetings, vendor reviews, attestations, vulnerability scans, penetration tests, backup tests, exercises, exceptions, and findings, do not need a separate collection test. Put any fixed external artifact in an External Evidence record and link it from the operating record. For each generated draft, choose its authoritative source System, attach or reference the real result, record its collector and classification, then have another person verify it. Run `npx filegrc evidence-test-drafts` to create any drafts needed after the control set changes.
 
 When the gate passes, set `workspace.candidatePeriodStart` to the date reliable evidence collection begins. Do not backdate it. `candidatePeriodStart` and `candidatePeriodEnd` express management’s target. They do not establish the final report period.
 
 Maintain risk assessments and the risk register while the program operates. Complete assessments on schedule and after material changes, and add or update controls when the conclusions require a different response. Audit preparation still checks for a current, independently reviewed assessment.
 
-Record complementary customer or subservice controls after the internal control set is defined. `complementary-control.relatedControlIds` is the source of truth for those links. FileGRC derives the reverse connections for Control pages and evidence packets.
+Record complementary customer or subservice controls after the internal control set is defined. `complementary-control.relatedControlIds` is the source of truth for those links. filegrc derives the reverse connections for Control pages and evidence packets.
 
 ## Audit preparation and evidence packets
 
@@ -204,16 +204,16 @@ Preparation creates a separate system description, management assertion, and man
 
 Review both evidence paths against the exact firm-agreed date or period:
 
-1. FileGRC Evidence consists of dated Step 5 operating records. Complete each applicable record, link it to the Controls it supports, record the result in structured fields or Markdown, and link any external artifact needed to support that result.
+1. filegrc Evidence consists of dated Step 5 operating records. Complete each applicable record, link it to the Controls it supports, record the result in structured fields or Markdown, and link any external artifact needed to support that result.
 2. External Evidence consists of verified `evidence` records from authoritative Systems. Confirm the source System, audit date or period, Control links, collector, verifier, and fixed attachment or approved external reference.
 
-Audit Readiness reports coverage for both paths. The packet includes the matching FileGRC records and Markdown with Git history, plus External Evidence records, retained attachments, delivery indexes, and checksums.
+Audit Readiness reports coverage for both paths. The packet includes the matching filegrc records and Markdown with Git history, plus External Evidence records, retained attachments, delivery indexes, and checksums.
 
 Near the end of fieldwork, link a verified fixed-format copy of the signed management representation letter to its engagement-specific document. Date it on or after the Type 1 date or Type 2 period end. A representation that is still marked for later blocks packet delivery.
 
 Catalog each authoritative source under Systems and assign its `evidenceSourceKinds`. A third-party application is still a System because it operates controls or produces evidence. Create a separate Vendor for its provider and connect the System through `vendorId`; keep contracts, due diligence, and supplier risk on the Vendor. Name the people who can access system reports and keep extraction instructions in the System's Record Markdown. For each Type 2 population, select one source system and export the exact audit period. Split a population when different systems or queries produce its items. Link a verified `population-export` evidence record that names the same source system and stores the query or report parameters, generation time, timezone, count, completeness check, and accuracy check. A zero count still requires the source export and query. A population linked to an in-scope control cannot be marked not applicable.
 
-Every evidence record names its collector. Verified evidence also names its verifier and verification date. Use `sourceSystemId` for system exports, `sourceResourceIds` for FileGRC records, and `sourceCommit` to bind the evidence to repository state.
+Every evidence record names its collector. Verified evidence also names its verifier and verification date. Use `sourceSystemId` for system exports, `sourceResourceIds` for filegrc records, and `sourceCommit` to bind the evidence to repository state.
 
 Preview coverage before writing output:
 
@@ -223,15 +223,15 @@ npx filegrc evidence-packet --audit audit-2026-type-2
 npx filegrc evidence-packet --audit audit-2026-type-2 --preview --require-ready
 ```
 
-The packet includes records explicitly related to the selected engagement, its systems, controls, criteria, policies, evidence, and dependencies. It does not include unrelated dated records from the workspace. A Type 2 packet adds FileGRC Evidence, recurring obligation occurrences, event workflows, and management population reconciliations. Output includes a control matrix with separate FileGRC Evidence and External Evidence columns, source-system index, external-evidence delivery index, population index, evidence index, committed historical source versions, and SHA-256 checksums. Output under `.filegrc/evidence-packets/` is derived and must not be hand-edited or committed.
+The packet includes records explicitly related to the selected engagement, its systems, controls, criteria, policies, evidence, and dependencies. It does not include unrelated dated records from the workspace. A Type 2 packet adds filegrc Evidence, recurring obligation occurrences, event workflows, and management population reconciliations. Output includes a control matrix with separate filegrc Evidence and External Evidence columns, source-system index, external-evidence delivery index, population index, evidence index, committed historical source versions, and SHA-256 checksums. Output under `.filegrc/evidence-packets/` is derived and must not be hand-edited or committed.
 
-Treat a packet as ready for management delivery only when its status is `delivery-ready`, its review list is clear, and its manifest names a clean Git revision. This means FileGRC's management checks passed. It does not mean the engagement team found the evidence sufficient or appropriate. The generator copies raw records, Markdown, and local fixed attachments. It never fetches external references. Reconcile `external-evidence-index.csv` to the auditor portal or other approved delivery system before telling the engagement team that submission is complete.
+Treat a packet as ready for management delivery only when its status is `delivery-ready`, its review list is clear, and its manifest names a clean Git revision. This means filegrc's management checks passed. It does not mean the engagement team found the evidence sufficient or appropriate. The generator copies raw records, Markdown, and local fixed attachments. It never fetches external references. Reconcile `external-evidence-index.csv` to the auditor portal or other approved delivery system before telling the engagement team that submission is complete.
 
-Link a control test to its `audit-population` record when sampling applies. Link item-level sample evidence separately. Management owns population completeness and accuracy. The auditor owns sample selection, independent testing, exception evaluation, and the report opinion. The auditor or publisher also supplies the authoritative criteria and examination guidance. FileGRC stores references and orientation text, not licensed criteria.
+Link a control test to its `audit-population` record when sampling applies. Link item-level sample evidence separately. Management owns population completeness and accuracy. The auditor owns sample selection, independent testing, exception evaluation, and the report opinion. The auditor or publisher also supplies the authoritative criteria and examination guidance. filegrc stores references and orientation text, not licensed criteria.
 
 ## Content and approvals
 
-The seed policy owner is {{policy_owner_name}} and the reporting address is {{security_contact_email}}. Replace ownership or contacts when responsibilities change.
+The seed policy owner is {{policy_owner_name}} at {{policy_owner_email}}, and the security reporting address is {{security_contact_email}}. Replace ownership or contacts when responsibilities change.
 
 Appoint an independent management reviewer during policy review, not as a condition of defining the service boundary. The reviewer must be separate from the policy owner and able to challenge the owner’s decisions. Most organizations assign another internal leader or manager. An external reviewer is also allowed, and a one-person company needs one because no second internal person is available. The reviewer chairs Security and Risk Oversight and approves policies and governed documents.
 

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,11 +34,11 @@ 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.
+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
 
@@ -46,8 +46,8 @@ The creation summary reports the resolved engine version, install result, and wh
 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.
+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 +57,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 +71,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 +79,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 +90,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 +108,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

@@ -2,7 +2,7 @@
 
 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.
 
-The workspace uses FileGRC {{filegrc_version}} through the dependency range `{{filegrc_version_range}}`.
+The workspace uses filegrc {{filegrc_version}} through the dependency range `{{filegrc_version_range}}`.
 
 ## Work locally
 
@@ -31,11 +31,11 @@ Read `AGENTS.md` and `data/AGENTS.md` before broad changes.
 
 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.
+1. Run `npx filegrc setup` for guided service and goal setup, or use browser onboarding. Then finish Step 1 by adding the real reviewers and operators, finishing the oversight team, and confirming 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.
+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.
+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.
 
 ## 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

@@ -5,7 +5,7 @@
   "type": "workspace",
   "title": "{{company_name}} SOC 2 Program",
   "organizationName": "{{company_name}}",
-  "timezone": "UTC",
+  "timezone": "{{timezone}}",
   "description": "SOC 2 Security program based on the AICPA Trust Services Criteria.",
   "riskMethodology": {
     "method": "5x5 likelihood and impact",

package/template/package.json

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

package/template-parameters.json

@@ -2,18 +2,30 @@
   "parameters": [
     {
       "key": "company_name",
-      "prompt": "Company name",
+      "prompt": "Legal organization name",
       "required": true
     },
     {
       "key": "policy_owner_name",
-      "prompt": "Your name",
+      "prompt": "Policy owner name",
       "required": true
     },
     {
       "key": "security_contact_email",
       "prompt": "Security contact email",
       "required": true
+    },
+    {
+      "key": "policy_owner_email",
+      "prompt": "Policy owner email",
+      "required": true,
+      "defaultFrom": "security_contact_email"
+    },
+    {
+      "key": "timezone",
+      "prompt": "Program timezone",
+      "required": true,
+      "defaultSource": "local-timezone"
     }
   ],
   "generated": [

package/template/data/people/person-independent-approver.json

@@ -1,9 +0,0 @@
-{
-  "schemaVersion": 1,
-  "id": "person-independent-approver",
-  "type": "person",
-  "title": "Independent Reviewer",
-  "status": "active",
-  "role": "Security and Risk Oversight Reviewer",
-  "teamIds": ["team-security-risk-oversight"]
-}