## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Self-hosted boards need a way to show occasional product announcements. > - An app release should not be required to publish or withdraw a card. > - Native card controls keep publishing consistent; the hero can use a static image or isolated HTML/CSS animation. > - This pull request renders a validated JSON feed with native components. > - It stores dismissals per account on each instance, so a closed card stays closed across companies and browsers. > - Named staging feeds let authors test content before production publication. ## Linked Issues or Issue Description **Subsystem affected** Board application shell, announcement delivery, and user preferences. **Problem or motivation** Operators need a small, optional announcement card. Users need reliable dismissal state. Authors need to test remote content without changing the production feed. **Proposed solution** Add one non-modal AnnouncementWell. Fetch validated JSON and content-addressed media through the instance server. Keep card controls native, with optional sandboxed HTML/CSS animation in the hero. Use stable announcement IDs for dismissal, an explicit empty manifest and quiet 404 handling. Provide a staged publishing helper and isolated test-drive guide. **Alternatives considered** Hosting the entire card as a page would move navigation and dismissal into remote content. This change limits HTML to a scriptless, isolated visual hero and keeps controls native. Browser-only storage would lose dismissals across browsers, so the instance stores account preferences. **Roadmap alignment** ROADMAP.md has no overlapping announcement feature. A GitHub title search found no related announcement pull requests. This work implements a maintainer-requested feature. ## What Changed - Add shared feed types, strict validation of every object, supported routes, expiration and version checks. - Add a board-only current-feed API, constrained media proxy, and idempotent dismissal API. Store the first dismissal and its company audit entry in one transaction. - Cache upstream data for one hour. Use conditional requests, request deduplication, response limits, public destination checks, and a three-second deadline. Treat a remote 404 as an empty feed with a fifteen-minute retry cooldown. - Keep announcement visibility stable when focus moves to browser chrome or another app pane; only tab visibility starts a return check. - Add a responsive native announcement card. Respect onboarding, dialogs and toast placement. Sync pending dismissals across tabs and retry after reconnect or return. - Add idempotent migrations for dismissals and validated publication IDs, design-guide examples, static and animated Storybook examples, and focused tests. The publication registry supports offline retries without accepting caller-invented IDs. - Add HTML/CSS animated heroes with static posters, automatic playback, reduced-motion handling, strict DOMPurify validation, an empty iframe sandbox and CSP that blocks scripts/network resources. - Add validated staging publication, content-addressed assets, an empty production manifest, preview fixtures, and authoring/operator documentation. ## Verification - The preceding implementation passed 98 targeted shared/server/publisher/route/OpenAPI/UI tests and 127 tests including the master rebase. The playback-control removal passes all 21 announcement UI tests, covering the rendered sandbox, fallback, reduced motion, dismissal and slow/stale state lookups. The preceding shared/server tests cover HTML validation and response sandbox headers. - The playback-control removal passes UI typecheck, production UI build, Storybook build and token gates locally. Browser verification confirms the animated card has only its dismiss button and two links, with no page errors. The full canonical CI matrix passed on current head `00e416431edb610861599d50490270bbd0f3c6b6`: 32 successful checks and two optional Storybook deployment checks skipped. This run needed no retries. Greptile reviewed this same head at 5/5 with no outstanding findings. - The local canonical general-server run passed 12,063 tests before reporting embedded-PostgreSQL startup failures in an unrelated fixture. All 31 tests in that fixture passed across isolated retries. The UI group passed 6,219 tests and other workspace groups passed 3,201; two CLI database-startup failures also passed individually. Serialized server suites were verified by the full CI matrix rather than repeating them locally. No source changes were needed for these environment failures. - The real S3/CloudFront staging manifest and both media asset headers were verified. Production remains empty/unpublished. The guide distinguishes the preview host's disabled edge cache from production cache requirements. - In the isolated test-drive, the animation visibly moves without playback controls. A 390×844 browser viewport keeps the card above navigation. Reduced motion makes no animation request. Both themes render correctly and browser page errors are empty. Browser fault injection verified that scripts cannot execute and CSS cannot make network requests; a missing animation leaves its poster and controls. - Refresh leaves the animated card visible. Closing it persists after reload and the API returns null. Earlier live checks verified dismissal across browsers, company-relative CTA navigation, modal deferral/restoration, and new-ID eligibility after restarting the same database. - The deployed empty feed and a real remote 404 return HTTP 200 with null from the board API, with a usable dashboard and no announcement popup or browser warnings. - Authoring documentation covers staging, animated HTML constraints, test-drive, withdrawal, ID reuse and cache-refresh steps. ## Risks - Animation supports self-contained visual HTML/CSS and inline SVG, without JavaScript or external resources. A static image is required. Older builds that do not recognize the optional animation field quietly hide that unsupported feed. - The default feed makes an outbound request from an instance when a board is used. Operators can disable it. Requests contain no account IDs, company data, cookies or interaction events. - Feed publication and withdrawal can take about 65 minutes to reach returning users because of CDN and instance caches. Expiration also removes visible cards locally. - Dismissals follow an account within one instance. No-login instances share the existing local-board identity. Separate installations do not share state. - Both tables are additive. A unique key prevents duplicate dismissals; the transaction prevents duplicate first-dismissal audit entries. The publication registry retains only validated IDs. AGENTS.md and the implementation spec document the required exception to company scope for these instance-level records. - Publication was limited to separate public staging prefixes on the existing preview host. Production remains empty/unpublished. No AWS policies or infrastructure were changed. ## Model Used OpenAI GPT-6 through Codex. The exact runtime model ID and context-window size are not exposed in this session. Capabilities used: reasoning, code editing, shell execution, tests, browser interaction, and tool use. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>
15 KiB
In-app announcements
Paperclip displays one optional announcement card in the board UI. Its feed is
https://pages.paperclip.ing/announcements/v1/current.json. The instance fetches
JSON on demand and renders it with native components.
Operator configuration
PAPERCLIP_ANNOUNCEMENTS_ENABLED=falsedisables fetching and display.PAPERCLIP_ANNOUNCEMENTS_FEED_URLoverrides the public HTTPS manifest URL. Credentials, query strings, private destinations and redirects are rejected.
Announcements are independent of telemetry. Feed/media requests originate from the instance without account IDs, company data, cookies or event tracking. The host sees ordinary server network request metadata. The browser requests only its own Paperclip API.
Authoring and publishing
The shared announcementManifestSchema defines the format:
{
"schemaVersion": 1,
"announcement": {
"id": "2026-09-projects",
"eyebrow": "New in Paperclip",
"title": "Your next idea starts here",
"description": "Bring your agents and work together in a project.",
"secondaryLink": { "kind": "external", "label": "Learn more", "url": "https://paperclip.ing" },
"primaryAction": { "kind": "route", "label": "Open projects", "path": "/projects" }
}
}
Content is plain text. Every manifest object rejects unknown fields, including
misspellings in actions and media. Optional fields: image: { path, alt },
animation: { path, alt }, expiresAt (ISO
timestamp), and minimumPaperclipVersion (stable major.minor.patch). Internal
actions accept stable pages in ANNOUNCEMENT_APP_ROUTES and use the selected
company. External HTTPS links open a new tab. Actions only navigate.
Images are assets/<sha256>.png, .jpg or .webp, at most 2 MiB, relative to
the manifest directory. Use an approximately 2.6:1 banner with important content
near the center; mobile crops it shorter. The manifest is limited to 64 KiB.
Run shasum -a 256 hero.png to get the image digest, copy the file to
announcements/assets/<digest>.png, and use assets/<digest>.png in the
manifest. An image correction changes this asset filename while retaining the
announcement ID.
Edit announcements/current.json, put its image under announcements/assets/,
then run:
node cli/node_modules/tsx/dist/cli.mjs scripts/publish-announcements.ts announcements --dry-run
Set PAPERCLIP_PAGE_BUCKET, optionally PAPERCLIP_PAGE_BASE_URL, and the page
uploader's namespaced PAPERCLIP_PAGE_AWS_ACCESS_KEY_ID and
PAPERCLIP_PAGE_AWS_SECRET_ACCESS_KEY (optional PAPERCLIP_PAGE_AWS_SESSION_TOKEN),
or PAPERCLIP_PAGE_AWS_PROFILE. Ambient AWS credentials also work.
For a host serving a subdirectory, PAPERCLIP_PAGE_DEFAULT_PREFIX prepends a
validated path to both S3 keys and public URLs. Use lowercase letters, numbers
and hyphens in each segment, without leading/trailing slashes.
node cli/node_modules/tsx/dist/cli.mjs scripts/publish-announcements.ts announcements --publish
The helper rejects symlinks, validates asset digests and animated HTML, uploads assets first and the manifest last, and verifies the public manifest and asset headers. It writes only the resolved announcement prefix; no remote objects are deleted or infrastructure changed. Allow up to six minutes for CDN propagation. Manifest caching is five minutes; immutable assets use one year. Before first publication verify the distribution's active cache policy has minimum TTL <= 300 and maximum TTL >= 300 for the manifest, and maximum TTL >= 31536000 for assets. Check the behavior matching each path, including any referenced cache policy. Public response headers alone cannot prove the effective cache lifetime or override a higher minimum. See AWS cache expiration.
Retain the ID when fixing copy/images/animations. Use a new ID to announce something new. ETags improve fetching but never determine redisplay.
Animated hero media
An announcement can show a self-contained HTML/CSS animation in its hero
area. The headline, description, close button and actions remain native
Paperclip controls. Add an animation alongside the required static image:
"image": { "path": "assets/<image-sha256>.png", "alt": "A team working together" },
"animation": { "path": "assets/<html-sha256>.html", "alt": "Agents plan, build and review work together." }
Replace the placeholders with the files' actual 64-character SHA-256 digests.
HTML is UTF-8, limited to 128 KiB, and uses a responsive document with zero body
margin. The hero is about 352 × 136 on desktop and shorter on phones. Use CSS
keyframes, inline styles, system fonts, and visual HTML (div, span, p,
br, strong, em, b, i) or inline SVG shapes/text (svg, g, path,
circle, ellipse, rect, line, polyline, polygon, text, tspan,
title, desc). No scripts, external libraries, links, forms, iframes, images,
SVG SMIL/foreignObject, meta refresh or other embedded resources. CSS URL
requests and imports are blocked by CSP; keep all styling self-contained.
The publisher and server use the same strict DOMPurify allowlist and reject
unsupported markup rather than publishing a silently changed animation.
Paperclip verifies the digest, validates the HTML, and renders the result in an
opaque sandboxed iframe with no permissions. A Content Security Policy blocks
scripts and network resources both inside the card and on direct API visits.
The browser fetches HTML from its own authenticated instance; it never loads
the publisher's page in an unsandboxed frame. The frame cannot receive pointer
or keyboard focus; its accessible description is supplied by animation.alt.
See iframe sandboxing.
The animation plays automatically without playback controls. The static image
stays visible while loading and on failure. With reduced motion enabled,
Paperclip does not request or play the animation. Also include a
prefers-reduced-motion CSS rule in authored documents for standalone previews.
Animations share the feed's constrained host, three-second server timeout,
bounded cache, request deduplication and fifteen-minute failure cooldown.
Dismissal and ID reuse rules are identical for animated and static cards.
Older Paperclip builds that do not recognize animation treat that feed as
unsupported and quietly show no card.
The complete authoring example is announcements/examples/animated/. Preview
it with the same staging/test-drive workflow below:
cp -R announcements/examples/animated .paperclip/announcement-animation-preview
# Edit HTML; recompute its digest and rename it; update current.json.
node cli/node_modules/tsx/dist/cli.mjs scripts/publish-announcements.ts .paperclip/announcement-animation-preview --staging animated-preview --dry-run
node cli/node_modules/tsx/dist/cli.mjs scripts/publish-announcements.ts .paperclip/announcement-animation-preview --staging animated-preview --publish
Point the isolated instance at the printed URL and restart it. Verify movement, reduced motion, mobile sizing, and dismissal across reloads. Try a missing animation asset: the poster and native controls must remain usable. Storybook's Animated, AnimatedDark, AnimatedMobile and MissingAnimation stories, and the design guide, provide local examples without changing the remote feed.
Preview an announcement before publishing
Use a named staging feed. --staging <name> writes
announcements/staging/<name>/v1/ instead of announcements/v1/, so a preview
cannot overwrite the production manifest. With no source directory it uses
announcements/examples/staging/, including a sample banner. Commands default
to dry-run unless --publish is supplied.
For Paperclip's existing preview host, use the branch preview area that CloudFront already has permission to read:
aws sso login --profile paperclip-dev
export PAPERCLIP_PAGE_AWS_PROFILE=paperclip-dev
export PAPERCLIP_PAGE_BUCKET=paperclipai-runner-e2e-history-078455283791-us-east-1
export PAPERCLIP_PAGE_BASE_URL=https://d1p6rlowie26tp.cloudfront.net
export PAPERCLIP_PAGE_DEFAULT_PREFIX=storybook/branches/codex-announcements
# Copy the public fixture into an ignored directory and edit current.json there.
mkdir -p .paperclip
cp -R announcements/examples/staging .paperclip/announcement-preview
node cli/node_modules/tsx/dist/cli.mjs scripts/publish-announcements.ts .paperclip/announcement-preview --staging my-preview --dry-run
node cli/node_modules/tsx/dist/cli.mjs scripts/publish-announcements.ts .paperclip/announcement-preview --staging my-preview --publish
Choose a unique staging name for your test and use the printed manifest URL.
The preview host currently uses CloudFront's Managed-CachingDisabled policy
for this branch area: edge TTL is zero even though public responses preserve
the five-minute manifest and one-year asset cache headers. This is useful for
preview iteration; it does not verify a production distribution's effective
cache lifetime. For another host, configure its bucket, base URL and optional
prefix, then verify its matching cache behavior as described above.
Create a test-drive configuration in this worktree. Put the feed override in
the selected instance's .env, not just the invoking shell: test-drive
deliberately clears inherited PAPERCLIP_* variables.
mkdir -p .paperclip/announcement-test-drive/instances/default
# On a new test directory, create this file. On reuse, update these entries
# while preserving the file's existing keys.
cat > .paperclip/announcement-test-drive/instances/default/.env <<'EOF'
PAPERCLIP_ANNOUNCEMENTS_FEED_URL=https://d1p6rlowie26tp.cloudfront.net/storybook/branches/codex-announcements/announcements/staging/my-preview/v1/current.json
PAPERCLIP_ANNOUNCEMENTS_ENABLED=true
PAPERCLIP_DB_BACKUP_ENABLED=false
HEARTBEAT_SCHEDULER_ENABLED=false
EOF
# A fresh test-drive needs a provider key for its initial CEO. Use your usual
# provider environment variable; never put a real key into a manifest or commit.
# Reusing an initialized data directory does not require a bootstrap key.
node cli/node_modules/tsx/dist/cli.mjs cli/src/index.ts test-drive --data-dir .paperclip/announcement-test-drive --no-browser
See test-drive setup for harness/key options. Open the printed local URL. The app chooses a free port starting at 3100 and keeps its database under the supplied directory. It creates no tasks or initial agent run. After onboarding/company selection, allow three seconds for the card.
Before promoting content, verify:
- The image, copy and both actions fit desktop/mobile and both themes.
- A dialog or bottom-left toast temporarily hides the card, then restores it.
- Close or follow a link; reload, switch companies and open another tab/browser. The same account should keep that ID dismissed.
- Edit copy with the same ID: it stays dismissed. Publish a new ID: it appears on the next eligible visit. Clearing browser storage alone does not reset database dismissals; use a new ID or a fresh isolated data directory.
- Try the empty fixture and a URL that returns 404. The dashboard remains usable with no announcement and no announcement error popup.
Stop and restart test-drive after changing its feed URL or republishing content
when you need immediate results. This clears the server's one-hour feed cache
while retaining dismissal records in the same data directory. Reload or return
to the app after restart; an uninterrupted active tab does not discover cards.
For promotion, validate the reviewed content again, configure the production
host/prefix, and publish without --staging. Production's checked-in manifest
remains empty until a real announcement is ready.
No announcement and withdrawal
The explicit none value is JSON null, not the string "none":
{
"schemaVersion": 1,
"announcement": null
}
Publish this manifest to withdraw an announcement while retaining every user's
dismissed IDs. Restoring an old announcement cannot resurrect it for people who
dismissed it. The ready-to-publish empty fixture is
announcements/examples/none/current.json:
node cli/node_modules/tsx/dist/cli.mjs scripts/publish-announcements.ts announcements/examples/none --staging my-empty-preview --publish
A remote 404 is also a normal empty feed: the board API returns HTTP 200
with null, clears previous content/ETag, and waits fifteen minutes before
checking upstream again. It produces no announcement warning in server logs or
popup in the UI. Other unavailable or invalid feeds likewise produce no card
or UI error popup; unexpected upstream failures can be logged for operators.
Withdrawal follows the cache/return timing below. Explicit expiration also
removes a visible card when its deadline arrives.
Timing and persistence
Show after three seconds when opening or returning to Paperclip, after company selection and onboarding. Dialogs and toasts take priority. Phones show it above bottom navigation. No automatic timeout, outside-click dismissal or carousel. Tab visibility controls the return check: moving focus to the address bar or an adjacent app pane leaves the card visible and does not restart its settling period. A hidden tab clears the card; becoming visible fetches fresh dismissal state before showing anything, even if that lookup takes longer than three seconds.
The instance caches the feed for an hour, deduplicates concurrent fetches, and uses conditional requests. Failed requests have a fifteen-minute cooldown; no card appears for unavailable/invalid/incompatible content. Each request has a three-second deadline. Active tabs do not poll for announcements. Publication and withdrawal are discovered on a return after cache expiry (normally within about 65 minutes for returning users).
Closing or following either link saves a unique (userId, announcementId)
record in the instance DB, shared across browsers and companies. Its first
write and audit entry commit together; the active company is audit context.
Viewers can dismiss their own card. No-login instances share local-board.
Separate installations do not share state.
The browser hides immediately, stores pending writes per account, and retries on reconnect/return. Failed saves explain that cross-device sync has not completed. If browser storage is unavailable, state lasts for this visit. Other tabs close through BroadcastChannel/storage events; another browser refreshes state on return. Logout clears displayed state and aborts account-bound work. A failed state lookup never shows a card.
Board-only APIs: GET /api/announcements/current,
GET /api/announcements/:id/image, GET /api/announcements/:id/animation, and POST /api/announcements/:id/dismiss
with { "companyId": "..." }. Responses use private, no-store. Repeated POSTs
return 204 without duplicate audits. Pending dismissals remain valid after the
feed moves to another ID. The instance retains only the IDs of validated
announcements in a publication registry, so offline retries survive withdrawal
and restarts. A caller-invented ID returns 404 without creating dismissal or
audit rows. This registry is not an archive and records no interaction events.
Production ships with an empty manifest. Design guide / Storybook fixtures are never used as a production fallback.