primitive-admin 1.1.0 → 1.2.0-alpha.0

package/dist/src/commands/settings.js

@@ -0,0 +1,54 @@
+/**
+ * `primitive settings` — the app-settings READER (issue #1033, Phase 2;
+ * narrowed to a reader by #2645).
+ *
+ * App settings are authored in `app.toml` and applied with `sync push`, so
+ * this group carries the one thing the file cannot answer: what the server is
+ * actually running. `settings get` renders the server-effective settings —
+ * `get` rather than `show`, so the read verb is the same word on every
+ * configuration surface.
+ *
+ * `settings pull`, `settings diff` and `settings push` are gone. They operated
+ * on the same `app.toml` and the same `entities.app` hash `sync` owns, so they
+ * were a second pathway to one piece of state; `sync pull|diff|push --only app`
+ * is the single one. The remaining command logic lives in
+ * `sync-app-settings.ts`, shared with `sync`.
+ */
+import { ApiClient } from "../lib/api-client.js";
+import { resolveAppId } from "../lib/config.js";
+import { showAppSettings } from "./sync-app-settings.js";
+export function registerSettingsCommands(program) {
+    const settings = program
+        .command("settings")
+        .description("View the app settings the server is running")
+        .addHelpText("after", `
+Examples:
+  $ primitive settings get                  # Render current server settings
+  $ primitive settings get --json           # Machine-readable
+  $ primitive sync pull --only app          # Write server settings to app.toml
+  $ primitive config set app app.baseUrl=https://example.com
+  $ primitive sync diff --only app          # Show local app.toml vs server
+  $ primitive sync push --only app          # Apply app.toml edits to the server
+
+app.toml is the ONLY way to manage app configuration (issue #2645): a full
+\`sync push\` applies it, and \`sync push --only app\` applies it alone.
+\`primitive config fields app\` lists its keys, types and defaults. The Google OAuth
+client secret is an ordinary [auth] key holding a reference into the app's
+secret store, never the secret itself: store the value with
+'primitive secrets set GOOGLE_CLIENT_SECRET --value <secret>', then set
+googleClientSecret = "{{secrets.GOOGLE_CLIENT_SECRET}}" in app.toml. A literal
+secret there is rejected by the server.
+`);
+    // settings get
+    settings
+        .command("get")
+        .description("Show the current server-effective app settings")
+        .argument("[app-id]", "App ID (uses current app if not specified)")
+        .option("--app <app-id>", "App ID")
+        .option("--json", "Output as JSON")
+        .action(async (appId, options) => {
+        const resolvedAppId = resolveAppId(appId, options);
+        await showAppSettings(new ApiClient(), resolvedAppId, options);
+    });
+}
+//# sourceMappingURL=settings.js.map

package/dist/src/commands/settings.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"settings.js","sourceRoot":"","sources":["../../../src/commands/settings.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;GAeG;AAGH,OAAO,EAAE,SAAS,EAAE,MAAM,sBAAsB,CAAC;AACjD,OAAO,EAAE,YAAY,EAAE,MAAM,kBAAkB,CAAC;AAChD,OAAO,EAAE,eAAe,EAAE,MAAM,wBAAwB,CAAC;AAEzD,MAAM,UAAU,wBAAwB,CAAC,OAAgB;IACvD,MAAM,QAAQ,GAAG,OAAO;SACrB,OAAO,CAAC,UAAU,CAAC;SACnB,WAAW,CAAC,6CAA6C,CAAC;SAC1D,WAAW,CACV,OAAO,EACP;;;;;;;;;;;;;;;;;CAiBL,CACI,CAAC;IAEJ,eAAe;IACf,QAAQ;SACL,OAAO,CAAC,KAAK,CAAC;SACd,WAAW,CAAC,gDAAgD,CAAC;SAC7D,QAAQ,CAAC,UAAU,EAAE,4CAA4C,CAAC;SAClE,MAAM,CAAC,gBAAgB,EAAE,QAAQ,CAAC;SAClC,MAAM,CAAC,QAAQ,EAAE,gBAAgB,CAAC;SAClC,MAAM,CAAC,KAAK,EAAE,KAAK,EAAE,OAAO,EAAE,EAAE;QAC/B,MAAM,aAAa,GAAG,YAAY,CAAC,KAAK,EAAE,OAAO,CAAC,CAAC;QACnD,MAAM,eAAe,CAAC,IAAI,SAAS,EAAE,EAAE,aAAa,EAAE,OAAO,CAAC,CAAC;IACjE,CAAC,CAAC,CAAC;AACP,CAAC"}

package/dist/src/commands/sync.d.ts

@@ -706,9 +706,6 @@ export declare function buildBlobBucketUpdatePayload(bucket: any): any;
  * first-wins rule: making the file's meaning depend on entry order is the kind
  * of implicit behavior this issue exists to remove, and silently picking one
  * would let the repo claim something the server does not do.
