mono/agent-desk-ng
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
Files
2f7a491666c82c45e2d6cd6c414855783da45294
agent-desk-ng/docs/hardening/README.md
mono 2f7a491666 feat: harden support, localize knowledge and add operator availability [skip ci] 
Source-only publication of reviewed commit 64e96a7f423673dc29ad56485be9fc79bce8af1c.

Passed in isolation: focused frontend/backend tests, race checks, TypeScript typecheck, lint, Go compilation, Flowgram build, and deterministic SDK build/tests.

Not accepted as a production release: Next.js export/native assembly remains blocked by environment memory limits; browser interaction and MySQL staging acceptance remain unverified. No production server, database/schema, runtime configuration, deployment, release tag, or workflow execution was performed.

Expected source tree: 0a4a7528e9.
2026-10-16 15:21:42 +00:00

3.9 KiB
Raw Blame History

Security and reliability hardening

This independent fork starts from the current source tree of MonoVerseNS/agent-desk-ng, revision b06954b0a495389cbb5194e0d388342eabe60636. It does not import the old Git history. The upstream Apache-2.0 license and notices remain applicable. This document records changes made by this fork; it is not a claim of production certification.

Integration baseline

The isolated integration reconciles public Gitea main 299ea50f with the reviewed hardening branch 63e04578. It preserves main's bounded connection attempts, abortable ongoing HTTP recovery and System setup navigation alongside the identity/live-access/draft/setup safeguards. Only the clean public repository history is used. See VALIDATION.md for executed checks and unresolved gates.

Release gate

The hardening changes must be reviewed and validated before deployment. Source inspection, a compiler check, a passing isolated test, and live acceptance are separate kinds of evidence. See VALIDATION.md for the actual checks performed. No production service, database, credentials, or external deployment is changed by committing this source code.

Changes being integrated

  • Separate guest, signed-user, issuer and channel identities. Use canonical customer/channel WebSocket topics and recheck recipients instead of treating a topic subscription as authorization.
  • Apply conversation-view permission to staff WebSockets; keep notifications separate. Revalidate session expiry, revocation, account state and permissions on long-lived connections. Disabled roles must no longer grant permissions.
  • Keep drafts and asynchronous responses bound to their identity and dialogue. Preserve drafts on failed sends, protect newly typed revisions, and prevent duplicate concurrent sends. Profile refresh and delayed API errors must not restore or expire the wrong signed-in account.
  • Turn setup repair into an explicit preview/apply operation. Never resurrect deleted configuration or silently introduce continuous working hours. Apply reviewed writes transactionally and dispatch only after commit.
  • Make empty setup, initial retry and standalone chat dismissal truthful and recoverable; remove bearer-token-bearing WebSocket URLs from browser logs.

Upgrade precautions

Customer identity scoping is an additive schema and token-contract change, not only a frontend patch. Existing unscoped customer tokens will be rejected. Legacy identities and conversations must be inventoried and reconciled with trusted issuer/channel provenance before expecting their old history in new customer sessions. No automatic customer merge or destructive cleanup is appropriate. See CUSTOMER_IDENTITY_UPGRADE.md before any deployment.

New anonymous sessions are server-issued. Knowing an old anonymous external ID is not sufficient to reclaim its history. Preserve the signed customer-session credential for normal resume; loss or expiry can require a new anonymous session.

The setup quick-fix API now requires preview and explicit apply. Older callers must not treat a successful preview response as proof that configuration changed. See the setup contract before integrating custom callers.

Verification priorities

  1. Guest/user/channel collisions, unauthorized staff topics, revoked/expired sockets, disabled roles and concurrent identity registration.
  2. Wrong-recipient drafts, failed and duplicate sends, delayed responses after switching conversations or accounts, and logout during profile refresh.
  3. Preview/apply tampering, permission denial, rollback, deleted configuration, off-hours schedules, empty-channel simulation and dispatch failure reporting.
  4. Desktop and narrow-screen interaction checks in Russian, English and Chinese.

Use temporary, isolated data for checks. Do not run migration/repair commands against a live database merely to validate the code.