Knowledge Base

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €24/mo; article authoring, search, category management

Generated from docs/plan/paid/knowledge-base/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Merchants need self-service documentation to reduce support load. This feature provides article authoring, category organization, search, and analytics to measure self-service effectiveness.

The problem

My support team gets the same questions repeatedly. I need a searchable FAQ that customers can find before emailing support, which would reduce my support volume by 30%.

What it does

• Article entity: title, slug, body (rich text), category, status (draft/published), created/updated timestamps
• Categories: hierarchical (parent/child), articles belong to one category; sidebar navigation
• Search: full-text search across title and body, return top 10 results, highlight matches
• Article versioning: track edits, revert to older version, show ‘last updated’ date
• SEO: meta description, canonical URL, open graph tags for social sharing, sitemap XML inclusion
• Analytics: view count, search queries that led to this article, bounce rate, average time on article
• Suggested articles: ‘Did this help?’ thumbs up/down, related articles sidebar
• Public URL: /help or /knowledge-base, accessible without auth, articles indexed for Google
• Admin editor: WYSIWYG editor, preview, publish/unpublish, category picker, version history
• API endpoints: GET articles, GET article by slug, POST article (admin), search, analytics

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Multi-language articles — same article slug in multiple languages requires i18n hooks; core is English only
• Discussion/comments on articles — readers cannot comment; article improvement is operator-only
• Video embedding beyond standard <iframe> — we allow video embeds but do not host or stream video
• Automatic article generation from support tickets — mining FAQs from chat logs is a future feature
• Integration with external help centers (Zendesk, Intercom APIs) — we do not sync to third-party systems

Data model

New entity: Article {id, title, slug (unique), body, category_id (FK), status, view_count, updated_at, created_at}. New entity: ArticleVersion {id, article_id, body, version_number, created_by_id, created_at}. New entity: ArticleCategory {id, name, slug, parent_category_id (nullable, for hierarchy)}. New entity: ArticleAnalytic {id, article_id, query (for search), visitor_id (nullable), viewed_at}. Schema migration across all three drivers.

API

• GET /api/articles — list published articles (paginated, public)
• GET /api/articles/search?q=query — full-text search (public)
• GET /api/articles/:slug — fetch article by slug (public)
• GET /api/categories — list all categories (public)
• POST /api/articles — create article (admin only)
• PATCH /api/articles/:id — update article (admin only)
• DELETE /api/articles/:id — unpublish article (admin only)
• GET /api/articles/:id/versions — version history (admin only)
• POST /api/articles/:id/restore — revert to version (admin only)
• GET /api/admin/analytics/articles — view counts and search analytics

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Knowledge base editor: list of articles with status (draft/published), search/filter by category. Create/edit article form: title, slug, category, WYSIWYG body editor, preview tab, publish/unpublish button. Version history sidebar: list of edits with timestamps, revert button. Analytics dashboard: top articles by views, top search queries, articles with low engagement (candidates for improvement).

The seam — why this is paid

Core owns the article model, versioning, search, and REST API. Paid layer owns SEO optimization (meta tag generation, XML sitemap auto-generation, Google Search Console integration for monitoring rankings), advanced analytics (visitor behavior tracking, A/B testing article titles, conversion attribution), and support for multi-language articles if i18n is added to core.

Support commitment: KB SEO optimization, article versioning, analytics

Dependencies

• Rich text editor library (assume available; e.g., TipTap, Slate, or simple HTML + sanitization)
• Full-text search (all three storage drivers must support it; core likely already does via libSQL FTS or similar)
• Slug generation and URL routing (assume core has URL-safe slug generation)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• An article can be created with title, category, and body; it is stored with status ‘draft’
• An article can be published; status changes to ‘published’ and it appears on the public site at /help/:slug
• A published article is searchable by title and body content; search returns it in results
• An article can be edited; the new body is stored and a version record is created with timestamp
• An older version can be restored; the current body is reverted and a new version is created
• Each view of a public article increments view_count
• A search query is recorded in ArticleAnalytic; analytics query shows top search terms that led to articles
• An article can be unpublished; it is no longer returned by public API calls and is hidden from search results

Risks

Full-text search performance can degrade with large article count; queries must be indexed. WYSIWYG editors can accept malicious HTML; all body content must be sanitized before storage and display. Article slugs are URLs; changing a slug breaks existing links (301 redirect tracking is optional). View count and analytics can be gamed by bots; bot detection (user-agent blacklist, rate limiting) is basic. Search indexing must be incremental; full reindex on every edit is too slow.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.