---

title: TasteFit emoji: 🍜 colorFrom: yellow colorTo: red sdk: docker app_port: 7860 license: mit

TasteFit

Click the map. One number answers Who should rent this unit?

At a Chicago pin you get three exhibits on one sheet: who lives here (Census ACS 5-year), who dies (official business licences, n = 5,692), and what the street loves (Qloo taste graph). OSM competitors sit on the map as geography, not as a survival claim. 80% open is not for sale as a rent. It is for sale as a share.

The pin is the only required action. Print memo is a one-page report from that pin. A cell is a block to scout, not a vetted address. Qloo answers who belongs here. Licences answer survival: location did not predict it (κ = 0).

Live demo: https://tastefit-776637567140.us-central1.run.app — pin Wicker Park, read the number, run the Qloo agent. Silent reel: https://tastefit-776637567140.us-central1.run.app/walkthrough.

60-second demo

1. Open the live demo. Pin a block (Wicker Park is the start). Qloo names who already eats there.
2. Print memo. Taste from Qloo, survival from licences, ACS tract, lease maths. Limits stay. Write [email protected].
3. Licences: how many of 100 still open. Location did not beat the city mean (κ = 0).
4. Drag “landlord share” toward 35%. 80% open is for sale as a share, not as a cheaper pin.

A silent 60-second reel is at /walkthrough on the running app (source: demo/walkthrough.html). Freeze a beat with ?scene=1 … ?scene=5. A recorded cut is demo/tastefit-60s.mp4 (60 seconds, product only).

GitLab's under-3-minute automation ask is the live pipeline and Duo flows, not this reel. There is no pipeline screen recording in the repo. Paste pipeline 2984949822 and the flows in .gitlab/duo/flows/ (Issue Planner, Developer, Domain Reviewer, Pipeline Medic, Release Scribe).

How it works

The judging page is the pin. /spot (Census + pack), /ask (licences), /taste (Qloo exhibit, offline without a key). An older LLM agent still runs a tool loop over the official Qloo hackathon harness (qloo exec) at /run and /tenant:

Agent tool	Qloo workflow	Purpose
find_tags	find_tags	Turn the concept ("Korean fried chicken counter") into Qloo tag URNs, choosing the right one among same-name tags
area_taste	recommend (place, location signal)	Places the area's audience has the highest affinity for
competitors	recommend (place, concept tags, location filter)	Existing places that match the concept: competition and benchmarks
hotspots	where_popular	Sub-areas where the strongest benchmark over-indexes
site_math	local (geo.py)	Barycenter site analysis over everything gathered, shown on a map

Site math (geo.py)

Hotspot cells come with coordinates; places carry an address, geocoded with OpenStreetMap Nominatim (keyless, max 1 request per second).

• Demand center: affinity-weighted barycenter of the places and hotspot cells the area favors, c = Σ wᵢ pᵢ / Σ wᵢ.
• Competition center: the same barycenter over places that match the concept.
• Catchment radius: weighted standard distance of demand around its center.
• Suggested spot: on a 41×41 grid over the area, maximize Σ wᵢ·K(x, dᵢ) − 0.7 · Σ wⱼ·K(x, cⱼ), with a Gaussian kernel K whose width follows the demand spread (0.3 to 3 km). This is a gravity model: be close to demand, away from look-alike competitors.
• Opportunity index: the score at the suggested spot as a share of the peak demand pull (0 to 100).

The map uses Leaflet with OpenStreetMap tiles. The suggested spot points to a block to scout, not a vetted address.

The memo cites places, tags and numbers returned by Qloo, OpenStreetMap supply counts attributed as such, and, when the city is Chicago, the committed City of Chicago Data Portal community-area footfall shares with their dataset id and date range. It does not attach those Chicago counts to another city, and a name such as South Loop is not given the Loop's totals. It keeps Qloo results separate from interpretation, and ends with a Limits section: Qloo describes aggregate group affinities, not foot traffic, rents or individual behaviour. No personal data is sent to Qloo; inputs are a concept and a place name. The footfall line is a community-area total, not a count at the door and not a vetted address.

City Scan and rent ceiling (/scan, /scan/unit)

