create-filegrc 0.1.0 → 0.2.0

package/README.md

@@ -9,10 +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, policy-driven work queue, event checklists, audit preparation, evidence packets, and one dependency: `filegrc`.
+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`.
 
-Generated workspaces also include layered `AGENTS.md` instructions and model-driven headless commands. Agents can discover types, scaffold JSON plus Markdown, inspect relationships, perform CRUD, complete policy work, and prepare audit packets through the same domain functions used by the renderer.
+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.
+
 Use `npx create-filegrc@latest --help` for non-interactive options.

package/package.json

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

package/src/cli.js

@@ -7,6 +7,8 @@ export async function runCli(argv = process.argv.slice(2)) {
   if (options.version) return printVersion();
   const result = await createFileGRC({ target, ...options });
   console.log(`Created ${result.target}`);
+  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("");
   console.log(`  cd ${result.target}`);
   if (options.install === false) console.log("  npm install");

package/src/defaults.js

@@ -70,7 +70,7 @@ const controls = [
     title: "Security governance",
     statement: "Management assigns security responsibilities, and a reviewer who is separate from the policy owner and control operators independently reviews the program, risks, incidents, findings, policy approvals, and overdue work at least quarterly.",
     requirements: ["CC1.1", "CC1.2", "CC1.3", "CC1.5"],
-    activity: "Assign an external independent reviewer and record quarterly oversight decisions, approvals, and actions.",
+    activity: "Assign an independent reviewer who is separate from program ownership and record quarterly oversight decisions, approvals, and actions.",
     controlType: "preventive",
     operationMode: "manual",
     frequency: "Quarterly",

package/src/index.js

@@ -22,6 +22,7 @@ export async function createFileGRC(options = {}) {
     ...prompted,
     effective_date: options.effectiveDate ?? new Date().toISOString().slice(0, 10),
     project_name: normalizePackageName(basename(target)),
+    filegrc_version: engineVersion,
     filegrc_version_range: `^${engineVersion}`
   };
 
@@ -30,13 +31,21 @@ export async function createFileGRC(options = {}) {
   await renderTemplate(target, parameterConfig, values);
   await writeBaselineRecords(target, values.effective_date);
 
-  if (options.install !== false) {
+  const installed = options.install !== false;
+  if (installed) {
     await run("npm", ["install", "--ignore-scripts"], target);
   } else {
     await writeMinimalLockfile(target, values.project_name, values.filegrc_version_range);
   }
-  if (!await isInsideGitWorktree(target)) await run("git", ["init"], target);
-  return { target, values, engineVersion };
+  const joinedExistingWorktree = await isInsideGitWorktree(target);
+  if (!joinedExistingWorktree) await run("git", ["init"], target);
+  return {
+    target,
+    values,
+    engineVersion,
+    install: installed ? "installed" : "skipped",
+    gitMode: joinedExistingWorktree ? "existing-worktree" : "initialized"
+  };
 }
 
 export async function resolveFileGRCVersion(explicitVersion) {
@@ -167,9 +176,11 @@ async function renderTemplate(target, parameterConfig, values) {
 
 async function templateDestinationPaths() {
   const template = join(packageRoot, "template");
-  return (await collectFiles(template)).map((source) => {
+  return (await collectFiles(template)).flatMap((source) => {
     const templatePath = relative(template, source);
-    return templatePath === "gitignore" ? ".gitignore" : templatePath;
+    if (templatePath === "README.md") return [];
+    if (templatePath === "WORKSPACE.md") return ["README.md"];
+    return [templatePath === "gitignore" ? ".gitignore" : templatePath];
   });
 }
 
@@ -177,7 +188,10 @@ async function copyTemplate(target) {
   const template = join(packageRoot, "template");
   for (const source of await collectFiles(template)) {
     const templatePath = relative(template, source);
-    const destinationPath = templatePath === "gitignore" ? ".gitignore" : templatePath;
+    if (templatePath === "README.md") continue;
+    const destinationPath = templatePath === "WORKSPACE.md"
+      ? "README.md"
+      : templatePath === "gitignore" ? ".gitignore" : templatePath;
     const destination = join(target, destinationPath);
     await assertNoSymlinkComponents(target, destinationPath);
     await mkdir(dirname(destination), { recursive: true });
@@ -202,13 +216,13 @@ async function collectFiles(directory) {
 async function writeMinimalLockfile(target, name, versionRange) {
   const lock = {
     name,
-    version: "0.1.0",
+    version: "0.2.0",
     lockfileVersion: 3,
     requires: true,
     packages: {
       "": {
         name,
-        version: "0.1.0",
+        version: "0.2.0",
         dependencies: { filegrc: versionRange }
       }
     }

package/template/AGENTS.md

@@ -12,11 +12,13 @@ Do not guess a resource type, field name, enum value, relationship, or file path
 
 ```sh
 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
 ```
 
-The first command lists every supported action and record type. The type guide gives the purpose, policy basis, timing, required and conditional fields, current relationship candidates, JSON location, and Markdown slots.
+`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.
 
 For a new record, generate a mutation envelope:
 