- *
- * `isActive` is accepted as a legacy spelling — the create leg read it before
- * pull ever wrote a marker, so a hand-authored file carrying it keeps working.
  */
 export declare function promptActiveConfigName(configs: any[]): string | undefined;
 /**
@@ -1554,7 +1551,7 @@ export declare function hashLocalConfigForDiff(spec: ConfigDiffSpec, parsedToml:
  * Hash a SERVER entity the same way, by serializing it into the file `sync
  * pull` would write and hashing that — so the two sides are normalized
  * identically by construction, and a legacy encoding on disk (a JSON-string
- * operation, an id-based rule-set reference) is not a false `Modified`.
+ * operation) is not a false `Modified`.
  *
  * `extra` carries the sibling rows a type's file also holds: a database type's
  * operations and subscriptions, which the list response does not include.

package/dist/src/commands/sync.js

@@ -1698,12 +1698,9 @@ const PROMPT_CONFIG_DEFAULT_STATUS = fieldServerDefault(PROMPT_CONFIG_TABLE, "st
  * first-wins rule: making the file's meaning depend on entry order is the kind
  * of implicit behavior this issue exists to remove, and silently picking one
  * would let the repo claim something the server does not do.
- *
- * `isActive` is accepted as a legacy spelling — the create leg read it before
- * pull ever wrote a marker, so a hand-authored file carrying it keeps working.
  */
 export function promptActiveConfigName(configs) {
-    const marked = (configs || []).filter((c) => c?.active === true || c?.isActive === true);
+    const marked = (configs || []).filter((c) => c?.active === true);
     if (marked.length > 1) {
         throw new Error(`Only one [[configs]] entry may set active = true; found ${marked.length} ` +
             `(${marked.map((c) => c.name).join(", ")}).`);
@@ -4012,7 +4009,7 @@ export function parseDatabaseTypeToml(tomlData) {
         },
     }));
     canonicalizeDatabaseTypeConfig(typeConfig);
