sphireinc/Foundry

Problem or use case Foundry currently exposes functionality through its CLI, admin and frontend HTTP APIs, compiled plugins, and out-of-process plugin RPC. These interfaces are useful for humans and conventional integrations, but they do not provide a standard Model Context Protocol server for MCP-compatible clients. As a result, an AI client that needs to work with a Foundry installation must either: Scrape rendered HTML. Call undocumented or narrowly scoped HTTP endpoints. Execute Foundry commands through a shell wrapper. Receive a custom integration for every deployment. Ask an operator to manually copy content, diagnostics, or configuration into the conversation. These approaches make the integration fragile and create inconsistent security boundaries. A shell-based integration could expose arbitrary commands. A direct filesystem integration could expose secrets or unrelated project files. A custom HTTP integration would need to rediscover the available capabilities and authoriza

Problem or use case The current CI already includes a publish workflow in .github/workflows/runtime-image.yml. It: Runs tests with Go 1.26. Grants the workflow packages: write. Logs into ghcr.io with GITHUB_TOKEN. Publishes images named like ghcr.io/sphireinc/foundry-runtime:runtime-v1.4.6 Publishes on runtime-v*.. tags or manual workflow dispatch. Also updates the latest tag. However, we don't fully publish Docker/OCI images publically. Proposed solution GH Container Registry supports Docker/OCI images, and Actions can publish a package associated with the repository using GITHUB_TOKEN. However, the first published package defaults to private, so the package would need to be made public. Also, there's a mismatch in the Go version that will need to be updated: go.mod requires Go 1.26.0. Dockerfile currently uses golang:1.25-alpine. The GitHub Actions workflow already uses Go 1.26. There is also a design distinction between the current runtime image and a static builder image. The c

Problem or use case Foundry is extensible, but a new user also evaluates maturity by the quality and breadth of official plugins. A first time user vetting Foundry will ask "I want more official plugins before betting on the platform." Proposed solution Ship or publish official plugins for: search redirects embeds syntax highlighting SEO tools scheduled publishing image optimization There are a longer list of suggestions in this discussion here: #45 Alternatives considered No response Prior art or references No response Area plugins

Problem or use case Theme security rules are stricter now, which is good, but authors may still need better feedback when a theme is rejected for things like undeclared remote assets CSP-related mismatches manifest policy mismatches Basically trying to NOT have theme/plugin authors run into questioning "my theme failed validation, but I want clearer remediation guidance." Proposed solution Improve validator diagnostics with concrete "declare this here" guidance. Alternatives considered No response Prior art or references No response Area content model

Problem or use case A new user often forms their impression from the scaffolded/default site. If the starting site is too minimal, it undersells: theming taxonomies media usage navigation admin capabilities I want the starter project to demonstrate what Foundry can really do. Proposed solution Improve the default starter content/theme/demo data. Alternatives considered No response Prior art or references No response Area themes