@@ -93,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, recurring obligations, event checklists, and bulk evidence preparation, then collects the initial service boundary, owner, business criticality, highest data classification, internet exposure, and optional audit objective. It creates or updates a `system` record and may create a planned `audit` record. Treat both as drafts to review against actual scope.
+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.
 
 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.
 
@@ -105,15 +107,15 @@ The generated workspace starts with the SOC 2 Security category:
 - The 33 Common Criteria reference IDs from CC1.1 through CC9.2, without the licensed criteria text
 - The nine Description Criteria reference IDs from DC1 through DC9, without the licensed criteria text
 - Planned controls mapped to those references and the included policies
-- A security and risk oversight team chaired by an external independent reviewer
+- A security and risk oversight team chaired by an independent reviewer who may be internal or external
 - 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, scope, operation, and evidence match actual practice. 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. 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.
+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.
 
-## Policy work queue
+## Work Queue and Policy Events
 
 Run the same obligation planner used by the web app:
 
@@ -122,7 +124,9 @@ npx filegrc obligations --json
 npx filegrc obligations --from 2026-01-01 --through 2026-12-31 --complete --json
 ```
 
-A calendar obligation’s recurrence anchor starts its first allowed cycle. Unless `window` narrows that range, completion is allowed from the cycle start through the day before the next cycle, and the item becomes overdue on the next cycle’s first day. Use **Record work** in the obligation board, or create and link a completion atomically with:
+Work Queue includes recurring obligations, Policy Event tasks, and every other open Action Item. Create an Action Item only when follow-up from a Finding, Risk, Incident, review, test, meeting, Exception, or request needs its own assignee, deadline, and completion proof. Point `sourceResourceId` to the record that produced the task. Use that source record’s Markdown for the report and observations.
+
+A calendar obligation’s recurrence anchor starts its first allowed cycle. Unless `window` narrows that range, completion is allowed from the cycle start through the day before the next cycle, and the item becomes overdue on the next cycle’s first day. Use **Record work** in Work Queue, or create and link a completion atomically with:
 
 ```sh
 npx filegrc complete obligation-id completion-record.json
@@ -130,14 +134,14 @@ npx filegrc complete obligation-id completion-record.json
 
 Keep prior completion links because the planner matches each dated record to its own period.
 
-Event obligations are templates. Do not mark a template complete or replace it for each occurrence. Start a workflow in the obligation board or run:
+Event obligations are templates. Do not mark a template complete or replace it for each occurrence. Use Trigger Work on Step 5 or run:
 
 ```sh
 npx filegrc trigger person-started --occurred-on 2026-07-25 --subject person-new-worker --json
 npx filegrc trigger person-ended --occurred-at 2026-07-25T16:30:00-05:00 --subject person-departing-worker --json
 ```
 
-The command creates one `obligation-event` and its complete action checklist in a single validated write. 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:
 
@@ -159,9 +163,34 @@ npx filegrc content risk-assessment risk-assessment-2026 --write updated-assessm
 
 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
