Don't let one AI decide alone.

Result from the council

Result from the council

Result from the council

Result from the council

Result from the council

Result from the council

1. critical

   The webhook processes the request body without checking the Stripe signature. Any external caller can therefore send forged `invoice.paid` or `customer.subscription.deleted` events and unlock or downgrade user accounts. The JSON parser also discards the unmodified raw body that Stripe signature verification requires.

   Fix: Use `express.raw({ type: 'application/json' })` for this route and call `stripe.webhooks.constructEvent(req.body, req.headers['stripe-signature'], webhookSecret)` before any processing. Make sure that no global JSON parser is already applied to this route beforehand; reject invalid signatures with 400.

   line 6 · found by gpt-5.6 · confirmed by gemini-3.6-flash

2. critical

   Missing validation of the Stripe webhook signature. An attacker can send arbitrary forged webhook events to this endpoint in order to set accounts to Pro without authorization or manipulate database entries.

   Fix: Use stripe.webhooks.constructEvent() with the Stripe webhook secret to verify the authenticity and integrity of every event.

   line 6 · found by gemini-3.6-flash · confirmed by gpt-5.6

3. critical

   SQL injection vulnerability due to direct concatenation of user input (event.data.object.customer) into the SQL query string.

   Fix: Use parameterized queries as in the previous statements: db.query('UPDATE users SET plan = $1 WHERE stripe_customer = $2', ['free', event.data.object.customer]).

   line 18 · found by gemini-3.6-flash · confirmed by gpt-5.6

4. critical

   The webhook never verifies the Stripe signature, and express.json() discards the raw body needed to do so. Anyone can POST a fake invoice.paid event and upgrade any account to pro for free.

   Fix: Use express.raw({ type: 'application/json' }) on this route and build the event with stripe.webhooks.constructEvent(req.body, req.headers['stripe-signature'], endpointSecret); reject the request on failure.

   line 6 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash

5. high

   The customer ID is inserted directly into an SQL statement. A value such as `' OR 1=1 --` can manipulate the WHERE clause and set all users to the free plan; depending on the database configuration, further SQL injections are possible.

   Fix: Fully parameterize the query: `UPDATE users SET plan = 'free' WHERE stripe_customer = $1` with `[event.data.object.customer]`. Additionally, authenticate the event via the Stripe signature.

   line 19 · found by gpt-5.6 · confirmed by gemini-3.6-flash

6. high

   There is no idempotency check. Stripe delivers webhooks at least once and retries them on timeouts or errors. The same `invoice.paid` event can therefore create identical payment entries multiple times.

   Fix: Store the Stripe event ID or invoice ID in the payment record, secure it with a UNIQUE constraint, and execute event processing together with the payment atomically as an insert/upsert. Acknowledge already processed events with 200 without repeating the business operation.

   line 14 · found by gpt-5.6 · confirmed by gemini-3.6-flash

7. high

   The `async` handler has no error forwarding. Express 4 does not automatically catch rejected promises from asynchronous route handlers. A DB error or an incomplete `invoice.paid` object therefore leads to an unhandled promise rejection and, under Node 20, can terminate the process instead of returning an error response in a controlled way.

   Fix: Wrap the handler in `try/catch` and pass errors on to `next(err)`, or use an async wrapper. Validate the input structure before accessing it and, on temporary processing errors, return a 5xx status in a controlled way so that Stripe redelivers.

   line 6 · found by gpt-5.6 · confirmed by gemini-3.6-flash

8. high

   Using express.json() for the webhook endpoint parses the body as JSON in advance. Stripe's signature verification, however, requires the unmodified raw body.

   Fix: Use express.raw({ type: 'application/json' }) instead of express.json() for the Stripe webhook route handler.

   line 6 · found by gemini-3.6-flash · confirmed by gpt-5.6

9. medium

   The user update and the payment entry are two independently committed database operations. If the INSERT fails after a successful UPDATE, the user gets the Pro plan even though no corresponding payment record exists.

   Fix: Execute both operations together with the idempotency marker in a single database transaction on the same client, and roll back completely on any error.

   line 12 · found by gpt-5.6 · confirmed by gemini-3.6-flash

10. medium

    The processing does not take into account that Stripe can deliver events out of their creation order. A delayed older `invoice.paid` can reset `paid_until`; a delayed `customer.subscription.deleted` can set a user who has since been reactivated back to `free`.

    Fix: Reconcile the current subscription state using stable Stripe IDs, for example by fetching it from Stripe, and persist state transitions or the timestamp of the last processed event. At a minimum, only ever update `paid_until` forward, and do not blindly apply deletion events to the current user state.

    line 12 · found by gpt-5.6 · confirmed by gemini-3.6-flash

11. medium

    `amount_paid / 100` assumes without checking that the currency has exactly two decimal places. That is wrong for JPY, for example. In addition, the currency is not stored alongside it, so the amount in the payment record has no unambiguous unit.

    Fix: Preferably store amounts unchanged in the smallest currency unit together with `invoice.currency`. If major currency units are needed, perform the conversion based on the respective currency exponents.

    line 15 · found by gpt-5.6 · confirmed by gemini-3.6-flash

12. medium

    Missing exception handling in an asynchronous Express 4 route. On a database error or missing fields, this leads to an unhandled promise rejection that can crash the application.

    Fix: Add a try-catch block and pass errors on to next(err), or use a utility such as express-async-handler.

    line 6 · found by gemini-3.6-flash · confirmed by gpt-5.6

13. medium

    No validation that invoice.metadata.userId is present. If the metadata or userId field is missing or undefined, the SQL queries fail or operate on invalid values.

    Fix: Before executing the database queries, explicitly check whether invoice.metadata and invoice.metadata.userId are present and valid.

    line 10 · found by gemini-3.6-flash · confirmed by gpt-5.6

14. medium

    Stripe retries webhooks and can deliver the same event more than once. Each delivery inserts another payment row, so revenue reports double-count.

    Fix: Store event.id (or the invoice id) with a unique constraint and skip events that were already processed.

    line 14 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash

Result from the council

1. critical

   The import is publicly reachable via `wp_ajax_nopriv_erp_import`; the authenticated hook also lacks capability and nonce checks. As a result, anonymous users or CSRF attacks can change product names, prices and stock levels.

   Fix: Remove the `nopriv` hook, check a suitable capability such as `manage_woocommerce` before any processing, and secure the request with `check_ajax_referer()`.

   line 3 · found by gpt-5.6 · confirmed by gemini-3.6-flash

2. critical

   The hook wp_ajax_nopriv_erp_import grants unauthenticated visitors access to the import function.

   Fix: Remove the nopriv hook and check the permission using current_user_can('manage_options').

   line 4 · found by gemini-3.6-flash · confirmed by gpt-5.6

3. critical

   The file path from $_POST['file'] is passed to file() unchecked, which enables path traversal and arbitrary file read (LFI).

   Fix: Handle file uploads via $_FILES, or strictly validate the input path against permitted directories (e.g. wp_upload_dir()).

   line 7 · found by gemini-3.6-flash · confirmed by gpt-5.6

4. critical

   SQL injection vulnerability, since $sku is inserted directly into the SQL query without sanitization.

   Fix: Use prepared statements with $wpdb->prepare().

   line 11 · found by gemini-3.6-flash · confirmed by gpt-5.6

5. critical

   The import is registered for wp_ajax_nopriv, and there is no capability check and no nonce. Any visitor can trigger it and overwrite prices, stock and product names.

   Fix: Remove the nopriv hook, check current_user_can('manage_woocommerce') and verify a nonce with check_ajax_referer() before doing anything.

   line 4 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash

6. high

   The path supplied by the client is passed to `file()` unchecked. This allows any readable local files and – depending on `allow_url_fopen` – external or internal URLs to be processed, which enables unwanted file access and blind SSRF.

   Fix: Do not accept freely chosen paths. Use only upload IDs known on the server side, check the canonical path against a fixed import directory, and allow only regular local CSV files.

   line 8 · found by gpt-5.6 · confirmed by gemini-3.6-flash

