@com55/node-red-ai-access 0.2.0-beta.6 → 0.2.0-beta.8

package/CHANGELOG.md

@@ -6,6 +6,56 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to
 [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.2.0-beta.8] - 2026-10-29
+
+- Proposal review shows human conflict reasons and Base / Live / Proposed field
+  values, including flow environment variables. Choices have explanations,
+  confirmation, a visible chosen state, and persisted undo of the latest choice.
+- Proposals with no net deployment change clearly say nothing changes and hide
+  approval and security notes.
+- Consolidate review notes with a count and separate security from
+  configuration; omit duplicate comparisons and unchanged editor diffs. Re-check
+  shows progress and a result toast. Pending totals match the badge, including
+  conflicts.
+- Improve light-theme readability, settings width, sticky navigation clearance,
+  sign-in footer visibility and stable sign-in button colors; errors use alerts.
+- Reject invalid TTL settings with a minimum of 1; keep invalid input visible
+  and never report it saved. Investigate the NR4 Active link (box-only
+  findings).
+
+- Merge disjoint fields on the same node and tab, including env entries by
+  unique name and credentials by key. Conflict choices preserve independent
+  changes from both sides and retain secret safeguards and warnings.
+- Keep peer proposals mergeable after approval of a different field on the same
+  node.
+- Report actual changed fields in `outbound_node_changed` warnings.
+- Expose `baseRev` and rename the informational revision flag to
+  `baseRevChanged`; use `rebase.state` and `rebase.rev` to assess the checked
+  merge.
+- Add `nodeId` + `choice` to MCP/REST proposal resolution and clarify that
+  replacement operations apply to the flow snapshot at `expectedRev`.
+- Allow full admins to withdraw proposals after token loss, with recovery
+  authority and original ownership in the audit log. Other tokens remain
+  blocked.
+
+## [0.2.0-beta.7] - 2026-10-28
+
+### Fixed
+
+- Unrelated flow changes no longer expire or reject pending proposals.
+
+### Added
+
+- Automatic three-way rebasing onto live flows, with a `conflict` status that
+  blocks approval until resolved.
+- Configurable `proposalTtlDays` (1–365 days, default 7); only TTL expiry closes
+  old open proposals.
+- Admin conflict-choice and recheck routes, AI REST resolution, and the MCP
+  `resolve_proposal_conflict` tool.
+- Diffs include editor changes and the merged deployment; approval requires a
+  `mergedHash` acknowledgement when live changes are merged.
+- Recent known stale revisions are accepted at submit and rebased immediately.
+
 ## [0.2.0-beta.6] - 2026-10-28
 
 ### Added

package/README.md

@@ -14,10 +14,10 @@ Temporary, owner-approved Node-RED access for AI clients. Ships as a **Node-RED
   services
 
 **Git mental model:** a proposal is like a pull request. Human approve = merge;
-reject = close; withdraw = the author closes their own PR. If `rev` /
-`expectedRev` does not match, treat it as a conflict: re-read the flow, rebase
-the edit, and resubmit. Every access link can see all proposals
-(`mine: true|false`).
+reject = close; withdraw = the author closes their own PR. Revision changes
+auto-rebase open proposals. A `conflict` blocks approval until resolved. Open
+proposals expire after a configurable TTL (default 7 days). Every access link
+can see all proposals (`mine: true|false`).
 
 Derived from
 [ziv-daniel/node-red-mcp](https://github.com/ziv-daniel/node-red-mcp).
@@ -46,8 +46,12 @@ Configuration).
 The `/ai-access` HTML shell is served without adminAuth so the page can read the
 editor token from browser `localStorage` (Node-RED does not use cookies) and
 call APIs with `Authorization: Bearer`. If no valid token is present, the page
-redirects to the editor login. All data and actions stay behind permission
-checks.
+shows a sign-in card. With credentials login, it posts to
+`<httpAdminRoot>/auth/token` as client `node-red-editor` using the password
+grant. The token is shared with the editor, stored under the editor's
+`localStorage` key (`auth-tokens` at `/`, or e.g. `auth-tokens-admin` at
+`/admin`). Other login strategies open the editor to sign in. All data and
+actions stay behind permission checks.
 
 The dashboard has tabs for **Overview** (status and diagnostics), **Settings**,
 **Access tokens**, **OAuth**, **Proposals** and **Audit log**. You can create