+
+Prepare the management program before creating an audit engagement:
+
+```sh
+npx filegrc program-readiness
+npx filegrc program-readiness --require-ready --json
+```
+
+The Evidence Ready gate requires:
+
+1. A management goal, selected systems, criteria, and controls.
+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.
+
+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.
+
 ## Audit preparation and evidence packets
 
-After setting a Type 1 as-of date or Type 2 period, initialize the engagement-specific management work:
+After engaging a CPA firm, create one audit record and set the firm-agreed Type 1 date or Type 2 period. Then initialize the engagement-specific management work:
 
 ```sh
 npx filegrc prepare-audit audit-2026-type-2
@@ -169,11 +198,20 @@ npx filegrc audit-readiness audit-2026-type-2
 npx filegrc audit-readiness audit-2026-type-2 --require-ready --json
 ```
 
+The audit record’s `typeOneAsOf`, `periodStart`, and `periodEnd` are the dates agreed with the CPA firm. Keep the workspace candidate dates even when the formal period differs.
+
 Preparation creates a separate system description, management assertion, and management representation document for the engagement from the local starter templates. Type 2 preparation also creates a period completeness statement and one `audit-population` record for each standard population. It is safe to run again and does not approve documents, mark controls implemented, or create evidence. Do not reuse one completed management document across engagements.
 
+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.
+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.
+
 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`. Name the people who can access its 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.
+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.
 
@@ -185,7 +223,7 @@ 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 period operating records, recurring obligation occurrences, event workflows, and management population reconciliations. Output includes a control matrix, 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.
 
@@ -195,11 +233,13 @@ Link a control test to its `audit-population` record when sampling applies. Link
 
 The seed policy owner is {{policy_owner_name}} and the reporting address is {{security_contact_email}}. Replace ownership or contacts when responsibilities change.
 
-The starter requires an external independent reviewer for SOC 2 oversight. This person must be separate from the policy owner and must not operate the controls they review. They chair Security and Risk Oversight and approve policies and governed documents. A one-person company must appoint a qualified person outside the company before approving the program. Do not use the audit firm for management or approval work without first confirming the firm's independence requirements.
+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.
+
+The management reviewer and CPA auditor are different roles. Do not assign the CPA firm management or approval work without first confirming the firm's independence requirements.
 
 Policy and training attestations must identify the exact Git revision of the content that a person acknowledged. Store signatures as evidence attachments and link their evidence IDs from the attestation.
 
-Committee and risk meeting minutes are `meeting` resources with a primary Markdown companion. An optional `-agenda.md` companion holds the agenda. Record attendees, decisions, risks discussed, and action item IDs. Keep action tracking in `action-item` records.
+Committee and risk meeting minutes are `meeting` resources with a primary Markdown companion. An optional `-agenda.md` companion holds the agenda. Record attendees, decisions, and risks discussed on the Meeting. When follow-up needs separate tracking, create an `action-item` whose `sourceResourceId` points to the Meeting.
 
 ## Audit evidence
 

package/template/README.md

@@ -2,7 +2,7 @@
 
 Run a SOC 2 program as files in Git.
 
-FileGRC gives a founder-led engineering team one place to adopt policies, track recurring compliance work, respond to company events, 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.
 
@@ -15,9 +15,10 @@ SOC 2 work tends to scatter across documents, calendars, tickets, screenshots, a
 FileGRC keeps that work connected:
 
 - A starter Security program links criteria references, policies, planned controls, owners, and schedules.
-- The obligation board turns policy timing into upcoming, due, and overdue work.
-- Event checklists cover hiring, departures, vendor changes, incidents, and other policy triggers.
-- Audit Readiness says what management work, source-system exports, and evidence are still missing.
+- Work Queue turns policy timing into upcoming, due, and overdue work.
+- Policy Events add the required hiring, departure, vendor, incident, and change tasks to the Work Queue.
+- Program Readiness says whether management can begin a candidate Type 2 evidence period without an audit record.
+- Audit Readiness starts later with the CPA engagement, formal period, fieldwork documents, populations, and evidence delivery.
 - The packet builder produces a scoped, indexed delivery with source files, attachments, history, and checksums.
 
 The starter content is a proposal, not a claim of compliance. Review every policy and planned control against how your company actually operates before approving it.
@@ -33,35 +34,42 @@ 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 helps define the service boundary, an independent approver, and an optional audit goal.
+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.
 
 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.
+
 ## How it works
 
-1. Add or edit compliance artifacts under `data/`.
-2. FileGRC validates relationships, renders the current program, and calculates policy work.
-3. Commit focused changes with a message that explains why the records changed.
-4. Git preserves the author, time, message, diff, and prior version.
-5. For an audit, define the Type 1 date or Type 2 period and generate an evidence packet from the selected revision.
+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.
 
 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.
 
+Third-party software is usually both a System and a Vendor. The application is the System because it operates controls and produces evidence. The provider is the Vendor because contracts, due diligence, and supplier risk belong to that relationship. Link the System to the Vendor with `vendorId`, and link exported evidence to the System.
+
 ## Run the program
 
-Use Overview to follow the audit chain: scope, criteria, policies, controls, operation, and audit. The sidebar follows the same order.
+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 Obligation Board for recurring work and event checklists. Each item shows its allowed completion window and overdue cutoff, based on the policy that created it. Link a dated completion record and evidence to close the occurrence.
+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 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.
+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.
 
 Agents use the same logic headlessly:
 
 ```sh
 npx filegrc guide risk-assessment --json
