create-filegrc 0.16.4 → 0.16.6

package/package.json

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

package/src/cli.js

@@ -30,20 +30,22 @@ export async function runCli(argv = process.argv.slice(2)) {
     `filegrc ${result.engineVersion}${result.enginePackage ? ` from ${result.enginePackage}` : ""}: ` +
     `${result.install === "installed" ? "installed" : "installation skipped"}`
   );
-  console.log("Use a dedicated private repository for your FileGRC workspace. The browser");
-  console.log("commits and pushes each saved program change, so a standalone repository keeps");
-  console.log("the compliance audit trail separate from application development history.");
+  console.log("Use a dedicated private repository for your FileGRC workspace.");
+  console.log("A standalone repository keeps the compliance audit trail separate from application development history.");
+  console.log(result.repository.mode === "trunk"
+    ? "In trunk mode, browser saves commit and push to the configured remote."
+    : "In manual mode, browser saves stay local until you commit and push with Git.");
   console.log(`Git: ${result.gitMode === "existing-worktree" ? "joined existing worktree" : "initialized new repository"}`);
   if (result.gitMode === "existing-worktree") {
     console.log("");
     console.log("This FileGRC workspace joined an existing Git repository.");
     console.log("");
-    console.log("FileGRC recommends a dedicated private repository because browser saves create");
-    console.log("frequent compliance commits. A standalone repository keeps the GRC audit trail");
+    console.log("FileGRC recommends a dedicated private repository. A standalone repository keeps the GRC audit trail");
     console.log("separate from application development history.");
     console.log("");
-    console.log("Monorepo mode remains supported. Browser Git operations will commit only files");
-    console.log("inside this FileGRC workspace.");
+    console.log(result.repository.mode === "trunk"
+      ? "Monorepo mode remains supported. Browser Git operations commit only this workspace."
+      : "Monorepo mode remains supported. In manual mode, browser saves remain local.");
   }
   if (
     result.gitMode === "existing-worktree"
@@ -90,7 +92,9 @@ export async function runCli(argv = process.argv.slice(2)) {
   console.log("  2. Appoint an independent reviewer who is separate from the policy owner.");
   console.log(result.gitMode === "existing-worktree"
     ? "Review the generated records and commit only this workspace's approved baseline."
-    : "Connect the dedicated private origin and push main before using browser writes.");
+    : result.repository.mode === "trunk"
+      ? `Connect a private ${result.repository.remote} and push ${result.repository.authoritativeBranch} before using browser writes.`
+      : "Review the generated records, then commit and push with Git when ready.");
 }
 
 function shellQuote(value) {

package/src/index.js

@@ -33,6 +33,9 @@ export async function createFilegrc(options = {}) {
     project_name: normalizePackageName(basename(target)),
     filegrc_version: engine.version,
     filegrc_version_range: engine.dependency,
+    repository_setup: repository.mode === "trunk"
+      ? `The editable browser uses \`${repository.authoritativeBranch}\` and pushes saved changes to \`${repository.remote}\`. Connect this repository to a dedicated private remote and push \`${repository.authoritativeBranch}\` before using browser writes.`
+      : "In manual mode, browser saves stay local. Review the workspace diff and commit or push with Git when ready.",
     ...starterText
   };
 
@@ -521,13 +524,13 @@ async function runCombinedSetup(target, input) {
 async function writeMinimalLockfile(target, name, versionRange) {
   const lock = {
     name,
-    version: "0.16.4",
+    version: "0.16.6",
     lockfileVersion: 3,
     requires: true,
     packages: {
       "": {
         name,
-        version: "0.16.4",
+        version: "0.16.6",
         dependencies: { filegrc: versionRange }
       }
     }

package/template/AGENTS.md

@@ -21,6 +21,8 @@ npx filegrc program-amendment SOURCE_RESOURCE_ID --json
 
 `program-path --next --json` gives agents the current step and first action. Use `--summary` for all five step statuses or `--current` for the current step’s page summaries, detailed guidance fields, commands, and next actions. The general guide lists every supported action and record type. A type guide adds the checks needed for that resource, including timing, required and conditional fields, current relationship candidates, JSON location, and Markdown slots.
 
+Before proposing a new process or record for a Control, inspect the current Control, its linked Policy and Markdown, Obligations, operating records, Components, and Evidence with `get`, `list`, `search`, and `references`. Read `get CONTROL_ID --workflow --json` and the relevant type guides to find the actual gap. Reuse an existing rule or workflow when it covers the requirement. If the design exists but operation is unproven, ask for the real event, actors, dates, and evidence needed to record it; do not ask management to design the process again. Ask users only for decisions or facts that the repository and available sources cannot verify. Never infer that a Policy or planned Obligation proves the Control operated.
+
 For a new record, generate a mutation envelope:
 
 ```sh
@@ -64,6 +66,8 @@ The JSON and Markdown under `data/`, the installed model, policy content, and Gi
 
 Start with `npx filegrc program-path --next --json` for the current step and next action. Use `npx filegrc workflow --json` when you need the complete derived checklist, named readiness assessments, blockers, and Work Items. `guide`, `list --workflow`, `get --workflow`, mutation previews, the HTTP API, and the browser consume the same calculation. In `get --workflow` output, `findings` and `workItems` preserve the complete checklist relevant to that record. `related` additionally groups downstream work that the record supports but that belongs to another record or program step. Resolve a derived finding by changing its source facts, recording a reviewed applicability decision, accepting an allowed Exception, or completing authoritative assigned work. Never add a separate TODO file or UI-only completion flag for calculated work.
 
+The workflow recommendation's `context` lists existing connected records, the work phase, and unmet checks. Open those records before following a setup prompt. A connected Policy, Obligation, or Evidence record is context; check the dated work and its proof before saying a Control operated.
+
 FileGRC marks an item `blocked` only when named prerequisite records must be resolved first. A missing record, editable error, or management decision is `ready` when you can act on it now, even when it prevents a readiness assessment from passing.
 
 An Action Item or Audit Request is a source record because it captures a real assignment, owner, deadline, and completion proof. A Collection Review is also a source record because FileGRC cannot infer that management reviewed an apparently complete or empty collection. `npx filegrc guide RESOURCE_TYPE --json` returns the type-specific review criteria and current confirmation state. Use `npx filegrc review-collection RESOURCE_TYPE --scaffold`, fill the conclusion and reviewer facts, preview it, then apply it with `--yes`. FileGRC calculates the collection revision and marks the confirmation stale after a reviewed record or material scope fact changes.
@@ -78,22 +82,22 @@ Git exclusively supplies file authors, commit timestamps, messages, diffs, revis
 
 Domain events still need explicit dates. Keep values such as `occurredOn`, `scheduledFor`, `approvedOn`, `completedOn`, and audit-period dates in their records.
 
-Use a dedicated private repository for your FileGRC workspace. The browser commits and pushes each saved program change, so a standalone repository keeps the compliance audit trail separate from application development history.
+Use a dedicated private repository for your FileGRC workspace. A standalone repository keeps the compliance audit trail separate from application development history.
 
 - Prefer creating or cloning FileGRC as a standalone private repository.
-- Run the editable browser from the authoritative branch's main checkout.
+- In trunk mode, run the editable browser from the configured authoritative branch's main checkout.
 - Do not place a new FileGRC workspace inside an application monorepo unless the organization has explicitly chosen that structure.
 - If FileGRC already lives in a monorepo, do not relocate it automatically.
-- In a monorepo, never include application changes in FileGRC-generated commits.
-- Treat detached and feature-branch copies as read-only unless an explicit development override is active.
+- In trunk mode, FileGRC-generated commits in a monorepo include only this workspace, never application changes.
+- In trunk mode, detached and feature-branch copies are read-only unless an explicit development override is active.
 
-New workspaces use trunk repository mode with `main` as the authoritative branch and `origin` as the remote. Each browser mutation checks the whole Git worktree, fetches the remote, fast-forwards only, rechecks the edited revision, writes through the normal domain function, validates the workspace, stages only this FileGRC workspace, creates a focused commit, and pushes it. Browser onboarding commits its related Workspace, Program, System, Component, and renderer changes together.
+In trunk repository mode, each browser mutation checks the whole Git worktree, fetches the remote, fast-forwards only, rechecks the edited revision, writes through the normal domain function, validates the workspace, stages only this FileGRC workspace, creates a focused commit, and pushes it. Browser onboarding commits its related Workspace, Program, System, Component, and renderer changes together.
 
-The Repository page reports `Synced`, `Syncing`, `Not synced`, `Read-only checkout`, or `Git setup required`. Browser saves return after the validated local commit, then push in the background. Treat `Syncing` as locally durable but not yet durable on the remote, and wait for `Synced` before starting another write. A failed push keeps the local FileGRC commit and offers Retry sync when every ahead commit changes only this workspace. FileGRC never pushes an ahead commit that includes files outside this workspace, and it never merges, rebases, switches branches, resolves conflicts, or changes files outside the workspace.
+In trunk mode, the Repository page reports `Synced`, `Syncing`, `Not synced`, `Read-only checkout`, or `Git setup required`. Browser saves return after the validated local commit, then push in the background. Treat `Syncing` as locally durable but not yet durable on the remote, and wait for `Synced` before starting another write. A failed push keeps the local FileGRC commit and offers Retry sync when every ahead commit changes only this workspace. FileGRC never pushes an ahead commit that includes files outside this workspace, and it never merges, rebases, switches branches, resolves conflicts, or changes files outside the workspace.
 
-Record lifecycle fields are the approval source. Draft, proposed, approved, and retired records may all live on the authoritative branch. Do not use Git branches to represent policy approval.
+Record lifecycle fields are the approval source. Draft, proposed, approved, and retired records may all live on the same branch. Do not use Git branches to represent policy approval.
 
-Manual mode requires an explicit `repositoryMode` in `data/renderer.json`. In manual mode, review the workspace diff and use the Repository controls or Git CLI. Agents and terminal users always own their Git synchronization and should pull, commit, and push directly. FileGRC does not replace repository authentication, authorization, branch protection, or review controls.
+Read `repositoryMode`, `authoritativeBranch`, and `repositoryRemote` from `data/renderer.json`. In manual mode, browser saves stay local, including on feature branches. Review the workspace diff, then commit and push with Git when ready. Agents and terminal users always own their Git synchronization. FileGRC does not replace repository authentication, authorization, branch protection, or review controls.
 
 Use `npx filegrc serve --allow-non-authoritative-writes` only for local development in a task worktree. The override is visible in the UI and never commits or pushes.
 
@@ -148,7 +152,7 @@ Headless agents get the same protection by exporting an edit payload with `fileg
 
 ## Renderer settings and onboarding
 
-`data/renderer.json` stores committed renderer and repository preferences. New workspaces set `showOnboarding` to `true`, `repositoryMode` to `trunk`, `authoritativeBranch` to `main`, and `repositoryRemote` to `origin`. In trunk mode, completing or skipping onboarding commits the related change and starts its background push.
+`data/renderer.json` stores committed renderer and repository preferences. New workspaces set `showOnboarding` to `true`; the default Git settings are trunk mode, `main`, and `origin`. Creation can choose manual mode or other branch and remote names. In trunk mode, completing or skipping onboarding commits the related change and starts its background push.
 
 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 one `system` record, stores that selected system and the management goal on `workspace`, and creates one planned service-commitment prompt. Replace that prompt with the actual customer promise or approved service requirement before activation. Onboarding does not create a Requirement Mapping for the baseline SOC 2 Commitment, mark Controls implemented, or create evidence. Selecting Type 1 or Type 2 does not create an audit engagement. Completing onboarding opens the Step 1 overview so the user can add the real reviewers and operators, finish the oversight team, commit the prepared Reporting Channel Set proposal, and confirm the criteria, commitments, any supplemental mappings, vendors, and systems before approving policies.
 

package/template/WORKSPACE.md

@@ -38,7 +38,7 @@ git add .
 git commit -m "Initialize FileGRC program"
 ```
 
-The editable browser uses `main` and pushes saved changes to `origin`. Connect this repository to a dedicated private remote and push `main` before using browser writes. CLI and file-based users can manage Git on their normal review cadence, but should still commit the baseline before changing program facts.
+{{repository_setup}} CLI and file-based users can manage Git on their normal review cadence, but should still commit the baseline before changing program facts.
 
 {{starter_setup}}
 

package/template/data/AGENTS.md

@@ -18,6 +18,10 @@ npx filegrc search "TERM" --json
 
 Use `program-path --next --json` for the current lifecycle step. Use `workflow --json` when you need the full shared assessments, complete checklist, Work Items, and blockers. 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, timing, and exact paths. Use `describe` only when you need the raw model definition.
 
+Before creating a record or asking for a new procedure, inspect matching records and their links with `list`, `search`, `get RESOURCE_ID --workflow --json`, and `references RESOURCE_ID --json`. Read the linked Policy and companion Markdown, Control, Obligations, operating records, Components, and Evidence as applicable. Reuse the authoritative record and update it when needed. Separate a documented design or enabled schedule from proof that work actually occurred. Ask for only the missing business facts, decisions, or external evidence that you cannot verify; do not invent an event or ask for facts already recorded here.
+
+In `get RESOURCE_ID --workflow --json`, inspect `workflow.recommended.context.existing` before using `scaffold`. The listed records are relationship candidates, not proof that work occurred.
+
 After changing a lifecycle fact directly, review `reconcile --preview --json`. A candidate asks whether the change represents a real policy event. Supply the actual event date or timestamp, departure risk when relevant, and explicit confirmation before applying it. If it is a false positive, use `reconcile --dismiss` with the exact candidate fingerprint, a Person reviewer, the review date, a rationale, and `--yes`. The immutable dismissal suppresses only that fingerprint.
 
 ## Choose the right record

package/template/package.json

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

package/template-parameters.json

@@ -51,6 +51,10 @@
       "key": "filegrc_version_range",
       "source": "resolved-filegrc-version"
     },
+    {
+      "key": "repository_setup",
+      "source": "repository-mode"
+    },
     {
       "key": "program_title",
       "source": "starter-profile"