NOS BBQ Docs
Initialize App →

Introduction

NOS BBQ 'O Matic is not a recipe app. It is a strictly typed, state-driven project management environment for coordinating group meat consumption.

The Problem

Standard cookout planning relies on unstructured, asynchronous data streams (WhatsApp groups). This leads to critical failure states, such as overlapping potato salads, untracked dietary violations, and unoptimized LKR budget splits. NOS resolves these merge conflicts before they happen.

System Architecture

Events are strictly controlled via a 5-phase state machine to prevent unauthorized scope creep.

1. The Blueprint (Setup)

The Host (Root User) defines the schema. 2 Apps, 3 Mains, 1 Dessert. Invites are generated.

2. Pitch Pool (Proposals Open)

Guests authenticate and submit parsed recipes into the temporary holding queue.

3. Admin Curation

The Host merges the best pitches into the main branch.

4. The Vibe Check

The group runs a QA pass. Any vetos require a text-based reason.

5. Finalized

The repo is locked. The budget is split. The grill is hot.

Live Pricing Telemetry

We don't guess costs. NOS routes every parsed ingredient through the live Sri Lankan Food Repo API. If the price of pork goes up, your dashboard budget updates in real-time.

Dietary Matrix Guard

Dietary requirements are not suggestions, they are system constraints. When a user marks "No Seafood" as a Dealbreaker, any proposed recipe containing shrimp will instantly trigger an AI-audited cross-contamination alert on the Host's dashboard.

The Veto Protocol

To prevent infinite loops of indecision, blind downvoting is disabled in the UI. If a guest executes a `VETO` on a proposed menu item, the schema strictly requires a non-null string payload explaining why (e.g., "I am deathly afraid of mayonnaise"). The Root User can then hot-swap the item to resolve the conflict.

Runtime Guide: Sausage Execution

A step-by-step guide to compiling a standard cylindrical protein payload without triggering a catastrophic memory (juice) leak.

1. Hardware Provisioning

Initialize the primary heat cluster (charcoal or gas). Establish a dual-zone thermal gradient. Target environment temperature for the direct heat zone: 180°C.

2. Payload Deployment

Deploy the sausage links to the indirect heat sector first. Ensure evenly distributed spacing to avoid thermal throttling.

3. Asynchronous Polling Loop

Initiate a runtime loop. Every `n` ticks (approx. 2 minutes), invoke the rotate() method using the Spatula middleware. This ensures uniform compilation of the Maillard reaction layer.

4. State Validation (QA)

Perform an internal state check using a thermal probe pointer. Assert that coreTemp >= 71°C.

WARNING: Do not pierce the outer casing prematurely with a fork process. This will cause an unrecoverable data loss event (all the juices will leak into the fire).

5. Graceful Shutdown

Terminate the heat process. Route the payload to a staging buffer (cutting board) for a 5-minute timeout. This allows internal pressure parameters to normalize before invoking the slice() function.