7. high

   `$sku` comes from the CSV and is interpolated directly into SQL. A SKU value containing SQL metacharacters can manipulate the query and, among other things, select any post ID as the update target.

   Fix: Parameterize the query with `$wpdb->prepare()`, for example with `meta_value = %s`, or use the WooCommerce function for looking up a product by SKU.

   line 13 · found by gpt-5.6 · confirmed by gemini-3.6-flash

8. high

   `file()` loads the entire input into memory, and `array_map()` additionally creates the complete parsed array. Without a size limit, a large or endless remote resource can exhaust memory, runtime and PHP workers; the public reachability makes this worse.

   Fix: Limit file size and line count, open the file locally with `fopen()` and process records in a streaming fashion via `fgetcsv()`. Additionally, use rate limits or a controlled background job.

   line 9 · found by gpt-5.6 · confirmed by gemini-3.6-flash

9. high

   Missing CSRF protection (nonce validation).

   Fix: Call check_ajax_referer() at the start of the function.

   line 6 · found by gemini-3.6-flash · confirmed by gpt-5.6

10. high

    The file path comes straight from the request and is passed to file(). An attacker can read any file the web server can read, or a remote URL if allow_url_fopen is on.

    Fix: Accept an uploaded file through wp_handle_upload() or read only from one fixed import directory; never take a path from the request.

    line 8 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash

11. medium

    It is assumed that every line has exactly four usable columns. Empty or corrupted lines yield missing values, which produces warnings and can unintentionally set name, price or stock to empty values.

    Fix: Before destructuring, check the column count and required fields, skip empty lines, and reject faulty records with a clear error message.

    line 12 · found by gpt-5.6 · confirmed by gemini-3.6-flash

12. medium

    The combination of `file()` and `str_getcsv()` parses each physical line separately. Valid CSV fields with embedded line breaks are therefore split into several faulty records.

    Fix: Read the CSV as a stream with `fgetcsv()`; this function handles multi-line, correctly quoted fields across record boundaries.

    line 9 · found by gpt-5.6 · confirmed by gemini-3.6-flash

13. medium

    Price and stock are stored unchecked as arbitrary strings. Non-numeric values, wrong decimal formats or impermissible stock levels can corrupt the product data and lead to inconsistent calculations.

    Fix: Validate price and stock before writing and normalize them with WooCommerce helpers such as `wc_format_decimal()` and `wc_stock_amount()`; reject values that are invalid or impermissible from a business standpoint.

    line 15 · found by gpt-5.6 · confirmed by gemini-3.6-flash

14. medium

    WooCommerce data is changed directly as post meta. As a result, related states such as `_stock_status`, product lookup tables and possibly caches are not reliably synchronized with the new prices and stock levels.

    Fix: Load the product via `wc_get_product()`, use the CRUD methods such as `set_regular_price()`, `set_price()` and `set_stock_quantity()`, set the stock status or `manage_stock` according to the business rules, and then call `save()`.

    line 15 · found by gpt-5.6 · confirmed by gemini-3.6-flash

15. medium

    The SKU lookup considers all post metadata and checks neither the post type nor whether the ID found is actually a WooCommerce product or variation. With duplicate or unrelated `_sku` metadata, a non-deterministic match is also updated.

    Fix: Use `wc_get_product_id_by_sku()` and then validate the result with `wc_get_product()` and the expected product type; treat duplicate SKUs as import errors.

    line 13 · found by gpt-5.6 · confirmed by gemini-3.6-flash

16. medium

    The return values of `update_post_meta()` and `wp_update_post()` are ignored. The import can partially fail or abort, but still reports the total number of lines read as successfully imported.

    Fix: Record success and failure per product, use `wp_update_post(..., true)`, count only records that were actually updated, and return a structured error response. Provide a resumable background job for large imports.

    line 15 · found by gpt-5.6 · confirmed by gemini-3.6-flash

17. medium

    For each CSV line, at least one lookup query and several individual write operations are executed synchronously. Large imports therefore cause many database round trips, can run into a request timeout and leave behind a catalog that is only partially updated.

    Fix: Run the import in limited batches as a background process, resolve SKUs collectively, and store progress and resume state.

    line 11 · found by gpt-5.6 · confirmed by gemini-3.6-flash

18. medium

    file() reads the entire file into memory at once, which leads to memory exhaustion errors with large CSV files.

    Fix: Stream the file line by line via fopen() and fgetcsv().

    line 8 · found by gemini-3.6-flash · confirmed by gpt-5.6

19. medium

    The array destructuring assumes that every line contains at least 4 elements; otherwise PHP warnings or uninitialized index errors occur.

    Fix: Before unpacking, check with count($row) whether enough columns are present.

    line 10 · found by gemini-3.6-flash · confirmed by gpt-5.6

20. medium

    Database queries and post updates are performed individually in a loop (N+1 problem), which slows execution time considerably.

    Fix: Split the import into batches and bundle queries/updates.

    line 11 · found by gemini-3.6-flash · confirmed by gpt-5.6

21. low

    Errors from `file()` are not checked. For a missing, unreadable or unsupported path, `file()` returns `false`, whereupon `array_map()` can throw a `TypeError` under current PHP versions.

    Fix: Explicitly check opening and reading, do not use PHP warnings as control flow, and on errors return an appropriate HTTP or `wp_send_json_error()` response.

    line 9 · found by gpt-5.6 · confirmed by gemini-3.6-flash

Result from the council

1. critical

   cakeId is interpolated directly into the SQL string. An attacker can inject SQL expressions or additional statements and thereby read or modify data, or put load on the database.

   Fix: Parameterize this query as well, e.g. `SELECT ... FROM cakes WHERE id = $1` with `[cakeId]`, and additionally check cakeId for the expected type.

   line 10 · found by gpt-5.6 · confirmed by gemini-3.6-flash

2. critical

   SQL injection vulnerability due to direct template-string interpolation of cakeId in the SQL query.

   Fix: Use a parameterized SQL query: pool.query('SELECT * FROM cakes WHERE id = $1', [cakeId]).

   line 9 · found by gemini-3.6-flash · confirmed by gpt-5.6

3. critical

   Client-side price manipulation is possible. The price is taken from req.body and directly stored and processed.

   Fix: Read the price server-side from the database (cake.rows[0].price) and do not trust the value sent by the client.

   line 8 · found by gemini-3.6-flash · confirmed by gpt-5.6

4. critical

   cakeId from the request body is interpolated into the SQL string: SQL injection.

   Fix: Use a parameterized query: SELECT * FROM cakes WHERE id = $1.

   line 10 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash

5. high

   The amount that is stored and passed to the payment flow comes entirely from `req.body.price`. A customer can enter a manipulated, negative or very small amount for any cake.

   Fix: Determine the price exclusively server-side from the selected cake or an immutable price version. Create a server-side payment session with this amount at the payment provider and verify the expected amount again server-side upon payment confirmation.

   line 16 · found by gpt-5.6 · confirmed by gemini-3.6-flash

6. high

   The order is created and a confirmation is sent before any successful payment has been verified. Aborted or deliberately unpaid transactions therefore appear as confirmed orders and can be generated at will.

   Fix: Create orders initially with a status such as `pending_payment`. Only switch to `paid` after an authenticated, idempotently processed payment provider notification, and then send the confirmation or trigger production or reservation.

   line 19 · found by gpt-5.6 · confirmed by gemini-3.6-flash

7. high

   Missing error handling in an async Express 4 route. Database or runtime errors lead to unhandled promise rejections.

   Fix: Use a try/catch block and forward errors with next(err), or use a package such as express-async-errors.

   line 8 · found by gemini-3.6-flash · confirmed by gpt-5.6

8. high

   The amount is taken from the client (price in the request body), so a customer can set their own price.

   Fix: Read the price from the cakes row on the server and ignore any client value.

   line 15 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash

9. medium

   The async handler has no error forwarding. Express 4 does not automatically handle rejected promises from `async` handlers; database or synchronous mail errors can therefore lead to unanswered requests and unhandled rejections.

   Fix: Wrap the handler in `try/catch` and pass errors on to `next(err)`, or use an established async wrapper. Additionally, configure central error handling.

   line 7 · found by gpt-5.6 · confirmed by gemini-3.6-flash