-    // Both rule-set spellings; the name form resolves to an id later.
+    // The `ruleSetName` reference; it resolves to an id later.
     applyRuleSetReference(typeSection, typeConfig);
     if (tomlData.triggers) {
         typeConfig.triggers = tomlData.triggers;
@@ -4081,13 +4078,16 @@ export function parseRuleSetToml(tomlData) {
 /**
  * Read a config's rule-set reference off its TOML table (#2644).
  *
- * Both spellings are accepted — the portable `ruleSetName` and the legacy
- * `ruleSetId` — and the name form is left as `_ruleSetName` for
+ * One spelling, the portable `ruleSetName`, left as `_ruleSetName` for
  * `resolveRuleSetReference` to turn into an id once the app's rule sets are
- * known. Neither present means no reference, which push sends as an explicit
- * `null` so removing the line clears it (#1567).
+ * known. Absent means no reference, which push sends as an explicit `null` so
+ * removing the line clears it (#1567). The id spelling `ruleSetId` is retired
+ * (#3997): the preflight refuses it through `retired-keys.ts`, and it is never
+ * read here, so no id authored in TOML reaches the wire.
  */
 function applyRuleSetReference(section, entity) {
+    // The payload builder put the `ruleSetName` value on the `ruleSetId` field;
+    // the resolver sets the real id.
     delete entity.ruleSetId;
     if (section.ruleSetName && section.ruleSetName !== "") {
         // Trimmed to match the name the server stores for the rule set itself
@@ -4097,9 +4097,6 @@ function applyRuleSetReference(section, entity) {
                 ? section.ruleSetName.trim()
                 : section.ruleSetName;
     }
-    else if (section.ruleSetId && section.ruleSetId !== "") {
-        entity.ruleSetId = section.ruleSetId;
-    }
 }
 /** Drop keys the TOML did not carry, so `"x" in entity` stays meaningful. */
 function dropUndefined(entity) {
@@ -4162,22 +4159,22 @@ export function parseCollectionTypeConfigToml(tomlData) {
 // the SAME push parser before hashing.
 //
 // Parsing through the push parser — rather than hashing the raw parsed TOML —
-// is what makes the comparison encoding-independent, and is why the four known
+// is what makes the comparison encoding-independent, and is why the known
 // false-diff traps do not fire: a legacy JSON-string operation and the native
 // `[operations.definition]` table the server emits normalize to one shape
-// (`normalizeOperationFromToml`); a `ruleSetName` reference and its legacy
-// `ruleSetId` resolve to the same id (`normalizeRuleSetRefForDiff`); an omitted
-// `autoAddCreator` picks up the same default the server serializes
-// (`parseGroupTypeConfigToml`); and a metadata-category's identity is read from
-// the parsed `[metadataCategoryConfig]` content, not the filename. Hashing raw
-// parsed TOML would show a false `Modified` for each of those equivalent forms.
+// (`normalizeOperationFromToml`); a `ruleSetName` reference resolves to the id
+// the server holds (`normalizeRuleSetRefForDiff`); an omitted `autoAddCreator`
+// picks up the same default the server serializes (`parseGroupTypeConfigToml`);
+// and a metadata-category's identity is read from the parsed
+// `[metadataCategoryConfig]` content, not the filename. Hashing raw parsed TOML
+// would show a false `Modified` for each of those equivalent forms.
 /**
  * Resolve a parsed entity's rule-set reference to a stable id for hashing.
  * `parseGroupTypeConfigToml` / `parseCollectionTypeConfigToml` /
- * `parseDatabaseTypeToml` leave either `_ruleSetName` (key-based) or a legacy
- * `ruleSetId` on the entity; collapsing both to `ruleSetId` here means the two
- * encodings of the same reference hash equal. `throwOnMissing: false` so an
- * unresolvable name degrades gracefully rather than aborting the diff.
+ * `parseDatabaseTypeToml` leave the `ruleSetName` reference as `_ruleSetName`;
+ * resolving it to `ruleSetId` here means the local file and the server entity
+ * hash the same reference. `throwOnMissing: false` so an unresolvable name
+ * degrades gracefully rather than aborting the diff.
  *
  * When the name does NOT resolve — a typo, or a rule set added locally in the
  * same tree but not yet on the server — `resolveRuleSetReference` deletes
@@ -5066,7 +5063,7 @@ export function hashLocalConfigForDiff(spec, parsedToml, maps, extra) {
  * Hash a SERVER entity the same way, by serializing it into the file `sync
  * pull` would write and hashing that — so the two sides are normalized
  * identically by construction, and a legacy encoding on disk (a JSON-string
- * operation, an id-based rule-set reference) is not a false `Modified`.
+ * operation) is not a false `Modified`.
  *
  * `extra` carries the sibling rows a type's file also holds: a database type's
  * operations and subscriptions, which the list response does not include.
@@ -17263,28 +17260,28 @@ What a push guarantees (two stages):
         let unchangedCount = 0;
         // ---- database-type-configs/ pass ----
         if (dbFiles.length > 0) {
-            // Hydrate ruleSetIdToName from local sync state so files that
-            // reference a rule set via the legacy `ruleSetId = "01..."` form
-            // round-trip with the correct `ruleSetName`. Without this, any user
-            // who runs migrate-toml against a file with a rule-set assignment
-            // would silently lose that reference (review feedback r3246633010).
-            //
-            // Files that use the modern key-based `ruleSetName = "..."` form
-            // don't need the map at all — `parseDatabaseTypeToml` stores the
-            // value in `typeConfig._ruleSetName` and the serializer now prefers
-            // that. The map is only load-bearing for the legacy ID-based form.
-            const ruleSetIdToName = new Map();
-            const migrateSyncState = loadSyncState(configDir);
-            if (migrateSyncState?.entities?.ruleSets) {
-                for (const [fileKey, entry] of Object.entries(migrateSyncState.entities.ruleSets)) {
-                    if (entry && typeof entry === "object" && "id" in entry && entry.id) {
-                        // fileKey is the sanitized rule-set name (see config pull at
-                        // sync.ts:1385). It's the same shape the server returned and
-                        // matches what a TOML file's ruleSetName field would carry.
-                        ruleSetIdToName.set(entry.id, fileKey);
-                    }
-                }
+            // #3997 — refuse a tree carrying a retired key (the id-based
+            // `ruleSetId`) with the message `config push` gives, before anything is
+            // rewritten. This is a separate pass, not a check inside the loop below:
+            // that loop writes each file and saves sync state before it parses the
+            // next, so an in-loop abort would leave earlier files rewritten. Every
+            // offending file is reported, so the author fixes the tree once.
+            const retiredKeyErrors = [];
+            for (const file of dbFiles) {
+                const message = configUnknownKeyError(`database-type-configs/${file}`, parseTomlFile(join(dbTypesDir, file)), DATABASE_TYPE_TABLE);
+                if (message)
+                    retiredKeyErrors.push(message);
             }
+            if (retiredKeyErrors.length > 0) {
+                for (const message of retiredKeyErrors)
+                    error(`  ${message}`);
+                error(`Aborting migrate-toml: ${retiredKeyErrors.length} database-type ` +
+                    "file(s) carry a retired or unrecognized key; nothing was rewritten.");
+                process.exit(1);
+            }
+            // The parser yields the rule-set reference only as `_ruleSetName`,
+            // which the serializer prefers, so there is no id to map to a name.
+            const ruleSetIdToName = new Map();
             for (const file of dbFiles) {
                 const filePath = join(dbTypesDir, file);
                 const rawBefore = readFileSync(filePath, "utf-8");