+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 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
@@ -69,15 +77,28 @@ npx filegrc complete-event obligation-event-id --completed-on 2026-07-25
 npx filegrc search "access review"
 ```
 
-`guide` reports the policy context, timing, required fields, valid values, relationship candidates, and Markdown locations for every resource type. `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. `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
+
+Program Readiness works without an audit ID or CPA firm:
+
+```sh
+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.
+
+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
 
-Record the audit firm, scope, and exact date or period. Audit Readiness then checks management-owned preparation, including the system description, assertion, policy and control state, source systems, 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)
 
-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 packages the selected records, Markdown, fixed attachments, historical versions, indexes, 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
@@ -87,6 +108,8 @@ 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.
 
+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.

package/template/WORKSPACE.md

@@ -0,0 +1,41 @@
+# {{company_name}} SOC 2 Program
+
+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}}`.
+
+## Work locally
+
+You need Node.js 20 or newer and Git.
+
+```sh
+npm install
+npm run validate
+npm run serve
+```
+
+The editable server binds to loopback by default and has no authentication. Do not expose it to an untrusted network.
+
+Agents and terminal users can inspect the workspace without the browser:
+
+```sh
+npx filegrc guide --json
+npx filegrc program-path --json
+npx filegrc obligations --json
+npx filegrc validate --json
+```
+
+Read `AGENTS.md` and `data/AGENTS.md` before broad changes.
+
+## Finish initial 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.

package/template/data/AGENTS.md

@@ -8,13 +8,14 @@ Treat the installed model as the authority. Do not infer a schema from a nearby
 
 ```sh
 npx filegrc guide --json
+npx filegrc program-path --json
 npx filegrc types --json
 npx filegrc guide RESOURCE_TYPE --json
 npx filegrc list RESOURCE_TYPE --json
 npx filegrc search "TERM" --json
 ```
 
-Use `guide` before any unfamiliar create or status transition. It reports required fields, fields required by a status, enum values, relationship types and candidates, Markdown slots, policy context, timing, and exact paths. Use `describe` only when you need the raw model definition.
+Use `program-path` to find the current lifecycle step and see the renderer’s exact page Instructions, Use, Policy Basis, commands, and next actions. Use `guide` before any unfamiliar create or status transition. It repeats the page guidance and reports required fields, fields required by a status, enum values, relationship types and candidates, Markdown slots, timing, and exact paths. Use `describe` only when you need the raw model definition.
 
 ## Choose the right record
 
@@ -23,7 +24,7 @@ Use `guide` before any unfamiliar create or status transition. It reports requir
 - 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`.