10. medium

    The result of `sendConfirmation` is neither awaited nor otherwise handled for errors. A promise rejection can remain unhandled; at the same time, the client already receives a success response even though sending the mail may have failed.

    Fix: Perform the sending after confirmed payment via a persistent outbox or job queue with retries. At a minimum, await the promise and log or handle errors in a controlled way.

    line 19 · found by gpt-5.6 · confirmed by gemini-3.6-flash

11. medium

    There is no idempotency protection. Browser retries, double clicks or network retries each create a new order and possibly multiple confirmations or payment attempts.

    Fix: Accept an idempotency key or checkout session ID, secure it with a unique constraint, and return the already existing order on retries.

    line 13 · found by gpt-5.6 · confirmed by gemini-3.6-flash

12. medium

    pickupDate, name, email, price and note are processed without business or syntactic validation. This means, for example, past or invalid pickup dates, missing customer data and unsuitable field values can be stored; database errors also only occur late and in an uncontrolled way.

    Fix: Use a request schema with types, required fields, length limits and normalized formats. Check pickup dates against time zone, lead time and permissible opening-hours or capacity rules; do not accept the price as client input.

    line 8 · found by gpt-5.6 · confirmed by gemini-3.6-flash

13. medium

    The async call to sendConfirmation is neither awaited nor caught for errors.

    Fix: Put await before sendConfirmation and handle possible errors when sending the email.

    line 17 · found by gemini-3.6-flash · confirmed by gpt-5.6

14. low

    Incomplete input validation for fields such as email, pickupDate, name and note.

    Fix: Implement schema validation (e.g. with Zod or express-validator) before processing the request data.

    line 8 · found by gemini-3.6-flash · confirmed by gpt-5.6

Result from the council

1. critical

   Missing database transaction and row lock. With parallel requests, race conditions (e.g. double spending of credit) and incomplete updates in the event of an error can occur.

   Fix: Use a client from the pool with BEGIN/COMMIT, and use SELECT FOR UPDATE to lock and update rows atomically.

   line 5 · found by gemini-3.6-flash · confirmed by gpt-5.6

2. high

   The three related updates are not executed in a database transaction. If debiting the customer credit or the status change fails, the invoice may already have been reduced without the credit having been correctly charged or the status having been set.

   Fix: Obtain a dedicated client from the pool and execute all checks and updates between BEGIN and COMMIT; use ROLLBACK on any error.

   line 11 · found by gpt-5.6 · confirmed by gemini-3.6-flash

3. high

   The invoice is first read and later overwritten with an absolute calculated value. Two parallel calls can read the same starting value and then overwrite each other; both credit debits still take place, while only one credit remains fully visible in the invoice.

   Fix: Lock the affected invoice within the same transaction with SELECT ... FOR UPDATE, or change the amount atomically via UPDATE ... SET total_cents = total_cents - $1 with suitable conditions.

   line 4 · found by gpt-5.6 · confirmed by gemini-3.6-flash

4. high

   Checking and debiting the customer credit are not atomic. Parallel calls can both see the same available coverage and then reduce the credit below zero.

   Fix: Lock the customer record transactionally or use a conditional UPDATE, such as UPDATE customers SET credit_cents = credit_cents - $1 WHERE id = $2 AND credit_cents >= $1 RETURNING credit_cents, and require exactly one returned row.

   line 8 · found by gpt-5.6 · confirmed by gemini-3.6-flash

5. high

   It is not checked whether the invoice belongs to the specified customer. As a result, a customer's credit can be applied to any invoice identified via invoiceId.

   Fix: Query and update invoice and customer via the ownership relationship, for example with WHERE invoices.id = $1 AND invoices.customer_id = $2; abort if there is no match.

   line 4 · found by gpt-5.6 · confirmed by gemini-3.6-flash

6. high

   The credit to be applied is not capped at the open invoice amount. If creditCents is greater than total_cents, a negative invoice amount is stored and excess customer credit is consumed.

   Fix: Only allow amounts up to the open invoice value, or determine the amount actually used as min(creditCents, total_cents) and debit only this amount from the customer credit.

   line 10 · found by gpt-5.6 · confirmed by gemini-3.6-flash

7. high

   Negative, non-integer or not safely representable values are not rejected. In particular, a negative creditCents value increases the invoice amount and at the same time, through the subtraction of a negative value, the customer credit.

   Fix: Require Number.isSafeInteger(creditCents) && creditCents > 0 before any database access; treat monetary amounts consistently as integer cent values.

   line 8 · found by gpt-5.6 · confirmed by gemini-3.6-flash

8. high

   The invoice status that is read is completely ignored. Credit can therefore also be applied to invoices that are already paid, canceled or otherwise no longer modifiable; an already paid invoice can become negative as a result.

   Fix: Explicitly define the permitted starting statuses and check them atomically in the UPDATE condition, for example AND status = 'open'. If there is no match, abort the operation.

   line 4 · found by gpt-5.6 · confirmed by gemini-3.6-flash

9. high

   Access to balance.rows[0] and inv.rows[0] without a prior check. If a customer or invoice is not found, the application crashes with an unhandled TypeError.

   Fix: Check inv.rows.length and balance.rows.length before access and throw an explicit error message.

   line 8 · found by gemini-3.6-flash · confirmed by gpt-5.6

10. high

    Missing validation of creditCents for negative values. A negative value bypasses the check (creditCents > available) and leads to incorrect credit or invoice adjustments.

    Fix: Make sure that creditCents is a positive integer greater than 0.

    line 9 · found by gemini-3.6-flash · confirmed by gpt-5.6

11. high

    The reads and the three updates run outside a transaction and without row locks. Two concurrent calls can both pass the credit check and spend the same credit twice, and a crash between the updates leaves invoice and credit balance inconsistent.

    Fix: Run everything in one transaction on a single client, lock the rows with SELECT ... FOR UPDATE, and commit only after all updates succeed.

    line 5 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash

12. high

    The function never checks that the invoice belongs to the customer or that it is still open. Credit from one customer can be applied to another customer's invoice, or to an invoice that is already paid.

    Fix: Select the invoice with WHERE id = $1 AND customer_id = $2 AND status = 'open' and fail if no row comes back.

    line 11 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash

13. medium

    The existence of the invoice and the customer is not checked. For unknown IDs, accessing rows[0] leads to runtime errors instead of a controlled business error; in addition, both queries are executed unnecessarily before this becomes apparent.

    Fix: Check rowCount or rows.length for both queries and raise a defined not-found error; integrate the check into the transaction and, if possible, into a relational query.

    line 4 · found by gpt-5.6 · confirmed by gemini-3.6-flash

14. medium

    The return value corresponds neither to the stored cent amount nor to a simple conversion into the main currency: it adds a flat 19 percent and uses floating-point arithmetic. As a result, the caller may receive a value that differs, in tax and rounding terms, from the remaining invoice balance actually stored.

    Fix: Return the remaining amount in cents unchanged, or define a clearly typed return value. If a tax calculation is required for business reasons, take the tax rate and rounding rule from the invoice data and calculate with integer or decimal arithmetic.

    line 17 · found by gpt-5.6 · confirmed by gemini-3.6-flash

15. medium

    Use of IEEE 754 floating-point arithmetic (newTotal * 1.19 / 100) for financial calculations. This leads to precision and rounding errors.

    Fix: Calculate consistently in cents with integers (BigInt/Math.round), or use a library for exact decimal arithmetic.

    line 18 · found by gemini-3.6-flash · confirmed by gpt-5.6

16. low

    A separate UPDATE command for the invoice status causes unnecessary database round trips.

    Fix: Combine the update of total_cents and status into a single UPDATE query.

    line 12 · found by gemini-3.6-flash · confirmed by gpt-5.6

Result from the council