Two read-only JSON endpoints serve prebuilt city packs (packs/, built offline by cityscan_publish.py; method in METHOD.md). The server never runs the model and makes no network call for them.

• GET /scan?city=paris&concept=specialty%20coffee&top=10: the cells of the city where the concept fits best, with reasons, nearest competitors and a 90% Monte Carlo interval on each score.
• GET /scan/unit?city=paris&lat=48.865&lon=2.377: for one unit, the highest monthly rent each tenant type (restaurant, fast food, bar/café) can pay and still reach the city's official 3-year survival rate, or "not viable at any rent" where even rent-free falls short. This is calibrated on official survival for Paris (SIRENE, EUR) and Chicago (business licences, USD). Other cities say "not calibrated" rather than borrow these numbers.
• Each city's map data is first checked against an official business register where one exists: the share of registered food businesses that have a mapped place within 50 m, corrected for matches expected by chance (the same test after shifting the register 300 m). Cities below 0.70 get the reason and no numbers.
  • Paris scores 0.84 (INSEE SIRENE).
  • Chicago scores 0.88 (City of Chicago business licences).
  • Philadelphia scores 0.60 (L&I commercial activity licences), so it is shipped as data-thin.
• Does captured spend cover the asking rent? Chicago and Philadelphia only. Census tracts in Cook County and Philadelphia County (ACS 2024 5-year, B19001 household income and B01003 population; public summary file) whose centroids fall within 1.2 km are multiplied by BLS Consumer Expenditure Survey 2024 Table 1203 mean food-away-from-home dollars for the matching income band. The ACS $60,000 to $74,999 bin crosses the CEX $70,000 line, so those households are left out and the spend is a lower bound. Share is 1/(1+n) among the new place and every OpenStreetMap food venue within 1.2 km (equal utility, the conditional logit when utilities are tied, McFadden 1974; food-away-from-home is not split by cuisine). Monthly captured spend is that annual figure times the share, divided by 12, with no discounting. It is a rough ceiling under those assumptions, before costs, not profit and not a forecast: missing mapped venues push it up, and workers and visitors are not counted, which pushes it down. One household is treated as one consumer unit. Cities below the 0.70 map-quality gate still get no opportunity scores and no rent ceilings. Philadelphia's spend note adds that its venue file failed that check, so a missing venue would overstate the share. A Chicago backtest of 2023-2024 openings found no measurable gain over a citywide baseline; this estimate does not change that. Outside the US the field is "not available". The cached aggregate is data/us_fafh.json (build_us_fafh.py).
• Without a register, the check falls back to the share of food places confirmed by two map sources (below 40% fails, a provisional threshold). Casablanca (18%) is shipped as that case.
• The Chicago calibration replicates the Paris finding: measured location demand does not predict 3-year survival in either city. So the ceiling mostly reflects each tenant type's calibrated revenue against its costs, and Chicago figures are city-level per tenant type rather than a location signal (, section 11).

Qloo

TasteFit is a new project, started Oct 10, 2026. The live product is pin-first: who should rent this unit.

Workflows used and why

All calls go through the official harness (qloo exec); 8 of its 9 workflows are used.

Workflow	Where	Why
recommend (place, location signal)	pin	What the area's audience over-indexes on: the taste a tenant would sell into
recommend (place, tag + location filter)	pin	Benchmarks for a concept in the city, and the existing supply inside the area where no OpenStreetMap venue file ships for the city
entity_tags	tenant pipeline	The tags behind the area's favourite places (cuisine, vibe, price)
audience_demographics	tenant pipeline	Age and gender skew of the area's top place, shown as relative bars
find_tags	pin	Turn a concept into a Qloo tag URN; the choice and the alternatives are shown
rank	tenant pipeline	One call ranks every benchmark for the area's audience, so the demand scores are comparable (scores from separate calls are not); a second ranks the same benchmarks for the whole city, for the over-index
compare_audiences	tenant pipeline	Shared taste between the area's favourites and the top concepts' benchmarks
where_popular	pin	Where the top benchmark's audience concentrates, and how far the unit is from it
trends	tenant pipeline	Reach of the top concept's reference chain (trends cover brands, not places)

describe is not needed: recommend already returns each place's description. A tenant run makes at most 25 Qloo calls; a cache that lives for one request makes repeated calls free and is dropped when the run ends.

