Carcinus.org Public Surface Assessment

Full report

On this page

Executive Summary

Carcinus.org exposes a large unauthenticated public surface centered on four areas: an AI-site publishing platform, a public Meeting Hub, an extensive Teleodynamic AI research section, and a set of machine-readable discovery/API documents. Using the official site map as the starting point, I identified at least 112 named public entry points before counting newly created meeting URLs: core platform/info pages, the research section, meeting pages, agent-tool pages, discovery/API documents, and 42 public bot pages under /public/{slug}/. The site’s own inventories are not fully reconciled, however: published-site counts appear as 39 on the changelog, 42 in /api/health, and 42 in the site map; the research-section page count appears as 17, 25, 31, and a larger named set in different official pages.

The highest-confidence public features that worked end-to-end in this assessment were the Meeting Hub flows and several JSON discovery endpoints. I successfully exercised unauthenticated meeting creation through the documented GET flow, observed a browser redirect into a new meeting room, opened the no-JavaScript text transcript view, fetched the live open-meetings JSON list, fetched public memory JSON, requested temporary agent tokens without authentication, and accessed machine-readable discovery files such as /.well-known/ai-agent.json, /.well-known/openapi.json, /api/health, /api/v2/sites/published, the Teleodynamic JSON schema download, the i18n token JSON file, and the SEO validation descriptor.

The most important issues were not basic reachability problems, but contract inconsistency, JS dependence, and test-artifact leakage. Public documentation disagrees about API versioning and auth placement; some pages advertise rich filtering/search/badges but degrade to “Loading…” in text/no-JS mode; the public site and meeting surfaces expose smoke-test and internal-looking artifacts such as live-smoke-get-mq0d2pq3, sitepub-bot, ProductionRateLimitSmoke*, and RateLimitHeaderSmoke*; and the advertised /llms.txt and /llms-full.txt endpoints could not be fetched by the browser parser used here even though other official docs advertise them. A broken example link was also observed: /agents/TestAgent loaded as a page shell, but its advertised JSON profile endpoint returned 404 Not Found.

Most public reads are truly public. By contrast, site mutation, webhook management, private memory, and other owned-resource operations require a write token or explicit owned-resource context. Public invitation flows and temporary token requests are intentionally unauthenticated, which makes access easy but also enlarges the public abuse surface unless throttling and auditing are strong in practice. The discovery file explicitly documents rate limiting at 20 mutations/minute per IP with public reads unlimited, and the API docs describe typed application/problem+json errors plus X-Correlation-Id for recovery.

Scope and Observed Public Surface

This inventory is based primarily on the official /site-map and the Teleodynamic research /teleodynamic-ai-carcinus/site-map-reference, then cross-checked against public discovery endpoints and sampled live pages. Where a feature required arbitrary form submission or free-form input not supported by the text renderer, I recorded the visible UI, any machine-readable fallback, and the documented contract.

flowchart TD
    Home["/"] --> Sites["/sites"]
    Home --> Docs["/docs"]
    Home --> Templates["/templates/"]
    Home --> Dashboard["/dashboard"]
    Home --> Meetings["/meetings"]
    Home --> Research["/teleodynamic-ai-carcinus"]
    Home --> Public["/public/{slug}/"]

    Docs --> ApiDocs["/instructions"]
    Docs --> ApiRef["/docs/api"]
    Docs --> ApiV2["/docs/api-v2"]
    Docs --> Agents["/docs/agents"]

    Meetings --> Create["/meetings/create"]
    Meetings --> Start["/meetings/start"]
    Meetings --> Open["/meetings/open"]
    Meetings --> MeetDash["/meetings/dashboard"]
    Meetings --> MeetSearch["/meetings/search"]
    Meetings --> MeetArchive["/meetings/archive"]
    Meetings --> MeetInbox["/meetings/inbox"]

    Research --> Builder["/teleodynamic-ai-carcinus/evaluation-template-builder"]
    Research --> Schema["/teleodynamic-ai-carcinus/evaluation-packet-schema"]
    Research --> Search["/teleodynamic-ai-carcinus/search"]
    Research --> Accessibility["/teleodynamic-ai-carcinus/accessibility"]
    Research --> Evidence["/teleodynamic-ai-carcinus/evidence-archive"]

    Home --> Discovery["/.well-known/ai-agent.json"]
    Home --> OpenApi["/.well-known/openapi.json"]
    Home --> Health["/api/health"]
    Home --> Published["/api/v2/sites/published"]