1. high

   The default inner join removes all record_id values that occur in only one of the two files. Kappa and conflicts are therefore calculated only for the intersection, without making missing screenings visible. At the same time, “Records screened” in line 18 reports the length of a instead of the intersection actually analyzed.

   Fix: Use an outer join with a merge indicator, compare the ID sets explicitly, and report missing decisions separately or treat them as data errors. For each metric, output the denominator actually used.

   line 7 · found by gpt-5.6 · confirmed by gemini-3.6-flash

2. high

   The uniqueness of record_id is not checked. Duplicate IDs lead to a many-to-many Cartesian product during the merge and weight individual studies multiple times, which distorts agreement, prevalences, kappa and output files.

   Fix: Before the merge, check record_id in both files for non-nullness and uniqueness, and abort on duplicates. Additionally, use merge(..., validate='one_to_one').

   line 7 · found by gpt-5.6 · confirmed by gemini-3.6-flash

3. high

   Decision values are not validated. Missing values, typos, upper/lower case or additional categories are implicitly treated like “exclude” when the include prevalence is calculated, while the observed agreement compares exact values. The calculation therefore no longer corresponds to a binary Cohen's kappa and can produce contradictory results.

   Fix: Normalize decision in a controlled way before the analysis and ensure that every value is exactly 'include' or 'exclude'. Handle missing or unknown values separately as data errors or incomplete screening.

   line 9 · found by gpt-5.6 · confirmed by gemini-3.6-flash

4. high

   excluded contains all records excluded by screener A, including conflicts in which screener B decided “include”. Such records are therefore written to both excluded.csv and conflicts.csv. If excluded.csv is meant to represent the finally excluded hits, unresolved conflicts can be wrongly removed from the review.

   Fix: Without a documented precedence rule, select only matching exclusions, i.e. (decision_a == 'exclude') & (decision_b == 'exclude'). Keep conflicts exclusively in conflicts.csv until a consensus decision has been made.

   line 16 · found by gpt-5.6 · confirmed by gemini-3.6-flash

5. high

   Incorrect filtering of the excluded studies: 'excluded' takes into account only the decision of screener A ('merged.decision_a == "exclude"'). If there is a conflict (screener A excludes, screener B includes), the study is wrongly counted as excluded.

   Fix: Only export exclusions if both screeners have consistently chosen 'exclude' (e.g. '(merged.decision_a == "exclude") & (merged.decision_b == "exclude")'), or wait for the conflict to be resolved.

   line 16 · found by gemini-3.6-flash · confirmed by gpt-5.6

6. high

   excluded.csv contains every record screener A excluded, including conflicts where screener B included it. Those records are dropped before the conflict discussion, which is exactly the false exclusion the protocol must avoid.

   Fix: Exclude only records both screeners excluded: merged[(merged.decision_a == 'exclude') & (merged.decision_b == 'exclude')]; send every conflict to resolution first.

   line 16 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash

7. medium

   If both screeners use only the same category, expected equals 1 and the denominator of kappa equals 0. The result becomes NaN or can produce a division-by-zero warning; the formatted output “nan” does not explain that kappa is mathematically undefined. An empty analyzed intersection also leads to meaningless NaN metrics.

   Fix: Before the division, check whether there are any paired valid decisions at all and whether 1 - expected is greater than 0. In degenerate cases, explicitly report kappa as “not defined” and report the underlying frequencies.

   line 13 · found by gpt-5.6 · confirmed by gemini-3.6-flash

8. medium

   Possible division by zero in Cohen's kappa if the expected chance value 'expected' equals 1 (e.g. if both screeners choose the same category for 100% of the records).

   Fix: Before the calculation, catch whether '1 - expected == 0' and in that case assign a defined value (e.g. 1.0 or NaN).

   line 12 · found by gemini-3.6-flash · confirmed by gpt-5.6

9. medium

   Silent discarding of records by the default inner join. If screener A and screener B have rated different sets of 'record_id's, discrepancies in the processed studies are not reported. In addition, 'len(a)' in the console output then does not correspond to the number of studies actually matched.

   Fix: Check whether 'len(a) == len(b) == len(merged)' holds, or perform an outer join to explicitly show incompletely rated records.

   line 7 · found by gemini-3.6-flash · confirmed by gpt-5.6

10. medium

    The inner merge silently drops records that only one screener has decided, and the printed count uses len(a). Unscreened records disappear from both the agreement and the PRISMA numbers.

    Fix: Merge with how='outer', indicator=True, and fail or report when any record lacks a decision from either screener.

    line 7 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash

11. low

    Missing input sanitization and handling of missing values in the 'decision' column. Upper/lower case, whitespace or NaN values lead to incorrect comparisons.

    Fix: Clean column values before the comparison (e.g. with '.str.strip().str.lower()') and ensure data type safety.

    line 9 · found by gemini-3.6-flash · confirmed by gpt-5.6

Result from the council

1. 1

   Replace the 14-day clock with three real sends

   gpt-5.6 · rule breaker · 18/20 points (9 + 9)

   Test a trial that ends after three sent invoices or payment chases instead of after 14 calendar days. This deliberately breaks the soft assumption that a time-limited trial is appropriate: freelancers may not invoice during an arbitrary two-week window, so the current trial can expire before the product proves its value. Keep the $19 monthly plan unchanged and compare activation-to-paid conversion by cohort.

2. 2

   Complete the task inside the article

   gpt-5.6 · within brief · 17/20 points (9 + 8)

   Embed a tiny invoice builder in “how to write a freelance invoice”: readers enter client, amount, due date, and payment terms, then see a finished preview. “Send or save this invoice” creates a trial with those details already loaded, eliminating the gap between learning and doing. Build it in weekly slices capped at three hours, then keep maintenance near zero.

3. 3

   Turn the chase article into a recovery console

   gpt-5.6 · neighbor · 17/20 points (9 + 8)

   As a one-step substitution of the embedded invoice builder, let readers enter an overdue amount and due date to generate a dated three-message chase sequence. Starting a trial saves the debtor, schedules the messages, and opens the first draft ready to send. This preserves the strongest pattern—useful output before signup—while matching the second post’s intent.

4. 4

   Put the conversion moment on the debtor’s calendar

   gpt-5.6 · within brief · 16/20 points (7 + 9)

   Offer a generated .ics file in the late-payment article with reminders for the due date and escalating follow-ups on days 1, 7, and 14. Each calendar event contains a deep link that opens the relevant chase workflow with the dates prefilled, bringing the reader back when the pain is real rather than while they are merely researching. It requires no email capture and can run unattended.

5. 5

   Permanently free plan for one client instead of a trial period

   gemini-3.6-flash · rule breaker · 16/20 points (8 + 8)

   This idea breaks the soft constraint of the 14-day trial and replaces it with a freemium plan for exactly one active client. Freelancers use the product permanently free of charge for their first client and upgrade seamlessly to the 19-dollar flat rate as soon as a second client is added.

6. 6

   Route readers by immediate problem

   gpt-5.6 · within brief · 14/20 points (8 + 6)

   Replace generic trial banners with three inline choices such as “I need my first invoice,” “I invoice repeatedly,” and “A client is already late.” Each choice opens a matching onboarding state rather than the same homepage, and article section IDs can preselect sensible defaults. Measure completed trial activation, not just CTA clicks, and test one route per week.

7. 7

   Publish three forensic invoice makeovers

   gpt-5.6 · within brief · 14/20 points (8 + 6)

   With permission, turn three anonymized customer invoices into static before-and-after case studies showing exactly what changed and why. Insert each makeover beside the relevant advice in the ranking post, with a CTA that opens the same corrected structure as an editable trial template. Specific evidence from a small customer base can be more credible than broad testimonials.

8. 8

   Let readers carry progress between both posts

   gpt-5.6 · within brief · 14/20 points (7 + 7)

   Store a reader’s chosen currency, invoice stage, and due date locally in the browser, then use that state when they move between the two articles. Someone who created an invoice plan can later see a contextual prompt such as “Your invoice is now 3 days late—open the prepared follow-up,” with trial onboarding prefilled. This creates a lightweight two-post journey without requiring an account or ongoing content production.

