primitive-admin 1.1.0-alpha.78 → 1.1.0-alpha.79

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

@@ -888,6 +888,35 @@ export interface ConfigFileValidationError {
  * to the per-type loop that reads it, which names the parse error itself.
  */
 export declare function collectConfigFileValidationErrors(configDir: string): ConfigFileValidationError[];
+/**
+ * Every `functions/<key>.toml` whose file-decidable errors `config push` would
+ * refuse (#3320).
+ *
+ * A second collector rather than a branch inside
+ * `collectConfigFileValidationErrors`, and deliberately so: push calls that one
+ * UNBOUNDED over the whole tree, which is right for the checks it runs (a
+ * mistyped key anywhere means the tree is not pushable) and wrong for these — a
+ * `config push --only webhook/<key>` must not be blocked by a broken function
+ * the operator did not select (#2645). The push path therefore runs these
+ * inside its own `selectFiles`-bounded function loop, and `config diff`, which
+ * compares the whole tree by construction, runs them from here.
+ *
+ * A file that does not parse is skipped: the per-type loop that reads it names
+ * the parse error itself, and reporting it twice helps nobody.
+ */
+export declare function collectFunctionTomlValidationErrors(configDir: string): ConfigFileValidationError[];
+/**
+ * The collectors' rows, one per diff row (#2880 symmetry, #3320).
+ *
+ * Two collectors reach the same function file — the definition-driven one
+ * every per-entity type runs, and the function preflight — and a file can
+ * break both at once (a mistyped `entrty`, which then leaves no `entry`).
+ * Push reports every message from both, so an overlay that let one row's
+ * messages REPLACE the other's would drop a diagnostic push prints, which is
+ * exactly the asymmetry #2880 forbids. Merging by row keeps the two commands
+ * reading identically.
+ */
+export declare function mergeConfigFileValidationErrors(collected: ConfigFileValidationError[]): ConfigFileValidationError[];
 /**
  * Every `<key>.tests/*.toml` sidecar under a config directory.
  *
@@ -1218,6 +1247,19 @@ export declare function classifyPushChange(input: {
     localHash: string;
     remoteHash: string;
     baselineHash?: string;
+    /**
+     * The server record has NOT been written since the last sync (#3317).
+     *
+     * Its own `modifiedAt` is what says so, and that is evidence no hash can
+     * contradict: a record nothing has written cannot have drifted, so the local
+     * file is the only side that can have moved. A baseline hash disagreeing
+     * with the current remote projection then says something about the BASELINE
+     * — recorded by a CLI whose projection of the same record differed — and not
+     * about the server. Left false by callers whose row timestamp does not cover
+     * everything the projection compares; `decidePushForConfig` owns that
+     * judgement.
+     */
+    serverUnchangedSinceSync?: boolean;
     legacy?: {
         localBytesMatchStoredContentHash?: boolean;
         liveModifiedAtMatchesStored?: boolean;
@@ -1414,6 +1456,13 @@ export interface PushBaselineEntry {
     modifiedAt?: string;
     contentHash?: string;
     semanticHash?: string;
+    /**
+     * The version the manifest last saw active, for a versioned type (#3317).
+     * Read only beside `serverModifiedAtCoversProjection`: a recorded pointer
+     * that is not the live one denies the timestamp's claim that the server
+     * stood still.
+     */
+    activeConfigId?: string;
 }
 /**
  * `config push`'s change decision for one configuration file (#2731 B1/B3/B4/B8).
@@ -1493,6 +1542,33 @@ export declare function decidePushForConfig(input: {
      */
     localExtra?: any;
     force?: boolean;
+    /**
+     * Whether the live record's `modifiedAt` covers EVERYTHING this type's
+     * projection compares (#3317).
+     *
+     * Opt-in, because it is a claim about the data model rather than about this
+     * push. A server function's header row carries its fields and the
+     * `activeConfigId` pointer, and a version is immutable, so any change to
+     * what the comparison reads moves that one timestamp — an equal timestamp
+     * therefore PROVES the server stood still, and a baseline hash that
+     * disagrees is stale rather than evidence of drift (the reporter's conflict,
+     * printed over two identical timestamps).
+     *
+     * A database type's is the counter-example and the reason this is not the
+     * default: its operations and subscriptions are rows of their own, so an
+     * out-of-band edit to one changes the projection while the type's own
+     * `modifiedAt` stands still. Claiming coverage there would turn a real
+     * server change into a silent overwrite.
+     *
+     * The timestamp is trusted only alongside the version pointer: when the
+     * manifest recorded an `activeConfigId`, the live record must still point at
+     * it. The baseline is written from a header refetched AFTER the push, and a
+     * concurrent activation landing in that window leaves the manifest carrying
+     * the other operator's timestamp beside the version this push activated —
+     * two timestamps that agree about a server that moved to a version the local
+     * file never saw. The pointer is what moved, so it is what settles it.
+     */
+    serverModifiedAtCoversProjection?: boolean;
     /**
      * Whether this type's push path ADOPTS an existing object by key (#2909).
      *
@@ -1941,6 +2017,49 @@ selects?: (name: string) => boolean): Promise<{
     /** Names the server listed, empty when the listing failed. */
     serverKeys: string[];
 }>;
+/**
+ * The manifest row `config push` records for a function it just pushed
+ * (#3317), and whether the server had already moved past that push.
+ *
+ * The header is refetched AFTER the version push, so the row's `modifiedAt`
+ * is the live timestamp — but the version pointer and the envelope are the
+ * push's own: the manifest names what THIS run activated, not whatever the
+ * refetch happened to find. A concurrent activation landing between the push
+ * and the refetch is exactly the case those two must not be conflated in:
+ * recording the refetched pointer would make the other operator's version the
+ * baseline the local file is then read as a plain edit of, and the next push
+ * would roll it back without `--force`. Recording the pushed pointer beside
+ * the live timestamp is what `decidePushForConfig` reads as "the pointer
+ * moved" — a refusal, until the operator pulls or forces.
+ *
+ * `movedTo` names the version the refetched header points at when it is not
+ * the pushed one, so the caller can say so at the moment it is known rather
+ * than leaving it for the next push to report.
+ */
+export declare function pushedFunctionBaseline(input: {
+    functionId: string;
+    /** The header refetched after the push, or the pre-push listing row. */
+    refreshed: any;
+    existingModifiedAt?: string;
+    contentHash: string;
+    /** The version the push activated (created, or the matched no-op). */
+    pushedVersion: any;
+    envelopeHash: string;
+    sources: string[];
+    spec: ConfigDiffSpec;
+    maps: ConfigDiffMaps;
+}): {
+    entity: {
+        id: string;
+        modifiedAt: string;
+        contentHash: string;
+        semanticHash?: string;
+        envelopeHash: string;
+        activeConfigId?: string;
+        sources: string[];
+    };
+    movedTo: string | null;
+};
 /**
  * Pull server-side `ServerFunction` rows into `functions/` (#3179).
  *