The site map’s top-level public inventory includes the following platform/info pages and discovery documents. All were publicly reachable according to the site map or docs; the llms text files were advertised but did not render successfully in this browser parser during testing.

The Meeting Hub and agent-tool surface includes the following named public pages or entry points. Several are clearly designed to degrade into JSON or text fallbacks for agents and no-JS clients.

The official research inventory is unusually large and partly split across two official pages. Between /site-map and /teleodynamic-ai-carcinus/site-map-reference, the named research surface includes: /teleodynamic-ai-carcinus, /concept-map, /glossary, /faq, /evaluation-handoff, /evaluation-template-builder, /evaluation-packet-gallery, /evaluation-packet-schema, /evidence-archive, /claim-status, /agent-boundary-model, /comparison-matrix, /reviewer-toolkit, /onboarding, /walkthrough, /api-examples, /search, /roadmap, /dashboard-metrics, /methodology, /i18n, /i18n/tokens, /content-health, /contribute, /demo-agent, /agent-directory, /research-index, /site-map-reference, /version-timeline, /pdf-report, /testimonials, /performance, /structured-data, /report-comparison, /simulation, and /accessibility. The research site-map reference supplies short descriptions such as “client-side builder with 3 profiles and download,” “full-text search,” “3 downloadable bundles with checksums,” and “8-item checklist,” while the broader /site-map adds the later pages such as Performance, Structured Data, Version Timeline, PDF Report, Report Comparison, Simulation Sandbox, and Accessibility.

The official site map also lists 42 public bot pages under /public/{slug}/. These are all public and unauthenticated, and sampled entries ranged from polished profile pages to minimal smoke-test pages. The listed slugs are: /public/badbot/, /public/carcinus/, /public/cipher-straylight-5512/, /public/e2e-bot-20260604-0427/, /public/echo-greaves-11181719/, /public/influencer/, /public/iris-vale-11181414/, /public/kestrel-thornfield-11181210/, /public/live-smoke-get-mq0d2pq3/, /public/lyra-ashborne-11181515/, /public/lyra-greaves-11181516/, /public/mara-thornfield-11181617/, /public/mara-vale-5216/, /public/mara-wren-1644005/, /public/nova-drift-1118107/, /public/nyx-thornfield-1643594/, /public/onyx-drift-11181413/, /public/onyx-vale-1118106/, /public/quill-straylight-3729/, /public/rook-greaves-1116261/, /public/rune-blackwater-4821/, /public/rune-greaves-11181312/, /public/rune-holloway-1118082/, /public/rune-morrow-1643573/, /public/rune-nightglass-2752/, /public/rune-wren-1643551/, /public/sitepub-bot/, /public/testbb111709/, /public/vanta-drift-1118118/, /public/vanta-drift-1643562/, /public/vanta-morrow-0112/, /public/vanta-nightglass-1118094/, /public/vanta-nightglass-4141/, /public/vanta-starling-11181311/, /public/vesper-blackwater-0947/, /public/vesper-starling-1118095/, /public/vesper-straylight-3131/, /public/vesper-thornfield-1118083/, /public/zephyr-blackwater-1118071/, /public/zephyr-drift-11181720/, /public/zephyr-thornfield-11181618/, and /public/zephyr-wren-1118119/. sampled examples showed that root public paths redirect to /index.html.

Interaction Testing Matrix

The following matrix focuses on interactive or operationally meaningful public features rather than every static content page. “Accessible?” means reachable and at least partly usable without authentication in this assessment. Notes distinguish observed behavior from purely documented behavior. The rows synthesize the cited pages/endpoints listed in the Notes column.

API and Network Findings

The most valuable public endpoints returned structured JSON without authentication. The strongest examples were: /api/health, which returned status, version, runtime, route inventory, and database check results; /api/v2/sites/published, which returned full published-site records and raw HTML templates; /.well-known/ai-agent.json, which returned a broad capability/auth schema; /.well-known/openapi.json, which returned the machine-readable API contract; /api/ai/memory/public, which returned [] at test time; /api/v2/tokens/request?agent=…, which returned a temporary token plus expiry; and /api/v2/seo/validate, which returned endpoint metadata including queryOptions, a POST recommendation for large HTML, and maxFetchedBytes: 524288.

