Engineering at Bookiji

Portfolio and platform architecture

Bookiji Inc is the company hub at www.bookiji.com. Each product lives in its own repo with its own scope. The Bookiji booking app is a sibling product — not this company site.

This page explains the model in public terms. The real proof lives in the product repos and the ops systems that are allowed to hold it.

Agent-assisted delivery

Agents help with bounded work: understand a task, draft a change, dig through evidence, and list what still needs checking. They stay inside repo rules. A change that exists is not the same as a change that works.

We start from the product bootstrap and standards, keep diffs reviewable, and leave enough trail that someone else can re-check the call. Bigger work also gets prompt-history and recon checks so it does not vanish into chat.

Human authorization points

People still own the hard calls: scope, review, sensitive actions, releases, and anything we say in public. Agents speed things up. They do not get to sign off.

Platform standards

Bookiji keeps a numbered set of engineering standards in the umbrella repo. Agents and humans are expected to read the ones that apply before changing behavior. This page lists the topics in public language — the full normative text stays in the private standards docs.

1. 01·Global engineering rules

   How agents and humans are expected to work in these repos.

2. 02·Secrets and config

   Secrets stay in the vault — never in Git, chat, or screenshots.

3. 03·Auth and identity

   Login methods must resolve to one account for the same verified email.

4. 04·Database and migrations

   Shared database per environment; products stay in their own schemas via migrations, with a fail-closed apply gate before schema-dependent work.

5. 05·Payments and Stripe

   Billing rules for products that take money.

6. 06·Testing and verification

   What “tested” means, and how we report PASS / FAIL / NOT_RUN.

7. 07·Git and repo operations

   How the umbrella and product repos stay in sync.

8. 08·CI/CD, release, and commit routing

   Where code lands, how we deploy, and what GitHub is (and is not) for.

9. 09·Agent execution and scheduled automation

   How agents report work, and how recurring jobs are supposed to run.

10. 10–11·Docs and product manifests

    Keep docs honest; every product declares its scope.

11. 12·Operational tooling baseline

    Health checks, error capture, and basic ops hygiene.

12. 13·Operator master access

    Break-glass operator login — separate from normal member accounts.

13. 14·Work tracking (GitHub)

    Issues and Bookiji Delivery are the work tracker — not chat or memory.

14. 15·Public demo vs real access

    Demo mode and operator access are not the same thing.

15. 16·Verification personas

    Prove the product for real users — not only the founder account.

16. 17·Commercial multi-user products

    Subscription products must support many independent accounts from day one.

17. 18·Workspace Self identity

    AI drafts stay first-person as the account owner — never invert who “I” is.

Related practice (not numbered 01–18): see Global Fair Pricing, AI standards and Support / Help Center below.

Bookiji products can use a shared platform pricing policy that adapts commercial offers to governed international markets while respecting sustainable product economics, payment-provider independence, and subscriber protections. The system separates thoughtful market accessibility from unsustainable discounting.

Status: Shared platform capability available for product adoption. Individual products adopt the policy across scheduled rollout gates.

AI standards

How Bookiji keeps product AI honest: shared runtime rules, Workspace Self, and curated Help retrieval where Help ships. Status tags use the same legend as the operational control plane.

Support / Help Center

Help is written as a standard, then proven product by product. Knowledge improves when resolved tickets are curated by operators into the help knowledge base — not when questions auto-feed FAQ.

Verification gates

Keep changes small enough to review. Public UI should be clear, usable, and responsive. When we verify, we report what each check actually did — missing checks stay NOT_RUN, not a silent pass.

Hover or focus each check to see what it covers.

Issue-to-release traceability

Ideal path: issue → change → review → checks → ship or publish. GitHub Issues and PRs hold the live work. Docs keep the longer-lived stuff: standards, architecture, runbooks, evidence.

We also look the other way: real Git work should show up as tracked work, and “done” work should not sit unlanded forever. Recon is there to catch that drift.

Operational control plane

Recurring ops work is moving into one shared view. Not autopilot shipping — just one place to see schedules, outcomes, recommendations, security findings, and unfinished work.

Prompt ledger and work reconciliation

Chat history is useful context. It is not the work tracker. We harvest supported agent sessions into a searchable prompt ledger, and Ops Center has a Recon view that lines that up with Git and Bookiji Delivery.

For serious work, agents should search that history when it helps and link or open a GitHub Issue. Issues and Bookiji Delivery stay the source of truth. Memories and future Prompteus decisions are context — they do not quietly override the board.

Execution-time agent safeguards

This is a new workstation rail (installed Aug 2026), not an old platform tradition. Before a coding agent runs a shell command, Cursor (and other supported tools) call a local guard called DCG. It checks the command against a small rule pack for risky Git and filesystem moves — for example git reset --hard or wiping a root/home tree — and can deny it in a few milliseconds.

The pack stays narrow on purpose. Normal solo work still goes through. Stricter “no direct push to main” rules stay off so day-to-day shipping is not blocked.

Security and environment governance

In public we keep it practical: least privilege, separate environments, secrets stay protected, people approve sensitive moves, and we review what we publish. The detailed evidence stays where it belongs.

Security Advisor findings can now feed the shared issue path so ERROR-level items are less likely to get stranded. Found ≠ fixed. Planned ≠ shipped. Shipped ≠ proven everywhere.

Evidence boundaries

This page does not claim launch readiness, commercial traction, compliance badges, full localization, accessibility certification, bulletproof security, full prompt coverage, unattended releases, or any metric. Tests prove what they cover — not the whole product.

If a gate did not run, we say NOT_RUN. That is not a fail, and it is not a pass.