9. 9

   Interactive reminder letter configurator

   gemini-3.6-flash · within brief · 14/20 points (7 + 7)

   Add a generator for escalating payment reminder letters to the article on following up on overdue payments. After the text is entered, the template is generated, combined with the CTA to set up automatic payment reminders for future invoices in the trial account.

10. 10

    Instant-send magic link without prior registration

    gemini-3.6-flash · neighbor · 14/20 points (8 + 6)

    Mutation of the in-content generator: the reader enters invoice details directly in the blog article and clicks on Send invoice right now. In the background, the system seamlessly creates a trial account and sends the email directly; the password is only set afterwards.

11. 11

    Live invoice generator directly in the blog article

    gemini-3.6-flash · within brief · 13/20 points (6 + 7)

    Embed a simple, interactive form tool directly in the article on writing invoices. Readers type in their invoice details and can download the finished PDF immediately and free of charge. A prominent button offers to send the invoice digitally with one click and to track the payment status in the 14-day trial account.

12. 12

    One-time pay-per-use reminder instead of a monthly subscription

    gemini-3.6-flash · rule breaker · 13/20 points (6 + 7)

    This idea breaks the soft constraint of the pure SaaS subscription model at 19 dollars per month. For a one-time fee of 5 dollars, readers of the late-payment article can have a legally sound reminder letter including a tracking link sent, with the fee fully credited if they later take out a subscription.

13. 13

    Template that opens in the tool

    claude · within brief · 11/20 points (6 + 5)

    Offer the invoice template from the post as a ready-to-use invoice in the tool: one click opens a pre-filled trial account instead of a file download.

14. 14

    Problem-specific exit intent with an automated email sequence

    gemini-3.6-flash · within brief · 8/20 points (4 + 4)

    Implement an exit-intent popup on the late-payment article that offers an emergency email template for late-paying clients in exchange for an email address. An automated three-part email sequence then passively explains how automated workflows reduce late payments, and links to the trial account.

Result from the council

1. 1

   Budget break: operations before launch gloss

   gpt-5.6 · rule breaker · 18/20 points (9 + 9)

   This idea deliberately breaks the soft constraint of the 25,000 EUR rebuild budget: the offer is, for example, 22,000 EUR for a deliberately lean launch plus 12,000 EUR for a binding first year of operation. In return, nice-to-have features are dropped from the initial project; instead, import hardening, restore drills, monitoring and monthly improvements are funded. The higher total volume pays off because the client is not once again buying a seemingly finished shop whose real operating costs only become visible after launch; all access credentials, data and work results remain transferable at any time.

2. 2

   CSV Product Gatekeeper

   gpt-5.6 · within brief · 17/20 points (9 + 8)

   Before every ERP import, an automated pipeline checks the CSV for missing prices, duplicates, invalid variants, image errors, DACH tax logic and suspicious stock changes. The monthly retainer covers rule maintenance, import monitoring and an understandable error report for the three employees. This turns technical maintenance into a direct business benefit: fewer wrong products, follow-up questions and abandoned purchases.

3. 3

   Reliability Dividend

   gpt-5.6 · within brief · 17/20 points (8 + 9)

   The client pays a moderate base fee for monitoring and maintenance; an additional quarterly amount only becomes due if agreed reliability targets such as successful imports, tested restoration and response times have been met. Avoidable outages caused by the agency generate service credits instead of billable emergency hours. This model aligns the economic incentives with prevention and takes away the client's fear that the agency profits from problems.

4. 4

   Exit-ready Care Charter

   gpt-5.6 · within brief · 16/20 points (9 + 7)

   The retainer is deliberately sold as an anti-lock-in product: monitoring, updates, backups, security checks and two small changes per month for about 1,200–1,500 EUR. All accounts are held by the client, and code and import scripts live in the client's repository; every month the client also receives documentation, a data export and a handover pack that lets them cancel at any time. This way the client pays for demonstrable operability instead of dependency.

5. 5

   Seasonal release train

   gpt-5.6 · within brief · 16/20 points (8 + 8)

   Instead of arbitrary support tickets, there are four plannable commerce releases per year, for example for garden furniture, end of summer, Black Week and Christmas. Included in the retainer for each release are a small UX or merchandising package, regression tests and the technical maintenance in between. This gives the client visible ongoing development and keeps the effort bundleable for the four-person agency.

6. 6

   The quarterly escape test

   gpt-5.6 · within brief · 16/20 points (9 + 7)

   Once a quarter, the agency provides a complete export of product, customer, order and content data and carries out a documented restart in a neutral test environment. What the client pays for, of all things, is the regularly proven exit: the access list, restore log and handover manual belong to the client. The hard no-lock-in criterion thus turns from an objection into an unusual selling point for the retainer.

7. 7

   Care Charter plus growth exchange

   gpt-5.6 · neighbor · 16/20 points (8 + 8)

   As a small mutation of the Exit-ready Care Charter, the included change hours are not fixed in advance but shifted monthly between operations, data quality and conversion improvements; unused volume carries over for at most one quarter. A joint 30-minute board decides how they are used, based on risks and revenue opportunities. The retainer stays exit-ready but feels less like insurance and more like a flexible external digital team.

8. 8

   ERP sync & catalog safety retainer

   gemini-3.6-flash · within brief · 13/20 points (7 + 6)

   The agency takes over the continuous monitoring and maintenance of the interface between the local ERP CSV and the online shop. Faulty data imports, missing furniture variants or wrong prices are caught automatically before they go live. This completely takes the operational burden of data maintenance off the client's 3-person team.

9. 9

   AI-powered product data enrichment flat rate

   gemini-3.6-flash · neighbor · 13/20 points (6 + 7)

   Mutation of the ERP interface idea: the agency not only maintains the CSV import but also uses AI scripts to automatically enrich the raw data with structured attributes, SEO copy and DACH-specific delivery time notes. This saves the client manual maintenance effort and increases visibility in the furniture market without additional agency staffing.

10. 10

    CI/CD-based visual regression maintenance contract

    gemini-3.6-flash · within brief · 12/20 points (6 + 6)

    Instead of risky live updates, the agency sets up a staging pipeline that automatically checks monthly plugin updates visually and functionally. The client receives a monthly transparency report and guaranteed response times for security vulnerabilities. This guarantees absolute stability without the previous emergencies.

11. 11

    Quarterly conversion & UX polishing

    gemini-3.6-flash · within brief · 11/20 points (6 + 5)

    In addition to basic maintenance, the retainer includes fixed hour quotas for optimizing checkout functions and furniture variant displays. The agency analyzes user behavior in the DACH region every month and implements high-return adjustments. This turns the retainer from a pure cost factor into a revenue driver.

12. 12

    Safe update & instant rollback guarantee

    gemini-3.6-flash · neighbor · 11/20 points (5 + 6)

    Mutation of the CI/CD maintenance contract: the retainer focuses purely on a guaranteed zero-downtime SLA with automated snapshot restoration within 15 minutes in the event of incidents. This directly addresses the client's fear after the two security incidents, with minimal ongoing manual effort.

13. 13

    Revenue-share growth package instead of a fixed budget

    gemini-3.6-flash · rule breaker · 9/20 points (4 + 5)

    Breaks the soft assumption of a rigid one-time rebuild budget of 25,000 EUR: the rebuild costs are reduced to 10,000 EUR, coupled with a monthly retainer with a small share of the additional revenue. This pays off because the client lowers its investment risk and the agency participates directly in the growth of the 1.2 million EUR shop.

14. 14

    Headless-Architecture Care Service

    gemini-3.6-flash · rule breaker · 7/20 points (3 + 4)

    Breaks the soft constraint of a classic monolith setup (such as standard WooCommerce): the frontend is decoupled from the backend, so plugin security vulnerabilities can no longer attack the website directly. This pays off because emergencies are structurally eliminated and the client remains portable at any time thanks to an open-source stack and full Git access.

15. 15

    Monthly one-page care report

    claude · within brief · 6/20 points (4 + 2)

    A one-page monthly report with uptime, page speed, updates applied and incidents prevented, so the client sees what the retainer pays for.