@@ -74,6 +78,9 @@ module.exports = {
     maxActiveLinks: 10,
     // Deploy type used on approve (default: "nodes"; also "flows" | "full")
     defaultDeploymentType: 'nodes',
+    approveQueueTimeoutMs: 60_000, // maximum time waiting to start approval
+    deployTimeoutMs: 60_000, // caller deadline; does not cancel deployment
+    deployHardCapMs: 300_000, // release the queue even if deployment never settles
     // In-memory rate limits for /mcp/api and /mcp/a (per IP + per access token)
     rateLimitWindowMs: 60000,
     rateLimitMaxPerIp: 600,
@@ -402,10 +409,83 @@ revoke the link and create a new one. After a restart every old token is
 invalid.
 
 Call `list_flows` or `get_flow` first and pass the returned `rev` as
-`expectedRev`. Submit checks the live rev (**409** if stale). Approve may send
-`deploymentType`: `nodes` (default), `flows`, or `full`. A stale `expectedRev`
-at approve marks the proposal **rejected** with a resubmit message; other deploy
-errors mark it **failed**. Reject never mutates flows.
+`expectedRev`. Recent known stale revisions are accepted and auto-rebased;
+unknown revisions return **409** `version_mismatch`. Human approval waits up to
+60 seconds for deployment. A timeout returns **504** `deploy_timeout`, leaves
+the proposal pending with a persisted `deployPending` reason shown in the API
+and dashboard, and holds the approval queue until the runtime settles or the 5
+minute hard cap is reached. Before the cap, a late success marks the proposal
+approved with its `resultRev`; a late failure clears `deployPending` and keeps
+it pending for retry. At the cap the queue and proposal lock are released,
+`deployPending.queueReleased` becomes true, and the card asks reviewers to check
+the live flow before approving again. Later runtime settlement leaves this
+unknown-outcome record unchanged. Every subsequent approval re-reads live flows
+before rebasing and deploying, recognizing already-applied results. Queued
+approvals time out after 60 seconds with **504** `approve_queue_timeout` without
+deploying. Queued proposals can still be rejected or withdrawn; their approvals
+then return `proposal_not_pending` when dequeued. These three deadlines are
+configurable in `settings.js` under `aiAccess` (positive milliseconds; invalid
+values use the defaults shown above). When choosing **proposed** during conflict
+resolution, unchanged secret spans keep their live editor values. If spans
+cannot be aligned safely, proposed values are retained with a
+`secret_may_revert` warning on the dashboard card. Deliberately deleted secret
+spans do not raise this warning. Deleting one of several identical secret lines
+while their live values changed keeps the proposal in conflict; resolve that
+field against the live flow or choose **live**. Changed env arrays with
+duplicate names show `duplicate_env_keys`, since pairing by name is ambiguous
+when entries are reordered.
+
+Open proposals merge changes per node and tab field. Different fields on the
+same node merge automatically; changes to the same field conflict even when both
+values are identical. Position (`x`/`y`) edits never conflict; a proposed
+position edit wins a tie. Env entries merge by unique name and then entry field;
+credentials merge by key (including nested keys). Duplicate env names use an
+atomic array comparison and retain the existing ambiguity warning. Deletion
+versus modification, id collisions, dangling references, and unsafe redacted
+placeholders still block approval.
+
+Proposal responses and diffs expose `baseRev` (an alias of `expectedRev`).
+`baseRevChanged` replaces `baseRevStale`: it only reports that the base revision
+differs from live for an open proposal. It is informational, including after a
+successful rebase. `rebase.rev` is the checked live revision and `rebase.state`
+is `clean` (proposal applies unchanged), `merged` (live edits incorporated), or
+`conflict` (approval blocked). A merged proposal still requires review of its
+current `mergedHash` before approval.
+
+MCP `resolve_proposal_conflict` and REST `POST /proposals/:id/resolve` accept
+`nodeId` + `choice: "live" | "proposed"` for one current conflict. Choices
+affect only overlapping fields; independent edits from both sides survive.
+Existing secret preservation and ambiguity warnings also apply. Alternatively
+send `expectedRev` + `payload` to replace the proposal body: node operations
+apply to the **flow snapshot at expectedRev**, not to the stored proposal or
+merged result, so include every intended edit. These modes cannot be mixed. Both
+require the submitting token; tab conflicts use the flow id as `nodeId`.
+
+If the submitting token is lost, a full (`*`) admin can withdraw an open
+proposal through `POST /mcp/api/v1/proposals/:id/withdraw` using the dashboard's
+authenticated admin session (optional JSON `reason`). Other access tokens,
+including replacement tokens, cannot withdraw it. Recovery records
+`proposal.withdrawn` with the admin identity, original owner id,
+`withdrawalAuthority: "admin-recovery"`, proposal id, and reason. Owner-token
+withdrawal records `withdrawalAuthority: "owner-token"`. Withdrawal never
+deploys flows and cannot interrupt an in-flight approval.
+
+Open proposals auto-rebase on editor changes. A `conflict` blocks approval until
+resolved using REST `POST /proposals/:id/resolve`, admin
+`POST /proposals/:id/resolve-conflict`, or MCP `resolve_proposal_conflict`. The
+dashboard confirms conflict choices and shows the chosen side. Admins can undo
+the latest choice with `POST /proposals/:id/resolve-conflict` and
+`{ "nodeId": "...", "choice": "undo" }` until the next proposal edit or choice;
+undo restores the proposal and rechecks current live flows without deploying.
+Diffs include `conflictValues` (base/live/proposed per field, including flow
+env; redacted for AI callers), `rebase`, `liveChanges` and (without conflicts)
+`vsCurrent`, the merged deployment. Approval requires the reviewed `mergedHash`
+when editor changes are merged. Proposals expire after `proposalTtlDays`
+(integer 1–365, default 7), editable through the settings API. Approve may send
+`deploymentType`: `nodes` (default), `flows`, or `full`. Approval rebases
+against the current revision; conflicts leave the proposal open for resolution.
+Deploy timeouts keep it **pending**; other deploy errors mark it **failed**.
+Reject never mutates flows.
 
 ### Flow runtime adapter
 

package/ai-access.html

@@ -14,7 +14,7 @@
     }
     window.__com55AiAccessSidebarLoading = true;
 
-    var EDITOR_SIDEBAR_ASSET_VERSION = '0.2.0-beta.6';
+    var EDITOR_SIDEBAR_ASSET_VERSION = '0.2.0-beta.8';
     var root = (RED.settings.httpAdminRoot || '/').replace(/\/$/, '');
     var src =
       (root || '') +