Vibecode Qooling
track this build5 steps, step by step0%NOT REALLY · don't bother
You can absolutely build a register: incidents in, corrective actions out, documents with version numbers, a dashboard that looks convincing. What you cannot build in a session is the thing anyone actually buys, which is an evidence trail an external ISO auditor will accept without argument, plus a mobile flow that a warehouse worker will actually use to report a near miss. Compliance software lives or dies on immutable audit logs, controlled document approval with signatures, retention rules and the fact that the vendor, not you, is the one explaining the system during a certification audit. A personal replacement also makes little sense here: this is inherently multi-user, and the value appears only when an entire site logs into it. Build the register if you want to understand your own processes; do not put your certification on top of it.
the project pack4 files · fastest path to a working personal build
You are building a lean indie version of Qooling. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # Qooling indie build ## Goal Build the smallest trustworthy replacement for the core Qooling workflow for one developer or a tiny team. ## Scope A local single-tenant QHSE register: log incidents and risks, attach corrective actions with owners and due dates, keep versioned controlled documents, and export a read-only evidence pack per standard clause. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - Auditor familiarity: external certification bodies have seen the commercial tools and know what to click - Immutable, tamper-evident audit logging and controlled document sign-off, which is the whole point of the category - A field-usable mobile app for incident and near-miss reporting with photos, offline - Prebuilt ISO 9001 / 14001 / 45001 / 27001 templates, risk matrices and clause mappings you would otherwise write from scratch - Someone else being accountable when the system fails during an audit or a serious incident investigation If those capabilities are essential, use Qooling instead of pretending the gap is solved. ===== AGENTS.md ===== # Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan ## Original build brief Build a self-hosted single-organisation QHSE register. This is a learning and internal-tracking tool, not a certification system, and it should say so on the dashboard. Stack, no substitutions: - Next.js (App Router) with TypeScript and Tailwind - SQLite via Prisma, file at ./data/qhse.db - Local disk storage for attachments under ./data/uploads - Single shared password from AUTH_PASSWORD in .env, cookie session, no user accounts, no OAuth, no cloud services, no telemetry Data model: - Person: name, email, site - Incident: type (incident, near miss, unsafe situation), date, site, reporter, description, severity 1-5, photos, status (open, investigating, closed) - Risk: hazard, activity, likelihood 1-5, impact 1-5, computed score, existing controls, owner, review date - Action: title, source (incident or risk or audit), owner, due date, status, closure note, closed date - Document: title, code, current version number, category, owner, review date, uploaded file per version, status (draft, approved, retired) - AuditLog: append-only table, every create and update writes actor, timestamp, entity, field-level before and after JSON. Never allow deletes on this table in application code. Screens: - Dashboard: open incidents, overdue actions, risks above score 15, documents past review date - List and detail views for each entity, with inline forms, no modals-only flows - Risk matrix view: 5x5 grid, colour by score, click a cell to see the risks in it - Evidence pack: pick a date range, get a single printable HTML page with all incidents, actions, risks and document versions in it, plus the relevant audit log rows In scope: seed script with two sites, five people, sample incidents and risks. CSV export for every list. Overdue highlighting. Out of scope: mobile app, offline capture, email notifications, e-signatures, multi-tenant, ISO clause libraries, permissions and roles. On the dashboard, print a fixed banner: "Internal tracking only. Not an audited compliance system." Include README with setup, .env.example with AUTH_PASSWORD, and a backup script that copies ./data to a timestamped folder. ## Required capabilities - A machine or small VPS to host it - File storage for document attachments and photos - Someone willing to define the clause-to-evidence mapping by hand - Backups you actually test, since this data is the audit ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden. ===== .env.example ===== # Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
You are building a lean indie version of Qooling. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # Qooling indie build ## Goal Build the smallest trustworthy replacement for the core Qooling workflow for one developer or a tiny team. ## Scope A local single-tenant QHSE register: log incidents and risks, attach corrective actions with owners and due dates, keep versioned controlled documents, and export a read-only evidence pack per standard clause. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - Auditor familiarity: external certification bodies have seen the commercial tools and know what to click - Immutable, tamper-evident audit logging and controlled document sign-off, which is the whole point of the category - A field-usable mobile app for incident and near-miss reporting with photos, offline - Prebuilt ISO 9001 / 14001 / 45001 / 27001 templates, risk matrices and clause mappings you would otherwise write from scratch - Someone else being accountable when the system fails during an audit or a serious incident investigation If those capabilities are essential, use Qooling instead of pretending the gap is solved. ===== AGENTS.md ===== # Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan ## Original build brief Build a self-hosted single-organisation QHSE register. This is a learning and internal-tracking tool, not a certification system, and it should say so on the dashboard. Stack, no substitutions: - Next.js (App Router) with TypeScript and Tailwind - SQLite via Prisma, file at ./data/qhse.db - Local disk storage for attachments under ./data/uploads - Single shared password from AUTH_PASSWORD in .env, cookie session, no user accounts, no OAuth, no cloud services, no telemetry Data model: - Person: name, email, site - Incident: type (incident, near miss, unsafe situation), date, site, reporter, description, severity 1-5, photos, status (open, investigating, closed) - Risk: hazard, activity, likelihood 1-5, impact 1-5, computed score, existing controls, owner, review date - Action: title, source (incident or risk or audit), owner, due date, status, closure note, closed date - Document: title, code, current version number, category, owner, review date, uploaded file per version, status (draft, approved, retired) - AuditLog: append-only table, every create and update writes actor, timestamp, entity, field-level before and after JSON. Never allow deletes on this table in application code. Screens: - Dashboard: open incidents, overdue actions, risks above score 15, documents past review date - List and detail views for each entity, with inline forms, no modals-only flows - Risk matrix view: 5x5 grid, colour by score, click a cell to see the risks in it - Evidence pack: pick a date range, get a single printable HTML page with all incidents, actions, risks and document versions in it, plus the relevant audit log rows In scope: seed script with two sites, five people, sample incidents and risks. CSV export for every list. Overdue highlighting. Out of scope: mobile app, offline capture, email notifications, e-signatures, multi-tenant, ISO clause libraries, permissions and roles. On the dashboard, print a fixed banner: "Internal tracking only. Not an audited compliance system." Include README with setup, .env.example with AUTH_PASSWORD, and a backup script that copies ./data to a timestamped folder. ## Required capabilities - A machine or small VPS to host it - File storage for document attachments and photos - Someone willing to define the clause-to-evidence mapping by hand - Backups you actually test, since this data is the audit ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden. ===== .env.example ===== # Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
You are building a production product version of Qooling. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== PRODUCT.md ===== # Qooling product brief ## Problem You can absolutely build a register: incidents in, corrective actions out, documents with version numbers, a dashboard that looks convincing. What you cannot build in a session is the thing anyone actually buys, which is an evidence trail an external ISO auditor will accept without argument, plus a mobile flow that a warehouse worker will actually use to report a near miss. Compliance software lives or dies on immutable audit logs, controlled document approval with signatures, retention rules and the fact that the vendor, not you, is the one explaining the system during a certification audit. A personal replacement also makes little sense here: this is inherently multi-user, and the value appears only when an entire site logs into it. Build the register if you want to understand your own processes; do not put your certification on top of it. ## Product outcome A local single-tenant QHSE register: log incidents and risks, attach corrective actions with owners and due dates, keep versioned controlled documents, and export a read-only evidence pack per standard clause. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - A machine or small VPS to host it - File storage for document attachments and photos - Someone willing to define the clause-to-evidence mapping by hand - Backups you actually test, since this data is the audit ## Explicit non-goals for v1 - Auditor familiarity: external certification bodies have seen the commercial tools and know what to click - Immutable, tamper-evident audit logging and controlled document sign-off, which is the whole point of the category - A field-usable mobile app for incident and near-miss reporting with photos, offline - Prebuilt ISO 9001 / 14001 / 45001 / 27001 templates, risk matrices and clause mappings you would otherwise write from scratch - Someone else being accountable when the system fails during an audit or a serious incident investigation ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees. ===== ARCHITECTURE.md ===== # Architecture ## Starting brief Build a self-hosted single-organisation QHSE register. This is a learning and internal-tracking tool, not a certification system, and it should say so on the dashboard. Stack, no substitutions: - Next.js (App Router) with TypeScript and Tailwind - SQLite via Prisma, file at ./data/qhse.db - Local disk storage for attachments under ./data/uploads - Single shared password from AUTH_PASSWORD in .env, cookie session, no user accounts, no OAuth, no cloud services, no telemetry Data model: - Person: name, email, site - Incident: type (incident, near miss, unsafe situation), date, site, reporter, description, severity 1-5, photos, status (open, investigating, closed) - Risk: hazard, activity, likelihood 1-5, impact 1-5, computed score, existing controls, owner, review date - Action: title, source (incident or risk or audit), owner, due date, status, closure note, closed date - Document: title, code, current version number, category, owner, review date, uploaded file per version, status (draft, approved, retired) - AuditLog: append-only table, every create and update writes actor, timestamp, entity, field-level before and after JSON. Never allow deletes on this table in application code. Screens: - Dashboard: open incidents, overdue actions, risks above score 15, documents past review date - List and detail views for each entity, with inline forms, no modals-only flows - Risk matrix view: 5x5 grid, colour by score, click a cell to see the risks in it - Evidence pack: pick a date range, get a single printable HTML page with all incidents, actions, risks and document versions in it, plus the relevant audit log rows In scope: seed script with two sites, five people, sample incidents and risks. CSV export for every list. Overdue highlighting. Out of scope: mobile app, offline capture, email notifications, e-signatures, multi-tenant, ISO clause libraries, permissions and roles. On the dashboard, print a fixed banner: "Internal tracking only. Not an audited compliance system." Include README with setup, .env.example with AUTH_PASSWORD, and a backup script that copies ./data to a timestamped folder. ## Boundaries Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors. ## Production baseline - Configuration: validated at startup with safe local defaults where possible. - Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts. - Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test. ## Decision records For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it. ===== AGENTS.md ===== # Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone. ===== MILESTONES.md ===== # Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations. ===== OPERATIONS.md ===== # Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted Qooling capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
README.md
# Qooling indie build ## Goal Build the smallest trustworthy replacement for the core Qooling workflow for one developer or a tiny team. ## Scope A local single-tenant QHSE register: log incidents and risks, attach corrective actions with owners and due dates, keep versioned controlled documents, and export a read-only evidence pack per standard clause. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - Auditor familiarity: external certification bodies have seen the commercial tools and know what to click - Immutable, tamper-evident audit logging and controlled document sign-off, which is the whole point of the category - A field-usable mobile app for incident and near-miss reporting with photos, offline - Prebuilt ISO 9001 / 14001 / 45001 / 27001 templates, risk matrices and clause mappings you would otherwise write from scratch - Someone else being accountable when the system fails during an audit or a serious incident investigation If those capabilities are essential, use Qooling instead of pretending the gap is solved.
AGENTS.md
# Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs".
BUILD_PLAN.md
# Build plan ## Original build brief Build a self-hosted single-organisation QHSE register. This is a learning and internal-tracking tool, not a certification system, and it should say so on the dashboard. Stack, no substitutions: - Next.js (App Router) with TypeScript and Tailwind - SQLite via Prisma, file at ./data/qhse.db - Local disk storage for attachments under ./data/uploads - Single shared password from AUTH_PASSWORD in .env, cookie session, no user accounts, no OAuth, no cloud services, no telemetry Data model: - Person: name, email, site - Incident: type (incident, near miss, unsafe situation), date, site, reporter, description, severity 1-5, photos, status (open, investigating, closed) - Risk: hazard, activity, likelihood 1-5, impact 1-5, computed score, existing controls, owner, review date - Action: title, source (incident or risk or audit), owner, due date, status, closure note, closed date - Document: title, code, current version number, category, owner, review date, uploaded file per version, status (draft, approved, retired) - AuditLog: append-only table, every create and update writes actor, timestamp, entity, field-level before and after JSON. Never allow deletes on this table in application code. Screens: - Dashboard: open incidents, overdue actions, risks above score 15, documents past review date - List and detail views for each entity, with inline forms, no modals-only flows - Risk matrix view: 5x5 grid, colour by score, click a cell to see the risks in it - Evidence pack: pick a date range, get a single printable HTML page with all incidents, actions, risks and document versions in it, plus the relevant audit log rows In scope: seed script with two sites, five people, sample incidents and risks. CSV export for every list. Overdue highlighting. Out of scope: mobile app, offline capture, email notifications, e-signatures, multi-tenant, ISO clause libraries, permissions and roles. On the dashboard, print a fixed banner: "Internal tracking only. Not an audited compliance system." Include README with setup, .env.example with AUTH_PASSWORD, and a backup script that copies ./data to a timestamped folder. ## Required capabilities - A machine or small VPS to host it - File storage for document attachments and photos - Someone willing to define the clause-to-evidence mapping by hand - Backups you actually test, since this data is the audit ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden.
.env.example
# Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
PRODUCT.md
# Qooling product brief ## Problem You can absolutely build a register: incidents in, corrective actions out, documents with version numbers, a dashboard that looks convincing. What you cannot build in a session is the thing anyone actually buys, which is an evidence trail an external ISO auditor will accept without argument, plus a mobile flow that a warehouse worker will actually use to report a near miss. Compliance software lives or dies on immutable audit logs, controlled document approval with signatures, retention rules and the fact that the vendor, not you, is the one explaining the system during a certification audit. A personal replacement also makes little sense here: this is inherently multi-user, and the value appears only when an entire site logs into it. Build the register if you want to understand your own processes; do not put your certification on top of it. ## Product outcome A local single-tenant QHSE register: log incidents and risks, attach corrective actions with owners and due dates, keep versioned controlled documents, and export a read-only evidence pack per standard clause. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - A machine or small VPS to host it - File storage for document attachments and photos - Someone willing to define the clause-to-evidence mapping by hand - Backups you actually test, since this data is the audit ## Explicit non-goals for v1 - Auditor familiarity: external certification bodies have seen the commercial tools and know what to click - Immutable, tamper-evident audit logging and controlled document sign-off, which is the whole point of the category - A field-usable mobile app for incident and near-miss reporting with photos, offline - Prebuilt ISO 9001 / 14001 / 45001 / 27001 templates, risk matrices and clause mappings you would otherwise write from scratch - Someone else being accountable when the system fails during an audit or a serious incident investigation ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees.
ARCHITECTURE.md
# Architecture ## Starting brief Build a self-hosted single-organisation QHSE register. This is a learning and internal-tracking tool, not a certification system, and it should say so on the dashboard. Stack, no substitutions: - Next.js (App Router) with TypeScript and Tailwind - SQLite via Prisma, file at ./data/qhse.db - Local disk storage for attachments under ./data/uploads - Single shared password from AUTH_PASSWORD in .env, cookie session, no user accounts, no OAuth, no cloud services, no telemetry Data model: - Person: name, email, site - Incident: type (incident, near miss, unsafe situation), date, site, reporter, description, severity 1-5, photos, status (open, investigating, closed) - Risk: hazard, activity, likelihood 1-5, impact 1-5, computed score, existing controls, owner, review date - Action: title, source (incident or risk or audit), owner, due date, status, closure note, closed date - Document: title, code, current version number, category, owner, review date, uploaded file per version, status (draft, approved, retired) - AuditLog: append-only table, every create and update writes actor, timestamp, entity, field-level before and after JSON. Never allow deletes on this table in application code. Screens: - Dashboard: open incidents, overdue actions, risks above score 15, documents past review date - List and detail views for each entity, with inline forms, no modals-only flows - Risk matrix view: 5x5 grid, colour by score, click a cell to see the risks in it - Evidence pack: pick a date range, get a single printable HTML page with all incidents, actions, risks and document versions in it, plus the relevant audit log rows In scope: seed script with two sites, five people, sample incidents and risks. CSV export for every list. Overdue highlighting. Out of scope: mobile app, offline capture, email notifications, e-signatures, multi-tenant, ISO clause libraries, permissions and roles. On the dashboard, print a fixed banner: "Internal tracking only. Not an audited compliance system." Include README with setup, .env.example with AUTH_PASSWORD, and a backup script that copies ./data to a timestamped folder. ## Boundaries Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors. ## Production baseline - Configuration: validated at startup with safe local defaults where possible. - Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts. - Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test. ## Decision records For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it.
AGENTS.md
# Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone.
MILESTONES.md
# Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations.
OPERATIONS.md
# Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted Qooling capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
$ choose a build depth, inspect the files, then open the complete pack in your agent · this prompt is generated from the build plan · improve it via PR
Because compliance is a social process, not a data model. Getting fifty people across three sites to report incidents, sign off documents and close corrective actions requires a tool that everyone tolerates, a mobile app that works in a loading bay, and a paper trail that survives an auditor picking a random clause and asking for proof. Companies also pay for someone to blame: if the certification audit goes badly, a vendor with ISO-shaped templates and support is a better story than a spreadsheet-plus-side-project maintained by whoever built it before they left.
xAuditor familiarity: external certification bodies have seen the commercial tools and know what to click
xImmutable, tamper-evident audit logging and controlled document sign-off, which is the whole point of the category
xA field-usable mobile app for incident and near-miss reporting with photos, offline
xPrebuilt ISO 9001 / 14001 / 45001 / 27001 templates, risk matrices and clause mappings you would otherwise write from scratch
xSomeone else being accountable when the system fails during an audit or a serious incident investigation
Nothing worth pointing at. That's why the prompt exists.
share on X ↗"I just replaced Qooling with one prompt"
Vibecode Qooling
Not really. Qooling's value is not the code: The moat is compliance-regulatory: auditor-accepted evidence trails, controlled document sign-off, and a vendor who stands behind them. See the honest breakdown above.
How much does Qooling cost?
Qooling's pricing is usage-based or varies by plan · Vendor pricing page lists Starter / Advanced / Enterprise with feature descriptions and Sign up buttons but no figures. Third-party directories (Capterra, GetApp) list Light EUR 12.00, Starter EUR 67.00, Advanced EUR 87.00 per user per month, Enterprise on request; those figures are unverified against the vendor and the tier names only partly match..
What do I lose by replacing Qooling?
Honestly: Auditor familiarity: external certification bodies have seen the commercial tools and know what to click; Immutable, tamper-evident audit logging and controlled document sign-off, which is the whole point of the category; A field-usable mobile app for incident and near-miss reporting with photos, offline; Prebuilt ISO 9001 / 14001 / 45001 / 27001 templates, risk matrices and clause mappings you would otherwise write from scratch; Someone else being accountable when the system fails during an audit or a serious incident investigation. If any of those are load-bearing for you, keep paying.
Is there an open-source alternative to Qooling?
No mature open-source alternative worth pointing at, which is exactly why the one-shot prompt on this page exists.