-- Proof belongs in `evidence`, not in 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`.
 
@@ -90,7 +91,7 @@ Never replace a complete record with a partial JSON object. Never change `id` or
 
 JSON is for stable metadata used by validation, relationships, filters, schedules, and audit checks. Markdown is for the actual work: inputs, method, observations, results, rationale, decisions, exceptions, and follow-up.
 
-If `guide` marks a Markdown slot recommended, fill it before treating the deliverable as complete. Link evidence and resulting risks, findings, exceptions, or action items in JSON. Do not put a report’s entire variable structure into new JSON fields.
+If `guide` marks a Markdown slot recommended, fill it before treating the deliverable as complete. Keep observations and report details in the source record’s Markdown. Create a Finding only for a confirmed gap that needs its own remediation lifecycle. Create an Action Item only when follow-up needs a separate assignee, deadline, and completion proof. Set each child record’s `sourceResourceId` to the record that produced it; do not maintain reverse Finding or Action Item arrays on the source. Do not put a report’s entire variable structure into new JSON fields.
 
 Use explicit business dates. Git records when a file changed, but it does not replace `occurredOn`, `assessmentDate`, `reviewedOn`, `completedOn`, or similar fields.
 
@@ -161,17 +162,18 @@ npx filegrc complete-action ACTION_ITEM_ID completion-mutation.json --completed-
 npx filegrc complete-event OBLIGATION_EVENT_ID --completed-on YYYY-MM-DD
 ```
 
-`complete` and `complete-action` validate the expected completion type and link the new record atomically. `complete-event` refuses to close the workflow until every action has its requested proof. For hour-based deadlines use `--occurred-at` with an RFC 3339 timestamp and timezone.
+Run `obligations` before `trigger` to preview every Policy Event task, owner, deadline, and requested proof. Triggering creates the event and adds all linked Action Items to the Work Queue atomically. `complete` and `complete-action` validate the expected completion type and link the new record atomically. `complete-event` refuses to close the workflow until every action has its requested proof. For hour-based deadlines use `--occurred-at` with an RFC 3339 timestamp and timezone.
 
 ## Audit work
 
 ```sh
+npx filegrc program-readiness --json
 npx filegrc prepare-audit AUDIT_ID
 npx filegrc audit-readiness AUDIT_ID --json
 npx filegrc evidence-packet --audit AUDIT_ID --preview --json
 ```
 
-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
 
-An action item must point to the record that created the work. 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 and the completion record or evidence is linked. 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

@@ -1,6 +1,10 @@
 # Audit Instructions
 
-Create one `audit` record for one engagement. Define the audit kind, framework, exact Type 1 date or Type 2 period, scope, owners, auditor, and report status from facts supplied by management or the engagement team.
+Create one `audit` record for one real CPA engagement. Define the audit kind, framework, exact firm-agreed Type 1 date or Type 2 period, scope, owners, auditor, and report status from facts supplied by management or the engagement team.
+
+Keep management’s candidate Type 2 dates on `workspace`. Do not copy them into the audit record until the CPA firm agrees to those dates. Preserve both sets when the formal period differs.
+
+The normal path is to pass `npx filegrc program-readiness --require-ready` and start reliable evidence collection before engaging the firm. Early engagement is allowed when a customer deadline or unusual scope needs CPA input.
 
 After the audit record has its dates:
 
@@ -11,6 +15,13 @@ npx filegrc audit-readiness AUDIT_ID --json
 
 Preparation creates engagement-specific management documents and, for Type 2, population records. It does not approve documents, implement controls, reconcile populations, or create evidence.
 
