filegrc 0.3.4 → 0.5.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/src/parties.js CHANGED
@@ -1,5 +1,6 @@
1
- const CURRENT_PERSON_STATUSES = new Set(["active", "external"]);
1
+ const CURRENT_PERSON_STATUSES = new Set(["active"]);
2
2
  const CURRENT_TEAM_STATUSES = new Set(["active"]);
3
+ const CURRENT_APPOINTMENT_STATUSES = new Set(["active"]);
3
4
 
4
5
  export function partyPeople(ids = [], byId, options = {}, seen = new Set()) {
5
6
  const people = new Set();
@@ -26,6 +27,19 @@ export function partyPeople(ids = [], byId, options = {}, seen = new Set()) {
26
27
  people.add(personId);
27
28
  }
28
29
  }
30
+ if (
31
+ record?.type === "appointment"
32
+ && (!options.appointmentStatuses || options.appointmentStatuses.has(record.status))
33
+ ) {
34
+ for (const personId of partyPeople(
35
+ [record.holderId],
36
+ byId,
37
+ options,
38
+ seen
39
+ )) {
40
+ people.add(personId);
41
+ }
42
+ }
29
43
  }
30
44
  return people;
31
45
  }
@@ -33,7 +47,8 @@ export function partyPeople(ids = [], byId, options = {}, seen = new Set()) {
33
47
  export function currentPartyPeople(ids = [], byId) {
34
48
  return partyPeople(ids, byId, {
35
49
  personStatuses: CURRENT_PERSON_STATUSES,
36
- teamStatuses: CURRENT_TEAM_STATUSES
50
+ teamStatuses: CURRENT_TEAM_STATUSES,
51
+ appointmentStatuses: CURRENT_APPOINTMENT_STATUSES
37
52
  });
38
53
  }
39
54
 
@@ -1,6 +1,7 @@
1
1
  import { currentPartyPeople } from "./parties.js";
2
2
 
3
3
  export function obligationProgramStatus(obligation, byId, asOf) {
4
+ if (obligation.status !== "active") return "proposed";
4
5
  if (currentPartyPeople(obligation.ownerIds || [], byId).size === 0) return "proposed";
5
6
  const policyIds = obligation.policyIds || [];
6
7
  const policiesReady = policyIds.every((id) => {
@@ -1,18 +1,19 @@
1
1
  export const RESOURCE_INSTRUCTIONS = {
2
- person: "Confirm the policy owner created during setup, then add the actual people who will approve, review, or operate the program.",
3
- team: "Review the starter Security and Risk Oversight team, including its members and chair. Add another team only when the organization assigns shared responsibility to it.",
4
- system: "Catalog all in-scope systems for the program. Treat anything that operates a control or produces evidence as a System, including software provided by a vendor (like HR software).",
5
- vendor: "Catalog the companies that provide in-scope software or services. Link each vendor-provided System to the company that provides it.",
2
+ person: "Record each person’s actual organizational job title. Keep named program authority, such as CISO, DPO, Policy Owner, or team chair, in dated Appointment records.",
3
+ appointment: "Record one person’s dated appointment to a named organizational or program responsibility. Scope it to the workspace, a team, or the records governed by that appointment.",
4
+ team: "Review the starter Security and Risk Oversight team, including its members and chair. Membership and chairs are authoritative on the Team record.",
5
+ system: "Catalog all in-scope systems for the program. Treat anything that operates a control or produces evidence as a System, including software provided by a vendor (like HR software). Set vendorId on each vendor-provided System; the Vendor’s System list is derived. For every authoritative evidence source, set its source roles, name current access owners, and write repeatable retrieval instructions in Record Markdown before implementing the linked Controls.",
6
+ vendor: "Catalog the companies that provide in-scope software or services. Link each vendor-provided System with the System’s vendorId.",
6
7
  framework: "Confirm the criteria framework and version used for the program.",
7
8
  requirement: "Review each criterion, decide whether it applies, and record the reason for that decision.",
8
- commitment: "Record supplemental customer promises and service requirements that shape the scope or control design.",
9
- policy: "Tailor each policy to match how the organization works. Clear placeholders, assign an owner and separate approver, then record its approval and effective dates.",
9
+ commitment: "Record supplemental customer promises and service requirements that shape the scope or control design. The Commitment’s systemIds and controlIds are authoritative for what fulfills it.",
10
+ policy: "Tailor each policy to match how the organization works. Clear placeholders, assign an owner and separate approver, then record its approval and effective dates. Controls link to their governing Policies.",
10
11
  document: "Tailor the governed plans and other supporting documents the program needs. Assign owners and approvers, then keep the approved Markdown in Git.",
11
- control: "Finish each applicable starter control with the procedure people will follow, its owner, scope, cadence, evidence source, and implementation date.",
12
- "complementary-control": "Record anything customers or carved-out providers must do for your controls to work as intended.",
13
- evidence: "Complete the generated tests for external evidence that has no dedicated Step 5 record. Link each result to its Control and source System, then have another person verify it. When a Step 5 operating record exists, link the artifact’s External Evidence record there instead.",
12
+ control: "Finish each applicable starter control with the procedure people will follow, its owner, scope, operation pattern, governing Policy and Requirement mappings, authoritative evidence source Systems, and implementation date. Put calendar and event schedules in Obligations. Confirm that each source is active, has the required evidence role and access owners, and includes repeatable retrieval instructions in Record Markdown.",
13
+ "complementary-control": "Review whether any in-scope Control depends on a customer or carved-out provider action. Record each real dependency, or confirm that the current scope has none.",
14
+ evidence: "Create External Evidence when a real export, report, screenshot, signed file, or approved external reference exists. Select its authoritative source System, link the Controls and operating record it supports, retain the fixed artifact or reference, and have another person verify it before audit use.",
14
15
  "risk-assessment": "Complete and approve an assessment of the risks to the in-scope service, systems, vendors, and commitments.",
15
- risk: "Record each risk identified by an assessment or operating activity. Assign an owner, rate it, and document the chosen response.",
16
+ risk: "Record each risk identified by an assessment or operating activity. Assign an owner, rate it, document the chosen response, and link the Controls that treat it from the Risk record.",
16
17
  obligation: "Review the recurring work proposed by effective policies. Confirm who owns it, when it is due, and what proof completion requires.",
17
18
  "obligation-event": "When a policy-triggering event occurs, record it here and complete the actions filegrc creates for it.",
18
19
  "policy-review": "Record scheduled and change-driven reviews of policies and governed documents, including the decision and any follow-up.",
@@ -33,46 +34,54 @@ export const RESOURCE_INSTRUCTIONS = {
33
34
  exercise: "Record each incident or continuity exercise, including its objective, participants, result, and follow-up.",
34
35
  finding: "Create a Finding only for a confirmed gap that needs separate remediation tracking. Keep the report details in the source record’s Markdown, then assign the Finding, set its due date, and verify closure.",
35
36
  "action-item": "Create an Action Item only when follow-up needs its own assignee, deadline, and completion proof. Point it to the record that created the work, then work it from Work Queue.",
36
- audit: "Create this record after engaging the CPA firm, then record the agreed scope, criteria, Systems, and report period.",
37
- "audit-request": "Record each request from the audit team, assign an owner and due date, and link the approved response and evidence.",
37
+ audit: "Create this record after engaging the CPA firm, then record the agreed scope, criteria, Systems, and report period. Control Tests and External Evidence link back with auditId or auditIds.",
38
+ "audit-request": "When FileGRC is the approved request tracker, record each request from the audit team, assign an owner and due date, and link the approved response and evidence.",
38
39
  "data-request": "Record privacy or contractual requests when they apply to the audit scope or the organization’s commitments.",
39
- "control-test": "Record how an in-scope control was tested, what was sampled, the result, and any exceptions.",
40
+ "control-test": "Record a management Control Test only when management performs and reviews one. The CPA firm records its own independent testing separately.",
40
41
  "audit-population": "Record each complete Type 2 population with its source System, fixed export, query, count, and reconciliation."
41
42
  };
42
43
 
43
- export const POLICY_EVENT_NAMES = {
44
- "person-started": "New Worker",
45
- "person-ended": "Worker Departure",
46
- "high-risk-person-ended": "High-Risk Departure",
47
- "person-role-changed": "Role Change",
48
- "personal-device-access-planned": "Personal Device Access",
49
- "vendor-access-planned": "Vendor Access",
50
- "vendor-reassessment-needed": "Vendor Reassessment",
51
- "system-material-change": "Material System Change",
52
- "material-incident": "Material Incident"
44
+ export const RESOURCE_PAGE_SUMMARIES = {
45
+ person: "Confirm who participates in the program.",
46
+ appointment: "Assign named program authority to the right people.",
47
+ team: "Confirm shared program responsibilities and membership.",
48
+ framework: "Confirm the SOC 2 criteria framework.",
49
+ requirement: "Decide which criteria apply to the service.",
50
+ commitment: "Record customer promises that affect scope or controls.",
51
+ vendor: "Identify providers that affect the service or its controls.",
52
+ system: "Define the service boundary and the Systems that operate controls or produce evidence.",
53
+ policy: "Turn starter policies into the organization’s approved rules.",
54
+ document: "Tailor and approve the plans and governed documents the program needs.",
55
+ control: "Define how each applicable control works and where its evidence comes from.",
56
+ "complementary-control": "Record customer or provider responsibilities, or confirm there are none.",
57
+ audit: "Record the real CPA engagement and agreed report scope.",
58
+ "audit-request": "Track approved fieldwork requests and responses.",
59
+ "audit-population": "Prepare complete Type 2 populations for sampling.",
60
+ "control-test": "Record management testing when management performs it."
53
61
  };
54
62
 
55
- export function policyEventName(eventType) {
56
- return POLICY_EVENT_NAMES[eventType] || humanize(eventType);
57
- }
58
-
59
63
  export const PROGRAM_PATH = [
60
64
  {
61
65
  id: "scope",
62
66
  number: 1,
63
67
  title: "Define Scope",
64
68
  description: "Ownership, criteria, and service boundary",
65
- summary: "Confirm the people and teams responsible for the program, set the management goal, review the criteria and customer commitments in scope, then define the customer-facing service, supporting systems, and supplier dependencies.",
69
+ summary: "Set program ownership, choose the criteria, and define the service, Systems, and providers in scope.",
66
70
  sections: [
67
- { id: "ownership", title: "Program Ownership", description: "Confirm the people and teams that own, approve, review, and operate the program.", steps: ["Confirm the policy owner created during setup, then add the organization’s actual reviewers and operators.", "Review the starter Security and Risk Oversight team, its members, and its chair.", "Add other teams only when the organization assigns shared responsibility to them."], types: ["person", "team"], defaultOpen: true },
71
+ { id: "ownership", title: "Program Ownership", description: "Confirm the people, appointments, and teams that own, approve, review, and operate the program.", steps: ["Confirm the initial program lead’s actual job title and the separate Policy Owner Appointment.", "Add the organization’s real appointments, reviewers, and operators.", "Review the starter Security and Risk Oversight team, its members, and its chair.", "Add other teams only when the organization assigns shared responsibility to them."], types: ["person", "appointment", "team"], defaultOpen: true },
68
72
  { id: "criteria", title: "Criteria", description: "Confirm the criteria used for the program, resolve whether each requirement applies, and record customer commitments that shape the service or control design.", steps: ["Review the included Security criteria references.", "Mark each requirement applicable or not applicable with a rationale.", "Record customer commitments and keep optional criteria out until management deliberately adds them."], types: ["framework", "requirement", "commitment"], defaultOpen: true },
69
- { id: "boundary", title: "Service Boundary", description: "Record the service and its supporting technology and providers. An application or platform is a System because it operates controls or produces evidence; the company providing it is a Vendor because contracts, due diligence, and supplier risk belong to that relationship.", steps: ["Create a Vendor record for each material provider.", "Create System records for the customer-facing service and each supporting application, platform, or internal system that is in scope or produces evidence, then connect vendor-provided Systems to their providers.", "Assign owners, classification, dependencies, and a clear in-scope decision to each System, and keep supplier reviews with the Vendor."], types: ["vendor", "system"], defaultOpen: false }
73
+ { id: "boundary", title: "Service Boundary", description: "Record the service and its supporting technology and providers. An application or platform is a System because it operates controls or produces evidence; the company providing it is a Vendor because contracts, due diligence, and supplier risk belong to that relationship.", steps: ["Create a Vendor record for each material provider.", "Create System records for the customer-facing service and each supporting application, platform, or internal system that is in scope or produces evidence, then connect vendor-provided Systems to their providers.", "Assign owners, classification, and dependencies, then select the program-scope Systems on the Workspace.", "For Systems that produce control evidence, add their evidence source roles and access owners, then write the exact retrieval procedure in Record Markdown before implementing the linked Controls."], types: ["vendor", "system"], defaultOpen: false }
70
74
  ],
71
- resourceTypes: ["person", "team", "framework", "requirement", "commitment", "vendor", "system"],
75
+ resourceTypes: ["person", "appointment", "team", "framework", "requirement", "commitment", "vendor", "system"],
72
76
  commands: [
73
77
  "filegrc setup",
74
78
  "filegrc guide person --json",
79
+ "filegrc guide appointment --json",
75
80
  "filegrc guide system --json",
81
+ "filegrc review-collection person --scaffold",
82
+ "filegrc review-collection framework --scaffold",
83
+ "filegrc review-collection vendor --scaffold",
84
+ "filegrc review-collection system --scaffold",
76
85
  "filegrc list system --json"
77
86
  ]
78
87
  },
@@ -81,9 +90,9 @@ export const PROGRAM_PATH = [
81
90
  number: 2,
82
91
  title: "Approve Policies",
83
92
  description: "Tailor, review, approve, and adopt",
84
- summary: "Turn every applicable policy and governed plan into the organization’s actual rules, remove placeholders, link governed controls, and establish approval and effective dates before scheduled work begins. The reviewer must be separate from the owner, is usually internal, and may be external.",
93
+ summary: "Turn the starter policy set into approved rules that match how the organization works.",
85
94
  sections: [
86
- { id: "library", title: "Policy Library", description: "Review, approve, and activate policies and governed plans without treating starter text as adopted practice.", steps: ["Review policy Markdown and replace every organization placeholder.", "Confirm the owner, separate approver, audience, linked controls, and review cadence.", "Record approval and effective dates before changing the status to active."], types: ["policy", "document"], defaultOpen: true }
95
+ { id: "library", title: "Policy Library", description: "Review, approve, and activate policies and governed plans without treating starter text as adopted practice.", steps: ["Review policy Markdown and replace every organization placeholder.", "Confirm the owner, separate approver, audience, review Obligation, and Controls that point to the Policy.", "Record approval and effective dates before changing the status to active."], types: ["policy", "document"], defaultOpen: true }
87
96
  ],
88
97
  resourceTypes: ["policy", "document"],
89
98
  commands: [
@@ -96,44 +105,31 @@ export const PROGRAM_PATH = [
96
105
  id: "controls",
97
106
  number: 3,
98
107
  title: "Implement Controls",
99
- description: "Tailor and finish the starter control set",
100
- summary: "Review the starter catalog against the scoped service, then give every applicable internal control an actual procedure, owner, system scope, cadence, policy and criteria mappings, authoritative evidence source, and implementation date. Mark it implemented only after the procedure is operating, then record any controls that customers or carved-out providers must perform.",
108
+ description: "Finish controls and their evidence sources",
109
+ summary: "Define how each control works, where its evidence comes from, and whether customers or providers have responsibilities.",
101
110
  sections: [
102
- { id: "catalog", title: "Control Catalog", description: "Finish the starter controls, record applicable complementary controls, and see whether filegrc tracks operation through Work Queue or evidence records.", steps: ["Open every planned control and confirm its mappings and suggested frequency.", "Write the real procedure in Record Markdown and add system scope and evidence sources.", "Record any required customer or carved-out provider controls as Complementary Controls."], types: ["control", "complementary-control"], defaultOpen: true }
111
+ { id: "catalog", title: "Control Catalog", description: "Finish the starter controls and their authoritative evidence sources, record applicable complementary controls, and see whether filegrc tracks operation through Work Queue or evidence records.", steps: ["Open every planned Control and confirm its mappings and operation pattern.", "Write the real procedure in Record Markdown, add system scope, and map the exact authoritative evidence source Systems.", "Create or confirm every calendar and event schedule as an Obligation.", "Confirm each source System is active, has the required evidence role and current access owners, and includes repeatable retrieval instructions in Record Markdown.", "Resolve every incomplete evidence-family check before marking the Controls implemented.", "Record any required customer or carved-out provider controls as Complementary Controls."], types: ["control", "complementary-control"], defaultOpen: true }
103
112
  ],
104
113
  resourceTypes: ["control", "complementary-control"],
105
114
  commands: [
106
115
  "filegrc guide control --json",
107
116
  "filegrc list control --json",
108
- "filegrc get CONTROL_ID --mutation"
109
- ]
110
- },
111
- {
112
- id: "evidence",
113
- number: 4,
114
- title: "Test Evidence Collection",
115
- description: "Verify sources before the period starts",
116
- summary: "Before starting the candidate period, test external evidence collection only where no dedicated Step 5 operating record exists. When Step 5 already records the work, attach or reference the external artifact there instead of creating a separate test.",
117
- sections: [
118
- { id: "collection", title: "Collection Test", description: "Test external evidence collection only where no dedicated Step 5 operating record exists.", steps: ["Confirm that each externally evidenced control names an authoritative source System.", "Complete each generated test export or capture.", "When a Step 5 operating record exists, link the artifact’s External Evidence record there instead."], relatedLinks: [{ label: "Source Systems", href: "#/resources/system" }, { label: "Controls", href: "#/resources/control" }], types: ["evidence"], defaultOpen: true }
119
- ],
120
- resourceTypes: ["evidence"],
121
- commands: [
122
- "filegrc evidence-test-drafts --preview --json",
123
- "filegrc guide evidence --json",
124
- "filegrc list evidence --json",
117
+ "filegrc get CONTROL_ID --mutation",
118
+ "filegrc review-collection complementary-control --scaffold",
119
+ "filegrc evidence-map --json",
125
120
  "filegrc program-readiness --json"
126
121
  ]
127
122
  },
128
123
  {
129
124
  id: "run",
130
- number: 5,
125
+ number: 4,
131
126
  title: "Operate the Program",
132
127
  description: "Run the work and retain dated proof",
133
- summary: "Record the management candidate start date when reliable evidence collection begins. Maintain current risk assessments and risks, updating the control set when needed. Complete recurring and event-driven work, run continuous and per-transaction controls, and keep dated evidence current throughout the period.",
128
+ summary: "Run scheduled and event-driven work, maintain risk, and retain dated evidence throughout the operating period.",
134
129
  sections: [
135
130
  { id: "risk", title: "Risk", description: "Maintain the program’s risk assessments and risk register as the service, threats, suppliers, and control needs change.", steps: ["Complete and approve risk assessments on schedule and after material changes.", "Record risks that need treatment, acceptance, or ongoing tracking.", "Add or update controls when the assessment identifies a new or changed response."], types: ["risk-assessment", "risk"], defaultOpen: true },
136
131
  { id: "queue", title: "Work Queue", description: "Complete recurring work, Policy Event tasks, and assigned follow-up within their required windows.", steps: ["Review proposed work while policies are drafts.", "Complete due work within its allowed window and link dated proof.", "Start Policy Events when hiring, departures, incidents, or material changes occur; every other open Action Item appears here automatically."], types: ["obligation", "obligation-event", "data-request"], utility: "obligation-board", defaultOpen: true },
132
+ { id: "evidence", title: "External Evidence", description: "Create records only for real exports, reports, screenshots, signed files, or approved external references collected during operation.", steps: ["Create External Evidence when the artifact exists or an operating record needs fixed supporting proof.", "Select the authoritative source System, link the Controls and source operating record, and retain the fixed attachment or approved reference.", "Record the collector and classification, then have another person verify the evidence before audit use."], types: ["evidence"], defaultOpen: true },
137
133
  { id: "governance", title: "Governance", description: "Record formal reviews, oversight meetings, and approved policy or control exceptions.", steps: ["Complete scheduled policy reviews and oversight meetings.", "Record decisions, attendees, follow-up work, and evidence.", "Approve time-bound exceptions before the departure begins."], types: ["policy-review", "meeting", "exception"], defaultOpen: false },
138
134
  { id: "inventories", title: "Assets and Vendors", description: "Maintain the asset inventory and recurring reviews of supplier relationships during operation.", steps: ["Keep ownership, custody, status, and lifecycle current for important assets.", "Perform vendor reviews on schedule and after material supplier changes.", "Link fixed reports and review evidence to the operating records."], types: ["asset", "vendor-review"], defaultOpen: false },
139
135
  { id: "access-training", title: "Access and Training", description: "Inventory service accounts before recording access decisions, periodic reviews, assignments, and acknowledgements.", steps: ["Catalog service accounts that need separate tracking.", "Preserve access approvals and removals as they occur, then complete periodic access reviews and resolve exceptions.", "Assign training and retain acknowledgement evidence for the exact content revision."], types: ["service-account", "access-grant", "access-review", "training", "attestation"], defaultOpen: false },
@@ -147,6 +143,7 @@ export const PROGRAM_PATH = [
147
143
  "obligation",
148
144
  "obligation-event",
149
145
  "data-request",
146
+ "evidence",
150
147
  "policy-review",
151
148
  "meeting",
152
149
  "exception",
@@ -170,6 +167,7 @@ export const PROGRAM_PATH = [
170
167
  {
171
168
  id: "policy-events",
172
169
  title: "Policy Events",
170
+ summary: "Start a guided checklist when a policy-triggering change occurs.",
173
171
  instructions: "Trigger the matching workflow when an event occurs. filegrc adds every required action to the Work Queue with its owner and deadline.",
174
172
  use: "Preview the full workflow before triggering it, then create the event and every linked task in one validated write.",
175
173
  policyBasis: "Active event obligations translate policy-triggering changes into owned, deadline-bound Action Items. Proposed workflows remain unavailable until their governing policies and linked controls are ready.",
@@ -178,27 +176,34 @@ export const PROGRAM_PATH = [
178
176
  {
179
177
  id: "work-queue",
180
178
  title: "Work Queue",
179
+ summary: "Complete scheduled, event-driven, and assigned work by its due date.",
181
180
  instructions: "Complete recurring work, Policy Event tasks, and assigned Action Items within their allowed windows, link the requested dated proof, and resolve overdue items.",
182
- use: "See proposed, upcoming, due, and overdue policy work together with every open Action Item. Continuous and per-transaction controls still operate in their source Systems and need dated operating records or evidence.",
181
+ use: "See proposed, upcoming, blocked, due, and overdue policy work together with every open Action Item. Continuous and per-transaction controls still operate in their source Systems and need dated operating records or evidence.",
183
182
  policyBasis: "Effective policies and implemented linked controls activate reusable obligations. Policy Events and source records create owned Action Items. Each occurrence or task retains its own deadline, completion record, and evidence.",
184
- commands: ["filegrc obligations --json", "filegrc complete OBLIGATION_ID completion-mutation.json --json"]
183
+ commands: [
184
+ "filegrc obligations --json",
185
+ "filegrc complete OBLIGATION_ID --scaffold --window-start YYYY-MM-DD --completed-on YYYY-MM-DD",
186
+ "filegrc complete OBLIGATION_ID completion-mutation.json --json"
187
+ ]
185
188
  }
186
189
  ],
187
190
  commands: [
188
191
  "filegrc obligations --json",
189
192
  "filegrc trigger EVENT_TYPE (--occurred-on YYYY-MM-DD | --occurred-at RFC3339) --subject RESOURCE_ID --json",
193
+ "filegrc complete OBLIGATION_ID --scaffold --window-start YYYY-MM-DD --completed-on YYYY-MM-DD",
190
194
  "filegrc complete OBLIGATION_ID completion-mutation.json --json",
195
+ "filegrc complete-action ACTION_ITEM_ID --scaffold --completed-on YYYY-MM-DD",
191
196
  "filegrc complete-action ACTION_ITEM_ID completion-mutation.json --completed-on YYYY-MM-DD --json",
192
- "filegrc complete-event OBLIGATION_EVENT_ID --completed-on YYYY-MM-DD --json",
197
+ "filegrc complete-event OBLIGATION_EVENT_ID --completed-on YYYY-MM-DD --expected-revision REVISION --json",
193
198
  "filegrc program-readiness --json"
194
199
  ]
195
200
  },
196
201
  {
197
202
  id: "audit",
198
- number: 6,
203
+ number: 5,
199
204
  title: "Audit",
200
205
  description: "Firm, formal period, fieldwork, and report",
201
- summary: "After the program is collecting reliable evidence, create an Audit record for the real CPA engagement, keep the firm-agreed report period separate from management’s candidate dates, complete management documents, populations, requests, evidence delivery, and fieldwork, then preserve the findings, responses, opinion, and final report.",
206
+ summary: "Set up the CPA engagement, support fieldwork, and prepare the final evidence packet.",
202
207
  sections: [
203
208
  { id: "engagement", title: "Engagement", description: "Record the actual CPA engagement, formal scope and dates, requests, and management responses.", steps: ["Create the Audit after the CPA firm is engaged.", "Record the firm-agreed type, scope, systems, criteria, and dates.", "Track incoming requests and approved response material."], types: ["audit", "audit-request"], defaultOpen: true },
204
209
  { id: "fieldwork", title: "Fieldwork", description: "Prepare management documents, reconcile Type 2 populations, review both evidence paths, support testing, and build the indexed packet.", steps: ["Initialize engagement-specific management documents and populations.", "Review dated filegrc Evidence and verified External Evidence for the formal period.", "Reconcile complete populations, link samples, and resolve fieldwork requests and findings.", "Build the packet from a clean Git revision; it includes filegrc records, Markdown, External Evidence, attachments, indexes, history, and checksums."], types: ["audit-population", "control-test"], utility: "audit-packet", defaultOpen: true }
@@ -208,6 +213,7 @@ export const PROGRAM_PATH = [
208
213
  {
209
214
  id: "audit-packet",
210
215
  title: "Audit Evidence & Packet",
216
+ summary: "Review fieldwork readiness and build the indexed evidence packet.",
211
217
  instructions: "Review filegrc Evidence and External Evidence for the formal period, complete engagement preparation, and build the indexed audit packet.",
212
218
  use: "Prepare management documents and populations, answer fieldwork requests, review both evidence paths, and compile a delivery bound to a clean Git revision.",
213
219
  policyBasis: "Management prepares the scoped records, evidence, populations, assertions, and responses. The CPA firm selects samples, evaluates evidence and exceptions, and issues the report.",
@@ -216,6 +222,8 @@ export const PROGRAM_PATH = [
216
222
  ],
217
223
  commands: [
218
224
  "filegrc guide audit --json",
225
+ "filegrc scaffold audit --title \"YEAR SOC 2 TYPE\"",
226
+ "filegrc create AUDIT-MUTATION.json --json",
219
227
  "filegrc prepare-audit AUDIT_ID --json",
220
228
  "filegrc audit-readiness AUDIT_ID --json",
221
229
  "filegrc evidence-packet --audit AUDIT_ID --preview --json"
@@ -232,6 +240,7 @@ export function buildAgentProgramPath(model) {
232
240
  order: stage.id === "run" ? null : `${stage.number}.${String.fromCharCode(97 + index)}`,
233
241
  type,
234
242
  title: definition.pluralTitle,
243
+ summary: RESOURCE_PAGE_SUMMARIES[type] || definition.description,
235
244
  instructions: RESOURCE_INSTRUCTIONS[type] || definition.description,
236
245
  use: definition.description,
237
246
  policyBasis: definition.guidance.policyBasis,
@@ -243,6 +252,7 @@ export function buildAgentProgramPath(model) {
243
252
  order: stage.id === "run" ? null : `${stage.number}.${String.fromCharCode(97 + stage.resourceTypes.length + index)}`,
244
253
  utility: utility.id,
245
254
  title: utility.title,
255
+ summary: utility.summary,
246
256
  instructions: utility.instructions,
247
257
  use: utility.use,
248
258
  policyBasis: utility.policyBasis,