A representative request/response snapshot looked like this:

GET /api/health
=> {"status":"Healthy","version":"3.1", ... "runtime":".NET 10.0.8", ...}

GET /api/v2/tokens/request?agent=my-agent
=> {"tempToken":"…","agent":"my-agent","expiresUtc":"2026-06-07T00:03:03.0705644Z","nextStep":"GET /api/v2/bots/register?botName=YOUR-NAME&token=…"}

GET /api/ai/memory/public
=> []

GET /api/v2/meetings?status=Open
=> [{"meetingCode":"58940bc4","title":"Test Meeting JSON", ...}, ...]

GET /api/v2/meetings/58940bc4/text
=> "# Test Meeting JSON" + transcript text

These examples are all directly observed from public endpoints.

The meeting flow is the best-exercised interactive flow and is well suited to agents, albeit with some ambiguity between browser and agent behavior. The official surface advertises creation via /meetings/start?title=X&displayName=Y, open-meeting listing, no-auth participation, and text-mode reading; the browser-observed behavior for create-via-GET was an immediate redirect into /meetings/{code}, while the text transcript endpoint for that room worked cleanly and exposed a GET-based message-send pattern. That behavior is consistent with the discovery file’s mention of content negotiation, but the docs do not present the browser-vs-agent distinction as cleanly as they should.

flowchart LR
    A["Agent or human"] --> B["GET /meetings/start?title=...&displayName=..."]
    B --> C["Observed browser redirect to /meetings/{code}"]
    C --> D["Meeting room HTML shell"]
    D --> E["No-JS fallback: /api/v2/meetings/{code}/text"]
    F["/meetings/open"] --> G["Public text list"]
    H["/meetings/dashboard"] --> I["JSON fallback: /api/v2/meetings?status=Open"]

The largest operational problem on the API side was spec drift. The home page quick start still shows /api/bots and /api/sites, while the API instructions say all examples use v2 endpoints. The API Reference and API Instructions describe update/publish/delete with {siteId} paths and writeToken in the request body, but the raw HTML templates tell users to PUT /api/v2/sites/by-bot/{botName} with X-Site-Token in a header, and the API v2 Reference lists still other variants such as POST /api/v2/sites/publish, PUT /api/v2/sites, and DELETE /api/v2/sites/{botName}. This level of drift is likely to break agent integrations and human copy-paste usage.

A second operational problem is that several public inventories are visibly stale or inconsistent. The changelog says 39 published sites, while /api/health reports 42 published bots and the site map lists 42 public bot pages. The research section is also inconsistent about its own size: the Dashboard Metrics page says 17 pages, the research Search and Content Health pages say 25, and the Structured Data Hub and Accessibility Audit say 31, while the broad /site-map names an even larger research set. These discrepancies undermine discoverability and trust even when the underlying endpoints are up.

Finally, the public surfaces clearly expose internal/testing artifacts. Examples include site slugs such as live-smoke-get-mq0d2pq3 and sitepub-bot, plus public meetings titled ProductionRateLimitSmoke, ProductionRateLimitSmoke2, ProductionRateLimitSmoke3, RateLimitHeaderSmoke, and RateLimitHeaderSmoke2. This is useful for transparency, but it also makes the public environment look like a mixed production/test surface.

Accessibility Security and Validation

Carcinus’s own research-section accessibility page claims a strong static audit result: WCAG 2.1 AA across 31 Teleodynamic research pages, with 12 checks passing, 0 critical issues, theme-contrast review, skip links, label coverage, keyboard flow, and no positive tabindex. That is a positive sign for the research section specifically. The same page also records future improvement ideas, including a skip-to-search link, live-region improvements for dynamic content, better theme-toggle announcement, and a high-contrast mode.

What I observed on the broader platform side is more mixed. Multiple non-research pages explicitly depend on JavaScript or behave as placeholders in text/no-JS mode: /sites, /dashboard, /meetings/dashboard, /meetings/archive, /memory, /agents/TestAgent, and meeting rooms themselves. Some of these provide good fallbacks—especially the Meeting Hub, which exposes text and JSON alternatives—but others simply show “Loading…” or similar placeholders. That is not necessarily a WCAG violation, but it is a practical accessibility and agent-usability issue.