One step, request to result (redacted)

For a unit clicked in Wicker Park, Chicago, step 5 ranks the six concepts' Chicago benchmarks for the local audience:

{"workflow": "rank",
 "input": {"options": ["<benchmark id: taqueria>", "<benchmark id: ramen shop>", "..."],
           "option_type": "place", "signal_location": "Wicker Park"}}

Qloo returns an affinity per option. TasteFit turns the order into a demand score from 0 to 100 within that call, adds the white-space count from recommend with the concept's tag and the area as filter, and the overlap from compare_audiences, then joins the City Scan rent ceiling for the clicked cell. The page shows every step with the request it sent; no Qloo response is stored.

Does Qloo help? Backtest (Chicago, offline)

backtest_chicago.py checks the tenant agent's demand ranking against what actually opened and survived. The ground truth is the City of Chicago Food Inspections register: a restaurant or bakery opened when its licence's first passing License inspection ever falls in 2023-2024 (licences that passed one earlier, such as renewals, are left out), and survived when no later inspection says Out of Business and it was inspected again since April 2025. Names are matched to the ten catalog concepts by keyword (200 of 1,751 openings match). For each area (1.2 km radius), the ten concepts are ordered by one Qloo rank call, and by the citywide share of surviving openings without that area (a "what is opening everywhere" baseline). The output is numbers only (backtest_chicago.json).

9 Chicago areas, 31 surviving openings	Qloo demand	Citywide baseline	Random
Surviving openings whose concept is in the top 3	29%	68%	30%
Mean rank correlation with surviving openings	0.02	0.31	0
Survival rate of openings in the top-3 concepts (vs. the rest)	64% of 14 (44% of 50)	49% of 43 (48% of 21)

Each opening counts once, for the nearest area centre, because neighbouring areas overlap. 3 of the 12 areas are not scored (Pilsen, Chinatown, River North): they had no surviving catalog opening, or Qloo's rank call returned no usable ranking (2 areas). So this is 9 areas and 31 openings, a small sample.

Result: no gain. Qloo's demand ranking did no better than random at naming the concepts that opened and survived, and the citywide baseline did clearly better: the Qloo-minus-baseline difference has a 90% bootstrap interval of -66 to -4 points. Openings in the concepts Qloo ranked highest did survive more often (64% vs. 44%), but on 14 openings that is not evidence. Earlier runs the same day, before each opening was counted once, gave Qloo between 30% and 54%, so the rank output also varies between runs. The LLM-only column needs a working LLM for every area and is not reported. Qloo and the LLM describe today's taste, after these places opened, so this checks agreement with what survived, not a forecast made in 2023.

Taste Gap Index. The second hypothesis was that Qloo helps once combined with supply: a concept the area loves more than the city does and that is under-served nearby. tgi.py computes, per concept:

• Over-index D: the same benchmarks ranked once for the area and once for the whole city, each standardised within its own call, D = z(area) − z(city). Scores from different rank calls are never compared raw.
• Supply ratio θ: OpenStreetMap venues of that cuisine within 600 m against the count expected from the local food mix at the city's concept share (a location quotient, Isserman 1977), shrunk with a Gamma prior fitted over the city's 1.2 km blocks (Clayton & Kaldor 1987) so one or zero venues cannot produce a wild ratio; P(under-supplied) = P(θ < 1) from 4,000 seeded draws.
• Index σ(D − log θ) with stated, unfitted weights, and a quadrant label (white space / proven demand, crowded / empty for a reason / avoid / neutral).

The backtest (--food, results in backtest_chicago_tgi.json) uses an OSM snapshot dated 2023-01-01, before the window, so supply has no look-ahead; D still comes from today's Qloo. The four orderings were fixed before the run. Same 9 areas and 31 surviving openings:

Top-3 hit rate (rank correlation)
Qloo rank alone (as above)	29% (0.02)
Over-index D alone	35% (−0.04)
OSM under-supply alone	32% (−0.10)
Taste Gap Index	48% (−0.16)
Citywide baseline + Taste Gap Index	55% (0.23)
Citywide baseline alone	68% (0.31)

