[agentel-tech]

Summary

Add agentel-network-chat-template, a single-operator chat application using Cloudflare Agents and Durable Objects to discover public Missions, Skills, Agents and supporting evidence through Agentel's read-only MCP tools. The operator supplies their own Reader credential, model-provider key and access password; INFO allowance, model charges and Cloudflare usage are separate.

The UI, assets and Agent routes remain authenticated. The browser tests exercise the real Worker, Durable Object and React UI with synthetic local credentials and empty Reader/model keys. MCP actions cannot apply for work, publish, submit results or claim rewards.

Scope

• Add the template, Dashboard metadata/README content, npm lockfile and local Worker/browser tests.
• Register the workspace dependency graph, including 17 template-scoped version groups and an exact streamdown@2.5.0 Shiki package extension. Existing workspace importer resolutions, package records and dependency snapshots are preserved.
• Add an explicit readiness HTTP status option so this authenticated template can expect 401; other templates retain the existing successful-response default. Four regression tests cover default 200, opt-in 401, default rejection of 401, and rejection of 503.
• Keep gRPC Container changes and emulation-specific timeouts out of this PR. No validation workflow or unrelated template source changes are included.

Validation

Current PR head: d7a2ffd1bb9e0c40f9077acde7b6667ab45a0f50. Validated source snapshot: 44acfcb153f98677c8ea083e80f74149dfa7ed1e; the follow-up commit changes only README installation instructions and evidence links, leaving runtime code, dependencies, lockfiles and tests unchanged.

Current-head native Ubuntu validation checks out this exact source from a separate validation branch. The workflow commit is 56271082b67fcac740d50cdbe52538b6eac84266, distinct from the source under test. No validation workflow is part of this PR.

Ubuntu 24.04 x86_64, Node 22.23.3, pnpm 10.2.0; default concurrency and timeouts, no slow-environment flag:

• Frozen install and 21 build tasks passed.
• pnpm -w check: 90/90 tasks; pnpm -w test: 21/21 tasks, default concurrency. Both had zero Turbo cache hits.
• Protected-readiness regressions: 4/4 passed.
• Full Chromium E2E: 68/68 first-attempt passes; no failures, skipped/flaky cases or retries. The case set exactly matches the prior 68. All four Agentel cases and the unchanged upstream gRPC case passed.
• Main job: 7m28s, leaving 12m32s of the 20-minute budget.
• Separate supplemental job: 2m46s, passed all repository Deploy to Cloudflare button, private/version metadata, and published live demo URL checks. Agentel is unpublished, so the published-demo audit does not certify its proposed preview format.

Counts of 90 and 21 refer to repository tasks, not test cases. This remains fork validation, not an upstream approval or an official Semgrep result. At the last upstream readback for validated source 44acfcb, the three runs had action_required with no jobs started, and the main run page required maintainer approval. This does not establish the result of upstream checks on the documentation-only follow-up head. Hosted acceptance below remains attributed to the runtime source/version actually deployed; no new paid conversation was sent for this CI run.

Additional independent validation

Standalone exports of validated source 44acfcb153f98677c8ea083e80f74149dfa7ed1e passed on Ubuntu 24.04 / Node 22.23.3 with npm 11.6.2 and bundled npm 10.9.9. Each passed npm ci, formatting/lint/types, 112 unit tests, 11 Worker integration tests, build, and a synthetic local UI smoke check. The npm lock stayed unchanged. No parent pnpm workspace or real credentials were used; this is not Dashboard deployment acceptance.

An independent Semgrep 1.160.0 auto scan reported zero findings in the new Agentel template. There were 49 findings elsewhere, all mapped to unchanged upstream code spans, and 17 parser warnings outside the new template. No unrelated source or ignore rules were changed. This is supporting evidence, not an upstream scan approval or a claim that the entire repository has zero findings.

Hosted acceptance and preview

• Public static preview overview: unauthenticated access works; HTML and its image matched the reviewed static package on readback. The page currently identifies its image as a local capture and is not an interactive demo.
• Protected deployed application: authenticated single-operator application, with no shared credentials published.
• Actual hosted UI screenshot: agentel-network-chat-template/docs/hosted-preview.png (1600 × 900), embedded in the proposed README update. It shows the connected hosted UI after clearing the acceptance conversation, not the model response itself.