On security and public-surface controls, the documentation is explicit about several things even where raw header values were not directly inspectable here. The site advertises CSP headers, XSS sanitization, rate limiting, PBKDF2-hashed tokens, typed application/problem+json errors, HMAC-SHA256 webhook signatures, and X-Correlation-Id for recovery. The ai-agent discovery file states 20 mutations/minute per IP and unlimited reads, while the API v2 docs describe documented error classes for 400, 401, 403, 404, 405, 409, 422, 429, 500, 502, and 503. /api/health also publicly discloses runtime and database connectivity state, which is useful operationally but arguably more environment detail than some public APIs expose.

Input validation and limits are documented in a few places with useful specificity. The Teleodynamic evaluation-packet schema requires packetId, createdUtc, agentSlug, and claimStatus, constrains several enums, and sets minima for counters such as noOpCount and blockedActionCount. The SEO validator endpoint publicly discloses accepted query options (html= and url=), prefers POST for large HTML, and states maxFetchedBytes of 524288. The ai-agent discovery file documents memory-proposal limits of title max 512 and content max 50000 characters. I did not find any public file-upload controls on the tested pages, so there were no public upload MIME/type/size rules to exercise directly; public inputs were mainly text fields, JSON text areas, URL fields, and client-side download generators.

Two public-safety design choices are especially notable. First, the token-request endpoint is unauthenticated and returns a registration next-step that places a token in the query string of a GET URL; that is convenient, but query-string credentials are usually undesirable because of logs, history, previews, and referrers. Second, the Meeting Invitations page explicitly states that invitations are public and trust-based with no authentication required. Those may both be intentional product choices, but they deserve careful hardening and documentation.

Actionable Priorities and Open Questions

The fastest path to a cleaner, more reliable public surface is to fix the contract layer first. The home page, API instructions, API reference, API v2 reference, and raw templates currently disagree about path shapes, versioning, and where tokens belong. Unifying those documents into one canonical contract should be the first priority, because it will immediately improve both human and agent success rates.

A practical prioritized list follows:

1. Unify the public API contract. Resolve the /api vs /api/v2 split, pick one update/publish/delete route family, and standardize where write tokens are sent. This is the most important blocker for external agents and developers.
2. Clarify browser vs agent meeting creation. If /meetings/start is meant to redirect browsers and return JSON to agents, document that explicitly and expose one clearly canonical JSON-first route.
3. Make discovery text files reliably consumable. /llms.txt and /llms-full.txt are prominently advertised but failed in this assessment’s browser parser. Those endpoints should be validated with multiple clients and included in smoke tests.
4. Reduce JS-only dead ends. Add non-JS or pre-rendered fallbacks for /sites, /dashboard, /meetings/archive, /memory, and /agents/{slug} the way the Meeting Hub already offers text/JSON alternatives.
5. Remove or quarantine public smoke-test artifacts. Publicly visible test meetings and smoke-test bot pages make the environment look mixed-purpose. Move them behind a non-indexed test namespace or exclude them from public listings.
6. Reconcile all public counts and inventories. Published-site counts and research-page counts should agree across changelog, health, site map, content health, accessibility, dashboard metrics, and search pages.
7. Harden unauthenticated token/invite flows. Prefer POST/body or another less log-prone flow over query-string registration tokens, and document throttling/audit controls on public invitation creation and temp-token issuance.
8. Review public DTO minimization. Decide whether /api/v2/sites/published really needs to expose raw htmlTemplate, internal IDs, and full metadata for every published site, and whether /api/health should expose runtime/database details publicly.

Open questions and limitations

A few things remain incomplete rather than unknown. I could not directly verify raw CORS or full response-header sets from this environment, so CSP/rate-limit/security-header conclusions are based on official docs and discovery files rather than raw header capture. Arbitrary form submission, arbitrary POST bodies, free-text search execution, and JS-only download buttons were also not fully exercisable here, so those features are reported as partially tested when appropriate. Finally, raster screenshots of webpages were not available from the text renderer used here, so this report relies on structured page captures, endpoint outputs, and diagrams instead of image-based screenshots.