Result: no measurable gain. The index beats the plain Qloo rank by 19 points, but the 90% interval of that difference (−13 to +42 points) includes zero, and every TGI variant is below the citywide baseline (index minus baseline: −36 to −6 points; adding the index to the baseline makes it worse, −22 to −6). On 9 areas, what is opening everywhere in Chicago predicts better than local taste or local gaps. The app still shows the index, labelled uncalibrated, because it is the clearest way to explain a recommendation; OSM supply also replaces four Qloo calls per run.

Footfall ("demand already there"). build_chicago_footfall.py writes data/chicago_footfall.json. Counts only, from the City of Chicago Data Portal, under the city's data disclaimer. No trip rows, no rider identifiers, and no Divvy gender or birth year. Every window ends before 2023-01-01.

Series	Dataset	Window
TNP evening drop-offs, trip end hour 17 through 21	m6dm-c72p	2022-01-01 to 2022-12-31
TNP weekend drop-offs, each Saturday and Sunday	m6dm-c72p	2022-01-01 to 2022-12-31
Divvy trip ends, placed by the station coordinate	fg6s-gzvg	2019-01-01 to 2019-12-31
CTA 'L' station entries, stations from 8pix-ypme	5neh-572f	2022-01-01 to 2022-12-31

The Divvy portal file ends 2020-01-21, so 2019 is its last full year and is still before the backtest. A Saturday evening trip is in both the evening series and the weekend series. A point is counted in the community area whose polygon contains it (boundaries igwz-8jzy). L stations outside the 77 areas, including the suburban ends of the system, are left out: 5,105,024 entries. A zero means the polygon contains no station, not that the file is missing. Hyde Park's polygon contains none in this join.

The concept score is a stated weight vector (footfall.WEIGHTS, each row sums to 1, fixed before this run, not fitted) dotted with the area's share of each citywide total. Dinner concepts load on evening and weekend drop-offs. Daytime concepts load on CTA entries and Divvy ends. The area total is the same for every concept; the weights are what change the order.

backtest_chicago.py --footfall rescores the same 9 areas and 31 survivors with the OpenStreetMap food snapshot dated 2023-01-01. No Qloo call. Over-index D is 0, so the Taste Gap column here is the supply leg plus footfall, not the published Taste Gap Index.

Ordering	Top-3 hit rate	90% interval versus this run's citywide baseline
Footfall alone	39%	−52 to +3 points
Footfall + Taste Gap supply	39%	−44 to −15 points
Footfall + citywide baseline	68%	0 to 0 points
This run's citywide baseline	68%

No footfall variant beats the citywide 68%. Adding footfall to the baseline did not change the top-3 hits. The counts are community-area totals, not a count at the door and not a vetted address. The page at /evidence quotes backtest_chicago_footfall.json. A tenant run reads the committed file and adds no Qloo call.

What this means for the product: Qloo is useful here as evidence a broker can show (what the area loves, who already serves it, where the audience is), not as a validated predictor of tenant survival. Every tenant memo's Limits section reports this backtest result (tenant.BACKTEST_NOTE, added by code if the LLM leaves it out).

Survivorship and intervals (backtest_bias.py, numbers in backtest_bias.json). A Heckman selection correction (Heckman 1979) is not estimated. It needs an exclusion restriction, and this file has none: a licence is missing from the survivor count because it closed, because it was not inspected again, or because its name matched no catalog keyword. Those are not separable from survival, and applications that never opened are not in the register.

Inverse-probability weights (Horvitz and Thompson 1952) are used instead. The propensity in a concept-by-area cell is survivors / openings. A cell with openings and no survivor is dropped, not filled in. The weights cover keyword-matched licences only. On a register pull with no Qloo call (10 areas that have a survivor, including River North, which the 9-area Qloo table left out), the citywide baseline's top-3 hit rate is 0.686 on 35 survivors and 0.766 after weighting (64 weighted openings; 10 openings dropped because the propensity was 0). Weighting does not reverse the published result. The Qloo column was not recomputed: rank orders are not stored, and this pull made no Qloo call.