Result from the council

1. 1

   The annual birthday autopilot

   gpt-5.6 · within brief · 18/20 points (9 + 9)

   At checkout, customers can voluntarily leave the occasion and month for a reminder the following year. An automated email 21 days beforehand leads to the pre-filled order page; this way every order builds a future order, without ongoing customer acquisition and with clean consent.

2. 2

   Real cake slots instead of generic posts

   gpt-5.6 · within brief · 17/20 points (9 + 8)

   The order page shows the actual remaining production slots for the next four weeks, such as “Still 2 custom cakes available for Saturday”. A weekly Google Business post links directly to this view; updating it and posting together take at most 20 minutes and create credible urgency without discounts.

3. 3

   The cake travels as its own advertising medium

   gpt-5.6 · within brief · 16/20 points (8 + 8)

   Every picked-up cake gets a small card saying “Reorder or customize this cake” and a QR code for the matching variant. The card is displayed visibly when the cake is cut, so that precisely the birthday or wedding guests present discover the way to order; a card set created once causes almost no weekly effort.

4. 4

   One-time cake consultation hour at launch

   gpt-5.6 · rule breaker · 16/20 points (8 + 8)

   On the first Saturday after launch there is an open cake consultation hour for four hours: guests choose flavor and style from sample cards and then place their order themselves via QR codes laid out for them. This deliberately breaks the soft constraint of at most two hours of effort in that week; the extra effort pays off because real orders, observed usability problems and reusable photos and customer questions are all produced at the same time — without additional staff or paid advertising.

5. 5

   Occasion partners instead of influencers

   gpt-5.6 · within brief · 15/20 points (8 + 7)

   Children's play venues, photographers, florists, wedding venues and clubhouses each receive a small QR stand that leads to a cake selection preconfigured for their occasion. In return, the bakery names these partners on a local recommendations page; five targeted requests per month are enough, and commissions and paid reach are eliminated.

6. 6

   Cake rota for offices and clubs

   gpt-5.6 · within brief · 15/20 points (8 + 7)

   Local offices, practices and clubs get a page where several birthdays or recurring dates can be collected and prepaid one after another. Quarterly rotas, once set up, turn individual occasions into plannable series orders; outreach can be limited to two organizations per week.

7. 7

   Hybrid cake consultation at the counter tablet

   gemini-3.6-flash · rule breaker · 14/20 points (7 + 7)

   Deliberately breaks the soft constraint 'online ordering only' by offering 1 hour of in-store consultation on Fridays, during which orders are entered together on a tablet. It pays off because undecided and older customers are gradually introduced to the new online system.

8. 8

   Reviews become a decision aid

   gpt-5.6 · neighbor · 13/20 points (7 + 6)

   As a small recombination of the strongest existing material, twelve meaningful sentences from the 120 Google reviews are paired with matching cake styles, each with a direct order link. This way the 4.7 stars are not just shown as a trust signal but help with product selection; after one-time setup the page is largely maintenance-free.

9. 9

   Sample-cake displays with shop deep links

   gemini-3.6-flash · neighbor · 13/20 points (6 + 7)

   A physical photo gallery of the most beautiful cakes in the salesroom includes a specific QR code with each picture that opens exactly this cake model preselected in the online shop. Mutation of idea 1: linking the in-store display with a direct deep link in the shop.

10. 10

    Google profile optimization & automated review links

    gemini-3.6-flash · within brief · 12/20 points (6 + 6)

    The strong Google profile (4.7 stars) is supplemented with the official 'Order online' button and updated weekly with a photo of current cakes. On pickup, customers receive a template by email with a link to the review and reorder page. Takes under 30 minutes per week.

11. 11

    QR code teaser on receipts & bread bags

    gemini-3.6-flash · within brief · 11/20 points (6 + 5)

    An eye-catching QR code is printed on every receipt and on packaging, leading directly to the online cake configurator ('Plan your dream cake for your celebration online'). This converts daily walk-in customers into digital pre-orderers without extra effort at the counter.

12. 12

    B2B partnership with local event venues

    gemini-3.6-flash · within brief · 11/20 points (6 + 5)

    Stands and flyers with a direct booking code for the website are placed at local restaurants, event barns and wedding planners. Celebrating customers book their cake directly online, while the venue receives a small expense allowance or a referral in return.

13. 13

    Daycare & school birthday calendar

    gemini-3.6-flash · neighbor · 10/20 points (4 + 6)

    Cooperation with local kindergartens via info flyers for parent councils that contain a fixed discount code for children's themed cakes. Mutation of idea 3: instead of general B2B partners, the high-frequency occasion of children's birthdays is specifically addressed in an automated way.

14. 14

    Monthly mini workshop for decorated cakes

    gemini-3.6-flash · rule breaker · 10/20 points (4 + 6)

    Deliberately breaks the soft constraint 'maximum 2 hours of time per week', since a 4-hour workshop takes place once a month. It pays off because participants act as brand ambassadors, create enthusiastic social media content and are guaranteed to place follow-up orders via the online shop.

15. 15

    Order link on every cake box

    claude · within brief · 8/20 points (4 + 4)

    Print a QR code to the ordering page on the cake boxes and receipts, so every customer who already buys a cake can reorder for the next birthday without calling.

Kirat's note to Claude: Best rule_breaker idea only at rank 4: "One-time cake consultation hour at launch" — it deliberately breaks a soft constraint. Steelman it once before discarding it.

Result from the council

1. 1

   Database firewall around billing tables

   gpt-5.6 · within brief · 17/20 points (9 + 8)

   Create separate Postgres roles for the monolith’s billing and non-billing code paths, then revoke direct writes to billing tables from the general application role. Route all mutations through a small set of reviewed stored procedures or transaction functions, adding temporary audit logging first to discover and migrate callers without stopping weekly feature work.

2. 2

   Executable financial invariants

   gpt-5.6 · within brief · 17/20 points (9 + 8)

   Encode a short list of invariants—such as immutable finalized invoices, balanced ledger entries, idempotent charge creation, and valid state transitions—as database constraints where safe and scheduled production probes where not. Run the same probes against anonymized production-shaped fixtures in CI, turning incident knowledge into permanent tripwires rather than broad test expansion.

3. 3

   Incident replay as a release gauntlet

   gpt-5.6 · within brief · 17/20 points (9 + 8)

   Convert the five billing incidents into deterministic replay scenarios using captured query shapes and sanitized rows, then require every billing change to survive them. Add generative tests that permute retries, duplicate events, transaction ordering, and partial failures around those exact scenarios, targeting the failure neighborhood instead of attempting exhaustive monolith coverage.

4. 4

   Shadow-enforce the billing boundary

   gpt-5.6 · neighbor · 16/20 points (9 + 7)

   As a lower-risk mutation of the database firewall, keep current permissions initially but log every query touching billing tables with its module, call site, and transaction ID. After four weeks, turn unexpected writes into CI failures, then production errors module by module; this substitutes staged enforcement for an immediate permission cutover.

5. 5

   Billing blast-radius switchboard

   gpt-5.6 · within brief · 16/20 points (9 + 7)

   Put risky billing behaviors—not the whole module—behind server-side kill switches and percentage rollouts, with dashboards keyed to invoice, payment, and reconciliation anomalies. Each weekly feature ships with a tested off-path so responders can disable the new behavior without reverting unrelated monolith deployments or undoing schema migrations.

6. 6

   Postgres schema encapsulation and Row Level Security

   gemini-3.6-flash · within brief · 15/20 points (7 + 8)

   Isolate billing tables in a dedicated Postgres schema (billing.*) and revoke direct write and read access from other DB roles. Modules access them only via defined SQL views or stored interfaces. This eliminates the main cause of the incidents directly at the database level.

7. 7

   Contract testing and shadow pipeline for billing releases

   gemini-3.6-flash · within brief · 15/20 points (8 + 7)

   Establish automated consumer-driven contract tests for all billing interfaces in the CI pipeline. In addition, billing changes to critical calculations run in shadow mode in production, without side effects and with automatic difference checking.