On 2026-10-16 (Asia/Shanghai), source b500e2a650f78d3a554888e1eb3e21fc88faab86 was deployed to an isolated Worker with compatibility date 2025-10-08 and MiniMax-M3 via anthropic-messages (https://api.minimaxi.com/anthropic/v1). This is separate runtime configuration; the template's default OpenAI route was not live-tested.

• Authentication: no credentials 401, wrong password 401, correct credentials 200; cross-origin RPC and WebSocket 403.
• Real Durable Object/Agent connection and discovery of all six read-only Agentel MCP tools passed.
• Exactly one real conversation turn inspected the connection and completed list_posts(limit=1): one returned item, successful tool result, costUnits=1; the observed Reader allowance difference was 1 INFO. No real turn was retried.
• Reload and Clear passed; the acceptance conversation was cleared afterwards. Reader/model secrets were not included in source, assets or the update package.

This was a deployment in the contributor's own account, not independent customer onboarding. The allowance change is an observed shared-Reader window, not exclusive billing attribution. Actual provider HTTP request count, tokens and final billed cost were not fully observed. Hosted Stop/cancellation and provider-side stopped billing were not validated. Code guard limits are not provider billing guarantees.

Draft status and remaining review items

• Deploy the candidate to an isolated protected Worker and complete one bounded real MCP/model acceptance turn.
• Prepare a real hosted application screenshot and document public overview/protected application addresses.
• Include the repository-prescribed Deploy to Cloudflare button at the top of the README; its text/URL format is checked separately from first-time deployment acceptance.
• Confirm whether the public static overview plus credential-protected application satisfies the gallery's publicly accessible deployed-preview requirement. Related discussion: Proposal: Cloudflare Agents chat template with a read-only Agentel MCP client #1170. This is pending; an open public chat demo is not claimed.
• Validate first-time customer deployment and the supported Deploy to Cloudflare flow. The standard top-of-README button is now included with the official main URL. That template path becomes available after merge; button-format validation is not a successful first-time deployment-flow test.
• Confirm the template-scoped dependency versions and the narrow package extension are acceptable.
• Have the Cloudflare team supply gallery preview image/icon URLs and decide publication. cloudflare.publish remains unset.

This PR stays Draft. The documentation and screenshot changes do not alter runtime code, dependency locks or test configuration. Earlier historical hosted evidence retains its original version attribution in the README. This draft requests implementation and fit review; it does not claim Cloudflare endorsement or Dashboard publication.

[agentel-tech]

The draft now includes a real 16:9 screenshot, an isolated deployment, and one bounded live MCP/model acceptance turn. Current PR head: d7a2ffd1bb9e0c40f9077acde7b6667ab45a0f50. This PR does not modify .github/workflows/.

The upstream Pull Request, Supplemental Checks, and Semgrep runs are currently action_required with no jobs started. Could a maintainer review and approve the fork workflow runs when appropriate?

• Main checks: https://github.com/cloudflare/templates/actions/runs/38832389030
• Supplemental checks: https://github.com/cloudflare/templates/actions/runs/38832389033
• Semgrep: https://github.com/cloudflare/templates/actions/runs/38832389032

Could you also advise whether the public static overview plus the separately authenticated operator application meets the gallery's preview expectations? No shared Reader, model key, or operator password is published. The README distinguishes the static page from an interactive demo. We can adjust the presentation to your preferred approach without exposing a shared credential or allowing public paid calls.

The standard Deploy to Cloudflare button uses the prescribed official main path, which becomes available after merge. First-time Dashboard deployment has not been validated. Preview image/icon URLs and cloudflare.publish remain for the Cloudflare team to configure.

Fork validation of runtime source 44acfcb passed (the d7a2ffd follow-up changes only README): https://github.com/agentel-tech/templates/actions/runs/38828766457 (68/68 first-attempt E2E, main job 7m28s; supplemental checks 2m46s). This is supporting evidence, not a substitute for the upstream checks or Semgrep.

[agentel-tech]

A brief follow-up on this draft: the current-head Pull Request run #2104 still awaits maintainer approval. Could a maintainer review the fork workflow runs and advise on the gallery fit when convenient?

The main decision we need is whether the public static overview plus a separately authenticated operator application meets the deployed-preview requirement, or what preview arrangement you prefer. First-time customer deployment is still unvalidated, and dependency acceptance and gallery publication remain open review items. The PR will stay Draft while those are unresolved.

The validation and version-bound hosted evidence are linked above; no new deployment or live paid calls were made for this follow-up. Thanks for taking a look.

[agentel-tech]

Hello, checking back on the draft. Could a maintainer advise whether the static public overview plus the separate authenticated application is acceptable for the gallery preview, and whether there is a preferred route for reviewing this submission? The current fork workflows still need maintainer approval.

The PR remains Draft while preview fit and first-time deployment acceptance are unresolved. The earlier validation details are linked above. Thank you.