28 Commits

Author	SHA1	Message	Date
Anso	38ee4527b1	feat(git): add GitOps revision store and Direct apply transitions (#1835) ... * feat(git): add GitOps revision store and Direct apply transitions Adds the canonical GitOps revision state model: schema, store, history, approval resolution, Direct apply transitions, and a first-cut read projection. Also widens recovery capture with generation, artifact, and source-acceptance bindings, rejects credentials and query strings in new Git repository URLs, and keeps Blueprint and node-label routes on the hub. * feat(git): add create-from-Git activation and teardown transitions Adds the durable half of create-from-Git: the single transaction that persists the application, resolved commit, generation, checkpoint, and candidate together, and the teardown that tombstones a create which never reached its success boundary. Adds the staging marker and operation-owned cleanup rules that decide what a crashed create is allowed to delete. * feat(git): make create-from-Git crash-safe Wires the create path through the GitOps state model: the staging marker is written before the candidate is built, the activation transaction persists the application, generation, and checkpoint together, and the source row plus accepted pointers now commit as one success boundary. A create that fails before that boundary removes only what it staged, then tombstones itself. The managed-area sweep no longer deletes a directory it cannot prove it owns, counts in-flight creates as claimed, and is awaited at startup so an interrupted create is settled before any mutation service runs. * feat(git): settle interrupted create-from-Git at startup Adds boot-time recovery for creates a previous process left in flight. A create whose project was already committed to disk is finished, including its source row and accepted pointers. Anything earlier has its files removed first and is then tombstoned, so the stack name becomes usable again instead of staying locked by a half-created application. A source row that outlived its application is always preserved. * fix(git): close create-from-Git ownership and reporting gaps Removes two ways a failed create could destroy files it did not own: boot recovery no longer deletes a stack directory the create never recorded making, and the managed-root teardown is gated on having created that root. Cleanup now rejects a path that is not a generation directory, so a malformed row cannot widen the blast radius. A create that fails during materialization now clears its staging marker, which previously stayed behind and made the stack name uncreatable until restart. Generation paths no longer resolve through a module cycle that left them pointing at a directory that never existed. Boot recovery restores the deploy spec and manifest cache a finished create needs, settles each application independently so one bad row cannot strand the others, and distinguishes a missing directory from one it could not read. A create that succeeds now clears its checkpoint, and a failure after the success boundary says the stack was created rather than reporting a bare error. * fix(git): reap managed areas that nothing has ever claimed The boot sweep now distinguishes a missing staging marker from an unreadable one. A missing marker means no stack, no create, and no marker claims the directory, which is the ordinary orphan a crashed stack deletion leaves behind, so it is removed as it always was. An unreadable marker is evidence of a claim that cannot be verified, so the area is preserved. Without this an orphaned managed area survived every boot forever, since a completed create deletes its marker and nothing else would ever claim it. * feat(git): complete the Direct source and target transitions Adds the remaining Direct events the state model owed: an invalid fetch that advances the resolved commit without minting a candidate, a blocked candidate that is visible but cannot apply, dismissal that leaves the running workload alone, material configuration change that invalidates a staged candidate while keeping accepted and applied pointers, the two deploy failure classes, and application and target tombstones. Widens the application update to every mutable column. It previously wrote about half of them, so a transition assigning a pause, suspend, recovery, or intent field would have type-checked, appeared in the history snapshot, and been silently dropped at commit. * feat(git): record Direct Git operations in the revision state Wires fetch, apply, and detach through the state model. A pull records the fetch and, when it produces a candidate, the generation behind it, marking a blocked change plan as a blocker that cannot apply. An apply records the acceptance that binds the generation to the workload, and closes its operation on failure so a throw cannot leave the source reporting work in progress. Detach tombstones the application and its target in the same transaction that removes the source row. Every producer is a no-op for a stack with no live application, so installs whose Git stacks predate this model are untouched until migration runs. * test(git): cover the Direct Git producers end to end Adds a harness that stubs only the git transport and rollback capture, so fetch, candidate materialization, change-plan classification, apply, and detach all run for real and are asserted against the resulting revision state. Covers the seam the transition-level tests could not: that a fetch advances the resolved commit without moving the accepted generation, that the apply binds the exact candidate the fetch recorded and its acceptance proves that generation and no other, that detach tombstones while keeping configured identity as a frozen fact, that a failed fetch closes its operation and leaves every pointer alone, and that a stack with no application produces no writes. * feat(git): bind the deployed generation from the Compose adapter Makes ComposeService the sole producer of deploy events. Every deploy path funnels through deployStack, so recording it there keeps one start and one terminal row per mutation instead of each caller reporting its own. A successful deploy binds the applied generation, a failure records the class and leaves the deployed pointer alone. The class is conservative: once the compose command is handed off we cannot prove the workload was untouched, and claiming it was intact is the more dangerous error. A stack with no live application, or one with nothing applied, has no deploy identity to record and is skipped entirely. * feat(git): promote healthy and last-known-good from health verdicts A stack health run now records which generation it observed, and its verdict drives the revision state. Promotion is narrow by design: healthy and last-known-good move only when the run passed, watched the whole stack, and the generation it watched is still deployed. A stale or service-scoped verdict records history and moves nothing. Last-known-good keeps the artifact expectation only when that expectation belongs to the promoted generation. Otherwise the generation is still good and its executable identity simply is not proven, so the pointer is left null rather than borrowed from another generation. beginStack now takes the deployed generation explicitly rather than reading current state, because a verdict is only meaningful for the generation the run actually observed. Update-path callers pass null until updateStack reports what it deployed. * feat(git): bind the deployed generation on the update path Gives updateStack the same treatment deployStack has: it opens a deploy operation at the point Compose is handed the mutation, closes it on both outcomes, and reports the generation it bound. The orchestrator carries that binding through, and all five update call sites now pass it to the health gate instead of null, so a passed health run after an update promotes healthy and last-known-good exactly as it does after a deploy. The operation is opened at the compose call rather than at entry, so an update that fails during capture or classification records nothing: it never touched the workload, and reporting a deploy failure for it would make the projection claim something that did not happen. * feat(git): track linked stacks and material config changes Linking an existing stack to a Git source now brings it into the revision state: the application starts live with nothing desired or accepted, so the projection asks for a fetch rather than claiming a state it has not observed. Editing a source's material configuration invalidates its staged candidate in the same transaction that writes the row and clears the pending pull. A candidate built from a different repository, ref, or file set can no longer be applied, and clearing pending without invalidating it would leave the model offering an apply the operator cannot produce. Credential-only and policy-only edits change nothing material and leave the candidate alone. * feat(git): retire the application when a stack is deleted Stack deletion now tombstones its GitOps application and targets in the same transaction that commits the deletion. A deleted stack that kept a live application would go on claiming the stack name and block re-creating it through the unique live-application index. The tombstone is driven from the deletion service rather than from inside DatabaseService, so the store keeps its transitions and their history in one place and the two modules do not form an import cycle. * feat(git): retire node targets when a node is removed Deleting a node now tombstones the GitOps targets that lived on it, in the same transaction as the delete and while those rows still exist. Otherwise a part-way failure would leave targets pointing at a node that is gone. Applications stay live: a Direct application still describes a real stack, and a Blueprint one may have targets on other nodes. Both the local and remote node paths go through the same helper, so neither can skip the retirement. * feat(git): add proof-bound recovery transitions A restore moves a target back to an older generation, the one case where a target and its application legitimately disagree about what is current. These transitions decide what may move with it. Pointers move only when the restore is provable: the recovery point named a generation, that generation still exists, and it belongs to this application. The artifact expectation comes from what the recovery point captured, never from what the application expects now, and the acceptance is kept only if it still proves the restored generation rather than borrowing one that authorized a newer one. A last-known-good survives unless the generation behind it is gone or turns out to belong elsewhere, and then the reason is recorded so the projection can say unavailable rather than none. An unproven restore is still recorded as a real operational recovery and moves nothing, because there is no evidence to move pointers to. * fix(git): close GitOps operations that cannot be recorded Recording a transition still never fails the operation it describes, but a rejected terminal event no longer leaves that operation open. A start that never terminates reported work in flight for ever and offered no actions, and because a new fetch refuses to open a second operation, one rejection silently stopped the model tracking that stack until a restart. Startup now reclassifies operations the previous process left open, which the transition already supported but nothing called. An interrupted restore is closed there too, since only the terminal recovery events clear it. The pull records its fetch, generation, and candidate as one transaction, and the apply verifies the candidate was built from the commit being applied. Separately those two allowed an apply to accept a generation whose files were never on disk while the projection reported the older commit as current. Also: the candidate now records its own invocation rather than the one it replaces, changing material configuration is refused while an operation is in flight, a tombstoned target cannot be repopulated by a late health verdict, a deploy handle is not returned when its start was not recorded, the mutation handoff is marked only once Compose is genuinely about to receive it, and a rejected tombstone fails one deletion rather than aborting the boot sweep. * feat(git): record why unprovable evidence was dropped The projection carried a limitations array that only read-time derivation ever wrote to. When a transition cleared a pointer it could not prove, the result was indistinguishable from that pointer never having existed, and in two cases it made the target read healthier: a dropped artifact expectation silently disables the runtime drift check, and an unproven restore left every pointer agreeing with itself so the target reported as synced and healthy. Adds a persisted, fail-closed evidence record on the application and target rows. The transitions that drop an artifact expectation, a last-known-good artifact, or a source acceptance now say why, an unproven restore is marked as such, and the deriver folds all of it into the limitations the projection already exposes. Clearing a code when the evidence becomes provable again is part of the contract, so a stale doubt cannot outlive its cause. This lands before the migration matrix because migration is the largest producer of evidence that cannot be proven, and the plan requires those to surface as bounded limitation evidence rather than as fabricated pointers. * feat(git): migrate pre-existing Git stacks into the revision state Git stacks created before this model had no application at all, so every producer was a no-op for them and the projection could not describe them. They are now brought in at boot. The governing rule is that a canonical pointer is written only when the evidence proves that exact generation under the repository and ref configured now. A legacy applied commit is not that proof on its own: the manifest may be gone, unreadable, or stamped for a repository the stack no longer points at. In each of those the commit is kept as recorded limitation evidence and the pointers stay null, so the stack asks for a fetch instead of asserting a state nobody verified. Deployed, healthy, and last-known-good are never invented, because a manifest proves what was materialized, not what is running, and no source acceptance is written because nobody approved through the model. Replay is decided by scope, schema version, and configuration fingerprint. A changed fingerprint re-runs the matrix, but a stack that already has an application is skipped rather than rebuilt, so migration cannot overwrite pointers written with proof it does not have. A stack whose directory has vanished migrates to a tombstone rather than claiming a name it cannot back. * feat(git): record rollbacks in the revision state A restore now opens a recovery in the model before any file moves, so a crash mid-restore leaves a target that says what it was doing rather than one that merely looks broken, and closes it on both outcomes. The failure is classified by whether the files had already been restored, because only a failure before that leaves the previous workload provably intact. Pointers move only when the restore is provable: the recovery point named a generation, that generation still exists, and the manifest actually restored carries the same commit and manifest version. Anything less is still recorded as a real recovery, it simply has nothing to bind, and the transition marks it unproven rather than guessing. The deployed pointer is never claimed here. This path drives Compose through a callback that reports nothing back, so binding cannot be proven and applied moves without it. * feat(git): add the deferred rollout-state transitions Retry scheduling, suspension, pause, and partial rollout complete the transition store. They have no production writer by design, but implementing them now means the deriver has no branch a writer cannot reach, and the shape a future producer has to satisfy is pinned rather than inferred from the read side. None of them is a statement about health. A scheduled retry leaves the failure that caused it visible, so a stack that keeps failing does not read as merely busy. A suspended source keeps everything it had accepted, and an operation in flight is interrupted rather than abandoned so it cannot report as running for ever. A paused or partially rolled out target keeps whatever was deployed, and the partial record never stands in for a deployed pointer. * test(git): stop the Compose producer tests reading Docker from the host Both deploy cases asserted that the compose command would reject, which was only true on a workstation with no Docker daemon. On Linux the command succeeded, the promise resolved, and the assertions failed. The compose subprocess now reports an exit code each test chooses, so the adapter is what decides the outcome rather than the machine. Only the verbs that need a daemon and travel through spawn are answered; `config` still runs for real, because a host with the CLI and no daemon parses compose files exactly as CI does, and failing that call breaks every create in the file. That also makes the bound path reachable, so the deploy test now covers it: a failed compose leaves the deployed pointer alone and classifies post-mutation, and a successful one binds the applied generation, returns it for health to bind against, and clears the earlier failure. * fix(git): contain every managed-area path at the call that uses it A stack name reaches the managed root without passing through `isValidStackName` on this path, so the marker, the cleanup, and the create's root probe all built filesystem paths from unvalidated input. Each call now resolves its target against the managed area and checks containment in its own scope, which is also the form the security scan credits: it does not follow the barrier through the shared `isPathWithinBase` helper, so the check has to sit with the call it protects. `cleanupUnclaimedManagedRoot` removes a whole root recursively and gets the same check, even though it was not among the reported calls. Clearing a staging marker can now fail, so the two boot-recovery branches that dropped the checkpoint first were reordered. Losing the checkpoint while the marker survives would report the area as settled and leave the stack name uncreatable. The deploy adapter's two failure logs built their format string from the stack name; both now use a constant format with the name as an argument. The marker and cleanup fixtures stood a bare temp directory in for a managed root, so nothing exercised the invariant these checks enforce. Both now build a real managed area over a scoped data directory. * fix(git): refuse to claim a managed area whose marker cannot be read A marker that exists but will not parse is still someone's claim, yet the write path refused only a readable foreign marker and wrote straight over a corrupt one, discarding the reason and logging nothing. A transient permission error, a marker truncated by a crash between write and rename, or a full disk all read as corrupt, and each one let a second create take ownership of an area the first still owned. Every other path in the module preserves on corrupt; this one now does too, and says why. Clearing a settled create's staging marker can fail, and reporting that as a retained create sent a reader looking for an unfinished create that had finished. It reports `marker_retained` instead. The checkpoint is still kept for the retry, so its encrypted token can outlive the create while the clear keeps failing; that tradeoff is stated at the call, because the alternative leaves a marker no later create can get past. The reaper also computed why it was preserving an area and threw the reason away, so a directory could survive every boot with nothing said about it. The containment checks these paths rest on had no tests and were silently deletable, so the out-of-area read, write, delete, and reap now have them. * feat(git): bind and observe a recovered generation A proven restore could never claim the deployed pointer, because the restore path drives Compose through a callback that reported nothing back: a caller that restored some other way resolved identically, so binding on a resolved promise would have claimed a workload nobody launched. The Compose wrapper now returns what it did, and only that answer binds. With binding reachable, a bound recovery claims its health run inside the same transaction as the pointers it describes, and arms the timer once that transaction lands. Committing the two together is the point: a crash between them would otherwise leave a restored workload nothing was watching. Anything that stops the timer starting writes the run off immediately, so an observing row never outlives the timer meant to watch it, and a reservation is never armed across a restart. The reservation is handed to the transition rather than reached for, because the health gate reports its verdicts back through the transition store and importing it there would close a module cycle. Startup now finalizes each interrupted observation on its own instead of sweeping them with one update, so the revision state hears a verdict for every run rather than watching the rows change under it. * feat(git): add the rollout-scoped rollback transitions Completes the deferred-state set. The three aliases write the same recovery columns under the same rules as the recovery events, differing only in provenance: Direct Git recovery emits `recovery_*`, and a later rollout producer emits these. Nothing in this PR writes them, which is why they are tested directly rather than through a caller. `partial` is the one failure class they add, for a rollback that reached some targets and not others. Completing has no unproven variant on purpose: a rollback nobody can bind to a generation has nothing to complete against, so it refuses without one and refuses a generation another application owns. Also covers the recovery health reservation end to end: reserving writes and links the row without arming anything, a replay reuses the run rather than opening a second observation of the same restore, arming inserts nothing and supersedes a conflicting stack gate, an unarmed reservation is written off once, and a reservation that outlived its process is finalized rather than armed. The per-row startup sweep is pinned too, since one row whose write fails leaving the others finalized is the entire reason it replaced a bulk update. * feat(git): add the Blueprint source and deployment transitions The first slice of the Blueprint work: the store side, with no production caller yet. The routes and the reconciler are wired to these next, and pinning the contract first means a caller cannot quietly satisfy a different one. What these enforce is that a terminal event names the request it answers. A deploy records the intent and candidate it was launched for, and a terminal is accepted only against that same request, matching stage and identity on one side rather than either in isolation. Without that pairing a deploy could be acknowledged out of an in-flight withdraw, or one request's intent stored against another's candidate. An acknowledgement carries the candidate from the matched request rather than from its own payload, for the same reason. Releasing an operation now releases its identity with it, and a resolved interruption is retired rather than left to match again. Both were leaking through the shared helpers: a stale identity let a later start resurrect a superseded intent as live, and a surviving interruption both reported completion as unknown for ever and let a late acknowledgement regress the target after two later deploys had succeeded. Fixing the helpers fixes the Direct paths too. A start refuses to displace an unrelated operation, which would otherwise abandon it with no terminal event and no history saying so. Observations write the latest stage, since the placement facet reads it to decide whether a stateful deployment is waiting on confirmation, and history alone could never reach a reader. Minting is left to the caller. A no-op Blueprint edit must mint no intent, because a fresh identity would invalidate acknowledgements that are still accurate. * feat(git): record Blueprint create, edit, pin, and delete Wires the Blueprint routes to the revision state. Each producer writes the Blueprint source row and its GitOps rows in one transaction, so an operator never sees a Blueprint that exists with nothing describing what it means, or an intent for a Blueprint that failed to save. The question these answer is when an edit invalidates what the fleet already acknowledged. Changing the name, the compose content, the selector, the drift mode, or whether it is enabled changes what nodes run or where, so each mints a new intent and candidate. Changing the description or the classification changes how the Blueprint reads and nothing a node can observe, so it updates the source row alone: minting there would make every acknowledgement report as stale over a reworded sentence. An edit is measured by value, not by which fields were submitted. The editor sends every field on every save, and the source layer decides what to invalidate from which keys are present, so only the keys that genuinely differ are passed down. Without that the two disagreed: rewording a description advanced the revision past the one the current intent describes and cleared the approval, while this layer classified it as metadata and minted nothing. Selectors compare by value too, so reordering a list that names the same nodes is not a placement change. That measurement also changes one behaviour: a save that alters nothing now leaves the approval alone, where before any save cleared it. Nothing changed, so nothing is invalidated. Pinning revises placement the same way a selector edit does, and re-pinning the node already pinned is not a change. Deleting tombstones the application and its live targets so the Blueprint stops claiming its slot, and withdraws nothing itself, because the route has already done that and doing it twice would record removals that never happened. The required node set is stored in a canonical order, so reordering it is not mistaken for a placement change. A Blueprint that predates the model has no application yet and is left for migration rather than given a first intent here, which would claim a starting point for deployments nobody has reconciled. Desired nodes are passed in rather than computed here: the reconciler that knows how to compute them reaches this layer, and importing it back would close a module cycle. * feat(git): record the placement a label or cordon moves A label and a cordon say nothing about any one Blueprint, but both change which nodes a selector matches. Each now revises placement for whichever Blueprints the change actually moved, by comparing the desired nodes either side of the write rather than reacting to the event. That comparison is the whole point. Labelling a node no selector mentions, or cordoning one no Blueprint wanted, moves nothing, and minting an intent for it would invalidate every acknowledgement in the fleet over an edit no node can observe. The same comparison covers a Blueprint pinned to a cordoned node: a cordon governs automatic placement only, so the pinned target still wants that node and its set does not move, without needing a case of its own. Nodes are compared as a set, so the same nodes returned in a different order is not a change either. Each route wraps its existing write and the recording in one transaction, so a recording failure cannot leave a fleet selecting on a label nothing recorded. The write itself is untouched, which keeps label validation and the per-node limit where they already live rather than restating them in a producer. Node deletion already retires its targets, so this adds nothing there. * feat(git): record Blueprint deployments by what caused them Every production write to a Blueprint deployment row now goes through one funnel that records the cause. The cause is carried rather than inferred from the resulting status, because several causes land on the same one: a deploy that failed and a withdraw that failed both read `failed`, and they mean opposite things about whether the deployment is still on the node. Recording is skipped when the status did not move, so a reconciler tick that re-asserts a state it already reported does not append a second event describing the same fact. The write still happens either way. A terminal answers the request the target says it was given, not whatever the Blueprint currently wants: an acknowledgement matched against the current intent would accept work for a revision that node was never sent. The first deploy to a node creates its target, since a Blueprint application has no targets until something is sent somewhere. Recording never fails the deployment. The rollout already happened, and turning a bookkeeping problem into a stuck rollout would be the worse outcome. The four reconciler observations record what was seen and nothing else. Preview cleanup stays outside this path deliberately: it reverses a projection nobody deployed, so recording it would report removals that never happened. * fix(git): record an Inline Blueprint coming into existence Creating a Blueprint inserted its application row directly, so the history began at the first intent and described an application nothing recorded coming into existence. Every other application-creation path emits the activation event, and the event's own definition covers this case: an Inline Blueprint inserts the application, the first intent, and the first candidate. Activation goes through a transition now, which also enforces the one thing the direct insert could not: a Blueprint gets one live application, refused rather than silently duplicated. No target is created. A Blueprint application has no targets until something is deployed somewhere, unlike a Direct one which always has the node its stack lives on. * fix(git): file withdraw failures as withdraw failures Four of the five withdraw failure paths were recorded as failed deploys. Only the thrown one was tagged correctly, and it is the rare case: a delete-lock conflict, a network error, a remote 409, and a remote non-200 all return rather than throw, and all four were filed under deploy. That inverted the thing this funnel exists to prevent. Recording a deploy failure clears the in-flight operation, so a routine "another operation is already in progress" wiped the withdraw that had just started and left the target reporting a failed deploy while the deployment was still on the node. A withdraw refused because the on-disk stack is not ours is now its own cause too, rather than borrowing the deploy-side name conflict. The status guard no longer suppresses starts. A start writes the identity that terminals are matched against, so skipping one because the row already read `deploying` let a later acknowledgement answer a request that had been superseded, reporting a node as converged on a revision it was not running. The guard now covers observations only, which is where repetition is the reconciler re-asserting a state it already reported. A newer deploy supersedes an older one so a redeploy of a stuck request can take over; anything else in flight is still refused rather than displaced with no terminal event. A rejection is logged differently from an infrastructure error, because a target the model keeps refusing holds its active slot and stops recording anything further, and that is worth seeing. * feat(git): migrate pre-existing Blueprints into the revision state Blueprints that predate the model are brought in at boot: an application, an intent describing what the Blueprint currently asks for, and a candidate marked as coming from the legacy inline record. None of it is an acknowledgement. The Blueprint revision is carried for display and nothing else, because a revision number is not evidence that any node is running what it names, and recording it as agreement would report a fleet as converged on an intent nobody verified. No targets are created for the same reason, and the candidate's required set is empty: migration records what is asked for, never which nodes currently satisfy it. An approval authorizes the intent it was given for, so a Blueprint that was never approved, or edited since, is recorded as needing reapproval rather than left blank. Blank would read the same as an approval that is merely absent. Replay is decided by the same scope, schema version, and fingerprint the Git migration uses, and a Blueprint the new path already described is skipped outright, since its rows were written with proof this pass does not have. Blueprints migrate in their own pass. Coupling them to the Git migration would let one unreadable Git stack keep every Blueprint outside the model. * fix(git): contain the blueprint stack-directory probe at its call The ownership probe resolved a path from the blueprint name and checked it through the shared helper, which the security scan does not credit as a barrier. The check now sits with the call it protects, matching the form used elsewhere for the same reason. The path was already validated, so this changes no behaviour. It surfaced now because an earlier commit in this branch rewrote the file's line endings, which made every line read as new and brought a pre-existing call into the scan's changed-code window. * feat(git): read GitOps history and carry revision state on source reads Adds the instance-local history API and the additive revision fields the source reads have been missing. `GET /api/git-sources` and `GET /api/stacks/:stackName/git-source` now carry `gitopsRevision` and `stackResourcePresent`. Only the instance that owns the files can say whether a stack directory is really there, so that answer travels with the response rather than being inferred by a reader that has never seen the filesystem. It is read through the strict stack listing: the lenient one answers a failed directory read with an empty list, which here would read as every stack having vanished and would turn an unreadable disk into an empty audit trail. Two history routes land with them: `GET /api/git-sources/history` across stacks, and `GET /api/stacks/:stackName/git-source/history` for one. Both page on `(created_at, id)` so rows written inside the same millisecond survive a page boundary, and both bound how far one request will scan. A malformed cursor or an unusable filter value is refused rather than ignored, because answering "show me the failures" with everything reads as an answer instead of a non-answer. Authorization is decided per row. A row reduces to a stack read only when it names a stack, its application is live, and the stack is present on disk; anything unprovable stays with Admin. The cross-stack routes classify every row, while the per-stack route is authorized whole by name, so reading a stack shows its full history including entries from an earlier application. That distinction is carried in the scope type rather than a flag, so skipping the row classifier without pinning the query to the authorized stack cannot be expressed. History entries record the fields each transition moved rather than a whole revision, so lifecycle for the classifier comes from the owning application row. That keeps authorization off the recorded payload entirely: an entry whose detail cannot be read still returns its identity, stage, and outcome with a stated limitation, and the decode failure is logged rather than passed over in silence. * feat(git): let auditors read GitOps history they cannot tie to a stack A history entry that cannot be tied to a readable stack fell to Admin, which left the auditor role seeing exactly what a viewer sees on the one surface it exists to read. History entries are an audit trail: insert-only, and recording the actor, trigger, stage, and outcome of every transition. The request audit log is already gated on the audit permission, so an entry whose audience cannot be narrowed now falls there too. Withholding it protected nothing in any case, since the request log already records that a Git-source mutation happened and who made it. The source collection deliberately keeps its Admin fallback. Those rows are live Git configuration, not a record of events, and a mandate to audit does not extend to reading the repository, ref, and credentials policy of stacks that were deleted or never finished being created. The fallback is now part of the requirement type rather than a role comparison, so each surface states which audience it falls back to and the compiler requires every case to be answered. * feat(git): correct remote node identities on GitOps reads A remote instance numbers its own nodes and has never heard of the hub's numbering, so every node id it reports is a statement in its own namespace. Read straight through, a hub joining two nodes showed two different machines as the same node. Four GETs now take a second hop that buffers the response and corrects those identities: the git-source list and detail, and both history routes. Everything else keeps streaming exactly as before, which is the reason this is a separate hop rather than a mode of the existing one: logs, downloads, and event streams must never be buffered, and the enumerated positions rewritten here do not appear in them. Only JSON numbers are replaced. A null node is preserved, since "no node" is a fact the remote is entitled to state and inventing one there would claim a placement that does not exist. Strings, application ids, and stack names travel untouched. The hub re-authorizes what comes back. A remote authorized its rows for the machine account the hub proxies with, which says nothing about the person behind the request, so every row is classified again against the signed-in user. To make that possible without the hub holding another instance's database, each history entry now carries the lifecycle of its owning application alongside the stack-presence answer already there. Both are validated fail-closed, and a verdict a remote might volunteer is ignored: the hub decides, the remote supplies evidence. Asking one node for another node's history is refused before the hop rather than forwarded, because the remote would answer about itself and the page would read as an answer to a question nobody asked. When the node asked for is the node being talked to, the hub translates that into a flag the remote resolves to its own default node. Only the hub may set that flag, and a remote honours it only on a proxied hop. Every way this hop can end converges on one terminal answer: rewritten, passed through, too large, undecodable, failed upstream, or abandoned by the client. A body the hub could not read never borrows the remote's success status. * test(git): assert the unlinked git-source response field by field The detach test compared the whole response to `{ linked: false }`, which stopped holding once that route started carrying the additive revision fields. The equivalent backend route test was updated when those fields landed; this one was missed. Asserted field by field rather than loosened to a partial match, so the two new fields are actually checked: a detached stack has no application to project while its directory is still on disk. * feat(git): carry GitOps revisions on blueprint, node, and drift responses Completes the additive JSON half of the revision-state read contract, so the Blueprint, node, and drift surfaces report GitOps state through the same projection the Git-source routes already return instead of leaving it unreadable. Blueprint list, detail, create, update, and pin carry gitopsRevision. Node-label add, cordon, uncordon, and node delete carry gitopsRevisions, ordered by blueprint id and covering only the Blueprints the mutation actually moved: an edit no selector reacts to reports an empty list rather than invalidating the whole catalog. Node deletion reads its Blueprint owners inside the deletion transaction and before the tombstone, which is the last moment a target row can be traced back to an application, and an orphaned target is logged rather than being silently indistinguishable from a Direct one. Both DELETEs that answered 204 still answer 204. The drift GET and re-check gain the same field alongside the existing ledger, which is untouched; no GitOps class is written into stack_drift_findings. Reads and mutations treat a projection fault differently, on purpose. On a read the revision is part of the answer, so a fault surfaces. On a mutation the write has already committed, so the revision is decoration and is built defensively: letting it throw would answer a successful cordon or a completed node deletion with a 500, sending the operator to retry a hard delete that already happened and be told the node does not exist. It degrades to an empty list and logs. Because both drift routes answer with that projection, the identity hop now intercepts them too, matching its route table per method instead of rejecting every non-GET. Left as they were, one object would carry the hub's node numbering or the remote's depending only on which route asked for it. The allowlist names a single mutation rather than opening a verb, and the hub's collection filter still keys off the git-source paths alone, so drift payloads are rewritten without being re-authorized: they are per-stack and already authorized by name before the hop. Tests cover the exact shapes, the preserved 204s, revision ordering, the empty-list cases, node deletion reporting its tombstoned Blueprints and surviving a projection failure, and the proxy's new route matching, drift rewrite, and filter exclusion. * fix(git): resolve every application a GitOps surface can own Three gaps found while building the additive JSON, all the same shape: an id or a sentinel stood in for a row, so "there is nothing here" and "the thing that should be here is unreachable" collapsed into one answer nobody could tell apart. A Blueprint application is stored with stack_name NULL, so no lookup by stack name could reach it, while the reconciler materializes every Blueprint as a stack directory of that name. A stack's Drift tab and Git panel therefore reported no GitOps at all for a stack GitOps was actively managing, while the Blueprint page reported a live application for the same thing. Stack surfaces now bridge the two through the deployment row for the asking node. The deployment row is what makes it safe: Blueprint and stack names share one namespace, so matching on name alone would let a Blueprint claim an unrelated stack of the same name on a node it never targeted. A retired application was unreachable for the same reason, because every entry point filtered to the live rows. Tombstoning deliberately keeps the configured identity and SHA pointers as frozen facts so the projection can still say what an application was, and the source deriver has a not_live status waiting for exactly that, but nothing could hand it one. A detached Blueprint or stack now reports what it was instead of reading as one that never existed. The not-applicable projection was typed so it could not carry a reason, which made a row that vanished between resolving it and re-reading it by id identical to a stack the model was never asked about. That one field widens to hold limitations, and the missing case now says so with the id as evidence. Every other missing-row path in the deriver already worked this way. Also logs, rather than silently skipping, a live application whose blueprint row is gone: with cascade off that is a real integrity fault, the placement did move, and the response would otherwise report that nothing had. Cordon and uncordon are deliberately left reporting nothing. A cordon governs whether new placements may be made, not what a Blueprint asks for, and the reconciler applies it only to new placements, so revising intent for it would invalidate acknowledgements fleet-wide over a change that evicts nothing. Two comments implied otherwise and now state the contract. * fix(git): keep stack-state resolution out of the Git-source read path Review of the previous commit found the fallback it added had reached further than intended. The resolver is now split by the question it answers. projectStackRevision answers "what Git source is attached to this stack" and stays Direct-only. projectManagedStackRevision answers "what manages this stack" and is what the drift routes use. The Git-source routes must not be answered with another application's identity, and there was a second reason: the row classifier takes the stack name from the Git-source row but the lifecycle from whatever the projection resolved, so a Blueprint application arriving there would have turned an Admin-only row into one any stack grant could read. The Blueprint that unlocked it could be the very one holding name_conflict because of that stack. The Blueprint-to-stack bridge also needed the right predicate rather than a present deployment row. name_conflict is written precisely when a stack of that name already exists on the node and Sencho does not own it, so guarding only against withdrawn admitted exactly the collision the bridge exists to prevent. It now requires last_deployed_at, which proves this Blueprint wrote the directory, and excludes name_conflict and withdrawn: the same predicate the delete and withdraw paths use. Only a live Blueprint application qualifies, since a retired one has no claim on the directory. The detached fallback no longer resolves deleted applications. Detached means the files are still on disk and still describe that stack; deleted means the stack is gone, so any directory of that name now belongs to something else and reporting the old repository and SHA against it would disclose one stack's Git identity through another's name. The authorization side already refused deleted rows for that reason, so the two now agree. Ordering breaks ties on rowid rather than a random UUID, and two partial indexes cover the new lookups, which the existing live-only unique indexes could not serve. The not-applicable variant's limitations are readonly, so pushing onto the shared frozen instance is a compile error again rather than a runtime throw. Tests cover a Blueprint claiming a stack it never deployed onto and one it hit a name conflict on, a detached Direct source projecting not_live, and a deleted one staying unresolved for a reused name. Drift fixtures move to afterEach so a failing assertion cannot leak state into the next test. * fix(git): stop the stack resolver falling through proven ownership A second review round found the resolution chain could answer with the wrong application, and that part of the previous commit was reading a state nothing writes. The Blueprint bridge returned one value for two different facts. Once the deployment row proved a Blueprint had written the directory, a missing application row for it still answered "no Blueprint here", so the chain continued to the detached-Direct lookup. A stack that once had Direct Git, was detached, and whose directory a Blueprint later took over would then report the old Direct application's repository, ref, and SHA as that directory's state. The bridge now separates "not mine" from "mine, but broken": the second logs and returns its own limitation, so the fault is visible and no unrelated identity is offered in its place. A Blueprint projection also carried the whole placement roster into a route authorized by a grant on one stack name. Targets are now scoped to the node being asked about, which is both the safe answer and the accurate one, since the question is what manages this directory here. The detached-Blueprint lookup, its index, and its fallback are removed. Blueprint retirement writes deleted, never detached, and the only detached writer is the Direct detach path, so the getter could never match and the index covered an empty set. The test that seemed to cover it built the state by hand and was green against something the product cannot produce; it now drives the real delete route and asserts what that path actually writes. The Git-source resolver goes back to live applications only. Detach removes the source row in the same transaction that tombstones the application, so a source row beside a detached one is not producible, and the route's row classifier takes its stack name from the source row but its lifecycle from the projection. Keeping that resolver narrow is what stops a resolution change from quietly moving who may read a row. The comment saying so is restored and now explains why it must stay true. * refactor(git): share the GitOps application fixture across the route tests Two test files carried near-identical 58-line GitOpsApplicationRow literals that differed only in a repo URL nothing asserted on. Both now import one helper. The drift tests also repeated a Blueprint seed and its activation across four cases, and re-imported DatabaseService per test; those become local helpers and one hoisted import, which lets the cleanup hook go synchronous. Node lookup throws on a missing default instead of casting. projectBlueprintRevisions is module-private again: its only caller is the committed-projection wrapper beside it. A third copy of the same fixture remains in git-source-routes.test.ts. It is left alone deliberately: it pins timestamps at 1 rather than now, and that file has ordering-sensitive history assertions that would need auditing first. * feat(git): mirror the GitOps revision contract on the frontend Adds the client-side read contract for the GitOps revision projection, with no consumers yet. types/gitops.ts is a hand-written mirror of the backend read contract, in the same convention as the other domain type files: the frontend never imports backend. The projection's two arms are named separately so a component can take the live one as a prop without re-narrowing, and the absent arm keeps its absent keys rather than nulls so reaching for a lifecycle status without narrowing is a compile error. The limitation code stays an open string, since the backend adds codes without a schema bump and an exhaustive switch would silently stop rendering the newest ones. lib/gitopsState.ts is the one place a facet status becomes words and a colour, so a state reads the same in a sidebar tooltip, a panel banner and the drift tab. Both maps are keyed on the closed status unions, so widening the mirror without naming the new state fails this build. Every line of copy states the condition the deriver actually tests, which is not always what the status name suggests. recovery_required is a recovery already running rather than one that is needed. candidate_ready is reached only when review is not required, so it is ready to apply, not ready to review. synced_and_healthy is also reached with the health gate switched off and never compares the deployed generation against the accepted one, so it claims neither. never_reconciled means nothing has been accepted; a fetch that produced no materialization still records its commit. pendingSourceStatus keys "an update is waiting" on the candidate pointer rather than the status name, because source_reconcile_required is reachable both from a stale candidate and from an accepted generation with no candidate at all. Retirement is excluded first: tombstoning keeps the candidate pointer as a frozen fact, so a stack detached mid-review still carries one. absentFault separates the two facts the empty projection carries. Empty limitations means the model was never asked about this stack and the right rendering is nothing; a non-empty list means an application that was expected could not be reached. A live application's limitations are caveats on state that is being reported, not faults, so they are deliberately excluded. * feat(git): name the Git source state on the stack and sidebar surfaces The sidebar indicator and the anatomy source row both read a raw pending commit pointer, so a candidate blocked by local conflicts, held for review, or stale against the configuration in force all render identically to one that is ready to apply. The projection distinguishes them; nothing was reading it. refreshGitSourcePending now derives each stack's state from the projection and the pending map carries that state rather than a boolean. Presence in the map still means exactly what it meant before, because it is keyed on the candidate pointer rather than the status name: source_reconcile_required is reachable both from a stale candidate and from an accepted generation with no candidate, and only the first is something to review. One narrow fallback remains, for a row with no projection at all: a failed GitOps write is logged and swallowed while the pending commit still commits, so the flat pointer is the only thing that can answer there. Wherever a projection exists it is the sole authority. The sidebar keeps one indicator, in the same slot, at the same size and colour, with the same position in the priority ladder. Only the tooltip changes, so a blocked plan now says so instead of reading as an ordinary update. A test asserts the rendered indicator is identical across states, which is what keeps the rendered sidebar unchanged. The anatomy source row keeps its pulsing dot alone for the ordinary case and adds the state word only for the states the dot cannot express. Inline rather than in a tooltip, since this is the reason something is stuck. * feat(git): surface derived GitOps state in the Git source and Drift panels The Git source panel's pending banner had two things it could say, read from a raw commit pointer and a single blocked boolean. It now names which of four states the candidate is actually in, so a plan blocked by local conflicts, one held for review, and one gone stale against the configuration in force stop rendering as the same ordinary update. The short commit sha stays. A new card above it reports an application the projection could not reach. That case renders as nothing at all today, which is indistinguishable from a stack the model was never asked about. Empty limitations stays silent, because that is the ordinary answer for most stacks and a header over an empty block would be worse than nothing. The summary block gains one row naming the source state. It is the first place the panel can show applying, retry scheduled, suspended, recovering, or a detached source, none of which have a pending commit and so never reach the banner. Both existing rows are untouched and the last applied commit stays a display fact. The revision lives in its own state rather than on the Git source type, because the PUT that saves this panel answers with a bare source and no revision. A save drops it instead of rendering a state the write has already moved. The Drift tab gains a third block below the two it already has. The compose versus runtime card and the since-last-deploy card keep their exact positions and copy; the new block answers a different question, which generation this node was asked to run and whether it got there. A Blueprint-owned stack shows its target rows and no source card, since a Blueprint application has no Git source and inventing one would be a claim the model never made. The drift class list renders against the type and expects no rows, because nothing populates it yet. * feat(git): declare revision fields on the blueprint and node clients Types first. The blueprint list, detail, create, update and pin responses all carry a GitOps revision, and the node label add, cordon, uncordon and delete responses carry a list of them. None of that was modelled, so the fields were being dropped silently and the next reader would have taken these for bare records. Most of it is declared and deliberately unread, with the reason written where the type lives. Create, update and pin are followed immediately by a re-read of the catalog or the detail that carries the same projection, so rendering the mutation's copy would show the same fact twice with one of them stale. Cordon and uncordon always answer with an empty list by design, because a cordon governs whether new placements may be made rather than what a Blueprint asks for, and the reconciler leaves existing deployments where they are. The comment on that type is the point: the risk there is a future reader building a consumer for a list that is never populated. Two places do report something. Deleting a node and adding a node label both re-place Blueprints, and both now say how many. The count only, and only when it is not zero: an empty list means both that nothing moved and that the projection faulted after the write had already committed, so it can never be reported as the first. Blueprint detail gains the same unreachable-application card the Git source panel has. A Blueprint with no live application row is a fact nothing in the product could previously express, which is a different problem from having two ways to say the same thing. * fix(git): close the gaps review found in the GitOps frontend consumers Six defects, each verified against the code before being fixed. The pending-map read assumed every /git-sources row carries a projection. That route is proxied, so a node predating the model answers rows without one, and dereferencing it threw inside the loop. The catch swallowed the throw, the map was never set, and every stack's Git indicator froze at its previous value for as long as that node was selected. The field is optional now and a row without one falls through to the same branch as a row with nothing to project. That fallback also branched on the arm alone, so a projection reporting an unreachable application plus a stale commit pointer was reported as a candidate ready to apply. It now excludes a faulted projection: a fault means an application was expected and could not be read, so the pointer is not evidence that anything is ready, and naming a state there would be a guess. Detaching a Git source cleared the source but not the revision, and the pending card is derived from the revision alone. The panel kept advertising a waiting commit for a stack Git no longer managed, behind a Review button that silently did nothing. A read that threw had the same problem across stacks: the panel is reused, so stack A's state could render under stack B's header. The panel also lost the flat-pointer fallback the sidebar keeps, so the two surfaces disagreed: the sidebar would show an indicator and clicking through showed no card. Both now apply the same rule. Node delete parsed the success body unguarded. The delete has already committed at that point, so a malformed body would have reported a completed deletion as a failure and skipped the refresh, leaving the deleted node on screen. Tests: five mutations that previously survived now fail. The zero-pixel claim compared the wrong element and passed when the indicator vanished entirely; the stale-read test asserted during the loading window, when the body is skeletons regardless; the sidebar passthrough test proved only that an indicator existed, not that the state reached it. Added coverage for the drift row, an unknown node, the not-applicable source guard, the save clearing, the Review button, and a live application carrying a caveat, which must not read as a fault. The fixture set drops two source statuses whose identity defaults describe a state they cannot be in, and gains a drift-item builder. * refactor(git): share the GitOps fault card and live-facet derivation The unreachable-application card was built inline on three surfaces, and the copies had already drifted: the Git source panel used one icon while the Drift tab and the Blueprint sheet used another, so the same failure rendered two different ways. It is one component now, which also owns the state key and the test id those surfaces assert on. Deriving the live source facet was likewise repeated, along with the two semantic decisions behind it: the absent arm has no facets, and a source facet of not applicable means a Blueprint owns the stack rather than that something is missing. Both now live next to pendingSourceStatus, which already encoded the same exclusion. The Git source panel's seven derived values collapse to three, with the pending-commit rule extracted to a named function so the four cases read straight through instead of as nested ternaries. Behaviour is unchanged in every case. The two flat-pointer fallbacks are deliberately not unified: they look alike but the panel also treats a live application whose source facet is not applicable as unanswered, and merging the predicates would change what that case renders. * feat(git): count and announce committed GitOps transitions Every history row that is actually inserted now produces one metric increment and one state-invalidate event, so the surfaces that read GitOps state hear about a change instead of waiting for the next poll. Announcement is buffered and drained on a macrotask rather than fired inline. better-sqlite3 is synchronous, so waiting for the macrotask puts the drain after the transaction that wrote the row, and after any outer transaction wrapping it, without having to detect which nesting depth it is in. The drain confirms each row is still present before announcing it, so a rolled-back transaction says nothing on its own, and the insert declines to queue a dedupe replay, so a retry says nothing either. The broadcaster is injected at startup rather than imported, keeping the GitOps layer free of a cycle back into the notification stack. Counters are process-local and in-memory, and their keyspace is finite by construction: history stages are now a closed union that the build enforces, and outcomes were already a closed set. The payload names no stack, node, repository, or actor, because a counter carrying those would be an audit trail with no retention rules and no per-row authorization, which is what the history routes provide. GET /api/gitops-metrics is Admin-only and instance-local, so selecting a node answers with that node's counters. On the client, a gitops-scoped invalidate refreshes the derived state through a 250ms trailing window, matching the existing stack refresh. One operation commits several transitions in a row and a first-boot migration commits a great many, so refetching per event would thrash the API for a picture that only settles at the end. * feat(git): show GitOps source state on the stack dashboards The dashboards list every stack on a node, which is where a fleet-wide reading of Git state is most useful and where, until now, a Git-backed stack looked exactly like a local one. Each row that the model has something to say about carries a chip naming its source state. The chip reads from the same status vocabulary the panels and the sidebar use, so a stack cannot be "pending update" in one place and something else in another. It sits beside the stack name rather than replacing the source column: the column says where the files come from, the chip says what GitOps makes of them, and those are different facts. The label is a word and the title is a whole sentence, so the state never rests on colour alone; the phone rows keep the word on screen, since touch has no hover. The join is by stack name, which is what the dashboards have, and its source is the same proxied route the sidebar reads. A row without a revision, a Blueprint-owned application, and a projection fault all leave the stack unbadged rather than inventing a state for it. State arrives by announcement rather than by poll, since it only moves on a transition, and a node switch blanks the map first: stack names repeat across nodes, so a slow answer for the node just left is discarded rather than allowed to label the wrong stacks. * feat(git): say which part of a GitOps state could not be proven Eighteen conditions can qualify a live projection: a manifest that does not match the branch configured now, an approval that could not be restored after a recovery, an artifact record that has gone. Every one was already recorded and none of them reached the operator, so a state with a hole in it read exactly like one without. Each now has operator wording under the state it qualifies, checked against the site that emits it rather than against the code's name, since several names describe something narrower or wider than the condition actually tested. The stored messages stay out of the UI: they are written for a log reader, and some are raw decoder errors. The presentation is deliberately quiet. A caveat is not a failure: the state above it is real, and one piece of evidence behind it is missing, so the reader learns which part to distrust without being told the whole thing is broken. Faults keep their own card, because those replace the state rather than qualifying it, and the two arms are read through separate helpers so neither can be rendered as the other. A code with no wording names itself rather than vanishing, so a node running ahead of this build degrades to something honest instead of reporting full confidence in a state its own backend flagged. * fix(git): record a stateful first placement and keep a half-built Blueprint editable Two faults that today's product cannot reach, and that the Git-backed Blueprint mode would reach immediately. The live-application lookup answers with an application that is active or still being created, because its other callers ask whether the Blueprint already holds the live slot, where a half-built row counts. Three producers passed that answer straight into transitions that accept only an active application and reject anything else by throwing, inside the caller's own transaction. A Blueprint edited or pinned while its application was still being created would have failed with a server error and rolled the Blueprint write back with it. The producers now narrow to what they actually require, through one shared predicate, leaving the slot check honest. Separately, a stateful placement is held for operator review before anything is deployed, so no target exists when that hold is recorded, and the observation was dropped for want of one. The hold left no trace: no history row, and nothing on the target to say the node had been asked to hold anything. First contact now creates the target, exactly as the first deploy does. Nothing else changes with it: no intent, no generation, no operation, and connectivity stays unset, because a node that has only been asked to hold something has not been contacted. Observations that follow a deploy already have a target, so they are unaffected, and a drift or evict report for a node nothing was ever sent to is still dropped. * fix(git): keep the Git source panel's state after a save The save answers with the source row and no revision, so the panel had nothing to replace its copy with and dropped it. The result was a stack that had just been reconfigured showing no GitOps state at all until the panel was reopened, which reads as a stack the model knows nothing about rather than one whose state has just moved. It re-reads instead. Keeping the old copy was not an option either: a material configuration change clears the staged candidate server side, so the state genuinely has moved and the panel would have gone on offering a commit that is no longer there. Only the server can say what replaced it. The alternative was returning the revision on the save itself. That route is proxied, and the identity hop rewrites node numbering for an enumerated set of routes, so adding a revision to a response outside that set would hand back a remote node's numbering unrewritten. Re-reading costs one request on a low-frequency action and needs no change to the hop. * docs(git): document what GitOps state means for an operator A commit SHA says which files Sencho wrote. It does not say whether that commit was accepted, whether something newer is waiting, or whether an operation was interrupted halfway, and until now the docs had no words for any of that. Git Sources gains a source-state table and a section on what happens when part of a state could not be proven, since a stack with missing evidence looks identical to one with complete evidence unless the product says otherwise. Drift Detection gains the gitops section and explains why it answers a different question from the two signals above it: those compare files and containers as they are now, this reports what has been proven over time. The dashboard page describes the state chip and, importantly, that it and the row tint are independent, so a healthy row carrying "pending update" is not a contradiction. The Blueprint page now separates its revision counter from GitOps state. The counter labels the spec; it says nothing about whether a given node has got there, and reading it as fleet truth is the mistake the note prevents. The tutorial's verification step names the source state it should show, so a reader can tell the difference between files written and a commit accepted. Audited and left unchanged: health-gated updates and fleet federation. Neither presents a SHA or a revision as canonical GitOps truth, so neither needed correcting. * docs(git): name which saves actually clear a staged commit The note claimed saving the form always clears the staged commit and moves the state to reconcile required. Only a change to what gets materialized does that: the repository, the ref, the compose paths, the project directory, or the env sync. Changing the token or the apply behavior leaves a staged commit alone, because neither changes what would be written, and telling an operator otherwise would have them pull again for nothing. * fix(git): say when a committed transition has nobody to announce it to Two silences worth breaking, both found reviewing the error paths in this slice. A server that never installs the event sink still counts every transition and still writes every history row, so the only symptom is that no client ever refreshes and the UI is quietly as stale as it was before any of this existed. It now says so, once rather than per row, since a boot migration would otherwise fill the log with one fact. The dashboard's source-state fetch dropped a non-ok response without a word. A refusal there freezes every badge at its last value, which looks exactly like a fleet where nothing has changed, so the status code is logged rather than inferred from badges that stopped moving. * fix(git): close the defects review found in the announcement slice Five findings, two of them able to reach an operator. The event sink was installed one line after the deletion reconcile, which tombstones applications and targets and awaits inside its own loop. A drain therefore landed while the sink was still absent, so those boot-time transitions were counted and never announced, and the warning added for an unwired sink would have fired on every boot with a prepared deletion intent: the fastest way to teach an operator to ignore it when it means something. The sink now precedes every reconcile and migration pass. The first-placement target was created outside the transition that records it. The observation runs in its own savepoint and can refuse, and the caller deliberately lets the deployment commit whatever the record says, so a refusal left an active target with no generation, no stage and no history: a placement relationship the model never established, which the delete path would later tombstone as if it were real. Both writes now succeed or fail together. The badge looked its status up in a map closed at compile time, behind two casts, while the value arrives over a proxy from a node that may run a newer vocabulary. An unmapped key dereferenced undefined inside a stack row and would have taken the whole table down with it. The facet and its status are now a discriminated union, the lookup is optional, and an unrecognised status renders nothing, which is what the join already does for a stack it has no state for. The dashboard's source-state loop derived each row inside the shared try, so one row in an unexpected shape abandoned the loop and froze every badge at its last value with nothing on screen to say so. Each row is now guarded on its own and the count of unreadable ones is logged. Two tests claimed things they did not check: both asserted a word was on screen with a matcher that also matches screen-reader-only text, so a compact badge would have kept them green, and one compared a label by containment where the shorter label is a prefix of the longer. Both now assert the visible node by equality. Added coverage for the window event the dashboard actually refetches on, an unknown status, a row that cannot be read, node-switch blanking, and a caveat recorded twice. One fixture built a status pair the deriver cannot emit and was corrected. Also: the guard narrowing Blueprint producers to an active application excludes nothing today, because every Blueprint-mode application is inserted as active and only Direct mode can be creating. The guard stays, since the getter's slot semantics and the transitions' requirement have drifted apart once already, but its rationale and its tests now say plainly that they pin a defensive guard rather than reachable behaviour. * refactor(git): make three runtime guards visible to the compiler Type review found the same shape three times: a correct guard whose necessity was asserted in a comment the type system could not see. This project does not set noUncheckedIndexedAccess, so each of these read as dead code to anything that trusts the types, and the guards protect the behaviours that matter most here. The limitation copy map typed its values optional, so the fallback for an unrecognised code is now something the compiler requires rather than something a comment explains. The badge reads its status through partial views of the two vocabularies, so a miss is a fact TypeScript derives: deleting the guard that stops one unknown status taking down a stack list now fails the build, where before it compiled. Neither needed a cast. The event payload has to be a type alias rather than an interface, because only the former gets an implicit index signature and the broadcaster takes an open envelope. That requirement now fails at the declaration instead of surfacing in the startup wiring as an unexplained index-signature error. Also added the reverse of the copy-coverage check: a code retired from the backend leaving stale wording behind was invisible, since the fallback only fires for entries that are missing rather than ones that linger. * fix(git): make the state cards survive an unknown status, and correct the copy Comment review found the protection added for the dashboard chip was claimed more widely than it held. Five other surfaces indexed the status vocabularies directly and passed the result straight to a card that dereferences it, so the exact input the comments said would take a list down still threw in the Git source panel, the Drift tab, the sidebar tooltip and the stack anatomy row. The card now takes an optional state and renders nothing without one, which also means a new surface cannot reintroduce the dereference by rendering a card the ordinary way, and the remaining four read through the lookups. Copy corrections, each against the site that emits it rather than the name of the code: The manifest-identity caveat said the manifest named a different repository or branch. It also fires when the manifest has no identity block at all, or identifies another node or another stack, so it now says it does not identify this stack on this node from the repository configured now. The last-known-good artifact caveat covered a mismatch but not the row being gone, which is the other half of the same condition. Doc corrections: a Blueprint-delivered stack was described as carrying the dashboard chip and a source state on the Drift tab, and it carries neither, because a Blueprint has no Git source of its own. Per-node Blueprint state was attributed to the detail sheet's GitOps section, which only reports what could not be read or proven; the Deployments table is where per-node status lives. Clearing a staged commit was said to always land on reconcile required, but a stack that has never had a commit accepted lands on never reconciled. The caveat lines were described as sitting under the state when they render above the form. And the pending banner was still documented as webhook-only, which this branch changed: it now appears for any staged commit and its heading is the source state. Also corrected two claims in the code: the observation branch does not skip for a Blueprint that migration brought in, because migration creates no targets, and the only refusal reachable from that call site is a tombstoned target. * refactor(git): simplify the announcement slice without moving any behaviour A simplification sweep over the new code, all of it behaviour-preserving and re-checked by breaking each guard afterwards. The drain now separates policy from mechanism: it decides whether a row survived, counts it, and either warns or hands it to a small announce helper that owns the envelope and its error handling. The row-to-state pass in the dashboard hook lifts out of the fetch, so one function does the request and another does the derivation. The caveat dedupe collapses to a set, which preserves first-insertion order and so keeps the ordering its own docstring promises. The badge renders one span with a conditional class rather than two that differed only by class. The metrics service drops an internal type that was byte-identical to the one it exports. One assertion goes: the observation branch tested membership and then re-asserted the same fact to index the stage map, and a type predicate lets the compiler carry it instead. Everything the sweep was told to leave alone is intact: the buffered drain, the row-existence re-check, the injected sink, the one-shot warning, the partial-view lookups and their guards, the optional copy map with its fallback, and the generation counter with its per-row guard. * fix(git): close audit findings in the GitOps revision model Five corrections from the pre-merge audit of this branch. Migration no longer certifies a commit it cannot prove. The manifest read now carries its resolved commit, and a manifest that names a different commit than the source row records as applied is refused: the applied directory materializes one commit while the row names another, so trusting them together would mint a generation pointing at files that are not the ones it claims. A manifest that names no commit at all, which is what adoption writes, is a separate answer rather than a disagreement, because reporting it as one would name a commit the manifest does not contain. Both are recorded as evidence and the projection asks for a fetch. Create cleanup proves containment against the real filesystem before it deletes. Every check on these paths was lexical, so a symlink or Windows junction above the target read as contained while the recursive delete followed it out of the managed area. Resolution keeps "is not there" apart from "could not be read": only a genuinely missing path lets the walk climb to an ancestor, because treating an unreadable one as absent would infer containment for the single path whose link status could not be established. Both sides are resolved, so relocating the data directory onto another volume keeps working, and an area that does not exist at all is nothing to delete rather than a suspected escape. The marker write takes the same barrier as the marker delete, so a link cannot be written through and then refused on the way out, wedging the stack name. Startup stops while an interrupted create is unresolved, matching the restore reconcile above it. A create that could not be settled leaves a stack directory the deploy path cannot tell apart from a finished one, so the alternative to stopping is letting a scheduler, webhook or operator act on a half-built stack. Only that blocks: once the staged directories are gone the create is torn down, and a staging marker nobody could unlink is reported rather than thrown, so one failed unlink is not the difference between an instance that boots and one that does not. Per-stack history no longer exposes a predecessor through a reused stack name. The grant covers the application holding the name now, which is what keeps a stack's own entries readable while it is still being created; every other row on that name is classified per row, so entries belonging to an application that held the name earlier need the audit permission, as they already did across stacks. A detached predecessor is still readable, which is the classifier's own standing decision about detach rather than a gap here, and is now pinned by a test. Blueprint observations reach a reader. The reconciler recorded state review, evict blocked, drifted and correcting against the target and nothing projected them, so a deployed Blueprint could report itself as never applied. The runtime facet now projects all four, below the states a live or failed mutation puts the target in and above the pointer checks, and any later transition supersedes the observation. The map is declared total over the stages the reconciler can record, so a stage added without a projection fails the build rather than silently reading as never applied again. * fix(git): confine managed-area cleanup to each stack's own location Cleanup proved only that a resolved path landed somewhere inside the managed area. That is satisfied by every other stack and every other node in it, so a link from one stack's generations directory into another's passed the check while the delete took a generation belonging to someone else. The check is now positional: the managed area is resolved once, so relocating the data directory onto another volume still works, and every segment below it must be reached without redirection. The create-path sinks use it on the write as well as the delete, so a claim cannot be written through a link and then refused by the hardened delete, and the manifest service's pre-existing deletion sinks (generation pruning, boot-sweep orphan reaping, detach staging and finalization, and whole-area removal, including after a restored snapshot) run it before their recursive deletes too. Each of those sinks also keeps a literal containment comparison beside the positional check, because static analysis credits only a comparison at the call and reports the delete otherwise. A refusal names both paths in the log, because it can hold the boot gate. Boot recovery dropped the checkpoint of an application that had left the creating state without first clearing its staging marker. That left a claim on the stack name with nothing to retry it, and every later create for that name was refused by a marker nothing could remove. The settled branches now share one exit, so the marker ordering holds for all of them. A detached application's history was readable on a stack grant because its files are still the stack standing at that name. Nothing in these tables can prove it still is: a Blueprint successor records the name off the application row, and a plain Compose stack recreated at the name leaves no trace at all, so no detection-based allowance can be made sound. Detach now moves an application's trail to the audit audience outright, the same answer deleted and creating predecessors get, while reading the stack itself stays where it was. * fix(gitops): close four audit findings in revision state and identity proxy A1: derive runtime and health against target desired_generation_id - deriveRuntime returns 'applied_not_deployed' when desired != deployed, so a stale deployment stays deploy-pending instead of reading synced_and_healthy - deriveHealth judges against desired_generation_id falling back to deployed when null; control case proves null-desired rows unchanged - collectRuntimeDrift emits the plan-pinned runtime drift item for exact/ qualified observation mismatches; equal/non-comparable observations emit nothing; ordering pin keeps deploy question first A2: stop upstream 304 responses from bypassing hub rewrite and reauthorization - identity proxy answers no-store on every terminal (rewrite, 204, 304, generated failures); validators (etag, last-modified, cache-control, expires, vary) no longer forwarded - conditional request headers (if-none-match, if-modified-since, if-match, if-unmodified-since) stripped on the identity-hop branch of the shared proxyReq handler; streaming hop untouched (optimistic-concurrency file writes depend on If-Match/If-Unmodified-Since) - supertest integration test drives the real middleware through a loopback capture server and asserts if-none-match absent while accept survives S1: migrate legacy query/userinfo URLs via secret-free path - parseLegacyRepoUrl strips userinfo, query, fragment instead of refusing; parseHttpsRepoUrl remains the strict gate for user-driven paths - migrationDirectSourceIdentity uses the tolerant parser; operational stack_git_sources.repo_url untouched; fingerprint convergence proven - trusted-manifest-on-legacy-URL test covers the worst real-world instance S2: emit runtime artifact drift for current evidence - top-level drift array carries the seven-class runtime item; frontend comments updated to reflect backend now emits runtime drift All regression tests added and passing. CI green (7,374 backend + 2,790 frontend tests; only pre-existing Windows EBUSY teardown failure unrelated). * test(frontend): fix DriftPanel drift item rendering test Update test assertions to match the new backend drift item format. The function now renders artifact_set expected identities as 'artifact <id> · <qualification>' and runtime_artifact observed identities as the raw identity string. * fix(gitops): emit a runtime drift item for desired-versus-deployed mismatch The projection reported applied_not_deployed with no entry in drift, so the canonical drift list contradicted the runtime facet it travels with. collectRuntimeDrift now emits the r27 generation-mismatch item for that state: desired generation as expected, deployed generation as observed, ComposeService as owner. The action mirrors what availableActions offers: deploy, unless an application-level fetch or apply is in flight or a recovery is in progress, which withhold deploying without removing the fact of the mismatch. The item clears once the desired generation deploys. The stale-deployment test pins the exact item shape, its stability across re-derivation, its convergence removal, and the withheld-action case; the ordering pin keeps the artifact observation suppressed while the deploy question stands. Frontend fixture aligns its artifact-mismatch example with the backend's none action. * fix(gitops): keep generation drift visible across failure and pause states The desired-versus-deployed drift item was keyed to the applied_not_deployed runtime status, but paused, failed, recovering, interrupted, and in-flight statuses all outrank the pointer comparison in the deriver. A failed deploy of a new generation over a running older one therefore dropped the drift report exactly while the old workload was still serving. The item is now judged from the pointers themselves: known and different means reported, whatever presentation status the target carries. Retired targets are excluded because nothing can rebind them, so their surviving pointer divergence would be permanently unresolvable noise. The action follows what the payload offers: deploy only when no application-level operation or recovery withholds it and availableActions lists deploying, none otherwise. The failed-redeploy regression test pins the exact item shape after a pre-mutation deploy failure, its stability across re-derivation, continued artifact suppression for the replaced workload, and convergence removal; a second pin keeps retirement silent. * fix(gitops): complete the available-action legality matrix The action list transcribed only part of the approved rules. An interrupted apply offered apply without checking that its recorded generation was still the current candidate; deploy fired for any target reading applied_not_deployed regardless of target mode, with no retry for an interrupted Direct deploy and none of the Blueprint interruption rules; approve_legacy sat in the type union with no producer, leaving a pending Inline placement review permanently unactionable through the projection; and drift items inherited whatever deploy recommendation any sibling target earned. Actions now follow the matrix. Deploy is decided per target through one predicate shared by deriveActions and the drift items: a paused or failed sibling can no longer inherit another target's legal deploy, a Blueprint-mode divergence never advertises Direct deployment, an interrupted Direct deploy retries against the generation still applied, and an interrupted Blueprint deploy or withdraw repeats only while its recorded intent revision and rollout candidate still equal what the application requires, where an absent pair matches because inline Blueprints carry no candidate until the later-phase producer lands. Interrupted apply requires the recorded generation to still be the current candidate and the source not to have been suspended meanwhile. A reachable Inline placement review now offers approve_legacy. Six tests pin the matrix: sibling isolation across failed and paused targets, the Blueprint mode guard, vacuous and matched Blueprint retry identities plus the superseded case, matching-versus-stale Direct deploy and apply interruptions, and the legacy review action. * fix(gitops): withhold apply retry while the candidate is blocked The interrupted-apply retry checked that the recorded generation still matched the current candidate and that the source was not suspended, but a later classification can also block that candidate, and applyStarted refuses a blocked one outright. The retry is offered only when every precondition the transition enforces still holds. * fix(gitops): prove apply preconditions and limit fetch to Direct The interrupted-apply retry checked identity, suspension, and blockage but never loaded the candidate generation, so apply could be recommended for a row that was missing, owned by another application, or built from a superseded materialization fingerprint; applyStarted refuses all three, and the positive fixture itself described a state no transition would accept. The gate now proves existence, ownership, and fingerprint before offering apply. Its fixture is rebuilt around a transition-legal candidate whose projected action is executed against applyStarted, with negatives for every refusal including suspension. Fetch was offered to any application whose source looked unreconciled, but the approved rules reserve fetch for live Direct applications; a Git-backed Blueprint divergence now advertises nothing of the sort. Controls pin both modes against equivalent source state. * fix(gitops): fail closed when a candidate row is missing or foreign Ordinary candidate_ready checked a fingerprint only when the candidate generation row existed, so a dangling id or one owned by another application fell through to ready and offered an apply that applyStarted would refuse on sight. The source now requires the row to exist under this application before readiness, records a limitation for the anomaly with its operator copy mirrored in the frontend, and reports reconcile-required instead. The Blueprint retry test also pins that a superseded rollout candidate alone, with the intent still matching, suppresses deployment. * fix(gitops): fail accepted-generation derivation closed The acceptance branch compared fingerprint and sha only when the accepted generation row loaded, so a dangling id or one owned by another application fell through and reported application_generation_accepted with no evidence behind it, while also withholding fetch as the recovery. The source now requires the row to exist under this application before any comparison, records an accepted_generation_invalid limitation naming the pointer with its operator copy and inventory entry mirrored on the frontend, and reports reconcile-required instead. Five scenarios pin valid, missing, foreign, fingerprint-mismatched, and sha-mismatched acceptances. * fix(gitops): enforce canonical state in dismiss, reconcile, and pulls - Route dismiss-pending through the canonical dismissed transition so a refusal while an operation is in flight surfaces as 409 instead of clearing staged state behind the model's back - Treat tombstoned targets as authoritative in both reconciler decision surfaces so ticks never redeploy onto a placement the model severed; an explicit deploy revives the target and records the revival delta - Keep application-level rows in node-scoped history pages so proxied hub views do not read as if the application never came into being - Expose repoIdentity and configuredRef on history items to match the server-side identity filters - Stand down when a pull resolves to exactly the live candidate (same commit, source fingerprint, plan verdict); pulls after an acceptance still open a fresh staging generation as the apply target * fix(rbac): classify git-source manifest reads as stack:read GET /stacks/:name/git-source/manifest had no rule in the hub route classifier, so proxied requests were refused with 403 before reaching the remote node even for callers holding stack read access. * fix(gitops): surface an error toast when dismiss is refused as in-flight Dismissing a pending Git update while a fetch or apply is still running now returns 409 OPERATION_IN_FLIGHT, but the frontend handler had no else branch for a non-2xx response, so the refusal was swallowed with no operator feedback at all. Add the same error-toast pattern already used by the sibling apply handler, and order the success toast before its side effects so a downstream failure cannot invert the outcome.	2026-08-27 10:25:27 -04:00
Anso	c3c6c1b0c1	fix(dashboard): use balloon-adjusted memory percent on the Memory tile (#1847) ... * fix(dashboard): use balloon-adjusted memory percent on the Memory tile When balloon fields are present, the Memory tile hero, tone, and gauge bar now use effectiveUsagePercent so they match the used/total bytes. Health and host RAM alerts still use working-set usagePercent. * fix(dashboard): align health banner and Memory tile on balloon-adjusted memory The health banner read the raw working-set percent while the Memory tile showed the balloon-adjusted one, so a hypervisor ballooning an otherwise healthy VM could flag it critical. Both now use effectiveUsagePercent, falling back to the raw percent when balloon fields are absent. Host RAM alerts keep the working-set percent: ballooned pages are reclaimed by the hypervisor and cannot be recovered by the guest on demand. Adds guarded context lines to the Memory tile: Current VM Memory (guest retained), Current pressure (effective used over retained), Balloon reclaimable, and, for ZFS nodes, Current memory in use (used plus ARC reclaimable) above ZFS ARC reclaimable. Validated with unit tests for both components including boundary cases, type checks, lint, and visual regression comparison confirming no change outside the Memory tile.	2026-08-24 05:57:06 +00:00
Anso	71be1634a5	feat: surface ZFS ARC reclaimable as dashboard context line (#1760) ... * feat: surface ZFS ARC reclaimable as dashboard context line Add arcReclaimable to the HostMemory interface and MemoryWire shape so the reclaimable ARC amount computed by readReclaimableArc() is exposed through /api/system/stats and /api/fleet/overview. Show it as a context line on the dashboard memory tile, matching the balloon pattern. ARC continues to feed the gauge percentage as before; this is a display-only addition for operator visibility. * docs: clarify ARC line requires nonzero reclaimable, not just readable stats	2026-08-03 13:44:20 -04:00
Anso	c613010199	feat: account for VM memory ballooning in host memory reporting (#1750) ... * feat: account for VM memory ballooning in host memory reporting Extend hostMemory.ts with a readBalloonedMemory() function that parses the Balloon: field from /proc/meminfo, following the same fail-open pattern as the ZFS ARC integration. When a nonzero balloon is detected, effective memory fields (effectiveUsed, effectiveFree, effectiveUsagePercent) are computed and exposed through /api/system/stats and /api/fleet/overview. All consumers that derive meaning from host memory now prefer effective values when present: the dashboard gauge, Fleet card RAM bar, mobile views, health verdict, health status bar stat tile, and host RAM alerts. Backward compatible: missing /proc/meminfo or absent Balloon: line preserves exact current behavior. Old remote nodes without the new fields continue rendering normally. * refactor: extract shared helpers for balloon memory wiring Extract readCandidateFile() and logSelectedPath() in hostMemory.ts to deduplicate ARC and balloon file-read logic. Add memoryToWire() to centralize the optional-field spread used by /api/system/stats and /api/fleet/overview. Add getNodeMemUsed()/getNodeMemTotal() helpers in nodeUtils.ts for frontend byte-text consumers. * fix: make desktop fleet masthead aggregate balloon-aware The desktop fleet overview's memory aggregate in useFleetOverview.ts still summed raw memory.used, while the mobile fleet aggregate and per-node cards already used effective values. Update to use getNodeMemUsed/getNodeMemTotal helpers. * fix: revert balloon adjustment from alerting and health decisions Ballooned memory is host-reclaimed (unlike ZFS ARC, which the guest can reclaim on demand). The guest cannot get ballooned pages back until the hypervisor deflates them, so treating ballooned memory as available for alerting or health can mask real memory pressure. Keep balloon parsing, wire fields, and the dashboard context line as informational-only. The memory gauge, health verdict, and host RAM alerts now use the standard ARC-adjusted working-set percentage regardless of balloon. Updated configuration.mdx and dashboard.mdx to document that balloon data is informational and does not influence alerting.	2026-08-02 20:48:38 -04:00
Anso	b1decbb32a	docs: v1 docs refresh (batch 7) (#1627) ... * docs(introduction): refresh screenshots and correct stale nav/tab coverage Replace all 5 screenshots with fresh 1920x1080 production captures. Document the shipped Take down stack action, the Compose Labels stack tab, and the Docker Labels Fleet tab, none of which were mentioned. Correct the Console nav item to note it is a limited-availability surface rather than a plain role/tier-gated view. * docs(quickstart): refresh screenshots and correct preflight, dashboard, and menu drift Replace all three quickstart screenshots with fresh captures and correct several claims that drifted from the current UI: - Document the environment preflight's 7th check (Sencho compose location), previously missing entirely from both the text and the screenshot alt text. - Add the Stack health table's Source and Port columns, and note that columns are sortable and default to load order. - Note the masthead's running-container count, live CPU/memory readout, and alert count. - Fix the profile menu list: replace the nonexistent "Feedback" entry with "Open New Issue", drop "Appearance" (it lives in Settings, not the profile menu), and add the conditional "Billing" entry. - Note that the sidebar groups stacks by Docker Compose label once labels are assigned, with pinned stacks first. * docs(configuration): document missing env vars and fix JWT secret wording Add SENCHO_UPLOAD_DIR, TRIVY_CACHE_DIR, SENCHO_MESH_RECONCILE_INTERVAL_MS, SENCHO_MESH_PROXY_TUNNEL_IDLE_MS, SENCHO_COMPOSE_COMMAND_TIMEOUT_MS, and SSO_OIDC_CUSTOM_ENABLED, all real environment variables that were missing from the reference tables. Clarify that the JWT signing secret has no environment variable at all, generated and stored in the database only, rather than implying an unused JWT_SECRET var exists. * docs(stack-management): refresh against current live app and source Rewrites the Stack Management page against the production node and frontend source: adds the Compose Labels anatomy tab (new since the last refresh), the Mute action on the stack header and sidebar context menu, corrects the update-available banner wording and the sidebar context menu's lifecycle ordering, notes the Doctor tab's severity dot and the scan-status banner, and replaces all 14 screenshots with fresh production captures. * docs(editor): refresh against current live app and source Replace all 8 screenshots with fresh 1920x1080 production captures (mobile shot at phone viewport). Document the self-stack protection dialog that blocks deploy/delete actions on the stack running the current Sencho instance, the multi-container summary strip and Compact/Detailed density toggle, the mutually exclusive Expand containers / Expand logs controls, the Files tab full-screen toggle, and the post-deploy scan-status banner on the Anatomy panel, none of which were previously covered. * docs(editor): recapture mobile compose screenshot without redaction The previous mobile screenshot used the plex stack, whose compose volume mount includes a real host path that had to be blacked out and overlaid with placeholder text, leaving a visible seam. Recapture against the dozzle stack instead, whose only volume is the Docker socket, so the screenshot needs no editing. * docs(stack-file-explorer): refresh page against current app and code Renames "Files & Volumes tab" references to the current "Files" tab label, documents the full-screen toggle and word-wrap control, expands the non-browsable-volume reasons to match the current containment logic (single-file binds, the full protected host-path list, and the Docker-unreachable named-volume case), documents the 100-item bulk selection cap and the 5000-file/1 GiB archive limits, corrects the non-existent DISK_FULL error code, notes that override compose files are unprotected, and scopes the atomic-write claim to fs-backed roots. Replaces all 9 screenshots with fresh production captures taken in the Files tab's full-screen mode, so no other stack UI (health metrics, logs) appears in the background. * docs(resources): refresh against current live app and source * docs(dashboard): refresh against current live app and source * docs(app-store): refresh against current live app and source Replaces all 6 screenshots with fresh production captures and corrects the Environment Variables and About-panel metadata claims to match what the bundled LinuxServer.io registry actually returns today. * fix(docs): recapture app-store advanced-tab screenshot without scroll cut-off The prior capture was taken mid-scroll to reveal the Security checkbox, leaving the template logo and About text cropped awkwardly at the top. * docs(global-search): refresh against current live app and source * docs(deep-links): refresh against current live app and source - Add App Store, Logs, Update, Console, and Audit to the URL table (previously undocumented) - Document hub-only URL redirect behavior and cross-link to Multi-Node Fleet - Note Fleet tab URL segments do not always match their on-screen label (Status/configuration, Map/dependencies) - Document the no-env-files edge case (Env tab absent, falls back to compose) - Clarify Settings section-list state is phone-only; desktop always normalizes to /settings/appearance - Note which top-level views share identical URLs between desktop and phone - Remove greenfield-violating temporal phrasing ("now has", "as today") - Replace em dashes in touched bullet list * docs(appearance): refresh against current live app and source * docs(stack-activity): refresh against current live app and source Add the missing "Stack taken down" event category, cross-link the Suppressed badge to notification mute rules, list the new Compose Labels tab in the Anatomy panel strip, and replace both screenshots with current production captures. * docs(dossier): fix generated-facts wording, add rollback readiness section Corrects three Dossier tab Generated Facts rows against current frontend behavior: the Ports count is not filtered to host-published mappings, the Network row's "bridge" label is fixed text rather than a derived driver, and missing env var names appear only in the Markdown export, not the live tab. Adds a Rollback Readiness subsection under Connected Features (previously only an orphaned Limitations bullet), links to Compose Networking and Storage Portability, and clarifies that a missing export section can mean either an older node build or a failed on-demand fetch, not only a version gap. Recaptures all three screenshots against production. * docs(stack-drift): refresh against current live app and source Fixes the stack detail tab bar description (Compose Labels tab was missing, Files/Edit compose were wrongly listed as tabs), documents that re-check only requires read access to the stack (so viewer and auditor roles can trigger a ledger write), and cross-links the network findings to the Networking tab's runtime drift section and the Fleet Overview's Drift filter. Replaces all four screenshots with fresh 1920x1080 production captures. * docs(compose-doctor): refresh against current live app and source Corrects the rule count from 31 to 32 and documents the previously undocumented self-managed-stack guard rule and enforcement, the per-browser dismiss control for the summary card and Doctor tab dot, the acknowledged summary state, the full Health-Gated Updates verdict mapping, and the temporary exposure intent option. Replaces all four screenshots with production captures. * docs(compose-networking): refresh against current live app and source Adds cross-links to the new node-wide Networking operator page, documents the "view node networking" link and the unset/inherit exposure-intent pill labels, corrects the stale Resources Hub network-tab reference, and replaces all screenshots against the production node. * fix(docs): unbreak stack-activity page render The screenshot alt text used backslash-escaped quotes, which is invalid MDX/HTML attribute syntax. Mintlify failed to parse the file and silently dropped it from routing, so the page 404'd despite being listed in docs.json navigation. * docs(environment-guardrails): refresh against current live app and source Fix the ENV FILES section description: it lists env_file: entries and project files with an existence problem, not every declared env file. A cleanly-resolving project file is already named in the Project Environment File panel above it. Replace all three screenshots with current production captures. * docs(docker-label-audit): refresh against current live app and source Add production screenshots (page had none), a Capability gating section, a Limitations section, and a Troubleshooting accordion. Tighten the secret-redaction heuristic description and cross-link Stack Labels, Compose Doctor, Environment Guardrails, and Node Compatibility. * docs(compose-storage): refresh against current live app and source Captured fresh production screenshots (both prior images were stale) and fixed a leftover pre-rename card title pointing at the Files tab. * docs(stack-labels): refresh against current live app and source Removed the stale trailing-dot sidebar claim (that rendering was removed from the sidebar in a prior UI pass), documented the new label-scoped notification muting available from the sidebar, stack context menu, and Settings panel, corrected the Fleet Actions card copy to match the redesigned cards, added the previously undocumented bulk-assign size cap and the node-scoped label bulk-action API, and replaced all 8 screenshots with fresh production captures. * docs(sidebar): refresh against current live app and source Removes the stale per-row label dot claim (removed from StackRow), corrects the update indicator and Updates chip color from orange to fuchsia, and documents Mute/Take down in the context menu, the label group mute kebab, Ctrl+A/Esc bulk-mode shortcuts, pin-eviction toast, and the offline-node skip behavior in cross-node search. Replaces all 8 screenshots with fresh production captures. * docs(deploy-progress): refresh against current live app and source Corrected the Scan entry point (node-wide Scan this node from Security Overview, not a per-stack config scan), added the missing Take down verb and entry point, broadened recovery actions to cover restart and rollback failures, fixed the modal status text and raw-output color claims to match the live UI, and replaced all screenshots with fresh captures from a throwaway demo stack on the production node. * docs(atomic-deployments): refresh against current live app and source * docs(health-gated-updates): refresh against current live app and source * docs(deploy-enforcement): refresh against current live app and source Correct the tier note to every-tier (verified against the current policy gate, which no longer has a paid-only blocking switch), add the Security Overview deploy-enforcement summary card, tighten the honor- suppressions default wording, cross-link the separate pre-deploy scan advisory dialog to avoid confusion with the block dialog, and replace all three screenshots against the current production UI. * docs(blueprint-model): refresh against current live app and source Replaced all 11 screenshots with fresh production captures. Corrected the volume-destroying-drift Enforce-downgrade claim (appeared three times): that code path has no call sites in the runtime reconciler, so any compose edit on a stateful or state-unknown blueprint always re-enters Awaiting confirmation regardless of drift mode. Corrected the Create workflow (creation does not trigger an immediate reconciliation tick) and the Delete workflow (now requires typing the blueprint name to confirm). * docs(scheduled-operations): refresh against current live app and source * docs(blueprint-model): drop tier framing, treat as Community-native Blueprints carry no tier gate, so "available on every tier" implied a comparison that doesn't exist. Removed the tier framing from the intro note, the Prerequisites table, and the Security section; the role requirement (admin to write, every role to read) already says everything that matters. * docs(auto-update-policies): refresh against current live app and source Documents that every update trigger on this page, Apply now and scheduled Auto-update tasks alike, runs through the same atomic backup, build-aware rebuild, and post-update health gate as a manual update from the stack editor, and is subject to the same deploy enforcement policy gate. Corrects the readiness-computation description to scope it to registry-image services and cross-links to Health-Gated Updates, Atomic Deployments, Deploy Enforcement, and Stack Management. Replaces the readiness board screenshot with a fresh production capture and removes three orphaned screenshots left over from the page's prior CRUD-policy layout. * docs(auto-heal-policies): refresh against current live app and source Correct the admin-only prerequisite: viewing policies and history is open to every signed-in role, only creating/toggling/deleting requires admin. Rewrite the matching troubleshooting entry to match, note the overlap behavior between an All-services and a named-service policy on the same container, and replace all three screenshots with a real production policy. * docs(webhooks): refresh against current live app and source Replaced all three screenshots with fresh production captures (single webhook create/reveal flow, two-card configured list), verified every claim against WebhookService/StackOpLockService/registry.ts, and added the previously undocumented per-stack lock skip behavior for non-Git-source-sync actions with a matching troubleshooting entry. * docs(global-observability): refresh against current live app and source * docs(audit-log): refresh against current live app and source - Fix nav terminology: Audit is a top navigation tab, not a sidebar tab. - Correct retention claim: Admiral shows full retained history (default 90 days), not a fixed 14-day window; the 14-day clamp only applies to the Community API, which has no navigation entry point at all. - Fix settings path: Settings - Operations - Data Retention (previously pointed at the now-split Developer Diagnostics section). - Restore current Recovery Vault naming (was stale Sencho Cloud Backup). - Expand the tracked-actions list: stack take-down, label management, MFA reset, and notification suppression rules were missing. - Note that assigning the Auditor role itself requires Admiral. - Replace all four screenshots with fresh production captures (Stream, Table, expanded row, Data Retention) reflecting the current five-row retention card. * fix(audit-log): reframe data-retention screenshot to card content only The prior crop included the Settings sub-navigation panel, which isn't part of what the surrounding text describes. Retake tightly cropped to match the page's other screenshots (card content only, no chrome). * docs(multi-node): refresh against current live app and source Rewrites the Pilot Agent enrollment flow (now a generated compose.yaml plus docker compose up -d, not a single docker run command) and the Settings scope table (current registry: Stacks, Container Alerts, Docker & Storage, Data Retention, Mute Rules, Recovery, and the Admiral Account / Recovery Vault renames). Adds a Sencho Mesh cross-link matching the live add-node form copy. Replaces all eight screenshots with sanitized production captures. * docs(pilot-agent): refresh against current live app and source * docs(readme): refresh GitHub README against current live app Replace all 9 screenshots (stale top nav showing a removed Console item and missing the new Networking page); document Take down, Drift Detection, Environment and Secrets Guardrails, Storage Portability, Docker Label Audit, Remote Updates, and the node-wide Networking dashboard; fix a broken non-root-user anchor link; correct the notification channels list (no email channel exists yet) and the global search scope (pages, nodes, and stacks, not containers or services); rename "scan policy packs" to the current "scan policies" terminology; broaden the App Store bullet to cover custom registries. * docs(readme): reposition intro copy and refresh badge row Lead with DevOps/platform/sysadmin framing instead of homelab-first, drop pre-1.0 "production" language, state plainly that Sencho provides a UI instead of promotional "does the work you do" phrasing, and call out that multi-node was part of the architecture from the start. Swap the Discussions badge for CodeQL, last-commit, open issues, and live website/docs status badges, and add a blog link. * docs: retake Dashboard and Global Search screenshots for accuracy Configuration Status now shows Recovery Vault instead of the stale Cloud Backup label, and the search palette capture includes the Networking page entry added after the prior screenshot batch. * docs: refresh Fleet View page against current app Fleet View has drifted since its last rewrite: the Docker Labels tab, Export Dossier action, Networking filter/badge, node label pills and latency in topology, the Policy sync status row, and the node card Mute submenu were all shipped but undocumented. The Check Updates and Add Node actions also moved into the Overview toolbar (renamed Node Update / Manage Nodes) and no longer sit in the shared action row. Replaces all five screenshots with fresh production captures and corrects the masthead's motion description (a calm shimmer on Healthy, a steady glow on Degraded/Critical, not a pulsing dot). Also fixes a Fleet Sync limitation that claimed no first-party sync-status panel exists, now that the Status tab surfaces one. * docs: refresh Fleet Dossier page against current app Adds the page's first screenshot, documents the network exposure summary now included per stack, documents the storage-summary omission versus the Stack Dossier export, and adds two troubleshooting entries. * docs(fleet-federation): deep rewrite for the rollout-approval gate Federation's cordon and pin controls no longer take effect by themselves: the reconciler requires a confirmed rollout preview (Apply now -> Confirm Apply) before it mutates the fleet, and pinning or unpinning always clears a blueprint's approval. Rewrote the mental model, step-by-step, lifecycle table, security section, limitations, practical workflows, troubleshooting, and cross-links to reflect that gate. Also corrected the audit-log claims: cordon/uncordon/pin are not filterable by a node.cordon/blueprint.pin action taxonomy, only by the free-text search box against the method, path, and summary. Replaced 4 screenshots and added 3 new ones (production fleet plus an isolated instance to capture the rollout preview dialog in both a safe and a blocked state), and fixed one stale pin-workflow sentence in blueprint-model.mdx that the same audit surfaced. * docs(fleet-federation): drop tier-availability framing The feature isn't tier-gated, so calling out "every tier" reads as an unnecessary advertisement. Removed the tier note and the Community/ Admiral prerequisite row, and reworded two role-visibility sentences that had conflated tier with role. * docs(fleet-actions): deep rewrite for the v2 action-card redesign Rewrites the page against the shipped Fleet Action Card redesign: a single cyan rail with per-card action-class chips instead of the old per-card rose/purple/amber rails, plus the live blast-radius preview, dry-run, and confirmed-target binding mechanics that replaced the old static warning banners. Documents two previously-undocumented endpoints (match-preview, prune/estimate), the preview-confirm-execute model shared by all three cards, per-node locking, timeouts, and the version-gated confirmed-target contract for mixed-version fleets. All five screenshots recaptured against the live production UI. * docs(fleet-actions): fix nested quote in screenshot alt text * docs(fleet-sync): refresh against current app and document proxy gap Retake all screenshots against the live fleet (control authoring view, a genuine replica showing the read-only banner, and replicated suppression rows) and document a previously-unwritten behavior: scan policies, CVE suppressions, and misconfig acknowledgements are fetched localOnly and are not proxied through the node switcher like most other Security page tabs, so viewing a remote's Fleet Sync state requires signing into that instance directly. * docs(fleet-backups): refresh against current app and note new integration points Replaces all 6 screenshots with fresh 1920x1080 production captures and corrects several drifted details: the Cloud Snapshots panel's pagination and per-item delete action, the exact Recovery Vault storage-mode label, and the real per-file size-cap behavior (an oversized compose.yaml skips the whole stack; an oversized .env is dropped but the stack still captures). Documents two entry points that were missing from the page: the pre-update snapshot checkbox in Health-Gated Updates and the snapshot coverage nudge on the Storage Portability tab. Expands the single warning banner description in the detail view to cover all four banner types, notes the Snapshots tab and Recovery Vault are hub-only, and adds a Where Fleet Backups fits table cross-linking the six adjacent features. * docs(remote-updates): refresh against current app and add hardened-channel notes Replace all screenshots with fresh 1920x1080 production captures and fix the Node Updates trigger label (Check Updates -> Node Update). Add the Changelog tab, correct the reconnect overlay's stale 'Update timed out'/Try Reloading copy to the current Taking longer than expected/Reload to check text, and document the Admiral Hardened Build channel's carve-outs (pinned-but-not-blocked, entitlement-gated local update path). Disambiguate this page from the unrelated top-level Update (Health-Gated Updates) nav tab. * docs(node-compatibility): refresh against current app and expand capability list Replace all screenshots with fresh production captures (node switcher, capability lock card, connection test panel) and swap the lock-card example from a now-hidden Host Console to Audit Log, which is directly reachable. Bring the capability table from 26 to 35 entries to match the current registry, add a Mute Rules row, and split out fine-grained fallback capabilities (update-guard, service-scoped-update, cross-node-rbac, stack-down-remove-volumes) with their non-lock-card fallback behavior. Fix the compose-networking row, which incorrectly claimed to also gate the node-level Networking overview. Note that Pilot Agent nodes never advertise host-console regardless of version. * docs(security): refresh against current app and document scan-node launcher Replaces all screenshots with fresh production captures, documents the Scan this node launcher and the third Scanner setup toggle (pre-deploy scan advisory), tightens the Compose risks example list and the Policies block-condition description to match the live app, and adds an On a phone section. * docs(vulnerability-scanning): refresh for exploit intel and risk-based policies Documents exploit intelligence (KEV/EPSS evidence tags), the redesigned risk-based scan policies (severity/known-exploited/fixable block conditions replacing the single max-severity field), and the new Findings badge state. Replaces all screenshots with fresh production captures and adds a Secrets tab example. * docs: refresh CVE suppressions page Retook all screenshots against production (prior ones predated the triage-status/OpenVEX UI and the edit capability). Documented the suppression edit flow, which the page previously described as delete-and-recreate only. Corrected the remote-node banner copy on the Suppressions tab and added a screenshot of it. Cross-linked the Misconfig acknowledgements panel that now sits on the same tab. * docs(two-factor-authentication): refresh screenshots and document rate-limit layers Replace all 11 non-count-variant screenshots with fresh production captures. Document the throttled sign-in state precisely (kicker/hero/caption change, not just the input), that a replayed TOTP counts toward the lockout counter, and the separate per-network-address sign-in rate limit that sits in front of the per-account MFA lockout. * docs(api-tokens): refresh screenshots and document service-scoped deploy actions Deploy Only now authorizes eight lifecycle POSTs (was six): the per-service update and restore endpoints were missing from the scope table. Universal restrictions gained a row for image channel management, which was already rejecting API tokens in code but undocumented. Replaced all five screenshots with fresh captures showing the current three-scope create flow and a populated list with one token of each scope. * docs(upgrade): refresh against current app and remove legacy-version framing Fixes migration-list inaccuracies (registry credentials were never plaintext, unlike node API tokens), rephrases the SSH/TLS and JSON-config migration bullets to drop version-numbered legacy framing, adds a GHCR mirror note matching the quickstart pattern, and cross-links the Hardened Build entitlement-gated update path so digest-pinned installs aren't sent down the manual docker pull steps. * docs: refresh Backup & Restore against current backend Broadens the encryption.key warning to cover everything CryptoService actually encrypts (node tokens, Git source and Fleet Secrets, SSO/MFA, Recovery Vault, fleet snapshot contents), not just registry credentials. Adds the built-in backupData CLI as a no-host-tooling alternative to the sqlite3 .backup command, cross-linked to Emergency command-line recovery. Corrects node-token migration guidance: tokens are signed with a secret stored in sencho.db and remain valid after a host move, so no regeneration is required. * docs: refresh Recovery guide against current Settings page and CLI Documents the Settings · Recovery page's full System health / Environment / Safe actions / Command-line hub instead of only its environment-preflight section, adds the missing "Sencho compose location" preflight check, adds the SSO/OIDC/LDAP lockout scenario now that disableSso.js exists, and corrects the rollback description (exact UI label, backup-required and image-layer caveats). * docs(emergency-cli): sync in-app page description, add CLI operational details Aligns the "in-app Recovery page" summary with the freshly refreshed Recovery guide (System health / Environment / Safe actions / Command-line recovery, SSO providers, one-click command download). Adds constraints verified against the CLI source: password/username minimums, the valid SSO provider identifiers with an example, and a note that diagnostics.js always reports Docker as unreachable (it runs without a live Docker connection, unlike the in-app page). * docs(troubleshooting): refresh against current backend and nav Corrects several claims that had drifted from the implementation: network name validation (underscore is not a valid leading character), the remote-update delayed-failure window (3 minutes, not 90 seconds), and an unsubstantiated version-compatibility check on the Admiral 403 entry. Removes two entries describing legacy pre-v0.39 node behavior that no longer applies to any currently shipped build. Replaces stale "Profile > Settings > X" navigation with the current Settings hub paths, and "wifi icon" with the current Test Connection label. Adds Pilot Agent awareness to the remote-offline entry with a cross-link to its dedicated troubleshooting section, and trims the docker-run converter entry to point at the fuller, already-current version on the Stack Management page instead of duplicating it with a broken anchor. * docs(verifying-images): document the :dev GHCR integration tag Verified the existing cosign/SBOM/VEX/tag-policy content against docker-publish.yml and docker-preview.yml; all accurate. Added the previously undocumented :dev/:dev-<sha> integration tag published on every push to main via docker-dev.yml. * docs(trivy-setup): sync install guide with node-scoped scanner and current Trivy upstream docs Documents that Trivy installs independently per node, adds the TRIVY_BIN override and non-PATH mounting option, fixes the deprecated apt-key install flow and RHEL repo gpgkey placement, notes the Exploit intelligence toggle for air-gapped hosts, and replaces the stale Scanner setup screenshot. * docs(two-factor-admin): document lockout recovery and self-reset gotcha Verified the reset flow, CLI recovery, and SSO toggle claims against current source and replaced the stale admin-reset modal screenshot. Added the failed-attempt lockout behavior (undocumented despite being promised in the page description) and a warning about resetting your own 2FA from the Users list, which signs you out immediately unlike the self-service disable flow. * fix(docs): make Settings and Self-hosting discoverable in the sidebar The Reference and Operations groups used root pages that were only reachable by clicking the ambiguous group label, and that click also triggered an unwanted double action (expand plus navigate). List both pages as explicit sidebar entries and disable global drilldown so group headers only expand or collapse. * docs(settings): sync reference page with current Settings Hub Renamed License to Admiral Account throughout (Hardened Build channel switch, image channel display, DURATION pill), corrected the password policy, documented the new Appearance navigation and log-chip-color controls plus font options, noted Mesh data plane is not on every installation, fixed the label cap (50, not 100), and replaced every screenshot with a fresh capture from the production node. * fix(docs): apply the sidebar toggle-only fix to Start here and Product guide These two groups had the same click-to-navigate-and-expand pattern as Reference and Operations. Flattening them is safe here too: the Product guide root page has no directory listing depending on it, and the Start here root page's own hand-authored Next steps CardGroup already covers the same links the auto-generated listing duplicated. * docs(licensing): refresh licensing page for Hardened Build and sales-led Admiral pricing Admiral pricing moved from self-serve checkout to a contact-sales model, and a new Hardened Build image-channel switcher shipped in the Admiral Account settings page; neither was reflected in the docs. Also documents the lifetime-license edge case (no Manage subscription button, no Billing row) and refreshes all four screenshots against the current UI. * docs(security): sync reference page with current API-token and encryption scope Verified every claim against the live implementation: the API-token universal restrictions list was missing MFA management, Recovery Vault, and image channel management; the encryption-at-rest field list was missing Recovery Vault credentials; added a note on the password strength indicator's recommended-vs-enforced distinction. Refreshed the SSO settings, API tokens, and audit log screenshots against the production node. * docs(settings): fix password policy and session-invalidation claims Cross-checked against auth.ts while verifying the same claims on the security reference page: the enforced minimum is 8 characters (the 12+/mixed-case/number text is a frontend strength hint, not a validated rule), and a password change invalidates every other session for the account rather than leaving them valid. * docs(contact): sync contact channels with sales-led pricing and current support gating Replace the retired contact@sencho.io with hello@sencho.io (the address actually used in the website footer and the pricing page's Get in touch CTA), narrow the licensing@sencho.io scope to existing-license activation/billing/refunds now that new Admiral conversations route through hello@sencho.io, drop the stale LICENSE-file and in-app upgrade-prompt claims (the AGPLv3 relicense removed both), correct the Support settings path and add the published response-time targets, and remove the unsubstantiated bug bounty mention.	2026-07-21 09:13:12 -04:00
Anso	63213c0960	feat: add service-scoped Compose update and restore (#1648) ... * feat: add service-scoped Compose update and restore Allow updating or rebuilding one declared Compose service on multi-service stacks without recreating siblings, with recovery snapshots, health-gate observation, and prune holds for rollback images. Full-stack update paths and single-service UX stay unchanged. * fix: sanitize service-scoped update log messages for CodeQL * fix: address service-scoped update audit findings B-01 through B-07 * fix: complete service-scoped update audit metadata and surfaces * test: wrap Updates readiness tests for deploy-feedback context * fix: keep service recovery reachable without Deploy Progress Make failed service-gate recovery discoverable when Deploy Progress is disabled or dismissed, suppress stale image-scan notification side effects, normalize ComposeService line endings, and add focused regression coverage. * fix: resurface ContainersHealth density and expand on multi-service stacks Service grouping hid the summary strip and Compact/Detailed/Expand controls that still applied to multi-container stacks.	2026-07-19 02:42:29 -04:00
Anso	83b3d932e5	feat: add Apprise as a fourth notification channel (#1644) ... * feat: add Apprise as a fourth notification channel Support keyed and stateless Apprise endpoints with secret-safe public DTOs, fail-closed malformed config, and mode-specific Settings UI. Docs and screenshots updated for four-channel Channels and routing. * fix: harden Apprise secrets at rest and preserve-on-write saves Encrypt Apprise endpoint and config with CryptoService so a downgrade cannot leak via SELECT *. Align channel and routing saves so blank destination fields omit config on same-mode URL edits, enforce keyed notify IDs, and keep secrets_redacted truthful. * fix: harden Apprise route type changes and mixed-version config UI Require a raw channel_url when switching notification-route types so ciphertext cannot strand under Discord/Slack/webhook. Default missing remote apprise status, replace Channels state on node switch, and exercise the production config-column migrator. * fix: tolerate stub fleet configuration payloads without agents Normalize remote Apprise agent status only when notifications.agents is present so successful Pilot/stub fetches stay online instead of throwing into the offline catch path. * fix: correct TypeScript in configuration normalize tests * fix: ignore stale Channels agent bodies after node switch Compare the active node after response JSON parsing so a slow body cannot overwrite the newly selected node's channel state. * fix: isolate corrupt Apprise crypto and keep keyed Tags visible Decrypt failures on one Apprise row no longer 500 agent/route lists or suppress sibling channel dispatch. Treat public /notify/<redacted> as keyed so Tags remain editable after reload.	2026-07-18 16:32:58 -04:00
Anso	381ed2a91f	feat: add Admiral Hardened Build channel and business assurance surfaces (#1629) ... * feat: add Admiral Hardened Build channel and business assurance surfaces Introduce Studio Saelix entitlement-backed Hardened Build switching, a single-flight image operation coordinator, Recovery Vault naming, Admiral Account settings, and typed Fleet update failures while preserving Community custom-repo and targetless pull-current updates. * fix: harden image-op paths and clear CI CodeQL/pilot flake Validate operation IDs before filesystem use, use hostname checks in Fleet fetch mocks, sanitize registry probe logs, and swallow expected TCP teardown errors in the pilot reverse-route post-handshake test. * fix: sanitize image-op docker config write and probe logs Allowlist-copy registry host keys and base64 auth before writing the temp DOCKER_CONFIG, and log registry probe failures with a fixed message so CodeQL no longer flags network-to-file and log-injection mediums. * fix: address Admiral Hardened Build audit blockers Expose imageChannel so hardened Fleet peers still POST for typed rejection, claim community updates before 202, terminalize helper failures, gate Hardened on paid, and align support/docs/e2e wording. * fix: terminalize image ops on helper survival and aborted claims * fix: prevent recreating persist from overwriting helper-exit failure * test: assert helper-exit failure lands before recreating persist * fix: keep current pointer when acknowledging a stale image operation	2026-07-14 10:47:54 -04:00
Anso	bb35c1bc92	feat: add sidebar update indicator toggle and Stack Health badge (#1570) ... * feat: add sidebar update indicator toggle and Stack Health badge - Add image_update_sidebar_indicators setting (default off, node-scoped) - Gate the Updates filter chip and sidebar status indicators on the setting - Add "Update available" badge to Stack Health table (always visible) - Extend ImageUpdateStatus with sidebarIndicators boolean - Poll /api/image-updates/status alongside /detail in useImageUpdates - React to SENCHO_SETTINGS_CHANGED for instant toggle propagation - Reset sidebar state on node switch; generation-guard stale responses - Disable toggle when status is null (loading) or field is absent (old node) - Wire stackUpdates through ViewRouter → HomeDashboard → StackHealthTable - Update settings registry, operator docs, and sidebar/dashboard docs * fix: guard against stale node renders, memo drift, and cross-node error toasts - Track owning node ID in useImageUpdates state so React never renders node B with node A's data before the passive effect resets (P2) - Replace incorrect stackUpdates dependency with sidebarStackUpdates in chipFilteredFiles useMemo (P3) - Guard the error toast in handleSidebarIndicatorsChange so a stale PATCH failure from node A does not surface while viewing node B (P3) * fix: default sidebar update indicators to on (opt-out) The sidebar indicators are a safe convenience that most users want. Switching the default from off to on matches the opt-out convention used by prune_on_update, reclaim_hero, and health_gate_enabled.	2026-07-05 02:52:17 -04:00
Anso	98667e0d6f	fix: make host memory usage ZFS ARC-aware (#1547)	2026-07-01 23:08:49 -04:00
Anso	04e69021e0	feat: make all security features available on every tier (#1502) ... Scan policies, deploy enforcement, the suppression-aware deploy-block toggle, SARIF export, and OpenVEX export now work on Community, matching the rest of the vulnerability-scanning surface that was already free. Backend: drop the tier gate from the seven security routes and from the dashboard configuration-status scan-policies row, so the Dashboard and Fleet config cards stop hiding the Vulnerability scanning row. Reading policies stays auth-only; mutations and exports stay admin-only. Frontend: always show the Policies tab and panel, the SARIF and VEX export actions, and the honor-suppressions toggle for admins. Docs: move scan policies, SARIF, and OpenVEX to every tier across the feature and API-reference pages; clarify that Fleet Sync's cross-node replication remains the paid part.	2026-06-28 08:14:21 -04:00
Anso	b7dd9dc1b0	feat: add ON/OFF toggle for host threshold alerts (#1456) ... * feat: add ON/OFF toggle for host threshold alerts Add host_alerts_enabled setting (default ON) as a master switch for CPU, RAM, and disk host threshold evaluation. When OFF, the four threshold controls in Settings > Host Alerts are disabled and MonitorService skips the systeminformation calls and alert dispatch entirely, while clearing stale suppression state so re-enabling starts fresh. The dashboard Configuration Status card shows "Off" when host threshold alerts are disabled. Crash capture, health gate, deploy guardrails, stack alert rules, and the Docker janitor are all unaffected. * fix: exit NumberChip edit mode when externally disabled When the host threshold alerts master toggle is turned OFF while a NumberChip is in edit mode, force-exit edit mode so the chip renders the greyed-out button state consistently with the other chips.	2026-06-25 16:05:16 -04:00
Anso	cc78873e65	feat(scheduler): group schedule action picker by operator intent (#1446) ... * feat(scheduler): group schedule action picker by operator intent Reorganize the New Schedule action picker from a flat dropdown to a category-grouped list (Lifecycle, Updates, Security, Maintenance, Backups). - Extend Combobox component with optional group field on ComboboxOption, rendering grouped sections with non-interactive headers when groups are present. Flat rendering is unchanged for all other callers. - Reorder SCHEDULED_ACTIONS by category group and update seven action labels per the operator-intent spec. - Add DEFAULT_SCHEDULED_ACTION_ID constant so picker order and form defaults are independently controllable. - Wire grouped actionOptions into ScheduledOperationsView. - Update all label references in docs and tests. - Add Combobox grouping tests, registry order test, and default-constant test. * fix(scheduler): correct Combobox grouping for interleaved groups, docs labels - Replace last-group-append with Map-based group partitioning so interleaved or mixed-group options land in the correct group. - Add interleaved-groups test and restore non-interactivity test. - Update stale "Start Stack" references to "Start / Bring Up Stack" in doc action-label contexts. - Update action-picker alt text to describe the new grouped order.	2026-06-25 01:40:31 -04:00
Anso	ce08a593d7	feat(settings): reorganize the settings hub into domain groups (#1321) ... * refactor(settings): split System Limits and regroup the hub System Limits had grown into a grab-bag of host alert thresholds, Docker cleanup, and mesh data-plane controls under one mislabeled section. Split it into Host Alerts, Docker & Storage, and Fleet Mesh, and split Developer into Developer Diagnostics and Data Retention. Reorganize the sidebar into ten domain groups: Personal, Access, Infrastructure, Monitoring, Notifications, Automation, Organization, Security, Operations, Help. Each section now saves only its own keys, so a concurrent edit in one section no longer clobbers another. Data Retention sends the audit-log window only on a paid plan, matching the field's existing visibility, so a Community save no longer fails on a key the operator cannot set. NumberChip moves to a shared module and the toggle reuses the existing shared component. The /settings API is unchanged. * test(settings): cover registry structure and per-section save payloads Add structural invariants for the ten-group registry (every item maps to a real group, ids are unique, the System Limits and Developer splits land in the right groups with the right gates, renamed labels and the Registries paid gate hold) and per-section payload tests asserting each split section patches only its own keys, including the Community path where Data Retention omits the paid audit-log key. * docs(settings): document the regrouped settings hub Rewrite the settings reference for the ten-group layout, replace the System Limits page with Host Alerts, Docker & Storage, and Fleet Mesh, and document the prune-on-update, reclaimable-space banner, and mesh auto-recreate settings that were previously undocumented. Update the Settings navigation breadcrumbs across the feature docs and refresh the affected screenshots. * fix(settings): show Access sections as instance-global, not operator-scoped License, Users, SSO, and API Tokens are instance-global settings but the masthead scope label rendered them as operator-scoped because it keyed off the old Identity group. Only Personal sections (account, appearance) are operator/browser-scoped now; everything else reads as global. Also add a compile-time exhaustiveness guard to the section switch so a future SectionId added without a matching case fails the build instead of silently rendering a blank panel. * docs(settings): remap remaining settings breadcrumbs to the new groups Update the navigation breadcrumbs that still pointed at the removed Identity, Alerts, and Advanced groups: API Tokens and Users now sit under Access, Webhooks under Automation, Labels under Organization, App Store under Infrastructure, Appearance under Personal, and scan policies under Security > Vulnerability Scanning. Correct the settings reference scope note so Access reads as global. * docs(settings): remap renamed-section breadcrumbs across feature docs Sweep every feature, operations, getting-started, and reference page for navigation paths that still named the renamed settings sections, and point them at the current ones: Security becomes Security > Vulnerability Scanning, Notifications becomes Notifications > Channels, Routing becomes Notifications > Notification Routing, and Developer becomes Operations > Developer Diagnostics (with its retention windows under Operations > Data Retention). App Store moves under Infrastructure and the four-group overview in the getting-started intro is rewritten to the ten groups. Separators each page already used are preserved.	2026-06-05 23:01:37 -04:00
Anso	28ea610e81	refactor(masthead): remove stat-tile hover tooltips (#1319) ... Drop the cursor-following hover tooltips from the masthead stat tiles: the RUNNING tile on the Home dashboard (the managed / external / exited breakdown) and the CONTAINERS tile on the Fleet view (the running / total split). Both revert to plain stat tiles, matching the CPU and MEM tiles beside them. The dashboard and fleet docs are updated to match and the orphaned screenshot is removed.	2026-06-05 21:53:14 -04:00
Anso	865d792874	feat(pricing): collapse to two tiers (#1309) ... * feat(pricing): collapse to two tiers (Community + Admiral) Collapse Sencho's pricing from three tiers (Community / Skipper / Admiral) to two: a generous free Community tier and a single paid Admiral tier. The Skipper tier is removed. Now free in Community: auto-heal, auto-update, scheduled operations, webhooks, notification routing, Fleet Actions and bulk operations, SSO preset providers (Google / GitHub / Okta), unlimited users with admin and viewer roles, and deploy safety (atomic deploys, auto-rollback, and one-click rollback). Admiral (paid) is focused on running and governing a fleet: blueprints, Fleet Secrets, deploy enforcement, vulnerability report export, audit log, host console, private registries, mesh networking, node cordon, managed cloud backup, LDAP / Active Directory SSO, and the advanced RBAC roles (deployer, node-admin, auditor) with per-resource scoped assignments. Internally the license variant distinction is removed so tier is binary (community / paid). License validation still verifies the Lemon Squeezy store and product before granting paid status. Docs and the contributor guide are updated to the two-tier model. * docs(pricing): correct licensing page to two-tier pricing and tidy stale tier wording The licensing docs page kept the old Admiral pricing plus a Founder Lifetime column and an Enterprise paragraph after the two-tier collapse. Update it to $12/month or $99/year, drop the lifetime and Enterprise content, and link to the pricing page for current pricing. Also fix stale "Skipper" wording in CLA.md, SUPPORT.md, one test title, and three test comments. Historical CHANGELOG entries and the retired-Skipper license-guard test are intentionally left as-is. * docs: align licensing and SSO pages with the two-tier model Correct the SSO overview so the Google, GitHub, and Okta presets read as available on every tier, matching the provider table; only LDAP and Active Directory require Sencho Admiral. Remove the lifetime-plan references from the licensing, settings, and troubleshooting pages so they reflect subscription-only Admiral pricing. * fix(rbac): omit scoped permissions from /me on the Community tier Scoped role assignments only take effect on the paid tier, but GET /api/permissions/me returned them unconditionally, so a downgraded instance with leftover assignments rendered per-resource affordances the API then rejected with 403. The endpoint now mirrors the permission middleware and includes scoped permissions only on the paid tier. Adds a regression test covering the downgrade case. * docs: use custom-pricing wording on the contact page The two-tier model has no Enterprise tier; reword the contact page's enterprise pricing/deals to custom pricing/deals so it does not imply a tier that no longer exists.	2026-06-04 17:45:53 -04:00
Anso	adcd04b01a	refactor(auto-update): retire per-stack gate, drive auto-update from schedules only (#1233) ... * refactor(auto-update): retire per-stack gate, drive auto-update from schedules only The per-stack Auto-update toggle in the stack sidebar context menu wrote a gate row to `stack_auto_update_settings`, but actual updates only ran when a `scheduled_tasks` row with `action='update'` fired. On a fresh install the toggle was inert: detection ran every 6h, nothing was applied. The same context menu already exposes `Schedule task`, which opens ScheduledOperationsView pre-filled for the stack where the user can pick `Auto-update Stack` and any cron. Keeping the toggle alongside that flow duplicated the same action and turned the gate table into a parallel store of "is a covering schedule active" derivable from `scheduled_tasks` itself. Drop the gate model entirely: - Backend: remove the `stack_auto_update_settings` table and its four accessors, the three routes under /api/stacks/*/auto-update, the per-stack skip in /api/auto-update/execute and SchedulerService.executeUpdate's fleet branch, and the clearStackAutoUpdateSetting call on stack delete. Dashboard `autoUpdate` count derives from scheduled_tasks (action='update' rows pinned to the node, total/enabled split). - Frontend: drop the Auto-update entry from the sidebar context menu and its optimistic toggle plumbing. Drop autoUpdateSettings state, the /stacks/auto-update-settings fetch, and the auto-update-settings-changed WebSocket branch. Slim useSidebarActivitySummary (just nextRunAt; no enabled/total counts). AutoUpdateReadinessView's per-card autoUpdateEnabled now means "a covering enabled action='update' schedule exists" (per-stack row or fleet row on this node, earliest next_run_at wins, per-stack row wins on ties), with the gate-fetch removed. - New: scheduledTasksRouter broadcasts scope: 'scheduled-tasks' on POST, PUT, PATCH /toggle, and DELETE so useConfigurationStatus and useNextAutoUpdateRun refetch under the 250ms debounce instead of waiting for the 60s poll. The broadcast is wrapped so a broken subscriber socket cannot turn a successful mutation into a 500. - Docs: rewrite the "Per-stack control" section of auto-update-policies.mdx to describe the schedule-based model; update the matching troubleshooting entry. The misleading fleet-update help text in ScheduledOperationsView is corrected to reflect that every stack on the node is covered. Tier parity: the surviving auto-update path (Schedule task -> Auto-update Stack / All Stacks) is gated `requirePaid + requireAdmin` backend and `isPaid + isAdmin` frontend, matching the gate the deleted routes carried. The pre-commit grep returns no tier-related diff outside this PR's scope. No data migration is provided: greenfield rules apply, and the leftover table on already-shipped instances is harmless because no code reads or writes it after this PR. * docs: sweep remaining references to the per-stack auto-update toggle The previous commit retired the per-stack Auto-update gate in favor of configuring auto-update purely through scheduled tasks. This commit removes the now-stale mentions of that toggle across the operator docs: - docs/features/sidebar.mdx: drop the Auto-update entry from the Inspect group description, the matching screenshot alt-text, and the Skipper Note that listed it. Schedule task now carries the cross-link to Auto-Update Policies. - docs/features/stack-management.mdx: drop the Auto-update list item; refresh the Schedule task entry to mention the Auto-update Stack action. - docs/features/dashboard.mdx: rename the Configuration Status row from "Auto-update stacks" to "Auto-update schedules" with the new value shape, and rewrite the troubleshooting accordion to describe the scheduled-tasks invalidation path. - docs/features/scheduled-operations.mdx: rewrite the Auto-update All Stacks row and helper text to reflect that every stack on the node is covered (no per-stack opt-out from this surface anymore). - docs/features/multi-node.mdx: rewrite the Updates column definition to derive the Auto/Off flag from enabled Auto-update Stack / Auto-update All Stacks schedules instead of the removed per-stack policy. The auto-update-policies.mdx rewrite in the previous commit already covered the main reference page. The sidebar-context-menu.png screenshot will be refreshed on release once the new menu is live in production; the alt text is updated in this commit so it accurately describes the shipping state. No website edits needed: the Auto-Update Policies feature card description ("Schedule automatic image pulls and redeployments per stack on your own cadence") and the feature matrix labels ("Auto-update stack schedule", "Auto-update all stacks schedule") remain accurate under the new model. * fix(stacks): drop orphaned requireAdmin import after auto-update route removal CI's backend lint step flagged this PR's earlier deletion of the three /api/stacks/*/auto-update routes: those handlers were the only callers of `requireAdmin` inside routes/stacks.ts, leaving the named import on line 15 unreferenced. `requirePaid` and `effectiveTier` from the same line are still in use elsewhere in the file and stay. tsc --noEmit does not flag unused named imports; ESLint's no-unused-vars does. Local backend lint reproduces and now reports 0 errors against the existing 334-warning baseline.	2026-05-26 11:08:33 -04:00
Anso	96c7104521	docs(dashboard): refresh Troubleshooting accordion for new metrics-stale chip and tightened refresh model (#1223) ... Three accordion edits keep the user-visible behaviour described on docs/features/dashboard.mdx in step with the audit's surface changes. - "Configuration Status still shows the old value after I changed a setting": replace the broad "most settings dispatch a live invalidation" language with the precise behaviour, which is that only a stack Auto-update toggle triggers an immediate refetch; every other settings edit waits for the 60-second poll. The change avoids promising responsiveness the card cannot deliver and points the operator at the hard-reload escape hatch. - New "The masthead shows a 'metrics stale' chip" entry: describe what the chip means, the threshold (three consecutive metrics-endpoint failures), that polling continues regardless, and that the chip describes data freshness rather than the polling cadence. Points the operator at the Docker daemon and Sencho container logs as first checks. - New "The dashboard feels sluggish on a large deployment" entry: document the Developer mode toggle as the supported diagnostic path for slow-dashboard reports. Lists the [Dashboard:debug] log shape so the operator knows what to look for, and reminds them to disable the toggle afterwards.	2026-05-25 12:10:13 -04:00
Anso	66b84932e0	feat(notifications): move Notification Routing to Skipper tier (#1145) ... * feat(notifications): move Notification Routing to Skipper tier Notification routing is automation (route alerts to channels by rules), not enterprise compliance. Aligning the gate with Skipper makes the tier boundary read consistently with the rest of the automation surface (webhooks, auto-update, auto-heal, scheduled tasks). Backend: requireAdmiral -> requirePaid on the five /api/notification-routes endpoints. Dashboard configuration-status now exposes the routing-rules row to any paid tier. Frontend: settings registry tier flipped to skipper; the Admiral wrapper around NotificationRoutingSection is removed (the inner CapabilityGate stays, preserving forward-compat with older remote nodes). Tests: added a tier-enforcement describe block covering Skipper (200) and Community (403 PAID_REQUIRED on all five endpoints). Docs: refreshed alerts-notifications, licensing, overview, dashboard, troubleshooting, and reference/settings; cleaned one fence-spec line per Directive 31. * fix(notifications): address audit findings on tier-move PR Docs: rewrite three lines that survived the initial sweep. The dashboard "you do not see a locked placeholder" clause and the settings.mdx "hidden on Community and Skipper" phrase were Directive 31 fence-spec. The alerts-notifications troubleshooting note still said "an Admiral routing rule" and contradicted the tier move. Tests: the Community-negative cases on POST/PUT/DELETE/POST :id/test could not distinguish requirePaid from a stray requireAdmiral, because Community fails on the tier check before variant is read. Adding Skipper-positive coverage per endpoint locks the gate identity in. Replace the leaky mockReturnValueOnce with a per-test mockReturnValue plus an afterEach restore so spies cannot bleed across tests.	2026-05-21 20:57:34 -04:00
Anso	380ed6fd50	feat(cloud-backup): make Custom S3-compatible target available on every tier (#1143) ... * feat(cloud-backup): make Custom S3-compatible target available on every tier Sencho Cloud Backup remains an Admiral feature; the bring-your-own-bucket Custom S3 target is now reachable on Community and Skipper as well. Backend splits the per-route Admiral gate into two helpers: operations that touch the saved provider use gateForCurrentProvider, PUT /config uses gateForRequestedProvider against the body. /provision and /usage stay requireAdmiral because they are Sencho-only by definition; GET /config is ungated so any tier can read its own stored configuration. Frontend drops the AdmiralGate wrapper on the Cloud Backup section, filters the Sencho provider option out of the dropdown for non-Admiral users, and gates the per-snapshot cloud-upload affordance on "cloud-backup configured" instead of Admiral tier. Dashboard Configuration row is no longer locked on lower tiers. Sidebar registry tier on cloud-backup goes from 'admiral' to null. Docs and licensing breakdown restate the rule once per page without fence-spec. * fix(cloud-backup): keep downgraded sencho config off the upload surface If an Admiral configured Sencho Cloud Backup and the license later drops to Skipper or Community, the saved provider is still 'sencho'. The FleetSnapshots cloud-upload affordance now requires either provider= custom (every tier) or provider=sencho with an active Admiral license, so a downgraded admin never sees an upload button that the backend would 403 on click. Also tidies the Fleet Backups doc, which still claimed the cloud-upload icon was Admiral only; the icon now renders whenever a Cloud Backup target is configured.	2026-05-21 18:11:16 -04:00
Anso	08caa914ce	docs: v1 docs refresh (batch 2) (#988) ... * docs(atomic-deployments): refresh page around current UI and behavior Rewrites the page to match the v1 docs refresh template. Corrects several factual errors against the current code, fills in missing detail, and adds a screenshot of the rollback overflow menu. Notable corrections: - Scheduled tasks do not run atomically; only stack editor Deploy and Update, App Store installs, webhook triggers, and image auto-updates pass the atomic flag through to ComposeService. - Rollback lives in the stack editor's More actions overflow menu, not on the action bar directly. The backup timestamp renders as a sub-line of the menu item. - Health probe is a 3-second window with an exit-code check on every container labelled with the compose project name; describe this exactly rather than as 'waits briefly'. - Document where backups live (DATA_DIR/backups/<stack>/), why they are kept outside the compose folder, and that the slot is one per stack with overwrite semantics. - Document the four streamed log markers users see in the deploy progress modal during the atomic flow. - Add a troubleshooting accordion group covering missing menu entry, late crashes outside the probe window, manual-intervention message, and the single-slot retention edge case. * docs(deploy-enforcement): refresh page for v1 and align with current enforcement paths Update the page to match the current pre-flight gate behavior, the v1 modal chrome on the block dialog, and the AccordionGroup troubleshooting pattern used across the v1 docs. Drift items corrected: - Replace the broken vulnerability-scanning/deploy-blocked-dialog.png reference with three fresh captures under docs/images/deploy-enforcement/ (policy list, policy editor, block dialog). - Drop "Recreate from the stack actions menu" and the git-source apply pre-flight claim; neither path runs the gate. - Add bulk label deploy and the auto-update scheduler to the enforced code paths, with a dedicated subsection for the auto-update interaction (alert-and-skip, not 409). - Drop the false claim that severity chips in the block dialog are clickable; the dialog is informational. - Document the compose-parse-fails-closed branch with its synthetic violation label. - Refresh dialog copy to reflect the v1 ModalDestructiveHeader (kicker, title, button variants). - Convert the troubleshooting Q&A into AccordionGroup blocks and add accordions for the compose-parse-error case and the auto-update-skipped case. - Quote the verbatim audit-log summary format. * docs(blueprints): refresh against v1 UI and add federation/state-review coverage * docs(git-sources): refresh page against v1 UI and current behavior Rewrites the page against the v1 docs refresh template (Note tier-gate, sectioned anatomy, AccordionGroup troubleshooting), aligning prose with the live UI labels and the current code paths. Corrections: - Authentication toggle reads "Public (no auth)" / "Personal Access Token" (not "None"), and apply mode "Auto-write files" (not "Auto-write"). - Diff dialog kicker is GIT . PULL PREVIEW; local-edits state opens an Overwrite local edits? confirmation modal whose primary button is Overwrite and apply. - Sidebar pending indicator is a small GitBranch icon, not a brand-color dot, and the image-update dot takes priority over it on the same row. - Pending update banner appears in the panel; Review re-fetches the commit and opens the diff (no client-side payload caching). Adds coverage for: - Anatomy of the panel (pending banner, form, last-applied stat strip, footer actions). - 10-second webhook debounce window. - Pending compose/env content is encrypted at rest in the database, not just the token. - Auth/host failures map to HTTP 400, never 401, so they do not sign the user out. - Per-stack lock serializes pull, apply, and create-from-git so a webhook firing during a manual apply waits rather than racing. - Compose validation has a 10-second budget; clone fetches have a 30-second timeout. - New troubleshooting accordion for Pending commit has changed since this pull was fetched. Recaptures all five screenshots from the v0.74.x production node, signed in as admin: panel, create-from-git tab, pull-preview diff dialog, sidebar GitBranch pending icon, webhook Action select with Git source sync highlighted. * docs(stack-labels): refresh page for v1 sidebar grouping and fleet-action surface - Lead with the v1 behavior the previous page did not cover: the sidebar groups stacks under collapsible label headers (PINNED first, label buckets sorted by stack count desc then name asc, UNLABELED last) with a count chip per group. Trailing colored dots on each row (max 3 + N overflow, paid-only) supplement the headers. - Drop the stale claim that a label-pill filter bar lives between search and the stack list; that UI no longer exists. - Drop the right-click-on-pill bulk actions table (Deploy all / Stop all / Restart all). The legacy per-node action endpoint stays in the backend but no longer has a UI binding, so the page documents only what users can click today. - Document the two Skipper+ Fleet Action cards: Stop fleet by label (name match across nodes, autocomplete, per-node breakdown, HTTP 429 on per-node concurrency) and Bulk label assign (per-node, replace semantics, clear on empty selection). - Document the inline 'New label' form inside the stack right-click / three-dot Labels submenu, the Settings - Advanced - Labels masthead N/50 stat, the LABELS - NEW / EDIT modal kickers, and the LABELS - DELETE - IRREVERSIBLE confirmation copy verbatim. - Document the Fleet Overview Tags multi-select filter (filters by stack labels aggregated across nodes), with cross-link to fleet-view. - Capture every screenshot fresh from production signed in as admin: sidebar-grouping, context-menu-labels, inline-create-form, settings-labels, create-label-dialog, fleet-tags-filter, fleet-actions. Drop the now-stale sidebar-with-labels, sidebar-filtered, and bulk-actions-menu captures. * docs(dashboard): refresh page for v1 layout (status masthead, gauges, fleet heartbeat, restart map) Aligns docs/features/dashboard.mdx with the redesigned Home tab. Replaces the obsolete Recent Activity feed coverage with the actual DashboardActivityCard split (Fleet Heartbeat when remote nodes are registered, Stack Restarts (7d) otherwise) and recaptures every screenshot from the v0.74.x production node. * docs(global-search): refresh page for v1 palette - Note tier and role gating on the Pages list (Auto-Update, Console, Schedules, Audit) so the prose matches what the top bar exposes. - Document the ACTIVE chip on the currently active node row. - Document the 50-result cap counter and the Searching... loading state. - Mention the ~250 ms debounce and clarify that filename matching includes the file extension. - Replace stack screenshot with a redesigned capture and add empty-state Pages and Nodes captures showing the ACTIVE chip. * docs(global-observability): refresh page for v1 layout (masthead, signal rail, filter strip, paused-resume chip) Full rewrite against the current Logs tab and the v1 docs refresh template (hero Frame, sectioned anatomy, AccordionGroup troubleshooting, refresh-cadence table). Replaces the single overview screenshot with seven captures under docs/images/global-observability/ (overview, masthead, signal-rail, filter-strip, feed-bands, paused-resume-chip, error-only-filter), all from the v0.75.x production node signed in as admin with PII scrubbed (profile chip patched to AD, in-feed LAN IPs and third-party hostnames substituted via DOM injection while the stream was paused). Aligns prose with the actual UI labels and code: - Masthead kicker reads LIVE LOGS · NODE · <NAME> with LOCAL for the local node; state word toggles Streaming / Idle / Offline; SESSION uses uppercase letter suffixes (1H 43M / 0M 12S) per formatUptime. - Signal rail tile counts are scoped to the 2000-entry buffer and reset with Clear; CONTAINERS is buffer-bound, not a monotonic accumulator. - Filter strip controls quoted verbatim (Stacks · All / Stacks · n, segmented controls All / Out / Err and All / Info / Warn / Error). - Feed row anatomy: severity dot, timestamp, brand-cyan container name with stack/container tooltip, message tinted by source. Row tint follows detected level, which is regex-based, so an STDOUT line containing ERROR: still classifies as ERROR. - Day bands: NOW, Nm AGO, Nh AGO, calendar date. - Empty states: two-tier kicker over caption (Awaiting events / No matches). - Pause keeps the SSE buffer filling up to the 2000-entry cap; resume pill reads <n> NEW · RESUME and counts the queue, not total arrivals during the pause. - Download filename and row format quoted: sencho-logs-<ISO8601>.txt and [<ISO>] [<stack>/<container>] <LEVEL>: <message>. Documents behavior the previous page never covered: - Active-node scoping; node switch resets the stream and the buffer. - SSE primary transport with 30-second server heartbeat and a 5-second polling fallback against /api/logs/global (server-capped at 500 lines per snapshot). - Initial replay of the last 500 lines per container when the SSE connection opens, so the feed has context immediately. - Display limits (2000 client buffer, 300 rendered rows, Showing last 300 of N overflow notice). - Refresh cadence table covering UI tick, flush cadence, polling cadence, SSE heartbeat, sparkline window, and the Idle threshold. Adds a seven-accordion troubleshooting block (Offline state, gray Idle dot, ERROR-without-tint, growing Resume pill, Clear-cutoff lag, node-switch buffer drop, fleet-wide aggregation expectations). Tightens the closing Note so it makes clear that Notification Log Retention does not govern this live container stream. * docs(alerts-notifications): refresh page for v1 and absorb notification-routing Full v1 template rewrite of /features/alerts-notifications. Bundles in the entire Notification Routing page so a reader sees channels, routing, per-stack rules, and retention in one place; deletes the standalone notification-routing.mdx and points all five cross-link sites at the new in-page anchor. * docs(alerts-notifications): drop "What's not in scope" section The page should describe what Sencho does, not enumerate what it does not ship. Users find missing integrations through the Webhook section and the routing matcher reference; the explicit disclaimer added noise without adding guidance. * docs(audit-log): refresh page for v1 layout, expanded action list, troubleshooting accordion - Clarify that the search/method/date filter strip lives in Table view only. Stream view always shows the unfiltered chronological feed. - Fold the total-entries readout into the card subtitle wording where it actually renders, instead of describing it as a separate header element. - Sharpen the Peak hour off-hours window to the literal 08:00 to 17:59 working window the tile keys off, plus the 5% / 20% failure-rate tints. - Note that the Actors tile names a sample actor alongside the new-IP count. - Expand the example actions list to cover surfaces that have shipped since the last edit: per-service stack lifecycle, node cordon/uncordon, fleet replica role changes, Sencho Cloud Backup operations, Fleet Secrets, and blueprint federation pin updates. - Correct the Settings path: Settings · Developer · Data retention card, Audit log input, Save settings button. - Add a Troubleshooting AccordionGroup matching the rest of the v1-refresh pages: missing tab, filter scope, anomaly thresholds, export cap, and retention pruning. - Replace all four screenshots with fresh captures of the current UI. * docs(multi-node): refresh page for v1 layout, pilot agent mode, refreshed table columns Rewrites docs/features/multi-node.mdx against the current product. The previous page predated the v1 Settings hub redesign and the Pilot Agent enrollment model, so it documented only the Distributed API Proxy add-node flow and missed the new Mode, Endpoint, and Labels columns on the Nodes table. Restructures the page into 13 sections: intro, How it works, the local node, Choose a remote mode (decision table comparing Pilot Agent vs Distributed API Proxy), Add a remote node: Pilot Agent (three steps plus re-enrollment), Add a remote node: Distributed API Proxy (three steps), Switching between nodes, the Nodes table (full column reference), What Settings apply per node (verified against settings/registry.ts), License enforcement across nodes, Editing and deleting nodes, Security (token security, transport encryption, why no application-layer TLS), and Troubleshooting (AccordionGroup matching the v1 template used on audit-log, atomic-deployments, and deploy-progress pages). Refreshes seven screenshots against the production node signed in as admin, scrubbing IPs and usernames before capture: full Nodes panel overview, Generate Node Token card with a placeholder token, Add node modal in Pilot Agent mode, Add node modal in Distributed API Proxy mode (with the inline plain-HTTP warning visible), Edit modal showing the Regenerate enrollment token card for a pilot agent, Pilot enrollment modal with the docker run command, refreshed node switcher popover, and a close-up of the table columns. Drops the obsolete add-node-form.png, http-warning.png, and per-node-scheduling/ folder. * docs(fleet-view): refresh page for v1 layout, expanded tabs, cordon, sheet-based updates - Aligns the Overview, Status, and Node Updates content with today's UI: the masthead's `The fleet` headline plus CPU / MEM / CONTAINERS stat tiles, the eight-tab strip (Overview, Snapshots, Status, Deployments, Traffic, Federation, Fleet Actions, Secrets) with per-tier visibility, and the Check Updates surface that is now a system sheet rather than a modal. - Documents the toolbar (search, sort, filter popover with Status / Type / Severity / Tags sections) and the Grid / Topology segmented control including the topology graph's status pill (Online / Critical / Offline), connector colouring, ReactFlow controls and minimap. - Documents the per-card surfaces that were missing from the prior page: Cordoned badge with cross-reference to Fleet Federation, fleet stack label dots in the drill-down, container drill-down rows (state dot, badge, image, status, open-in-editor hover button), and the Admiral three-dot Node actions menu for cordon / uncordon. - Documents the Node Updates sheet anatomy (Recheck and Update all (n) header actions, four summary cards, node table columns, Update flow, reconnecting overlay timing, admin enforcement) and the GitHub Releases with Docker Hub fallback resolution path with its 30-minute cache. - Replaces every stale screenshot with a fresh capture (overview, topology, drill-down, status tab, node updates sheet) and removes the obsolete files plus the empty docs/images/fleet/ folder. - Reformats troubleshooting as an AccordionGroup matching dashboard, multi-node, and audit-log refreshes. * docs(fleet-backups): refresh page for redesigned fleet and settings UI Replace all six screenshots with current production captures. Update content to reflect the new fleet header card, eight-tab layout, full- page Cloud Backup settings with header stats, and corrected navigation paths. Add cloud backup rows to the access control table. * docs(fleet-backups): convert troubleshooting to AccordionGroup pattern Match the foldable-accordion pattern used across the v1 docs refresh batch. Merges the standalone Cloud Backup troubleshooting subsection into a single Troubleshooting section at the bottom of the page with seven accordions covering skipped nodes, two restore failure modes, three cloud-upload failure modes, and a diagnostic logging entry. * docs(remote-updates): refresh page for v1 sheet, accordion troubleshooting, factual fixes Rewrites the page against the v1 docs refresh template (Note tier gate, sectioned mechanism deep-dive, Frame screenshots with detailed alt text, inline AccordionGroup troubleshooting), bringing it in line with the recently-refreshed fleet-view, fleet-backups, dashboard, and audit-log pages. The page is repositioned as the mechanism deep-dive (prerequisites, what runs on a node during an update, completion and failure detection, recovery actions). The full UI tour for the Node updates sheet remains in fleet-view so the two pages stop overlapping; remote-updates now links into fleet-view#node-updates instead of restating the table anatomy. Captures three screenshots from the production node, signed in as admin: fleet-node-updates.png shows the Node updates sheet with eight nodes and seven remote updates available; local-update-confirm.png shows the LOCAL · UPDATE alert dialog with the Cancel and Update & restart buttons; node-card-update-available.png shows the Opsix card with the Update available pill and the Update to v0.76.7 outline button. Corrects several factual claims that no longer matched the current code: - The remote early-fail threshold is about 3 minutes, matching EARLY_FAIL_MS in backend/src/routes/fleet.ts, not 90 seconds. - The Recheck button sits in the sheet header, not the footer. - The component is a SystemSheet, so the page now consistently calls it the Node updates sheet instead of a dialog, with lowercase "Node updates" and lowercase "Update all (n)" matching the live UI. - Reconnecting overlay polls /api/health every 3 seconds, not "every few seconds". - The local Failed badge surfaces as soon as the helper writes its error file, by the 3-minute mark at the latest. Documents the LocalUpdateConfirmDialog kicker, title, body, and CTA verbatim, the Triggering... loading state on the Update buttons, the four completion signals the gateway accepts (version change, process startedAt change, offline-then-online transition, version at or above the comparison target after 15 seconds), and the 60-second auto-clear of the Updated badge. Drops references to two screenshots that never existed (fleet-node-updating.png, fleet-node-failed.png); the in-flight and failed states are described in prose instead, the same way fleet-view handles them. * docs(scheduled-operations): refresh page for v1 timeline, fleet-wide update action, sheet-based run history Rewrites the Scheduled Operations page against the v1 template (Note tier gate, sectioned anatomy, Frame screenshots, AccordionGroup troubleshooting) applied to sibling pages in this batch. Captures seven fresh screenshots against the production node signed in as admin (timeline, all-tasks, action-picker, create-restart, create-prune, create-scan, run-history) and removes every legacy PNG. Documents the new "Auto-update All Stacks" action that was absent from the page, extends the Skipper allow-list to all four Skipper actions (Auto-update Stack, Auto-update All Stacks, Fleet Snapshot, Vulnerability Scan) and clarifies that the action picker hides operations the active tier cannot run. Corrects several factual claims that no longer matched the code: - Scheduled scan completion is `info`/`scan_finding` on a clean run and `warning`/`scan_finding` when findings are present (not `info`/`system` as previously stated). Cross-link now points at `alerts-notifications#vulnerability-scanning`. - Lifecycle actions (auto_backup, auto_stop, auto_down, auto_start) execute against the local Sencho instance only; only Auto-update Stack / All Stacks have a remote-proxy code path. The page reinstates the guidance to schedule remote lifecycle operations from that node's own UI. - Run history lives in a right-side sheet with a "Schedules › <task> › Runs" breadcrumb and a Download CSV secondary action. - Timeline masthead is described in terms of the v1 visual (`NEXT 24 HOURS` kicker, italic display heading, monospace date range, right-anchored Next pill with countdown, glowing cyan now rail, six-tick bottom axis). * docs(rbac): refresh RBAC & user management page against v1 template Bring /features/rbac onto the v1 docs refresh template (Note tier gate, sectioned anatomy, Frame screenshots, AccordionGroup troubleshooting). Recapture five screenshots from the production node signed in as admin and remove the three stale captures under docs/images/rbac/. Corrections vs. the prior page: - Deployer no longer claims node:read in the permission matrix; the backend grants only stack:read and stack:deploy. - Add the system:registries row (container registry management). - Document the form as inline below the Add user button (not a modal). - Note the (you) marker on the signed-in admin's row and the disabled delete icon on that row. Additions: - Settings nav location and hub-only visibility. - 2FA reset row action with verbatim modal kicker, title, and body. - Five-failure / 15-minute MFA lockout behavior and admin reset recovery. - Token-version session-security table covering deletion, role change, password change, and admin 2FA reset. - SSO password-fields-hidden line quoted verbatim and the per-provider Require MFA toggle. - Audit-log emissions list for every user-management mutation. - API tokens cross-link explaining the user-vs-machine boundary. - Scoped permissions section retightened: scoped role picker is Deployer / Node Admin / Admin only; resource type is Stack or Node. AccordionGroup with eight troubleshooting entries covering missing nav, greyed role options, seat-limit errors, unexpected sign-outs, scoped deployer mismatches, missing shield icon, re-locking MFA accounts, and SSO role drift at provisioning. * docs(2fa): refresh two-factor authentication and admin guide against v1 template Bring /features/two-factor-authentication and /operations/two-factor-admin onto the v1 docs refresh template (Note tier gate, sectioned anatomy, Frame screenshots with descriptive alt text, AccordionGroup troubleshooting, verbatim modal copy with kicker callouts). Recapture every screenshot under docs/images/two-factor-auth/ from a fresh session and add six new captures for surfaces the prior page did not document. Corrections vs the prior pages: - Panel rename: Settings -> Account & Security is now Settings -> Account, under the Identity group of the settings sidebar. Replaced every occurrence on both pages. - Enrol dialog titles match the current modal: Pair your authenticator, Confirm the pairing, Save your recovery codes (was: Set up 2FA, Confirm, Save your backup codes). Step rail 01 PAIR / 02 CONFIRM / 03 ARCHIVE documented. - Manual-entry affordance is the always-visible Secret manual entry row with a copy icon, not the toggleable Can't scan Show secret key link. - Confirm step auto-submits on the sixth digit; no submit button. Verified in MfaChallenge.tsx and MfaEnrollDialog.tsx and called out explicitly. - Authenticator-app list trimmed to match in-app copy (1Password, Bitwarden, Google Authenticator, or any TOTP app). Authy and Microsoft Authenticator dropped because the dialog does not mention them. - Disable dialog: kicker SECURITY MFA DISABLE, title Turn off two-factor, destructive header, Disable button. Replaces the prior Disable 2FA paragraph that did not describe the dialog chrome. - Regenerate dialog: two-step flow with kicker SECURITY BACKUP CODES, Confirm identity then New recovery codes, with the verbatim PREVIOUS CODES HAVE BEEN INVALIDATED warn rail on the show step. Documented that the dialog only accepts a TOTP, not a backup code. - Per-user SSO toggle label corrected: Require 2FA on SSO sign-in (was: Require 2FA even when signing in via SSO). Added the per-provider vs per-user distinction on both pages (admins can also enable Require MFA on the SSO provider config, which is independent of the per-user toggle). - Admin reset modal: verbatim USERS RESET 2FA kicker, Reset 2FA for <username> title, full-body copy reproduced. Documented that the reset bumps the target's token version and invalidates active sessions. Additions: - Sign-in throttle: five failed verifications lock the account for 15 minutes, server returns 423 with Retry-After, UI shows the Retry in MM:SS countdown plus Rate limited label. Lockout recovery section explains that the counter only clears on a successful sign-in, so retries after the window expires re-lock immediately. - Account panel anatomy section enumerates the three rows (Authenticator app, Backup codes, Require 2FA on SSO sign-in) plus the destructive Disable 2FA link, and the masthead 2FA on / BACKUP N left chips. - Recovery codes section now covers all three count states (3 plus, 1 to 2, 0) with verbatim helper text, tone, and the standalone No backup codes left callout that renders at zero. New screenshots for the 2-remaining and 0-remaining states. - Cross-references to the admin operations page (CLI fallback, token version rotation, what a reset changes in the DB), the SSO page, and the RBAC page (per-provider Require MFA toggle, SSO auto-provisioning). Troubleshooting on the feature page rewritten as an AccordionGroup with nine entries: clock drift, wrong account selected, QR will not scan, lost phone with no codes, lost codes with authenticator, ran out of codes, unexpected SSO prompt (with both toggle causes), repeated lockout after the window expires, missing shield icon on Users panel. The admin operations page also gains the SSO + 2FA two-toggles table so administrators can answer the per-user vs per-provider question without context-switching between pages. Six new images added; six existing images replaced. Total 14 captures. * docs(rbac,host-console): drop enforcement-boundary detail from tier-gate notes Operator-facing docs should state tier or role requirements once, in plain customer-facing language, and leave the enforcement chain to the source. Two surfaces on the v1-refreshed pages over-specified the gate: - `features/rbac.mdx::Scoped permissions`: the Note enumerated both the UI hide on Skipper and the `/api/users/:id/roles` write rejection. The first half ("Scoped permissions require Admiral.") is the operator-relevant fact; the rest reads as a fence specification, which is awkward for an open-core product where the gate is readable in source anyway. Trimmed to just the tier claim. - `features/host-console.mdx::Availability`: the paragraph already says who can use the console and that the Console tab is hidden on Community or Skipper. The trailing "Attempting to access the console endpoint directly without the correct license or role is rejected" is the same bypass-prevention coda. Dropped. No functional behavior change; the gates themselves are untouched. * docs(sso): refresh SSO & LDAP authentication page against v1 template Rewrites docs/features/sso.mdx against the v1 docs refresh template (intro + tier callout, sectioned Configuration anatomy, Frame screenshots, AccordionGroup troubleshooting), bringing it in line with the previously refreshed two-factor-authentication and rbac pages on this branch. Recaptures all four screenshots from the production node signed in as admin: sso-settings (overview with the five collapsible provider cards), sso-settings-ldap (LDAP form expanded), sso-settings-oidc (Google form expanded), sso-settings-custom-oidc (Custom OIDC form expanded with all eleven fields). Refreshes the Settings UI section to match the redesigned panel: each provider is a collapsible card with an Active badge on the header, an enable / disable toggle pill, and a footer with Save, Test Connection (green check or red X next to the button), and Remove (only after a config has been saved). Documents the static callback-URL helper that sits below all five cards. Clarifies that the per-OIDC claim mapping environment variables (SSO_OIDC_*_ID_CLAIM, *_USERNAME_CLAIM, *_EMAIL_CLAIM) are accepted for Google, GitHub, and Okta, not just Custom OIDC. The Settings UI hides those fields on the presets because the defaults match. Converts the troubleshooting section to an AccordionGroup with five entries (Test Connection discovery failure, issuer validation error, wrong username or missing email after sign-in, invalid redirect URI, SSO buttons missing on the login page). Cross-links the operations troubleshooting page for setup-time errors. Tightens the LDAP TLS env var note to spell out the literal string 'false' requirement. Syncs the Combining SSO with 2FA section to use the live toggle label 'Require 2FA on SSO sign-in'. * docs(sso): drop the Community-tier Custom OIDC workaround tip The Tip walked through how a Community-tier operator could integrate Google, GitHub, or Okta by pointing Custom OIDC at the provider's discovery URL, bypassing the Skipper preset gate. Operator docs should state the tier rule once and stop; they should not describe how to circumvent it. The tier matrix above the removed block already names which providers are paid; the Custom OIDC row already lists "any spec-compliant OIDC provider" as its scope. That is enough. * docs(vulnerability-scanning): refresh page for v1 UI and corrected tier mapping The page was last revised before the v1 visual redesign and before the tier-mapping changes shipped in v0.81.2 (open Community access to secret scanning, compose misconfig scanning, scan history, and scan comparison). This refresh: - Rewrites the tier matrix to match the shipped Community / Skipper / Admiral split. Secret detection, compose misconfig scanning, scan history, scan comparison, and misconfig acknowledgements are now correctly marked as Community. Scheduled fleet scans, scan policies with block_on_deploy, SBOM, SARIF, and Trivy auto-update stay paid. - Drops two stale Notes that said secret detection and compose misconfig scanning required Skipper or Admiral. The page now states each tier requirement once, in plain language. - Refreshes all six existing screenshots from the production node: resources-badges, scan-details-sheet, scan-history-sheet, scan-compare-sheet, security-settings, app-store-toggle. - Adds a new scan-config-button screenshot showing the stack-page overflow menu where Scan config now lives. - Describes the scan drawer header accurately: Re-scan + Compare + CSV + SARIF as top-level buttons, with SBOM as a separate button below the summary. - Updates the compose misconfig flow to point at the stack overflow menu (not the Deploy controls). - Converts the troubleshooting section to a single AccordionGroup per the v1 template, and audits each entry for legacy phrasing and the removed tier claims. - Adds a TRIVY_BIN reference to the How it works section so operators know about the host-binary override. * docs(cve-suppressions): refresh page for v1 UI and corrected suppression specifics - Recapture all three screenshots from the production node signed in as admin under `docs/images/cve-suppressions/` (`settings-panel`, `create-dialog`, `suppressed-row`). The previous file referenced three image paths that did not exist in the repo. - Align prose with the actual UI labels: - Dialog kicker `SUPPRESSIONS . NEW`, title `New suppression`. - Field labels match the form: `CVE or advisory ID`, `Package (optional)`, `Image pattern (optional)`, `Reason`, `Expires in (days, optional)`. - Remove confirmation reads `Remove suppression` with kicker `SUPPRESSIONS . REMOVE . IRREVERSIBLE`. - Factual corrections: - Fleet sync truncation cap is 5,000 rows (not 10,000). - State the admin-role requirement once in the lead Note. - Drop references to a `Fleet . Sync status` page and a `Reanchor` button; neither exists in the UI. The reanchor flow is an admin API call and is documented in /features/fleet-sync. - Sharpen the specificity scoring section (package + image scores 3, package only 2, image only 1, neither 0) so the order matches the read-time filter logic. - Note that the image-pattern glob is case-sensitive. - New coverage: - Suppressing directly from a scan result, including which fields are read-only in that inline flow and when to fall back to Settings to broaden scope. - The `replicated` and `expired` row badges in the panel. - Hovering the package column on a suppressed row to surface the Reason. - Two distinct read-only modes: viewing a remote node from the hub (panel hidden, banner shown) versus signing into a replica instance (panel visible, read-only). - SARIF export carries suppressions through as `kind: external, status: accepted`, cross-linked to the Vulnerability Scanning page. - Convert troubleshooting to AccordionGroup with six entries; update the truncation entry to reflect the 5,000-row cap. * docs(private-registries): refresh page for v1 UI and fleet-wide credential model Rewrites the page against the v1 docs template (Note tier gate, opening Frame, sectioned anatomy, AccordionGroup troubleshooting) and replaces every screenshot with a fresh capture taken against the current product. Corrects several factual claims that no longer matched the current code: - Registries are stored once on the control instance and applied fleet-wide, not configured per node. The old Multi-node behavior section and the matching troubleshooting entry described a per-node model that the product no longer has. - The Registries section is hidden on remote nodes (global scope) and on Sencho versions that do not surface the feature. New troubleshooting entries explain both visibility states. - The feature is admin-only on Admiral. Non-admin operators do not see the section even on Admiral; previous copy implied any Admiral license user could manage credentials. - Registry endpoints are not reachable from API tokens; only an admin browser session can manage credentials. The Security section now states this without naming internal route paths. Documents UI behavior the previous page omitted: the inline form (not modal), the four type-specific form variants, the Docker Hub read-only URL field, the destructive delete confirmation with its stack-pull warning, the masthead REGISTRIES count, and the empty-state callout copy. Screenshots replaced: - registries-overview.png: section with one configured GHCR card and the masthead stat at one. - registries-empty.png: empty state with the Add registry button and callout. - registries-add-form.png: inline form with the Docker Hub default and the read-only URL field. - registries-ecr-form.png: form switched to ECR, showing the AWS Region field and the relabelled AWS credential inputs. - registries-card-detail.png: card close-up with the three action icons and the metadata row. - registries-delete-confirm.png: destructive ConfirmModal with the kicker, title, and stack-pull warning body. - registries-with-entry.png removed (superseded by registries-overview.png and registries-card-detail.png). * docs(auto-update): refresh readiness page for v1 redesign Bring the Auto-Update Readiness doc in line with the shipped UI: - Replace the hero screenshot with a fresh capture of the redesigned board (italic-display hero, brand-cyan accent, per-node groups with local/remote pills, dashed-border changelog separator). - Rewrite the card-anatomy list. Drop the rollback-target bullet (the field exists in the backend payload but is not rendered). Add the "Rebuild available" inline label and the primary-image / multi-service count line. - Rewrite the risk-tags table as a risk-badges table using the actual badge labels and colors emitted by the UI (Safe / Review / Blocked with the corresponding icons; Digest rebuild for non-semver tags). - Add an Empty state section and document the per-node group header. - Tighten the hero subtitle paragraph to match the actual UI string (only major-bump count is surfaced separately; preview failures are not). - Fix workflow step 4: major-bump apply path is the stack lifecycle Update action, not the Schedules editor (a scheduled task hits the same block). - Add the 2-minute manual-refresh cooldown to the Recheck workflow. - Remove the broken cross-link to the non-existent /features/image-update-detection page and inline the 6-hour cadence fact from ImageUpdateService.INTERVAL_MS. - Convert troubleshooting to AccordionGroup format per the troubleshoot ing convention used on /features/deploy-progress. - Sync the Auto-Update entry in /features/overview.mdx to the new badge labels and the corrected hero-counter description. * docs(auto-update): fix Auto-Update entry point in Workflow step 1 Workflow step 1 said "Open the Auto-Update view from the sidebar." The Auto-Update view is opened from the top nav strip (alongside Home, Fleet, Resources, App Store, Logs, Schedules, Console, Audit). The sidebar carries the stack list and the per-stack right-click / kebab context menu that toggles auto-updates on or off; it does not house the Auto-Update top-level view. * docs(auto-update): trim enforcement detail from per-stack control note State the tier requirement once and stop, per Directive 27. The "The toggle does not appear on Community" sentence enumerates the enforcement effect of the gate, which the source already reflects; operator docs do not need to narrate it. * docs(auto-heal): refresh page for v1 UI and policy hardening Rewrite Auto-Heal Policies docs against the current Stack Monitor sheet: corrects the Max restarts / hr field label, documents the per-policy enable toggle, the consecutive-failures pill, the full Recent activity action set (including Docker unavailable), the 30s evaluation cadence, multi-node behavior, notification dispatches, and the dashboard Configuration status counter. Replaces the broken /images/auto-heal-policies/policy-sheet.png reference with three fresh screenshots captured against a live node: the sheet on the Auto-heal tab, a single policy row, and the expanded Recent activity panel. * docs(webhooks): refresh page for v1 UI, correct tier and add Git source sync - Fix tier note: gate is Skipper or Admiral, management is admin-only. - Update Settings path to Settings -> Alerts -> Webhooks; document the read-only Node field and the green secret-reveal callout. - Add the missing Git source sync action and the git-pull override value. - Refresh the configured-webhooks card description: action/stack/node badges, On/Off toggle, copy URL, and the Recent executions disclosure. - Tighten the trigger section with a constant-time signature check note and a status/body/meaning response table. - Add an Accordion troubleshooting block covering common signature failures, the 404 case, no-op actions on 202, and git-pull prereqs. - Re-capture all three screenshots from the v1 UI. * docs(webhooks): wrap troubleshooting accordions in AccordionGroup * docs(sidebar): refresh page for v1 redesign with filter chips, bulk mode, row anatomy, and troubleshooting Rewrites the Stack Sidebar page against the live v1 sidebar and the v1 docs refresh template (Frame screenshots, Note tier callouts, AccordionGroup troubleshooting). Recaptures all four existing screenshots and adds three new captures: filter chips, row anatomy, and bulk mode. Adds coverage for features the previous page omitted entirely: the ALL / UP / DOWN / UPDATES filter chips with their counts cap and collapse toggle; bulk mode (B key, sticky toolbar with Start / Stop / Restart, and Update gated on Skipper or Admiral); stack-row anatomy (status pill, label dots with +N overflow, image-update dot vs Git source icon priority, hover kebab); the Auto-update toggle, Schedule task, and Open App entries in the context menu; the B shortcut for bulk mode. Corrects three claims that no longer matched the code or UI: Auto-Heal is gated on Skipper or Admiral, not universal; the global Ctrl+K opens the command palette, not the sidebar search box; the activity footer kicker reads LIVE / IDLE with the verbatim copy from SidebarActivityTicker. Documents the in-menu ↗ and L › glyphs as visual hints rather than global keybindings to match useStackKeyboardShortcuts.ts. * docs(sidebar): trim enforcement-effect sentence from context-menu tier note State the Skipper / Admiral requirement once and stop, per Directive 27. The "They do not appear in the menu on Community" clause described the enforcement effect alongside the gate, which the directive bans in operator-facing docs. * docs(host-console): refresh page for v1 UI and clarify shell metadata Rewrite the Host Console page to match the current Cockpit layout (masthead + terminal well + chip strip), replace the legacy PowerShell screenshot with a fresh bash capture, and document the masthead tone states, kicker, metadata pills, and session/heartbeat behavior. Trim the security section to state the tier and role rule once. * docs(licensing): refresh page for v1 UI, corrected pricing, and trial flow Rewrites the Licensing & Billing page to match the redesigned v1 Settings layout. The previous draft still described the legacy Settings Hub: in-app "Upgrade your plan" Skipper/Admiral cards, "Start monthly trial" / "Start annual trial" buttons, the "Have a license key?" field, "Manage Subscription" with a capital S, "Deactivate License" as the button label, and the license-active.png asset rendering the literal "Sencho Pro" string in the card title. None of that exists in the current product. - Refreshes the Plans table to the live pricing on sencho.io/pricing and adds an Enterprise mention with the floor price ($3,500/year). Skipper now $11.99 annual / $14.99 monthly / $449 lifetime, Admiral now $69.99 annual / $89.99 monthly / $2,499 lifetime. - Rebuilds the Feature breakdown from a code-level audit of every requirePaid, requireAdmiral, requireScheduledTaskTier, and requireTierForSsoProvider call site in backend/src/routes, not from the marketing page. Notable code-grounded items: CVE suppressions on Community (no requirePaid guard), manual fleet snapshots on Community (scheduled snapshots on Skipper), Sencho Mesh under Admiral (entire mesh.ts router is requireAdmiral), and scheduled-task tiering names update/scan/snapshot as the Skipper subset with everything else under Admiral. - Rewrites the Free trial flow end to end. The previous steps told operators to click in-app "Start monthly trial" or "Start annual trial" buttons; no such buttons exist. The new flow starts on sencho.io/pricing, switches to the Annual or Monthly tab, clicks "Start 14-day trial" on the Admiral card, completes the Lemon Squeezy checkout (card-required, no charge before day 14), and pastes the issued key into Settings -> License -> License key. - Adds a new "The Plan section" anatomy block describing the masthead SCOPE / PLAN / DURATION (or RENEWS, TRIAL, STATUS) stat pills and the Plan card fields (Customer, Product, masked License key, status helper). - Adds a new "License states" reference table covering Community / Trial / Active subscription / Active lifetime / Expired / Disabled, what each surface renders, and which of the Plan / Activate / Pricing sections is visible in each state. - Corrects every UI label that drifted: section heading is Activate, field label is License key (not "Have a license key?"), buttons are Manage subscription (lowercase s) and Deactivate (not "Deactivate License"), and the action-row hint reads "Lemon Squeezy manages billing". - Documents the redesigned profile dropdown: identity header with initials chip, role badge, and tier badge, then Settings, conditional Billing, Documentation, Feedback, an Appearance segmented control, and Log Out. Billing only appears when the license is an active non-lifetime subscription. - Replaces all four screenshots under docs/images/licensing/: license-admiral-active.png (production Admiral lifetime view), profile-menu.png (redesigned popover), and two new captures for the Community-tier surfaces (license-activate-section.png, license-community.png). Removes the stale license-active.png (legacy "Sencho Pro" card) and profile-billing.png (legacy dropdown). * docs(settings-reference): refresh page for v1 UI with new sections and masthead Rewrites docs/reference/settings.mdx against the current Settings Hub so a reader encounters an accurate map of every section. Adds the previously missing **Cloud Backup** and **Security** sections, restructures **System Limits** into Host thresholds and Docker hygiene subsections (GiB units, "Global crash capture" toggle), fixes the Account password minimum to 8 chars and documents the two-factor subsection, refreshes License/Routing/Webhooks/App Store with the field labels actually rendered today, and documents the masthead pills (SCOPE/NODE, EDITED, plus the per-section stats like 2FA, PLAN, CHANNELS, ROUTES, WEBHOOKS, LABELS, TRIVY, POLICIES, PROVIDER, USED, SNAPSHOTS, DEV MODE). Replaces five existing screenshots that predated the v1 redesign and adds five new captures: Account with the 2FA card, License panel, System Limits with both subsections, Security with the Trivy installer, and Cloud Backup with Sencho Cloud Backup provisioned. All shots taken against the production node. * docs(licensing): drop billing-provider name from operator-facing copy The previous draft named the third-party billing provider in nine places (checkout, receipt email, error toast verbatim, Customer / Product field descriptions, the action-row hint, the billing portal, and the validation API). Operator docs don't need to advertise which vendor sits behind the checkout, billing portal, and validation calls. Rewrite each instance to describe what the operator sees and does without naming the upstream service. * docs(node-compatibility): refresh page for v1 UI with lock card visuals and current capability list - Replaces the legacy "dim + blur + pill overlay" description with the current CapabilityGate behavior: a centered lock card with an Unplug icon, title "<feature> is not available on this node", and a body line that names the node and its running version. - Corrects the tier-interaction section: on the wrong tier the entry point is hidden entirely, so the lock card only appears for users who already cleared the license gate. - Documents the public /api/meta endpoint, the 5-minute success cache, the 30-second failure cache, and the lazy-fetch behavior visible in the switcher (the version pill appears once a node has been visited). - Refreshes the capability table against the current CapabilityRegistry list, adding container-exec and vulnerability-scanning, with a note that vulnerability-scanning is only advertised when Trivy is installed. - Adds three production screenshots captured on the live fleet: switcher popover with mixed-version pills (one node on v0.76.9, rest on v0.81.11), a real lock card on an older pilot agent, and the Connection Details panel from Settings · Nodes. * docs(security): refresh security architecture page for v1 UI Add Fleet Secrets and Webhook signatures cards plus tier-matrix rows for shipped-but-undocumented features. Rename SSO presets from "one-click" to "preset providers" (presets still require OAuth-app provisioning on the upstream IdP). Update settings paths to the v1 middle-dot convention: Settings · Users, Settings · Account, Settings · Developer · Data retention. Extend the encryption-at-rest list with registry credentials and Fleet Secrets bundle payloads (both sealed with the same AES-256-GCM data key) and clarify the password section with bcrypt cost factor 10. Add a Webhook signature authentication subsection covering the per-webhook HMAC-SHA256 secret, one-shot display, masked preview thereafter, and constant-time comparison on inbound triggers. Replace the API Tokens screenshot with a fresh capture against the v1 Settings · Identity · API Tokens panel. * docs(security-advisories): retire reference page The reference/security-advisories page does not survive the v1 docs refresh: - Misuses the term "Security Advisories", which industry-wide refers to published notices for confirmed product CVEs (ID, severity, affected versions, fix version, remediation). The retired page was a narrative changelog of internal hardening work between v0.19 and v0.25.2. - The narrative is also frozen at v0.25.2 (April 2026) while current release is v0.81.11. Refreshing it would require backfilling ~56 release entries' worth of hardening copy. - The framing is uniformly "improved from prior behavior" (minimum 8 characters up from 6, 1-year token expiry previously without expiry, CORS previously allowed all origins, users should upgrade promptly). Sencho has not shipped publicly; there are no users to address as upgraders. All operationally relevant content already lives elsewhere: the security architecture page covers the current posture, verifying-images covers the supply-chain attestations, cve-suppressions covers operator acknowledgment, vulnerability-scanning covers the in-app scanner, and contact + the security architecture page both surface the disclosure path. Published Sencho-product advisories, when any exist, will appear on the GitHub Security tab, which is already linked from those pages. Inbound-link audit returned a single hit on the nav entry itself; no other doc, README, or operator artifact deep-links the slug. * docs: rewrite Pilot Agent page with deep architecture and operations reference Reframes docs/features/pilot-agent.mdx as the architecture-and-operations companion to the operator walkthrough in Multi-Node Management. Adds a mental model section, an explicit security and trust model, a full agent env-var reference, an honest limitations list, and a 5-item FAQ. Verifies every constant and label against the current backend source. Refreshes four production screenshots (admin login, scrubbed) and resolves the previously-broken /images/pilot-agent/enrollment-dialog.png reference. Adjacent edits keep the cross-linking coherent: - multi-node.mdx adds a one-line forward link to the rewritten page - security.mdx adds a Pilot Agent tunnel credentials subsection * docs(fleet-federation): deep rewrite with production screenshots Rewrites the Fleet Federation page against the v1 docs refresh template following the recent fleet-view, pilot-agent, and multi-node refreshes. Doubles the page length (92 to 204 lines) while keeping the cut-line v1 MVP scope: operator-driven placement controls (cordon + pin) for Blueprints, no expansion into mesh/sync/pilot territory. What changed: - Adds four production-captured screenshots under docs/images/fleet-federation/: the Federation tab with a cordoned node populated, the node-card kebab menu showing the Cordon node entry, the cordon confirmation dialog with a reason filled in, and a node card displaying the Cordoned pill. - Expands the page to eleven sections: opening summary, philosophy (kept), key capabilities, prerequisites, step-by-step usage with embedded screenshots, behaviour and lifecycle table, security and audit, limitations and non-goals (expanded), practical workflows (new: OS patching, host-to-host migration, gateway pinning), troubleshooting (eight accordions, up from five), and a Where Federation fits cross-link table. - Documents the exact production UI strings observed: the cordon dialog description, the uncordon confirmation copy, the reason field cap (256 chars), and the audit log action names (node.cordon, node.uncordon, blueprint.pin). - Documents the audit visibility surface so operators know how to filter the Audit view for cordon and pin history. - Adds eight cross-links to sibling pages (Fleet View, Multi-Node, Pilot Agent, Mesh, Fleet Actions, Fleet Sync, Blueprints, Licensing) with one-line scope contrasts so newcomers can place Federation in the broader fleet picture. - Tightens lifecycle table to operator-relevant terms (no DB column names) and audit section to operator-facing wording (no middleware names), keeping the page operator-focused rather than implementation-focused. Validation: - Captured screenshots against the production node logged in as admin, using Playwright MCP. Cordoned and pinned actions reverted; audit log confirmed the matched cordon/uncordon pair. - Verified every cross-link target exists in the v1-refresh worktree (/features/fleet-view, /features/multi-node, /features/pilot-agent, /features/sencho-mesh, /features/fleet-actions, /features/fleet-sync, /features/blueprint-model, /features/licensing). - Compliance: no em dashes, no PII, no "previously"/"used to" framing, no fence-spec language, tier rule stated once in plain language. * docs(fleet-federation): drop fence-spec phrasing in the open-core context Sencho is open-core: anyone can clone the repo and read the tier gate. Operator docs that name exactly where the UI gate sits ("hidden at the Community and Skipper tiers", "lower-tier users do not see the toggle", "only the Federation tab is gated") work as a dig-target for a tech-savvy reader and undercut the open-core posture. Directive 27 already bans enforcement-chain spelling; the open-core threat model makes the same phrasings risky even when they describe UI surfaces rather than route guards. Removes three instances of the pattern on this page: - Top Note callout: drops "The tab is hidden at the Community and Skipper tiers." Keeps the one-line requirement: "Federation is an Admiral feature. Cordon and pin actions require an admin user role." - Security and audit section: drops the sentence enumerating which UI affordances are hidden from which tiers. Keeps the customer-visible behavior (the Cordoned pill stays visible at every tier as a read-only signal). - Troubleshooting "Federation tab is not visible" accordion: rewrites to lead with the requirement and the role check, drops the "Federation is hidden by design" and "only the toggle and the Federation tab are gated" phrasings. Other claims on the page unchanged; rule is still stated once in plain language at the top of the page. * docs(fleet-sync): deep rewrite with production screenshots Replace fleet-sync.mdx with a verified end-to-end reference. The previous page named two replicated resources but the code syncs three, described a sync-status panel and a fleet-vs-node scope picker that do not exist in the shipped UI, and was missing prerequisites and several edge cases. Highlights of the rewrite: - Names all three replicated resources (scan policies, CVE suppressions, misconfig acknowledgements) and treats them uniformly. - Drops the sync-status-panel and node-scope-picker UI claims; both move to the Limitations section as honest caveats. - Adds prerequisites covering the paid-tier requirement on the control, admin-role requirement, proxy-mode remotes, and reachability. - Expands lifecycle coverage: per-node serialised pushes, add-node backfill, monotonic pushedAt, per-resource watermarks, identity-drift notifications, the 5000-row truncation cap, stale-target warnings, audit-log entries on the replica. - New "Where Fleet Sync fits" closing table cross-linking to Fleet View, Multi-Node Management, Pilot Agent, Vulnerability Scanning, CVE Suppressions, Fleet Federation, Fleet Actions, and Licensing. - Two fresh production screenshots: control Security panel and the "Scanner is per-node" callout shown when proxying to a remote. * docs(fleet-actions): deep rewrite with production screenshots Three cards are documented end to end: Stop fleet by label, Bulk label assign, and Prune Docker resources fleet-wide. Adds the execution-path distinction (control-orchestrated fan-out vs single-node proxy), per-card behaviour and partial-failure semantics, prerequisites, limitations, practical workflows, an Accordion troubleshooting section, and a Where Fleet Actions fits comparison table linking the surrounding Fleet view features. Corrects the prior page's tab-neighborhood claim, confirm-dialog wording, autocomplete-vs-request scope, and missing batch ceiling. Replaces the ten-day-old single screenshot with five fresh production captures under docs/images/fleet-actions/. * docs(fleet-secrets): deep rewrite with production screenshots Full rewrite of /features/fleet-secrets matching the fleet-actions structure. Replaces the sparse v1 page (no Frames, inline Q&A) with a gold-standard layout: opening Frame, single Note for the tier gate, 'What it covers' table, mental model, prerequisites, create + edit + versions + push (Target / Preview / Results) sections each with a production Frame, Import from stack section, behaviour and lifecycle table, audit-trail mapping with the six exact audit strings, limitations and non-goals, practical workflows, AccordionGroup troubleshooting, and a Where-it-fits cross-link table. Adds six fresh production screenshots under docs/images/fleet-secrets/ : overview, create, versions, target, preview, and results. Documents the Import-from-stack flow (depends on the bundle editor's new Import action) and uses the post-rename 'Send' wording on the bundle-row action (depends on the aria-label fix). Corrects three factual drifts vs the code: env-key regex described as 'letter or underscore, then letters/digits/underscores; case- sensitive' to match ^[A-Za-z_][A-Za-z0-9_]*$ ; documents only the 'ok' and 'failed' status pills (the 'skipped' enum value is unused); replaces the bogus 'stack not found' troubleshooting entry with the real 'env file not declared' cause. Drops the fence-spec phrasing 'The tab is hidden on Community.' per Directive 31; the tier requirement is now stated once in plain language. * docs(sencho-mesh): deep rewrite with mental model, lifecycle, security, screenshots Replace the feature-reference page with a deep product + technical guide. Adds: - Opening hook framing audience and problem (cross-node service-to-service without a separate VPN or service-mesh sidecar). - Mental model: three moving parts (sencho_mesh bridge, alias registry, cross-node transport) with direction-of-flow described in prose. - Key capabilities, prerequisites, step-by-step usage with inline screenshots. - Full lifecycle section covering opt-in, opt-out, sticky stack-stopped state, peer reconnect, and the proxy-mode bridge with its real default (persistent, env-override for idle). - Security and trust boundaries split into authentication, inbound exposure, encryption, audit, and app-layer caveats. - Limitations and non-goals: one-alias-per-port, port 1852 reserved, central-relay for remote-to-remote, shared 1024-stream pool with the Pilot tunnel, no L7, host-network unsupported, in-memory activity log. - Three concrete workflow examples and a complete troubleshooting accordion (every data-plane reason, every probe stage, every unreachable cause) plus a Common questions FAQ. - Where Mesh fits CardGroup linking Pilot Agent, Multi-Node, Federation, Licensing. Corrections vs prior text: - Tab is labelled Traffic in the UI (not Routing); all navigation references updated. - Proxy-mode bridge default is no idle close (env-overridable to opt into idle teardown); prior 5-minute-teardown claim removed. - Audit trail scope tightened: only opt-in / opt-out write durable rows; tunnel-state and probe events live in the in-memory activity log. Adds seven production screenshots under docs/images/sencho-mesh covering Table view, opt-in sheet, graph (Tunnels and Aliases edge modes), Diagnostics, activity log, and per-stack topology. * docs(blueprints): add missing detail-state-review screenshot Captures the Blueprint detail sheet with a deployment row in the "Awaiting confirmation" status (stateful first-deploy gate), to fix the broken image referenced at blueprint-model.mdx:132. mint broken-links now reports zero broken references. * docs(blueprints): deep rewrite with mental model, lifecycle, security, prerequisites Restructures the Blueprints page against the v1-refresh template used by the recently-refreshed mesh, secrets, and atomic-deployments pages. Adds a mental model, prerequisites table, lifecycle and status-transition map, security and trust boundaries section, practical workflows, common questions accordion, and a Where Blueprints fits CardGroup. Removes the internal-style rollout and watch-plan section. Replaces all nine production screenshots with fresh captures against the production node signed in as admin, and adds two new captures (federation pin policy table, stateless eviction dialog). Rewrites the tier-gate Note to drop the fence-spec phrasing that violated Directive 31. Every retained claim is anchored to current backend or frontend code. * docs(pilot-agent): recapture enrollment dialog with compose payload Replaces the pre-0.84 docker-run capture with the current dialog (Compose file, two-step instructions, "Copy compose file" button) and refines the alt text to describe the captured content. URL and token redacted to placeholder values during capture.	2026-05-20 08:43:18 -04:00
Anso	d7d8f9bfe8	feat(dashboard): replace 24h charts with Configuration Status and Recent Activity (#785) ... * feat(dashboard): replace 24h charts with Configuration Status and Recent Activity The 24-hour CPU/Memory area charts summed per-container metrics normalized to each container's CPU quota, producing numbers that bore no honest relationship to host load. The live ResourceGauges strip already shows accurate host-level stats, making the historical charts both inaccurate and redundant. This commit replaces that row with two side-by-side cards: - **Configuration Status**: aggregates every toggleable feature on the active node (notification agents, alert rules, routing rules, auto-heal, auto-update, webhooks, scheduled tasks, MFA, SSO, vulnerability scanning, cloud backup, and alert thresholds) into a single at-a-glance card. Tier-locked rows display an upgrade indicator instead of a value. Each row is clickable and navigates to the relevant settings section. Data refreshes every 60 s and immediately on state-invalidate events. - **Recent Activity**: lists the ten most recent notification-history events for the active node (deployments, image updates, auto-heal actions, scan findings, cloud backup events, system notices) with category icons and relative timestamps. Refreshes every 30 s. New backend endpoints: - GET /api/dashboard/configuration - per-node feature status with locked/ requiredTier markers so the frontend renders upgrade chips without extra calls. The endpoint sits after authGate and before the remote proxy so remote-node requests are transparently forwarded. - GET /api/dashboard/recent-activity?limit=N - thin wrapper over DatabaseService.getNotificationHistory. - GET /api/fleet/configuration - fleet-wide fan-out using the same Promise.allSettled dead-node-tolerant pattern as /fleet/overview. Exposed as the new "Status" tab on the Fleet page (after Snapshots). Shared utilities: - visibilityInterval and formatCount extracted to frontend/src/lib/utils.ts so the three polling hooks and two components share a single copy. * docs(dashboard): fix stale alt text referencing removed historical charts	2026-04-26 18:42:28 -04:00
Anso	748ba46669	feat(dashboard): status masthead, unified gauges, stack health sparklines (#676) ... * feat(dashboard): status masthead, unified gauges, stack health sparklines Rework the home dashboard around a single cyan-railed status masthead that carries the health state word, node meta, and reasons inline. The resource block collapses into one strip with a CPU hero sparkline, memory and disk gauge bars, and a network tile whose sparkline is built from per-container byte-counter deltas. Stack health becomes an 8-column mono table with row tinting, an uptime column sourced from the oldest running container's creation time, and a per-stack 10-minute CPU sparkline. Historical charts pick up a cyan gradient and an amber peak marker. A shared Sparkline primitive backs all of the above. * docs(dashboard): refresh screenshot for phase B layout * fix(dashboard): anchor sparkline bucketing to latest metric timestamp The cpuHistory, netHistory, and cpuPeakLabel memos called Date.now() inside useMemo, which violates react-hooks/purity: the rule fires because re-renders can produce different bucket boundaries from the same inputs. Derive a historyEndAt anchor from the newest metric sample in the polled series and thread it through to ResourceGauges.	2026-04-18 01:36:12 -04:00
Anso	9db97107aa	fix(dashboard): harden real-time dashboard with bug fixes and design compliance (#517) ... * fix(dashboard): harden real-time dashboard with bug fixes and design compliance - Fix host alert spam: add 5-minute cooldown for CPU/RAM/disk threshold alerts, preventing duplicate notifications every 30s during sustained breaches. Extract shared dispatchWithCooldown helper (also used by Docker janitor alerts). - Fix memory metric inflation: subtract filesystem cache from stored memory_mb values, matching the existing calculateMemoryPercent logic. - Fix crash detection reliability: replace fragile 'seconds ago' string matching with a tracked Set of alerted container IDs. Containers are only alerted once per crash event, with automatic cleanup when they start running again or after a 1-hour TTL. - Fix health status bar: exited containers now trigger 'degraded' state independently of unread error notifications. - Fix CPU chart Y-axis: auto-scale when aggregate container CPU exceeds 100% instead of silently clipping at the hardcoded domain ceiling. - Fix grammar: 'actives' to 'active' in container count label. - Add shadow-card-bevel to all dashboard cards per design system. - Update dashboard docs to reflect revised health status thresholds. * test(dashboard): update monitor service tests for new alert signatures - Add container Id fields to crash detection test fixtures - Update host alert assertions to match dispatchWithCooldown 3-arg call - Fix unhealthy container test to use State: 'unhealthy' instead of State: 'running' (running containers are now skipped in crash detect)	2026-04-12 04:25:41 -04:00
Anso	622c1f9262	feat: home dashboard and Settings Hub polish (#506) ... * feat(dashboard): drop CPU column and relative timestamp from Stack Health and status bar The Stack Health table's CPU column duplicated data already surfaced in the top ResourceGauges and the CPU Usage historical chart. The health status bar's 'just now' timestamp was cosmetic: no consumer relied on lastUpdated state for polling, staleness detection, or conditional rendering. Removing both tightens the dashboard and eliminates a dead prop chain through useDashboardData. * refactor: remove dead admin_email field from setup flow The Setup form captured an admin email under 'Used for license recovery. Never shared with third parties.' but the value was written to global_settings and read nowhere: no license recovery, SMTP, or support contact flow consumed it. Rather than building UI on top of the dead field, delete the input, the payload key, and the backend persistence. Any orphaned row from prior setups is harmless and the frontend ignores unknown settings keys. * feat(settings): use Radix ScrollArea with per-section scroll memory Settings Hub used a native-scroll div that snapped to the top every time the user switched subsections and exposed the default browser scrollbar. Wrap the nav and content panes with the shadcn ScrollArea (Radix under the hood, type='hover') and expose a viewportRef so the modal can stash each section's scrollTop in a ref and restore it via useLayoutEffect on switch. Style the thumb with translucent foreground tokens so it reads as glass against popovers and dialogs. Replaces a hand-rolled scroll hook and ad-hoc CSS utility.	2026-04-12 01:04:15 -04:00
Anso	a1804c8fbe	docs: comprehensive review and refresh of all documentation (#374) ... * docs: comprehensive review and refresh of all documentation pages Reviewed every doc page against the current app state after the v0.38 dashboard redesign. Updated content, fixed inaccuracies, and refreshed all screenshots at 1920x1080. Pages updated: - introduction: expanded feature list to 25 items across 6 subsections - quickstart: fixed docker run command (Docker Hub, auto JWT, COMPOSE_DIR) - configuration: replaced personal paths with generic /home/user/docker - sso-quickstart: fixed Settings navigation reference - sso: added SSO_LDAP_DISPLAY_NAME env var - overview: added 8 missing feature sections (labels, API tokens, schedules, etc.) - dashboard: complete rewrite for new health bar, gauges, stack health table - stack-management: updated for UP/DN indicators, rollback button, split actions - editor: rewritten for two-column layout, inline stats, embedded terminal - resources: updated Quick Clean docs, added network topology and inspect - app-store: updated categories, deploy sheet details, permission gate, settings - openapi.yaml: fixed YAML parsing error on line 1831 Screenshots refreshed: 14 images across 6 feature areas. * docs: review and update observability, console, multi-node, and compatibility pages - Global Observability: fix log format fields, add download button docs, split display limits into memory buffer vs rendered rows, correct settings labels - Host Console: remove internal implementation details per security docs policy, add stack directory behavior, expand header bar docs, remove unverified scrollback claim - Multi-Node: add Compose Directory field, document connection test details panel, fix edit/delete node behavior, simplify token security section, remove internal details - Node Compatibility: add missing self-update capability, remove internal endpoint paths and cache TTL, move from Features to Reference group in navigation - Refresh all screenshots for the redesigned UI (7 images) * docs: review and refresh fleet, remote updates, labels, alerts, routing, and webhooks pages - Fleet View: added node updates modal, container detail, version/update/critical badges, Tags filter - Remote Updates: removed internal details, added capability cross-link, fast polling - Stack Labels: three creation methods, two assignment methods, 10 colors, bulk actions screenshot - Alerts & Notifications: fixed metric labels, added notification popover detail, status banner - Notification Routing: HTTPS requirement, rule card layout, channel terminology fix - Webhooks: corrected license tier to Admiral, matched action labels to UI, removed internal security details, added local-only note - Troubleshooting: centralized entries from remote-updates, stack-labels, notification-routing - Refreshed all screenshots at 1920x1080, removed 11 orphaned images * docs: review and refresh RBAC, user management, and atomic deployments pages - RBAC: added missing Auditor role (5th role), updated permission matrix, fixed license tier references, documented username/password validation rules, self-deletion protection - Atomic Deployments: added "Which operations are protected" section covering webhooks/schedules/app store, removed internal backup path, fixed license tier to Skipper/Admiral - Screenshots: cropped to dialog element per updated strategic cropping guideline, removed 2 orphaned images * docs: review and refresh fleet-wide backups and audit log pages Update fleet-backups page to reflect current inline create form, add scheduled snapshots section, document the detail view and restore dialog, expand RBAC table to all five roles. Update audit log page to document expanded row detail fields, pagination, refresh button, and data retention screenshot. Replace all screenshots with fresh captures at 1920x720. * docs: review and refresh API tokens and private registries pages - API Tokens: clarify Full Admin scope, add Managing tokens section with card details, document revocation confirmation dialog, add usage tracking to security model, refresh screenshot - Private Registries: add Managing registries section with card details and action buttons, document edit behavior, fix URL auto-fill description, remove encryption algorithm name per security policy, fix grammar, refresh both screenshots * docs: review and refresh auto-update policies, scheduled operations, and SSO pages - Auto-Update Policies: document all 8 table columns, expand action buttons, add "All Stacks" wildcard option, fix field labels, add CSV export and pagination details, refresh screenshots - Scheduled Operations: fix System Prune target description, add Task List table columns, restructure create dialog fields with action-specific annotations, rewrite execution history with column table, refresh screenshots - SSO: remove encryption algorithm name per security policy, add LDAP and OIDC configuration field tables, document provider card controls (Save, Test Connection, Remove, Active badge), refresh screenshots - Move SSO troubleshooting entries to centralized troubleshooting page * docs: review and refresh licensing & billing page Update upgrade card feature lists to match actual tier gating (Skipper: fleet view, webhooks, labels, atomic deployments, backups, auto-update policies; Admiral: scoped RBAC, SSO, audit log, host console, API tokens, private registries, scheduled operations). Add flex layout to align upgrade card buttons at the bottom. Replace stale screenshot with fresh community and active license captures. Add feature breakdown subsection and profile menu billing shortcut to docs. * docs: review and refresh settings reference and security advisories pages Settings Reference: add 5 missing sections (SSO, API Tokens, Registries, Labels, Routing), expand Users from 2 to 5 roles, fix System Limits and Developer field labels to match UI, restructure Developer into Streaming and Data Retention sub-tables, update App Store and Support sections, refresh overview screenshot. Security Advisories: restructure into versioned sections (v0.25.x hardening and v0.19-v0.24 CVE remediation), expand from 3 bullet points to 10 specific improvements, fix GitHub URL from SaelixCode to AnsoCode, redact internal details per security docs policy. Remove "Sencho Pro" product name from all three pages, replaced with tier names (Community, Skipper, Admiral). * docs: review and refresh troubleshooting page, remove architecture and development guides - Rewrote forgotten password section to remove exposed SQL and table names - Updated all Settings navigation paths to Profile > Settings > X - Fixed network topology from "tab" to "view mode", added Pro license note - Updated Prune Networks to current "Prune Dead Networks" label - Corrected update check cooldown from vague to 2 minutes - Consolidated two network creation error sections into one - Removed hardcoded version reference (v0.34.0) - Replaced em dashes throughout - Deleted architecture.mdx (exposes internal implementation details) - Deleted development.mdx (contributor guide belongs in repo, not public docs) - Removed both pages from docs.json navigation * docs: review and refresh operations pages (backup, upgrade, self-hosting, troubleshooting) Backup & Restore: - Added missing encryption.key to all backup/restore procedures - Added Warning about restoring db without matching encryption key - Added cross-reference to Fleet-Wide Backups for paid tiers - Removed false claim about no built-in backup scheduler - Updated cron example to include encryption key copy Upgrading Sencho: - Removed internal migration details (table names, column specs, encryption algorithm) - Replaced with high-level migration summary per security docs policy - Added encryption.key to pre-upgrade backup command - Updated version pinning example from 0.25.3 to 0.38.0 - Added Remote Updates cross-reference for Skipper/Admiral users Self-Hosting Best Practices: - Removed JWT_SECRET from env var table (auto-generated, not an env var) - Removed PORT from env var table (hardcoded to 3000, not configurable) - Added API_RATE_LIMIT to env var table (actually exists in code) - Fixed listen port description from "configurable" to "fixed" - Updated resource recommendations based on measured footprint audit - Removed su-exec reference (internal implementation detail) - Upgraded data directory Note to Warning with file names Troubleshooting: - Fixed "Pro features" heading to "Paid features" with correct tier names	2026-04-04 21:32:51 -04:00
Anso	32a7d53b2b	feat: RBAC, atomic deployments, fleet backups, and licensing (Pro) (#185) ... * feat: add RBAC viewer accounts, atomic deployments, and fleet-wide backups (Pro) Introduces three Pro-tier features: - RBAC: Multi-user system with admin/viewer roles, user management UI, automatic migration from single-admin credentials, viewer restrictions across the entire UI (read-only editor, hidden action buttons) - Atomic Deployments: Pre-deploy file backup to .sencho-backup/, automatic rollback on health probe failure, manual rollback button, health probes added to stack updates, webhook-triggered deploys use atomic rollback - Fleet-Wide Backups: Point-in-time snapshots of compose files across all nodes (local + remote), stored centrally in SQLite, per-stack restore with optional redeploy, graceful handling of offline nodes * fix(settings): use correct ProGate prop name in UsersSection * fix(settings): remove unused isPro prop from UsersSection * fix(auth): fetch user info after login and setup so isAdmin is set correctly * feat(pricing): revise pricing strategy and enforce variant-based seat limits Raise Personal Pro from $49/yr to $69/yr with 3 viewer seats (up from 1). Add $15/mo billing option for Team Pro. Mark lifetime pricing as a 90-day early-adopter offer. Store Lemon Squeezy variant_name on activation/validation and enforce seat limits server-side per variant. * feat(licensing): add Lemon Squeezy checkout, webhook, and billing portal integration Server-side checkout URL generation (POST /api/checkout) with admin email pre-fill and instance_id custom data. HMAC-SHA256 verified webhook endpoint (POST /api/webhooks/lemonsqueezy) handling order, subscription, and payment lifecycle events for automatic license activation. Customer billing portal link stored from webhook events and exposed via GET /api/billing/portal. In-app checkout buttons in Settings with manual license key fallback. * fix(licensing): exempt Lemon Squeezy webhook from auth middleware The catch-all auth middleware on /api/* was blocking the public webhook endpoint. Added /webhooks/lemonsqueezy to the exemption list alongside /auth/* and /webhooks/:id/trigger. * feat(pricing): update pricing to final live rates Personal Pro: $7.99/month, $69.99/year, $249 lifetime. Team Pro: $49.99/month, $499.99/year, $1,499 lifetime. Added personal_monthly checkout variant across backend, frontend, and website. * refactor(licensing): remove server-side checkout/webhook for self-hosted model Sencho is self-hosted — each user runs their own instance, so there is no central server to receive webhooks or hold the store API key. Replaced in-app checkout buttons with a "View Pricing" redirect to sencho.io and kept manual license key activation as the primary flow. - Delete LemonSqueezyService (checkout, webhook, HMAC verification) - Remove POST /api/checkout, GET /api/billing/portal, POST /api/webhooks/lemonsqueezy - Remove raw body parser and auth exemption for webhook route - Remove all LEMONSQUEEZY_* env vars from .env.example - Replace checkout buttons in SettingsModal with single "View Pricing" button - Simplify LicenseContext checkout to open sencho.io pricing page - Update licensing docs to reflect website-based purchase flow * chore: normalize em-dashes to hyphens across codebase (linter) * chore: remove accidentally tracked directories from index	2026-03-26 21:58:24 -04:00
SaelixCode	7c120c671c	docs: add Tier 2 feature pages ... - dashboard: container stats, system stats, historical charts, docker run converter - resources: disk footprint widget, images/volumes/networks/unmanaged tabs, prune scopes - app-store: template grid, category filter, deploy sheet (env vars/volumes/ports), custom registry - global-observability: unified log stream, standard vs SSE mode, filters, capacity limits - host-console: PTY terminal, shell type, security model, common uses - mint.json: add all 5 new pages to Features nav group	2026-03-22 22:43:53 -04:00