8. 8

   A second database as a safety instrument

   gpt-5.6 · rule breaker · 14/20 points (7 + 7)

   Deliberately break the soft assumption of “one Postgres database” by adding a read-only shadow database fed through logical replication, while keeping billing inside the monolith and retaining the primary as the sole writer. Run new billing reads and reconciliation checks against both databases, compare results before exposure, and use the shadow for forensic queries so incident diagnosis cannot overload or accidentally mutate production.

9. 9

   Strict module boundary linting and public API facade

   gemini-3.6-flash · within brief · 14/20 points (7 + 7)

   Introduce architecture linting via dependency-cruiser that forbids direct imports of billing internals in other modules at the build step. Communication may only take place via a single, type-safe BillingFacade interface, so that creeping coupling is blocked immediately.

10. 10

    Billing change passports

    gpt-5.6 · within brief · 13/20 points (7 + 6)

    Require every billing-related pull request to carry a machine-checked passport: affected tables, invariants, migration compatibility, rollback path, and one production query proving post-deploy health. A CODEOWNERS gate plus a 15-minute rotating billing steward review keeps the process lightweight enough for weekly changes while concentrating scrutiny on cross-module effects.

11. 11

    Auto-generated read-only Postgres views for external modules

    gemini-3.6-flash · neighbor · 13/20 points (7 + 6)

    A mutation of the schema encapsulation: instead of costly API refactorings, read-only Postgres views are automatically provided for external queries. External modules read only these stable views, while direct table access is blocked via DB permissions.

12. 12

    Asynchronous in-process event bus for read models

    gemini-3.6-flash · within brief · 12/20 points (4 + 8)

    Instead of other modules querying billing tables directly, the billing module sends in-memory events on state changes. Receiving modules build their own local projections. This completely decouples read access from the billing tables without introducing distributed systems.

13. 13

    Two-week feature freeze for billing encapsulation

    gemini-3.6-flash · rule breaker · 11/20 points (5 + 6)

    Breaks the soft constraint of continuous weekly feature output for exactly two weeks. The entire team concentrates on separating DB couplings. The one-time effort lays the foundation for sustainably reducing incident numbers over the remaining 5 months.

14. 14

    Database role per module

    claude · within brief · 11/20 points (6 + 5)

    Give billing its own Postgres schema and role and revoke other modules' write access to billing tables, so direct writes fail in staging before they reach production.

15. 15

    Physical DB partitioning into a second Postgres instance

    gemini-3.6-flash · rule breaker · 9/20 points (3 + 6)

    Breaks the soft constraint of the single-database architecture but keeps the monolithic code. Billing data moves into its own database instance, which makes cross-cutting SQL joins technically impossible. Operational complexity remains minimal because the code remains monolithic.

Kirat's note to Claude: Best rule_breaker idea only at rank 8: "A second database as a safety instrument" — it deliberately breaks a soft constraint. Steelman it once before discarding it.

Result from the council

1. 1

   Two-human exclusion gate

   gpt-5.6 · rule breaker · 18/20 points (10 + 8)

   Have Reviewer A screen every record, but send A's includes and uncertain decisions directly forward; Reviewer B independently assesses only A's proposed exclusions. Exclude a record only when both humans independently exclude it, and automatically advance every disagreement, eliminating most conflict discussions. This deliberately breaks the soft current-protocol assumption that two humans must assess every record; it is worthwhile because it saves screening time while structurally allowing more false inclusions, but no additional false exclusions, and is straightforward to describe in the PRISMA selection-process section.

2. 2

   Calibration sprint with an edge-case ledger

   gpt-5.6 · within brief · 16/20 points (9 + 7)

   Independently dual-screen a stratified first batch, resolve conflicts, and turn recurring ambiguities into short operational rules with positive and negative examples. Lock the rules before continuing; retain pilot decisions only if eligibility criteria did not change, otherwise rescreen them. This preserves dual independent screening while reducing later deliberation and conflict-resolution time, and the calibration can be reported under PRISMA.

3. 3

   Fast binary console, not miniature data extraction

   gpt-5.6 · within brief · 15/20 points (8 + 7)

   Give both reviewers a blinded, keyboard-driven interface limited to include, exclude, or uncertain, with the complete title and abstract always visible; defer detailed coding and exclusion reasons to full-text review. PRISMA 2020 does not require record-level reasons at title-and-abstract stage. The decision process remains unchanged, but avoidable reading, clicking, and documentation time falls.

4. 4

   Include-only machine release valve

   gpt-5.6 · neighbor · 15/20 points (9 + 6)

   As a one-step mutation of the two-human exclusion gate, run A's proposed exclusions through a validated classifier that may only release records to inclusion, never exclude them; Reviewer B independently screens everything the classifier does not release. Final exclusion still requires concordant decisions from two humans, so a machine error can add full texts but cannot create a false exclusion. Report the model, version, inputs, thresholds, validation, and its strictly include-only role under PRISMA.

5. 5

   Asymmetric exclusion screening

   gemini-3.6-flash · within brief · 15/20 points (7 + 8)

   A first reviewer classifies all 3,000 records completely. The second reviewer checks only those records that the first reviewer excluded, in order to catch false negatives (inclusions are accepted directly). This nearly halves the second reviewer's effort, keeps the risk of false exclusions extremely low, and meets all PRISMA requirements.

6. 6

   Bypass screening for high-yield strata

   gpt-5.6 · rule breaker · 13/20 points (8 + 5)

   Predeclare high-yield subsets—such as records from a highly specific search block, direct descendants of known eligible studies, or records already included in a closely aligned review—and send all of them directly to full-text retrieval without title-and-abstract decisions. This deliberately breaks the soft two-screener protocol for those records, but it cannot increase false exclusions because nothing in the subset is excluded; the trade-off is additional full-text work. Report the bypass rule and resulting counts explicitly in the PRISMA flow diagram and selection methods.

7. 7

   Prioritized screening via active learning

   gemini-3.6-flash · within brief · 13/20 points (5 + 8)

   Both human screeners use an active learning tool (such as ASReview) that sorts relevant titles/abstracts to the top. As soon as a statistically validated stopping criterion is reached (e.g. 500 irrelevant hits in a row), screening is ended. The procedure saves up to 70% of the time, can be documented in a PRISMA 2020-compliant way, and maintains a minimal false exclusion rate through the algorithm calibration.

8. 8

   Exact-only deduplication before screening

   gpt-5.6 · within brief · 12/20 points (8 + 4)

   Remove only records proven identical through DOI, database accession number, or exact normalized bibliographic matching; retain the metadata-richest copy and merely flag uncertain near-duplicates. Both reviewers then independently screen every remaining unique record, while PRISMA reports the duplicates removed before screening. This cuts volume without creating a pathway for excluding a unique study.

9. 9

   Human-AI cascade with an AI safety net

   gemini-3.6-flash · neighbor · 12/20 points (5 + 7)

   A mutation of asymmetric exclusion screening: one human screener processes all records alone, while an AI model tuned for maximum sensitivity checks only the human exclusions. A second human checks only where there are discrepancies. This reduces human capacity by over 50% with complete coverage.

10. 10

    Fully automated AI second reviewer

    gemini-3.6-flash · rule breaker · 11/20 points (3 + 8)

    Breaks the soft constraint that two human beings must necessarily do the screening. A large language model (LLM) takes on the role of the independent second reviewer with zero-false-negative prompting. It pays off because human working time is halved and LLMs have been shown to achieve high recall rates in abstract screening; PRISMA 2020 explicitly allows AI tools to be reported.

11. 11

    Risk-adapted single screening with confidence triage

    gemini-3.6-flash · rule breaker · 11/20 points (5 + 6)

    Breaks the soft constraint of continuous double screening for the entire dataset. If the first reviewer states a high subjective confidence and clear exclusion reasons exist, the second reviewer is dropped; only uncertain cases move into double screening. This saves up to 60% of staff time, while the risk of missed studies remains minimal because resources are focused on gray areas.

12. 12

    Calibration round first

    claude · within brief · 11/20 points (6 + 5)

    Both screeners screen the same 100 records, discuss every conflict and sharpen the eligibility criteria before the main round, so later conflicts and re-reads drop.