+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.
+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.
+
 Run readiness repeatedly and fix source records. Preview the packet before writing it:
 
 ```sh

package/template/data/evidence/AGENTS.md

@@ -1,7 +1,9 @@
-# Evidence Instructions
+# External Evidence Instructions
 
 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.
+
 ## Create evidence
 
 1. Run `npx filegrc guide evidence --json`.

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

@@ -1,13 +1,13 @@
 # Policy Event Instructions
 
-Do not create an `obligation-event` or its action items by hand. Start the configured checklist:
+Do not create an `obligation-event` or its Action Items by hand. Preview the configured Policy Event, then trigger its work:
 
 ```sh
 npx filegrc obligations --json
 npx filegrc trigger EVENT_TYPE --occurred-on YYYY-MM-DD --subject RESOURCE_ID --json
 ```
 
-Use `--occurred-at` with an RFC 3339 timestamp when any action has an hour-based deadline. The command creates the event and full action checklist atomically.
+The obligations output lists every task the trigger will add, with its owner, deadline, and requested proof. Use `--occurred-at` with an RFC 3339 timestamp when any action has an hour-based deadline. The trigger creates the event and adds all Action Items to the Work Queue atomically, then reports the event, task count, task IDs, and deadlines.
 
 Complete each action with the requested resource type and proof. Then close the workflow:
 

package/template/data/obligations/AGENTS.md

@@ -5,7 +5,8 @@ An obligation is a reusable policy schedule or event template. It is not the rec
 - Calendar obligations need a valid recurrence anchor, owners, expected completion types, and policy or control links.
 - Event obligations need a stable lowercase `eventType`, a prompt, owners, expected completion types, and an explicit deadline window.
 - Keep completed occurrences in `completionResourceIds`. Do not replace prior links when a new period starts.
+- Keep starter obligations as proposals until every governing policy is active and effective and, when the obligation names controls, at least one linked control is implemented.
 - When an approved cadence changes, update the policy, control, and obligation together.
 - Pause or retire a template only when the underlying policy work no longer applies. Do not delete historical templates that explain prior periods.
 
-Use `npx filegrc obligations --json` to inspect calculated work. Use `npx filegrc complete OBLIGATION_ID completion-mutation.json` to create and link a dated occurrence in one validated write.
+Use `npx filegrc obligations --json` to inspect calculated recurring work and preview every Policy Event task, owner, deadline, and requested proof. Use `npx filegrc complete OBLIGATION_ID completion-mutation.json` to create and link a dated occurrence in one validated write. Use `npx filegrc trigger EVENT_TYPE ...` only after the matching event occurs; it adds all configured Action Items to the Work Queue atomically.

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

@@ -2,9 +2,8 @@
   "schemaVersion": 1,
   "id": "person-independent-approver",
   "type": "person",
-  "title": "Independent Approver",
-  "status": "external",
-  "role": "External Security and Risk Oversight Reviewer",
-  "employmentType": "external-reviewer",
+  "title": "Independent Reviewer",
+  "status": "active",
+  "role": "Security and Risk Oversight Reviewer",
   "teamIds": ["team-security-risk-oversight"]
 }

package/template/data/policies/AGENTS.md

@@ -2,7 +2,7 @@
 
 Policies state required behavior. Controls, obligations, training, attestations, and evidence show how the organization applies that behavior.
 
-Use the `content` Markdown slot for the policy text. Keep ownership and approval metadata in JSON. The approver must be separate from the owner, including through team membership, and must not operate the controls they review.
+Use the `content` Markdown slot for the policy text. Keep ownership and approval metadata in JSON. The approver must be separate from the owner, including through team membership. The reviewer will usually be another leader or manager in the organization, but may be external.
 
 Keep a policy `draft` until its text, owner, scope, related requirements and controls, approval, effective date, review cadence, and acknowledgement requirement match actual practice. When activating it:
 
@@ -12,4 +12,6 @@ Keep a policy `draft` until its text, owner, scope, related requirements and con
 4. Update or create its recurring and event obligations.
 5. Assign training or attestations when the policy requires them.
 
+The independent policy approver is a management reviewer, not the CPA auditor. Appoint the reviewer during policy adoption. Recurring and event obligations linked to the policy remain proposals until the policy is active and effective and, when they name controls, at least one linked control is implemented.
+
 For a material revision, preserve Git history, obtain a new approval, and require a new acknowledgement when the audience’s responsibilities changed. Do not reuse the audit firm as a management approver without confirming independence.

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

@@ -26,9 +26,9 @@ The policy owner:
 - Coordinates incidents, exercises, reviews, and audit work.
 - Approves security exceptions or obtains the required approval.
 
-An external independent reviewer chairs the security and risk oversight group. This person must be separate from the policy owner and must not operate the controls under review. The reviewer approves policies and governed plans, challenges management's assessment of control operation, and records independent decisions.
+An independent reviewer chairs the security and risk oversight group. This person must be separate from the policy owner and able to challenge the owner's decisions. The reviewer will usually be another leader or manager in the organization, but may be external. The reviewer approves policies and governed plans, challenges management's assessment of control operation, and records independent decisions.
 
-The security and risk oversight group meets at least quarterly to review the risk register, material incidents, significant findings, vendor and access review results, policy changes, exercises, and overdue work. Each meeting has formal minutes, decisions, and assigned actions. A one-person company must appoint a qualified external person to fill the independent reviewer role before it approves the program.
+The security and risk oversight group meets at least quarterly to review the risk register, material incidents, significant findings, vendor and access review results, policy changes, exercises, and overdue work. Each meeting has formal minutes, decisions, and assigned actions. A one-person company must appoint a qualified external person to fill the independent reviewer role because no second internal person is available.
 
 System and process owners classify their systems and data, approve access, maintain safeguards, respond to findings, and keep recovery information current.
 
@@ -230,4 +230,4 @@ Violations may result in access removal, corrective action, contract remedies, o
 
 ## Review
 
-The policy owner reviews this policy at least annually and after a material change to systems, services, risks, or obligations. The external independent reviewer, who must be separate from the policy owner, approves this policy and other governed policies and plans. The security and risk oversight group reviews material changes and records its decision in meeting minutes. Git history records approvals and changes.
+The policy owner reviews this policy at least annually and after a material change to systems, services, risks, or obligations. An independent reviewer who is separate from the policy owner approves this policy and other governed policies and plans. The reviewer may be internal or external. The security and risk oversight group reviews material changes and records its decision in meeting minutes. Git history records approvals and changes.

package/template/data/renderer.json

@@ -3,5 +3,6 @@
   "id": "renderer-settings",
   "type": "renderer-settings",
   "title": "Renderer settings",
-  "showOnboarding": true
+  "showOnboarding": true,
+  "completedStagePageIds": []
 }

package/template/data/risk-assessments/AGENTS.md

@@ -9,7 +9,7 @@ Use a `risk-assessment` for the dated assessment process and one `risk` record f
 3. Scaffold the assessment and keep it `planned` or `in-progress` while the work is underway.
 4. Write the method, inputs reviewed, threats considered, observations, decisions, and conclusion in Record Markdown.
 5. Create or update the individual `risk` records. Link all risks considered with `riskIds`, newly identified risks with `newRiskIds`, and materially changed risks with `changedRiskIds`.
-6. Link evidence, findings, and follow-up action items. Do not hide an unresolved issue in the narrative.
+6. Link evidence from the assessment. When a confirmed gap needs its own lifecycle, create a Finding whose `sourceResourceId` points to this assessment. Create an Action Item only for separately assigned follow-up. Do not hide an unresolved issue in the narrative.
 7. Use a reviewer who is not one of the assessors. Set `methodology` and `approvedOn` before marking the assessment `complete`.
 8. Run validation, review the full diff, and commit the assessment, risk changes, and evidence together when practical.
 

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

@@ -1,6 +1,6 @@
 # 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, event checklists, 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
 

package/template/package.json

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

package/template-parameters.json

@@ -26,6 +26,10 @@
       "key": "project_name",
       "source": "target-directory-name"
     },
+    {
+      "key": "filegrc_version",
+      "source": "resolved-filegrc-version"
+    },
     {
       "key": "filegrc_version_range",
       "source": "resolved-filegrc-version"