Skip to main content
Q-Code

Foundations · 5 modules

What are the foundation modules?

The foundation modules are the five every Q-Code project installs first: visibility, analytics, security, legal pages and cookie consent.

They cover what a published site has to be true regardless of what it sells: findable, measured honestly, hardened against the obvious attacks, and carrying the policies and consent a real visitor is owed. Nothing else in the library assumes these five are already in place.

The 5 modulesAll 20 modules

Why this group exists

What foundations is for.

A site that cannot be found, cannot say honestly how it performed, and has no privacy policy is not finished, it is a demo dressed as one. These five close that gap and are deliberately boring: each does the part that is the same on every project, so no project solves it twice.

They also share one rule. What they measure and enforce is checked against the built HTML a visitor and a crawler actually receive, never the source it was written from, which is the only version of a page that is honest to audit.

The modules

5 in this group.

Visibility engine

@ccd/visibility

One score across SEO, AEO, LLMO, conversion and agent readiness, measured on the built HTML.

  • Audits the pages a crawler actually receives, not the source they were written in.
  • Explains every finding in plain English, then hands it back as a fix you can approve.
  • Adds the SEO settings panel: title templates, canonical host, social image, crawler policy.

Analytics

@ccd/analytics

Server-side page and event counts with no cookies and no consent banner.

  • Reports pages, referrers and countries without storing anything that identifies a visitor.
  • Needs no cookie banner, because it sets no cookie.
  • Marks the events that matter to you as goals, so conversion is measured rather than guessed.

Security baseline

@ccd/security

The baseline hardening every project ships with: HTTPS, headers, row-level security and a firewall.

  • Enforces HTTPS with HSTS, and sets the hardened response headers a browser checks for by default.
  • Keeps every table behind row-level security, so one project can never read another’s data.
  • Scans dependencies for known vulnerabilities and the code for leaked secrets on every change.

Q&A

Questions about the foundations modules

Do I have to install all five?

No. Each is independent and a site works with none of them. In practice a project heading toward publication installs visibility, analytics and security in its first week, which is why they sit together here.

Does every project need the cookie consent module?

No. The analytics module sets no cookie, so a project with nothing else that does either needs no banner at all. Add anything that does, such as an embedded video or a third-party widget, and this module is what asks first.

What does the security module actually change?

It turns on HTTPS with HSTS, hardened response headers, row-level security on every table and a managed firewall in front of anything the public can reach, plus scanning for known vulnerabilities and leaked secrets on every change.

The other groups

Where to look next.

Describe the feature, not the module.

You are not expected to know which of these you need. Say what the site should do and the build reaches for the parts that already exist.

See how a build worksThe whole library