13. 13

    Binarized rapid screening with AI triage

    gemini-3.6-flash · neighbor · 10/20 points (4 + 6)

    Mutation of the active learning prioritization: the team uses a simplified interface for quick rating (only clicks for 'Include/Unsure' vs. 'Exclude'). An AI model evaluates uncertainties in the background and sends only borderline candidates on to in-depth double checking. Drastically minimizes cognitive load and reading time per abstract.

14. 14

    Deterministic pre-filtering via matching algorithms

    gemini-3.6-flash · within brief · 6/20 points (3 + 3)

    Conservative search filters and scripts sort out clearly unsuitable hits in advance (e.g. wrong study design or non-human population). Both screeners check these automated exclusions only via a representative sample (e.g. 10%). This reduces the total volume to be screened manually in a PRISMA-compliant way and without loss of sensitivity.

Result from the council

1. 1

   "Get paid without Word—free for 14 days"

   gpt-5.6 · 17/20 points (9 + 8)

   Speaks directly to Word users, puts getting paid front and center and makes the risk-free trial concrete.

2. 2

   "Send invoices in minutes. Get paid on time."

   claude · 17/20 points (8 + 9)

   The orchestrator's own draft.

3. 3

   "Replace Word and Excel. Get paid days faster."

   gemini-3.6-flash · 14/20 points (7 + 7)

   Addressing the current manual workflow directly offers an immediate contrast, framing the trial as a quick, risk-free upgrade to cash flow without using generic hype.

Result from the council

1. 1

   "Losing furniture buyers to a slow, frustrating WooCommerce store?"

   gemini-3.6-flash · 18/20 points (8 + 10)

   Directly targets the owner's primary frustration—lost sales due to poor store performance—without using tech jargon or self-congratulatory agency language.

2. 2

   "Is your WooCommerce shop turning furniture buyers away?"

   gpt-5.6 · 17/20 points (9 + 8)

   Names the core pain directly and speaks to furniture retailers without jargon.

3. 3

   "Fewer shop emergencies, more time for your furniture."

   claude · 11/20 points (7 + 4)

   The orchestrator's own draft.

Result from the council

1. 1

   "Your celebration cake, baked here for pickup."

   gpt-5.6 · 19/20 points (10 + 9)

   Warm, concrete and personal: “baked here” feels local, while “for pickup” makes the online process feel straightforward.

2. 2

   "Order your custom birthday cake, pick up fresh."

   gemini-3.6-flash · 16/20 points (8 + 8)

   The headline specifically names the occasion as well as pickup and, through the freshness promise, conveys local craft quality without impersonal clichés.

3. 3

   "Your cake, your date. Order in two minutes."

   claude · 9/20 points (5 + 4)

   The orchestrator's own draft.

Result from the council

1. 1

   "Fix billing's boundaries first, split it later if needed"

   claude · 19/20 points (10 + 9)

   The orchestrator's own draft.

2. 2

   "Keep Billing Together, but Isolate It to Prevent Incidents"

   gpt-5.6 · 16/20 points (9 + 7)

   The title states the decision to retain billing in the monolith while strengthening its boundaries, and ties that choice to the shared goal of fewer incidents.

3. 3

   "Strengthen Billing Boundaries in Current App Before Splitting Service"

   gemini-3.6-flash · 13/20 points (7 + 6)

   The title makes a clear decision on direction, avoids unnecessary jargon such as 'monolith' for management, and directly addresses the shared goal of stability.

Result from the council

1. 1

   "Large Language Model–Assisted Study Selection in Health Services Research: A Method for Additional Screening in Systematic Reviews"

   gpt-5.6 · 18/20 points (9 + 9)

   The title identifies the screening method, systematic review context, and health services research setting without implying performance or benefit.

2. 2

   "An LLM as additional screener: a prospective comparison in a health services systematic review"

   claude · 16/20 points (9 + 7)

   The orchestrator's own draft.

3. 3

   "Large Language Models as Auxiliary Screeners in Health Services Research Systematic Reviews: A Methodological Evaluation"

   gemini-3.6-flash · 15/20 points (7 + 8)

   The title names the field of application and the methodology precisely, avoids trigger words and chooses a factual, citable tone for a scientific publication context.

Result from the council

gpt-5.6 · 9/10 Very calm, credible home office workspace with natural morning light, a screen turned away and plenty of free wall space for a headline. Looks somewhat staged, but fulfills the brief almost completely.

gemini-3.6-flash · 9/10 Very bright, natural morning-light atmosphere. The laptop turned away solves the screen problem perfectly without an artificial blur effect. The bright wall area offers ideal space for text.

gpt-5.6 · 6/10 Cozy and authentic with a blurred screen, but clearly visible text on the notebook and handwritten notes appear in the image. In addition, the composition is fuller and offers less calm headline space.

gemini-3.6-flash · 7/10 Very cozy and realistic setup. However, the artificially softened screen looks somewhat conspicuous, and the overall composition offers somewhat less calm space for a headline.

Result from the council

gpt-5.6 · 9/10 Very credible, bright Central European living ambience with natural daylight, four chairs and realistic oak texture; the somewhat extensive decoration distracts minimally from the table.

gemini-3.6-flash · 9/10 Very successful, homely atmosphere with authentic daylight and realistic wood grain. Fulfills all requirements excellently.

gpt-5.6 · 8/10 The solid oak table is clearly staged, four chairs are present, and the wood color and grain look convincing; overall, however, somewhat too flawless and slightly render-like.

gemini-3.6-flash · 9/10 The dining table is clearly in focus; the oak wood and the textures look extremely natural and photorealistic. Perfect editorial style for the online shop.

Result from the council

gpt-5.6 · 8/10 Cake as the clear main subject, simple cardboard box, natural daylight and a plausible local bakery setting. No visible text or logo; the calm lid area is suitable for a headline, even though the image looks somewhat heavily staged.

gemini-3.6-flash · 9/10 Fulfills the brief optimally: completely free of text and logos, the cake is clearly in focus, bright natural light and a very authentic atmosphere. The opened cardboard lid offers an ideal calm area for headlines.

gpt-5.6 · 4/10 Cake and pickup box are clearly staged, and the artisan bakery looks credible. However, it clearly violates “no text”: lettering on the cake topper, menu boards and a receipt; in addition, there is no calm headline area.

gemini-3.6-flash · 3/10 Violates the strict requirement 'no text in the image' through the 'HAPPY BIRTHDAY' topper and the labeled boards in the background. The background is also somewhat too busy.

Result from the council

gpt-5.6 · 9/10 The isolated unit with a dashed boundary is immediately recognizable and clearly contrasts with the dense, interconnected cluster of blocks. Calm, muted coloring; easy to read even at small size. Slight spatial shading instead of a consistently flat style.

gemini-3.6-flash · 7/10 Good depiction of the isolated block with a dashed boundary, calm style and clear legibility even at a small size.

gpt-5.6 · 6/10 The set-apart element and the complex tangle basically convey the decoupling, but the boundary looks more like a screen frame than a clearly defined module boundary. The cluster is very fine-grained and loses legibility when displayed small; overall, though, still calm and without logos or readable text.

gemini-3.6-flash · 4/10 The focus is on a tablet screen instead of a separated building block; the jumble looks less structured.

Result from the council

gpt-5.6 · 9/10 Serious, documentary desk scene with soft daylight; two trays and colored tabs clearly convey the sorting. No logos or clearly readable text, no people.

gemini-3.6-flash · 9/10 Very well executed. High photographic quality in a documentary style; the sorting concept with stacks and trays is clearly understandable, without readable text or faces.

gpt-5.6 · 5/10 The scientific work context and the sorting are clearly recognizable. However, the readable tray labels violate the requirement “no readable text”; in addition, a person with a recognizable, if blurred, face can be seen in the background.

gemini-3.6-flash · 4/10 The motif fits in principle, but a person/face is visible in the background and the trays contain garbled, partly readable text (INCLVDED/EACLVDED).