CHANGELOG.md

Changelog

Unreleased

• The AI builder speaks the shared component registry (design 2026-11-09): before starting a space.app.build run, Space reads OpenVibe.Design's public design.component@1 registry (GET /api/v1/components) and passes the definitions as the run's components input, so a built space is made from the same navbar, menu, Dock, composer, sheet, rows and settings as the rest of OpenVibe. The read is cached for an hour, times out after 2.5 s, and a missing registry only means a build without the vocabulary: it never fails a build. The URL is OV_DESIGN_URL (default https://openvibe.design). test/spaces-registry.test.js.
• The builder is the person's own agent (plan 2026-10-22 §Z, stage Z1): "Describe it and OpenVibe AI builds it" starts a task of the person's one agent (OpenVibe.Actor) instead of Space's own AI loop. The space is the task's subject; the agent writes its files through Space's builder API (/api/v1/builder/spaces, the capabilities space.build.read|create|write|publish), and the editor opens the Dock at that task and shows the space as the agent writes it. The step reaches the network's agent namespace (agent.step.started|updated|ended, product space), so the Dock's one timeline shows it. Publishing is never done on its own: the agent asks, the person's answer lands in the Dock ("Needs you") and nothing goes live until they say yes (POST /api/v1/agent/approvals/:id/decide). The old builder stays behind SPACE_BUILDER=legacy until the new one is proven; nothing is deleted. test/spaces-agent.test.js.
• The forum's links follow Community's move to /forum (design 2026-11-07): Space's forum redirect now
  maps /s and /s/* straight to /forum and /forum/<space>/<thread> (the /t/ segment is gone) instead
  of passing the old path on, so a bookmark lands in one hop. The home page, both navbars and llms.txt link
  https://openvibe.community/forum; the forum API paths still answer 308 unchanged.
• Official example spaces (plan §4 Space: "Next: official example spaces"): three published examples owned by the official OpenVibe account — a link page (ov-links), a portfolio (ov-portfolio) and a monthly community night with a live RSVP list (ov-night) — adapted from the Space kit's site-links, site-portfolio and site-event templates and kept in seeds/official-spaces/. node scripts/seed-official-spaces.js creates and publishes them through the service's own modules (server/spaces/official.js); it is idempotent, --revise repairs drift, and a slug somebody else holds is reported and never taken. spaces.create now accepts an explicit slug (same checks as a generated one). test/official-spaces.test.js.
• Share: a space's page carries the network's one Share button (data-ov-share-sheet) in its actions; it shares the published space's own address (or the page's address for a draft), with its name and description. test/spaces.test.js.
• Guest drafts (openvibe.website, plan 5.9: "making websites and code without needing OpenVibe logins"): a visitor who is not signed in makes a draft on openvibe.space (GET/POST /spaces/guest) from a website template or a sentence, and edits it with a secret link (/spaces/<id>/edit?key=…; the cookie only remembers it, the link alone works). The draft has no owner and of the secret only its sha256 is kept. It is static: never published, no visitor's data, no server functions; in the preview the SDK answers "sign in to use this" where a visitor's account would be needed. A signed-in person who holds the secret claims it (POST /spaces/<id>/claim): it becomes theirs, the secret is cleared, and space.app.claimed is logged. The limits (per address, per draft, per service) and the seven-day expiry are in server/hosting-config.js; the abuse screen (server/spaces/content-check.js) refuses a phishing page and any form in a guest draft that posts to another origin.
• Usage readings (plan T5 step 14, Space slice): server/billing.js turns the bytes the local object store keeps (space_blobs, each blob once per project) into one platform.usage-sample@1 gb-month reading per production project and owner per closed UTC day, queued in billing_readings (migration 0006_billing_readings.sql) and relayed to OpenVibe.Billing's billing.usage.record. Off unless SPACE_BILLING_INTERVAL_MS > 0; with SPACE_OBJECT_STORE=media Space emits none, because Media bills the stored bytes.
• The forum moved back to OpenVibe.Community (owner decision, 2026-10-08), so Space keeps none of it. Removed: server/forum/*, server/relay/*, server/vip/*, server/media/*, server/identity/*, server/{chat-rooms,votes,limits,actor-limits,events,events-consumer}.js, server/http/v1.js, server/render/{board,forum,markdown,jsonld,highlight}.js, public/js/space.js, the forum suites and their fixtures, docs/discord-relay.md and the roadmap JSON.
• Every forum URL answers a permanent redirect to the same path and query on https://openvibe.community: /s and /s/* by 301 for GET and HEAD and 308 otherwise (the method and body are preserved), and /api/v1/spaces*, /api/v1/posts/*, /api/v1/space-groups* and /api/v1/relay* by 308.
• Space's home page (/) is now a short, honest page: Space will host code and dynamic pages, and "spaces" — apps people build on their OpenVibe account, the network's services and the SDK — with a clear link to the forum at https://openvibe.community/s. It claims no feature Space does not have.
• Kept: sign-in (the Network OAuth2 client space), the discovery files (robots, llms.txt, llms-full.txt, a sitemap holding / alone), health/ready/release.json. Removed the account export/deletion hooks and the rest of the network-event consumer: they only ever touched the forum's tables, and the forum's account data is Community's. The forum tables stay in the database; this release writes no drop migration.
• The suite is now home, redirects and boot (the real process on a fresh database, ending in a clean SIGTERM).