A split-conformal interval (Vovk, Gammerman and Shafer 2005) around the leave-one-area citywide survivor share, 90%, has quantile 1 and mean width 2 on a rate that lives in [0, 1]. Coverage on the test half is 1 because the interval is the whole range. It does not tighten the claim, and it is not an interval for a Qloo fit score. Those scores are not stored.

Decision layer (decision.py)

Three additions turn the evidence into a decision. None of them uses an extra Qloo call.

• Rent-first call. This applies wherever a concept has a Taste Gap label. The rent is checked before taste: no taste fit rescues a rent the unit cannot carry.
  • NO-GO if the asking rent is above the ceiling's 90% range, or the label is "avoid".
  • GO if the rent fits and taste is strong. Strong means "white space", or a positive over-index in the run's top third by Taste Gap Index.
  • ADJUST otherwise, with the adjustment spelled out: negotiate to the central ceiling, or reposition toward the run's white-space concept.
  • Concepts without a label (no venue file for the city) keep the score thresholds. The score still orders concepts within each call.
• Score breakdown. An exact Shapley split (Shapley 1953) over all 16 coalitions of four signals, against a city-typical baseline: taste over-index (Qloo), supply ratio (OpenStreetMap), audience fit (Qloo, relative to the run's median), and rent headroom (City Scan).
  • The card shows each signal's contribution and the Qloo share.
  • The weights are stated priors, not fitted, so the split explains TasteFit's model, not cause and effect.
  • Momentum is left out because trends covers one reference brand, not each concept.
• Check first, before signing. This is the expected value of partial perfect information (Howard 1966; binned estimator, 20 bins, 2,000 seeded draws). It is computed on monthly profit at the asking rent, or at the ceiling when none is given, using the City Scan break-even model's stated cost ranges.
  • It ranks which input (covers per day, ticket, staff, …) is worth checking before signing, in currency per month of decision value.
  • A check is shown only when its value exceeds twice a noise floor, measured with a random input.
  • The figures are monthly, with no discounting and no interest.
  • They come from TasteFit's stated assumptions, not the user's own numbers. For example, a Chicago restaurant at 6,000/month: covers per day dominates.
• Test before you lease. The top concept gets a pop-up of 4, 6 or 8 weeks. Eight weeks when two or more checks sit above the value-of-information noise floor. Four weeks when the top check is at least half of the monthly value of perfect information. Six weeks otherwise. There is no discount rate and no interest in that choice. Success is the mode break-even at the rent-first central ceiling (rent_max) on that concept's own top check, or covers per day when that concept has no value-of-information result. Another concept's check is not reused. A NO-GO top concept does not get a pop-up, and a non-positive line is omitted. The figures use TasteFit's stated cost assumptions, not the reader's. The line is: covers per day, ticket or days at least that line, or staff, other fixed costs or a cost share at most that line. The memo also states the line at the top of the ceiling's 90% range. The plan's SHA-256 covers the area, the concept, the check, the direction, the ceiling, the threshold, the weeks and the UTC time. The outcome log (observed value, weeks run, cleared) has a second hash. Neither is inside the five-field prediction fingerprint, so the Chicago batch hash is unchanged. A pop-up is not a vetted address.

Limits

• Qloo describes aggregate taste affinities, not foot traffic, sales or rents. The rent ceiling comes from City Scan (official survival data for Paris and Chicago only).
• Scores are relative within one run's rank call; two runs can order close concepts differently.
• filter_location is fuzzy for small neighborhoods (a Wicker Park filter can return Lincoln Park places).
• Trend data in the hackathon environment showed no change over the periods tested, and the page says so.
• Alcohol-led concepts and benchmarks are excluded by design.

Run locally

Requires Python 3.10+ and Node.js 22.19+ (for the harness).

git clone https://gitlab.com/gitlab-ai-hackathon/transcend-october-2026/43239248/tastefit.git && cd tastefit
npm ci                             # installs @qloo/qloo-harness locally (no Python packages needed)
export QLOO_API_KEY=...            # Qloo hackathon key, never commit it
export QLOO_BASE_URL=https://hackathon.api.qloo.com
export GEMINI_API_KEY=...          # optional: free Google AI Studio key. Tries gemini-3.8-flash (8s), then gemini-3.1-flash-lite
export LLM_BASE_URL=...            # optional fallback: any OpenAI-compatible endpoint (default: a free keyless one)
python app.py                      # http://localhost:8000
python backtest_chicago.py --no-llm  # optional: the Qloo backtest above (public Chicago data, about 35 Qloo calls)
python backtest_chicago.py --public-only  # register only: IPW and conformal, no Qloo call
python tgi.py build chicago 2023-01-01 /tmp/chicago_2023.json.gz && \
  python backtest_chicago.py --no-llm --food /tmp/chicago_2023.json.gz  # optional: with the Taste Gap Index

The API keys stay on the server; the browser only receives the streamed steps and the memo. LLM calls go to Gemini first when GEMINI_API_KEY is set, then to the fallback endpoint. The tenant match never depends on an LLM to finish: without one it uses a fixed candidate list and a template memo.

CLI: python agent.py "Korean fried chicken counter" "Austin, TX"

MCP server (mcp_server.py, standard library, stdio JSON-RPC): exposes tenant_match, city_scan and city_scan_unit to any MCP client. The key comes from the client's environment and is redacted from every tool result.

{"mcpServers": {"tastefit": {"command": "python3", "args": ["/path/to/tastefit/mcp_server.py"],
  "env": {"QLOO_API_KEY": "...", "QLOO_BASE_URL": "https://hackathon.api.qloo.com"}}}}

Tenant match (GET /tenant?lat=41.9088&lon=-87.6796&rent=4000, or ?city=Paris&location=Le%20Marais): for a vacant unit, which food concepts the local audience wants that nobody nearby serves, and whether each can pay the rent. A fixed pipeline of at most 25 Qloo calls (8 workflows; a cache that lives for one request only, so repeated calls within a run are free and nothing Qloo returns outlives the request) streams each step, then a scored shortlist, a "without Qloo" comparison and a memo (tenant.py).

Claim ledger (the "without Qloo" panel): the same LLM, with no tools, suggests concepts and names up to 5 competitors within 500 m. Each concept is marked confirmed (Taste Gap "white space", or "neutral" with a positive over-index), contradicted ("proven demand, crowded", "empty for a reason", "avoid"), partly supported, or not tested by this run. Each named venue is looked up in OpenStreetMap within 500 m with City Scan's name matcher (similarity >= 0.6 found, 0.45-0.6 ambiguous); Qloo's own area favourites that read as food venues go through the same check (1.5 km, since they are area-level; the OSM file holds food venues only). The page shows counts, and calls them agreement with the run's evidence and existence in open data, not accuracy: OSM misses real venues too. Supply estimates whose city-wide prior carries >= 80% of the weight are badged "Data coverage: low": the local OSM count barely moves them. This happens when the expected count near the unit is small or the city's block counts vary little; it is not a measure of how complete OSM mapping is.

Front end: index.html plus static/ (app.js, styles.css, icons), no build step. The map starts on Wicker Park; that pin is geography, not a vacancy listing. "Try the Wicker Park example" drops the pin and opens Print memo (live /spot and /taste). demo/wicker-park.json remains in the repo as an aggregates-only snapshot (GET /wicker-example.json); it stores no Qloo response.

Tests: python -m unittest discover -s tests -t . -v (389 tests).

Deploy

Live demo (Cloud Run, free tier): https://tastefit-776637567140.us-central1.run.app (us-central1, 0 to 1 instances). The deploy-gcp job copies the signed, scanned CI image by digest to Artifact Registry and deploys that digest, authenticated by Workload Identity Federation (no stored key); smoke-gcp checks that /health returns the commit SHA.

Paste the Cloud Run URL. A Render service may still exist from earlier deploys; it is not the live demo.

Agentic DevSecOps on GitLab

TasteFit started on GitHub (https://github.com/youssefbenzidiya-cmd/tastefit) with no CI, no tests and no post-deploy check. On GitLab, every commit goes through a 7-stage pipeline, and four custom GitLab Duo Agent Platform flows plan, fix, review and release the project when events happen, without being asked. A person merges every change.

Pipeline (.gitlab-ci.yml): test → build → security → package → deploy → verify → release. Latest main pipeline: 2984949822 (merge of feat/pin-first). An earlier main pipeline (2935652252) passed all 15 jobs then listed: unit-tests, lint, flows-lint, image-build, semgrep-sast, secret_detection, dependency-scanning, container_scanning, cve-gate, sbom, sign-image, verify-signature, deploy-render, smoke-test, release. A daily schedule (06:00 UTC) rebuilds and rescans the image and checks that production is up.

GitLab stages covered

Stage	What automates it	Evidence
Plan	Issue Planner turns a new issue into a scoped plan with labels and open questions. Issues assigned to GitLab's Duo Developer flow become MRs.	#15 (planner), #5 (Duo Developer)
Create	Duo Developer opens feature MRs; Pipeline Medic opens fix MRs	!4, !1, !9, !11
Verify	Unit tests with a JUnit report and coverage (74%), ruff lint, flows-lint of the Duo flow files; Medic checks its fixes with the CI linter	pipeline 2935652252 (159 of 159 passed)
Package	Docker image built, started and health-checked, then pushed to the GitLab container registry; CycloneDX SBOM; cosign keyless signature, verified in CI	container registry, jobs sbom, ,

Flows

Definitions are in .gitlab/duo/flows/; rules are in AGENTS.md and skills/tastefit-guardrails/. Each flow runs as its own service account with an explicit toolset. No flow has a merge tool.

Flow	Runs when	What it does
Issue Planner	an issue is created	Rewrites the issue as a scoped plan with acceptance criteria, sets labels, and lists the questions a person must answer before work starts.
Duo Developer (GitLab foundational flow)	an issue is assigned to it	Implements the issue and opens a merge request.
Pipeline Medic	any pipeline fails	Reads the failing job logs, classifies the failure, and opens a minimal fix MR on medic/<pipeline id>, checked with the CI linter. It looks for an existing MR first and adds a note instead of a duplicate. On medic/ and duo/ refs it never opens a fix, so it cannot loop. The definition splits the work between a log_analyst and a fixer subagent.
Domain Reviewer	a merge request is created, or the bot is assigned as reviewer	Checks the 9 product rules a generic reviewer cannot know (secrets, Qloo data terms, privacy, Nominatim policy, site-maths tests, memo honesty, stdlib-only server, protected security jobs, agent governance), posts inline suggestions, and answers GO / ADJUST / NO-GO, like TasteFit itself.
Release Scribe	a pipeline on main passes	Writes release notes for restaurant owners with deployment proof (deployed SHA, smoke-test job) and a security summary across all scanners. Opens a grouped issue for High or Critical findings, and posts a note on issues the release shipped.

Live proof

Every row links to a public page in this project.

Claim	Evidence
The smoke test went red after a good deploy at 22:16:08 UTC. It was a false negative: curl exit 23, caused by grep -q closing the pipe under pipefail.	pipeline 2934704707, failed job 17087586018
Pipeline Medic opened a one-line fix MR at 22:17:47, without being asked, and validated it with the CI linter	!1, commit 4d905e3e
A second Medic run found that MR and added a note instead of a duplicate	!1 (note at 22:18:15)
Domain Reviewer posted GO with its rule table at 22:19:51; a person merged at 22:20:38; the next pipeline deployed and passed	!1, pipeline 2934713922
Medic fixed a failed release job (shell-evaluated backticks in the release description)	pipeline 2934914083, !9
Medic fixed a lint failure on ; the next pipeline passed all 15 jobs and published release v1.86

The loop, measured. Time from the failed job to the Medic fix MR, on every real failure so far:

Failure	Job failed (UTC)	Fix MR opened	Delay	Review	Merged by a person
smoke-test on main	22:16:08	!1 22:17:47	1 min 39 s	GO 22:19:51	22:20:38
release on main	01:08:07	!9 01:10:03	1 min 56 s	GO 01:12:46	01:12:51
lint on a research branch	08:20:41	!10 08:22:29	1 min 48 s	GO 08:35:15	08:37:10
lint on main	08:29:29	!11 08:30:39	1 min 10 s	GO 08:35:13	08:37:06

Review times depend on when a person assigned the reviewer (see Limits).

Seeded benchmark

On 11 Oct 2026 we opened eight merge requests through the API. Each had one planted problem, and none had a hint in its title or description. We recorded what the agents did without stepping in. All eight are now closed, unmerged.

Planted problem	MR	Expected	Domain Reviewer (time to verdict)	Pipeline / Medic
Harmless copy edit	!16	GO	GO (47 s)	green
Slug limit that breaks unit tests	!17	red pipeline, fix MR	ADJUST (54 s)	unit-tests red; Medic fix !25 restores the limit
Hardcoded (fake) API key	!18	NO-GO (rule 1)	NO-GO (51 s)	unit-tests red; Medic fix !24 removes the key and restores the guard
Qloo responses written to disk	!19	NO-GO (rule 2)	NO-GO (54 s)	green
Secret detection disabled	!20	NO-GO (rule 8)	NO-GO (55 s)	green
geo.py default changed, no test	!21	ADJUST (rule 5)	NO-GO (53 s)	unit-tests red; Medic fix !26 restores the default

What it shows:

• All seven planted problems were flagged (six NO-GO, one ADJUST), and the safe change got a GO. Every verdict arrived within a minute.
• All three Medic fixes were correct and minimal. Each restored the guard or default the change broke. None edited a test to make it pass.
• The benchmark found a policy gap, and a human closed it. In !22 the Reviewer found the rule 6 problem but answered ADJUST, exactly as its rubric said: only rules 1, 2, 3, 8 and 9 were blocking. We made rule 6 blocking in !27, a human branch that the Reviewer itself reviewed, GO. We published the flow as 1.2.0 and re-ran it on !22. The verdict became NO-GO, and the Reviewer noted that its earlier ADJUST was too lenient.
• Limits:
  • Secret detection did not flag the fake key; it has no rule for its format. The Reviewer and the unit tests caught it.
  • On !21 the Reviewer was stricter than expected, because the change also broke the demo-report tests.

Before and after

The baseline is GitHub commit 8c465c1 (2026-10-10, 19:08 UTC), the last commit before any GitLab work. The next commit, fda392a (19:22 UTC), added the first tests, /health and a first .gitlab-ci.yml.

	Before (GitHub 8c465c1)	After (GitLab main)
Tests	none	164 unit tests with JUnit and coverage, plus lint, on every push
CI/CD	none	7-stage pipeline: test, build, security, package, deploy, verify, release
Image	node:22-slim (Debian 12), built by the host, never scanned	node:22-alpine, built in CI, started and health-checked, signed, with an SBOM
Container findings	not measured (the same Dockerfile later scanned at 338: 5 Critical, 67 High)	0 on the image GitLab builds from the deployed commit
Image size	141 MB compressed (same Dockerfile, measured in the GitLab registry)	100 MB (−29%)
Deploy	Render web service, no post-deploy check	exact commit, verified live by /health returning that SHA
Releases	none	GitLab Releases with image digest and SBOM, plus owner-facing notes from Release Scribe
Broken pipeline	noticed by chance	fix MR opened by Pipeline Medic in under 2 minutes, 4 times so far
Review	none	Domain Reviewer on every MR, 9 product rules
Agents	none	Issue Planner, Pipeline Medic, Domain Reviewer, Release Scribe, plus GitLab's Duo Developer

Limits

• A person merges. No flow has a merge tool, and every merged merge request so far was merged by a person after a Domain Reviewer verdict. A fix waits for a human.
• Bot-created MRs do not fire the MR-created trigger, so a person assigns Domain Reviewer on them (as on !1, !9, !10 and !11).
• Scanned image vs deployed image on Render. Google Cloud Run runs the exact image GitLab built, scanned and signed (same digest). Render, the second host, builds its own image from the same Dockerfile at the same commit, so its bytes are not the ones we scanned.
• cve-gate covers container findings only. Dependency scanning reports 4 High findings (undici, brace-expansion), tracked in #12, and they do not fail the pipeline.
• Stale Vulnerability Report records. The report still lists 72 Critical/High container records for the superseded Debian image c1605d83 (#9). Current scans of the Alpine image show 0.
• Three Medium SAST findings (SSRF, CWE-918, at cityscan.py:1418, geo.py:87 and agent.py:110) appear in every release note and are not yet triaged.
• Tool gaps. create_vulnerability_issue rejected our calls, so Release Scribe groups findings in one issue.

License

MIT