Related Pages

Related topics: Publishing Workflow, Expiring URLs & Password Protection, Agent Integration, Skills & Hooks, Chrome Extension & Feedback Analytics Worker

Overview & System Architecture

Pagecast is a local-first publishing tool for agent-generated HTML reports, Markdown docs, and small static web projects. It runs on the user's own machine, previews files, and deploys them to shareable Cloudflare Pages URLs under the user's own Cloudflare account. The project is distributed as an npx executable (no global install required) and ships as package.json version 0.1.6. Source: package.json:1-6

The product targets two workflows: a local admin UI at http://127.0.0.1:4173 for humans, and a headless pagecast CLI for coding agents such as Claude Code or Codex. Source: README.md:11-26

Purpose & Scope

Pagecast fits a narrow, well-defined niche: turning locally-produced static artifacts into a public URL without setting up a hosting account, a CI pipeline, or a static-site generator. Source: README.md:13-22

The "publish" boundary is the key design choice: publishing creates a public URL, so the CLI and agent skill both require an explicit user confirmation before deploying. Source: plugin/skills/publish-report/SKILL.md:13-19, llms.txt:51-56

High-Level Architecture

flowchart LR
    User[User / Coding Agent] -->|reads local file| LocalApp[Local Pagecast App<br/>Node.js · src/server.js]
    LocalApp -->|preview| Admin[Admin UI<br/>127.0.0.1:4173]
    LocalApp -->|preview| LocalPreview[Local Published-Page Preview<br/>127.0.0.1:4174]
    LocalApp -->|wrangler pages deploy| CFPages[Cloudflare Pages<br/>User's own account]
    LocalApp -->|provisions once| FeedbackWrangler[Feedback Worker<br/>feedback/worker.js]
    CFPages -->|embeds widget.js| FeedbackWrangler
    CFPages -->|edge check| Functions[(functions/_middleware.js<br/>generated by src/crypto.js)]
    User -->|view / react| CFPages

The runtime consists of four cooperating pieces:

1. Local Node.js server (src/server.js) — owns the admin API, file staging under .pagecast/, and the Cloudflare Pages publisher. Source: src/server.js:30-50
2. Markdown renderer (src/markdown.js) — zero-dependency, security-hardened Markdown → HTML, used when publishing .md artifacts. Source: src/markdown.js:1-15
3. Crypto / edge middleware generator (src/crypto.js) — produces a functions/_middleware.js (HTTP Basic Auth via PBKDF2) and a scoped _routes.json so protected slugs are gated at the edge. Source: src/crypto.js:1-20
4. Feedback Worker (feedback/worker.js) — a small Cloudflare Worker deployed once per account that backs reactions + view analytics via a single KV namespace. Source: feedback/worker.js:1-15

A Vite/React admin UI (web/) is bundled into the pagecast package and served by the Node server. Source: web/package.json:1-20, package.json:38-46

Publishing & Data Flow

The publish path is uniform across entry points (npx pagecast publish <file>, the admin UI, the Chrome extension, and the agent skill):

1. The CLI receives an absolute path to a .html / .htm / .md / .markdown file. Source: plugin/skills/publish-report/SKILL.md:24-32
2. The server stages the file under .pagecast/pages-site/p/<slug>/, with slug allocation handled in src/server.js.
3. For Markdown inputs, src/markdown.js renders to a self-contained HTML document. Every text run is HTML-escaped and only a safe URL scheme allowlist survives sanitization, because published pages are PUBLIC. Source: src/markdown.js:5-15
4. If a page is password-protected, src/crypto.js injects a generated _middleware.js (PBKDF2-SHA256, 100k iterations) and a _routes.json that scopes the Function to /p/<slug>/ only — unprotected sites remain fully static. Source: src/crypto.js:15-25
5. Social-meta tags (Open Graph + Twitter) are injected, optionally gated on the "Published with Pagecast" badge for white-label deployments. Source: src/server.js:1-30
6. The server invokes wrangler pages deploy from inside the staging directory and parses the resulting URL. Source: src/server.js:50-80

For whole-site deploys to a named Pages project (not share-link tokens), users run npx pagecast pages deploy or npx pagecast publish site; this replaces project contents rather than minting a new /p/<token>/ link. Source: llms.txt:21-35

Design Decisions & Community Context

Why Pages, not Workers with Static Assets? A community question on the issue tracker asks exactly this. The answer is implicit in the architecture: Pagecast depends on Pages Functions (functions/_middleware.js) for both password protection and expiring URLs (v0.1.6). The edge check runs in the same Function used for auth, so a link dies on schedule even when the user's machine is off — a guarantee Workers-with-Static-Assets did not provide when the project started. Source: src/crypto.js:1-20, plugin/README.md:1-20

Expiring URLs (v0.1.6). Each published link can carry an expiry window (hours / 1d / 2d / 7d / 30d, or "Never"); default is 30 days, configurable per-install and overridable per-publish. Expiry is enforced at the edge, not on the user's machine, so it survives shutdowns. Source: package.json:3, src/crypto.js:1-25

Agent-first ergonomics. The publish-report skill defaults to offering publication after any HTML/Markdown write — but only once per file, and only on an explicit "yes." Source: plugin/skills/publish-report/SKILL.md:7-19 The Chrome extension mirrors this with a toolbar/right-click action that talks to the local loopback server only — no data leaves the user's machine except the eventual Pages deploy under their own account. Source: extension/store/listing.md:7-25

See Also

• Publishing & CLI workflow — llms.txt
• Password protection & edge middleware — src/crypto.js
• Feedback Worker & analytics — feedback/worker.js
• Agent plugin & skill — plugin/skills/publish-report/SKILL.md

Related Pages

Related topics: Overview & System Architecture, Agent Integration, Skills & Hooks

Publishing Workflow, Expiring URLs & Password Protection

Purpose and Scope

Pagecast is a local-first publishing tool for agent-generated reports and small static web projects. The publishing workflow turns a local HTML or Markdown file into a Cloudflare Pages URL, with two optional edge-level guards available on top of the URL: password protection (long-standing) and expiring URLs (introduced in v0.1.6). Both guards are enforced at the edge by a generated Cloudflare Pages Function, so the user's machine does not need to stay online for them to keep working. Source: package.json (v0.1.6), README.md.

Publishing Workflow

The headless CLI is the entry point and is distributed as the pagecast binary, with the server exporting the app from ./src/server.js. Source: package.json.

The canonical command takes an absolute path to a file and a --json flag for automation:

npx pagecast publish "/absolute/path/to/report.html" --json
npx pagecast publish "/absolute/path/to/report.md" --json

The same command accepts a built static app's entry file (e.g. dist/index.html). Markdown is rendered to a clean page; HTML and Markdown files are both supported. Source: llms.txt, README.md.

A first publish auto-creates the user's Pages project — no manual setup beyond the one-time Connect Cloudflare step. To update a page in place at the same URL, the user re-syncs from the Pagecast app; re-running publish mints a new /p/<token>/ link. Source: plugin/skills/publish-report/SKILL.md, llms.txt.

A "goal" variant (npx pagecast goal publish ... --json) writes/rewrites a pagecast-goal.md so progress updates land on the same URL — publish always mints a new token, while goal publish updates the existing one in place. Source: plugin/skills/publish-report/SKILL.md.

The Chrome extension follows the same path: the popup detects a file:// URL whose extension matches a publishable allowlist, confirms the local server is up, confirms Cloudflare is connected, and POSTs the file path to the loopback server. Source: extension/popup.js.

Password Protection at the Edge

Password protection is opt-in per report and works for both single HTML files and multi-file reports or folders. Source: PASSWORD-PROTECTION.md.

The CLI surface is two flags: --password "<pw>" sets or replaces protection; --no-password removes it. If neither is passed, any existing protection on a reused report is left untouched. Source: PASSWORD-PROTECTION.md.

Enforcement is delegated to a generated Cloudflare Pages Function — not to anything in the report's own HTML. On every deploy, when at least one publication is protected, Pagecast writes:

• functions/_middleware.js — the HTTP Basic Auth gate plus a baked manifest of protected slugs and their password hashes.
• _routes.json — scopes the Function to protected /p/<slug>/ paths only, so unprotected sites stay purely static.

When no report is protected, both files are removed entirely. Content is deployed plain; the Function gates it at request time. A correct password sets a signed session cookie, so a multi-asset page pays the hashing cost only on the first request, not for every sub-asset. Source: PASSWORD-PROTECTION.md, src/crypto.js.

The password hash is computed with PBKDF2-SHA256, 100 000 iterations, a 16-byte random salt, and a 32-byte derived key — modest vs. the 600k typically used for downloadable blobs, because the hash is never served as a static asset. The hash is baked into the Function source, never published as a static file, and cross-runtime parity with WebCrypto PBKDF2 is asserted in tests. Source: src/crypto.js.

Expiring URLs (v0.1.6)

v0.1.6 adds auto-expiring share links. A link lives for a chosen window — hours, 1 day, 2 days, 7 days, 30 days, or Never. The default is 30 days, configurable per-install and overridable per-publish. Source: package.json, community release notes for v0.1.6.

Expiry is edge-enforced by the same Cloudflare Pages Function used for password protection, so a link dies on schedule even when the publisher's machine is off. Password protection and expiry share the same _middleware.js and _routes.json infrastructure, which is why both guards can be composed without per-report server code. Source: community context (v0.1.6 release), PASSWORD-PROTECTION.md.

Architecture and Trust Model

flowchart LR
  A[Local HTML / Markdown file] --> B[pagecast publish / goal publish]
  B --> C[Generated static assets]
  B --> D[functions/_middleware.js]
  B --> E[_routes.json]
  C --> F[Cloudflare Pages project]
  D --> F
  E --> F
  F --> G{Edge Function checks}
  G -- password ok & not expired --> H[Serve assets]
  G -- bad / missing / expired --> I[401 or expiry response]

Pagecast publishes to Cloudflare Pages rather than Workers with Static Assets — a design choice surfaced in community discussion. The rationale matches the threat model: protection is edge-enforced by a Pages Function bound to _routes.json, content is deployed plain, the password hash is baked into the Function source (never served), and the attack surface is online password guessing, not offline brute force. Treating the URL itself as a 128-bit unguessable secret, plus edge-side expiry, plus optional password protection, composes into a layered model without a Pagecast-hosted middleman. Source: SECURITY.md, PASSWORD-PROTECTION.md, src/crypto.js.

For agent workflows, the publish-report skill detects finished HTML/Markdown artifacts via a PostToolUse hook and offers *"Want me to publish this with Pagecast?"* — once, only on explicit yes, never silently. Source: plugin/README.md, plugin/skills/publish-report/SKILL.md.

See Also

• README.md — overview, quick start, admin UI.
• PASSWORD-PROTECTION.md — full password-protection guide.
• SECURITY.md — threat model and hardening roadmap.
• plugin/README.md — agent-plugin setup.
• llms.txt — command discovery for agents.

Related Pages

Related topics: Overview & System Architecture, Publishing Workflow, Expiring URLs & Password Protection

Agent Integration, Skills & Hooks

Overview and Purpose

The Agent Integration layer is a portable bridge between Pagecast (the local publishing CLI and server) and coding agents such as Claude Code, Codex CLI/Desktop, and any Agent-Skills-compatible tool. Its job is to make publishing an agent-generated artifact feel like a one-line confirmation rather than a separate workflow: the agent creates an HTML or Markdown report, the hook hints that a shareable artifact was produced, the skill offers to publish, and on an explicit "yes" the headless CLI returns a public pagecast.pages.dev link. Source: plugin/README.md:1-15

The layer ships in three coordinated pieces:

• A passive PostToolUse hook that fires when an .html or .md file is written.
• A portable SKILL.md describing *when* to offer and *how* to publish.
• A headless CLI invocation (npx pagecast publish … --json) that performs the deploy.

The explicit design constraint, repeated in both the plugin README and the skill, is that publishing must never happen without explicit user confirmation — public links are only revoked on demand, so a stray publish is irreversible without an active revoke. Source: plugin/skills/publish-report/SKILL.md:1-40

Architecture

flowchart LR
  A[Agent writes .html / .md] --> B[PostToolUse hook<br/>detect-report.mjs]
  B -->|hint| C[Skill: publish-report<br/>SKILL.md]
  C -->|offer once| D{User says yes?}
  D -->|no| E[Drop it; never nag]
  D -->|yes| F[npx pagecast publish --json]
  F --> G[Pagecast server.js]
  G --> H[Cloudflare Pages<br/>/p/<token>/]
  H --> I[Public URL returned]

The hook layer is agent-specific (Claude Code's PostToolUse model), but the skill itself is portable Agent-Skills format. The bundled plugin ships the portable skill at plugin/skills/publish-report/SKILL.md, a Codex-native copy under .codex/skills/publish-report/, and a Claude Code marketplace entry that bundles skill plus hooks together. Source: plugin/README.md:21-60, package.json:25-40

The Chrome Extension (Experimental) lives alongside this layer and offers a one-click "Publish to Pagecast" action for file:// pages opened in the browser, gated on the local server being up. Source: README.md

End-to-End Workflow

1. Detection (Claude Code)

When the agent writes a file, the PostToolUse hook inspects the path and fires a hint if the extension is .html, .htm, .md, or .markdown and the file is not in the skip-list (node_modules, dist build internals, repo-meta files like README, CHANGELOG, AGENTS.md). Source: plugin/skills/publish-report/SKILL.md:15-30

The hook does not publish. It only signals; the publish decision sits with the model reading the skill.

2. Offer (the skill)

The skill instructs the agent to ask, at most once per file: *"Want me to publish this with Pagecast? It'll create a shareable public link."* If the user declines or ignores, the skill says explicitly to drop it and not re-ask. Source: plugin/skills/publish-report/SKILL.md:35-45

3. Publish (the CLI)

On a yes, the agent runs the headless CLI with the absolute path and --json:

npx pagecast publish "/absolute/path/to/report.html" --json
# → {"ok":true,"url":"https://pagecast.pages.dev/p/<token>/", ...}

Source: plugin/README.md:10-15, llms.txt:25-40

For static projects with a build step, the skill prescribes building first (npm run build) and then publishing the generated entry file (dist/index.html, build/index.html, out/index.html, or public/index.html). Source: plugin/skills/publish-report/SKILL.md:50-70

For whole-site Cloudflare Pages deploys, a different command applies — npx pagecast pages deploy "<abs path>/dist" --project <name> --branch main --json — which replaces the target Pages project contents rather than minting a new /p/<token>/ link. Source: llms.txt:35-50

Per-Agent Installation

The plugin README gives three install paths because each agent exposes a different discovery surface.

Codex CLI / Codex desktop uses Codex's native skill discovery, so the entire skill directory is copied into ~/.codex/skills/. Source: plugin/README.md:25-35

Claude Code installs the whole plugin through its marketplace, which bundles both the publish-report skill and the report-detection hooks:

/plugin marketplace add Amal-David/pagecast
/plugin install pagecast@pagecast

Source: plugin/README.md:35-45

Other Agent-Skills tools copy the portable SKILL.md directly. The detection hooks are Claude-Code-specific, but the skill still triggers when a report is created or when the user explicitly asks to publish one. Source: plugin/README.md:45-55

Configuration and Common Failure Modes

After install, the only one-time setup is connecting Cloudflare, either through the panel UI (npx pagecast → Connect Cloudflare) or headlessly via npx pagecast pages setup --project pagecast. The first publish auto-creates the user's Pages project — no manual project bootstrap is required. Source: llms.txt:50-60

Common errors the skill and llms.txt call out:

• 401 from npx pagecast — OAuth token is missing or out of scope. Recovery: run npx pagecast pages setup or click Connect Cloudflare in the panel. Source: llms.txt:60-70
• 409 from npx pagecast — multiple Cloudflare accounts are available. Recovery: pass --account <account-id> or choose one in the app. Source: llms.txt:70-75
• recreated: true in a goal-publish JSON response — the old goal URL was gone and a new one was minted; tell the user the new URL. There is one goal page per workspace. Source: plugin/skills/publish-report/SKILL.md:75-90
• Re-running plain publish — mints a fresh /p/<token>/ link each time. For in-place updates at the same URL, use npx pagecast goal publish … --json or re-sync from the admin app. Source: plugin/skills/publish-report/SKILL.md:75-90

Community-relevant note: Pages vs Workers

A recurring community question is why Pagecast is built on Cloudflare Pages rather than Workers with Static Assets. Pages is the right substrate here because published artifacts are pure static output (/p/<token>/index.html plus sibling assets) and Pages Functions give per-prefix middleware for password protection and expiring URLs without per-request runtime cost. The related v0.1.6 release adds edge-enforced expiring URLs (default 30 days, configurable per-install and overridable per-publish), checked at the edge by the same Pages Function used for password protection — so a link dies on schedule even when the publishing machine is off.

See Also

• Admin UI & Security Model — see README.md for 127.0.0.1 binding, revoked-token 404 behavior, and public-route defenses.
• Chrome Extension (Experimental) — see extension/README.md for the one-click "Publish to Pagecast" toolbar action for file:// pages.
• Goal Pages workflow — see plugin/skills/publish-report/SKILL.md for the pagecast-goal.md in-place update loop.

Related Pages

Related topics: Overview & System Architecture, Publishing Workflow, Expiring URLs & Password Protection

Chrome Extension & Feedback Analytics Worker

Pagecast ships two cooperating surfaces that sit alongside the local CLI: a Chrome extension that turns file:// reports into public links with one click, and a tiny Cloudflare Worker that records coarse reactions and view analytics for every published page. Together they extend the local publishing workflow into the browser and into the edge without requiring any Pagecast-hosted middleman.

1. Chrome Extension: `file://` to Public Link

The extension is a load-unpacked MVP for Chrome that turns a local HTML or Markdown file open in a tab into a public link by talking to the locally-running Pagecast server. The project README states that re-publishing the same file updates the same URL in place, which means the extension is essentially a thin client for the npx pagecast publish flow. Source: extension/README.md.

Activation Model

The extension only acts on local pages whose URL ends in .html, .htm, .md, or .markdown. The Chrome Web Store listing explains the trigger flow: the user clicks the Pagecast toolbar button, or right-clicks the page and picks "Publish to Pagecast", while viewing a local file. The extension then sends the file path to the local server, which reads the file and deploys it to the user's own Cloudflare Pages account. Source: extension/store/listing.md.

The submission checklist defines the precise set of declared permissions and their justification:

Source: extension/store/SUBMIT.md.

Installation Requirements

Two preconditions are enforced before the extension will do anything useful:

1. The Pagecast app must be running locally (npx pagecast), with Cloudflare connected at least once.
2. Chrome's "Allow access to file URLs" toggle must be enabled on the extension's details page. Without it, Chrome blocks the extension from reading file:// tab URLs, and the popup surfaces a reminder.

Source: extension/README.md.

Privacy Posture

The submission checklist declares that the extension does not collect or use user data, and contains no remote code — all JavaScript ships in the package. The only network call it makes is to the user's own loopback server, which is consistent with the "no Pagecast-hosted middleman" stance of the project. Source: extension/store/SUBMIT.md. The privacy policy itself lives in extension/store/PRIVACY.md.

2. Feedback Analytics Worker

The feedback Worker is a small Cloudflare Worker, deployed once to the user's own account, that backs the reactions and view analytics for every published page. The local server embeds a widget.js (served from the Worker) into published HTML; the widget beacons a view and posts reactions, and the local admin UI reads aggregate stats back. Source: feedback/worker.js.

Storage Model

The Worker keeps a single JSON aggregate per page slug in a KV namespace bound as PAGECAST_FEEDBACK, keyed stats:<slug>. Because Cloudflare KV has no atomic increment, writes follow a get -> mutate -> put pattern, which is best-effort under heavy concurrency. The design comment explicitly accepts this trade-off as acceptable for view and reaction analytics and notes it avoids the cost and complexity of a D1 binding. Source: feedback/worker.js.

The aggregate shape is:

Source: feedback/worker.js.

Reactions Allowlist and Privacy

The reactions that a viewer can leave are restricted to a fixed allowlist exported as REACTIONS: ["👍", "❤️", "🎉", "🚀", "👀"]. Anything outside this set is ignored, which prevents the endpoint from being abused to store arbitrary attacker-controlled strings. Source: feedback/worker.js.

Only coarse, aggregate signals are stored: country (from request.cf.country), referrer HOST (not the full URL), and device class (derived from the User-Agent). No IP addresses, no cookies, no per-visitor records, and no PII are retained. The pure helpers are exported from the Worker module so they can be unit-tested under Node without a Workers runtime. Source: feedback/worker.js.

3. Server-Side Integration

The local server is the glue between the extension, the deployed Worker, and the published HTML. Two integration points are worth noting.

Stats proxy. The local server exposes GET /api/feedback/stats, which reads the feedback config block, calls the Worker's /api/v1/stats?slug=…&token=… endpoint with a server-held statsToken, and returns the result to the admin UI. This proxying means the stats token never reaches the browser. Source: src/server.js.

Widget injection. When a publication is built, the server calls injectFeedbackWidget(html, { url: feedback.url, slug }) so the published page loads widget.js from the Worker's domain. The "Published with Pagecast" badge and branded Open Graph image are gated on the badge setting, allowing white-label pages to unfurl cleanly without Pagecast branding. Source: src/server.js.

Provisioning with scope elevation. Provisioning the Worker requires wrangler deploy plus a KV namespace binding. The implementation auto-retry path in src/server.js is interesting: if the first deploy fails with Cloudflare error code: 10000 ("Authentication error"), it re-runs the OAuth login with the broader feedback scopes and retries the deploy once. The same provisioning step writes a generated wrangler.toml with the KV binding and a PAGECAST_STATS_TOKEN env var. Source: src/server.js.

4. Architecture Diagram

flowchart LR
    A[Browser file:// tab] -->|Publish to Pagecast| B[Chrome Extension]
    B -->|127.0.0.1:4173| C[Local Pagecast server]
    C -->|reads file| D[HTML / Markdown source]
    C -->|wrangler deploy| E[Cloudflare Pages /p/token/]
    C -->|widget.js injected| E
    F[Viewer] -->|GET /p/token/| E
    E -->|widget beacon| G[Feedback Worker]
    G -->|stats:slug| H[(PAGECAST_FEEDBACK KV)]
    C -->|proxy /api/feedback/stats| G
    G -->|aggregate JSON| C
    C -->|render| I[Admin UI]

5. Community Context

The choice of Cloudflare Pages over Workers with Static Assets has been raised by users (see the top community issue "Pages not Workers?"). The current architecture leans on Pages Functions for edge-enforced features — the latest release notes for v0.1.6 state that expiring links are checked at the edge by the same Pages Function used for password protection, so a link dies on schedule even when the publisher's machine is off. Source: README.md.

This explains why the analytics Worker ships as a *separate* Worker rather than as Pages Functions: it needs its own KV binding, its own deploy lifecycle, and a stable widget.js origin that the published HTML can embed unconditionally. The Markdown renderer also remains in-process on the local server, security-hardened with an explicit scheme allowlist in sanitizeUrl, so a malicious source cannot smuggle javascript: or data: links into a public page. Source: src/markdown.js.

See Also

• Plugin & Agent Skill — the publish-report skill that drives headless publishes from coding agents.
• Local CLI & Server — the npx pagecast entry point and the HTTP surface that the extension and admin UI both call.
• Privacy Policy — the published privacy posture that backs the Web Store listing.

Doramagic Pitfall Log

Found 9 structured pitfall item(s), including 2 high/blocking item(s). Top priority: Installation risk - Installation risk requires verification.

1. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/Amal-David/pagecast/issues/7

2. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/Amal-David/pagecast/issues/1

3. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.host_targets | https://news.ycombinator.com/item?id=48590505

4. Capability evidence risk: Capability evidence risk requires verification

• Severity: medium
• Finding: README/documentation is current enough for a first validation pass.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.assumptions | https://news.ycombinator.com/item?id=48590505

5. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://news.ycombinator.com/item?id=48590505

6. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: downstream_validation.risk_items | https://news.ycombinator.com/item?id=48590505

7. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: risks.scoring_risks | https://news.ycombinator.com/item?id=48590505

8. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: issue_or_pr_quality=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://news.ycombinator.com/item?id=48590505

9. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: release_recency=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://news.ycombinator.com/item?id=48590505

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using pagecast with real data or production workflows.

• Docker? - github / github_issue
• Pages not Workers? - github / github_issue
• v0.1.6 — Expiring URLs - github / github_release
• Configuration risk requires verification - GitHub / issue