Vibecode Europe-Camions
track this build5 steps, step by step0%NOT REALLY · don't bother
The software here is a search form over a database of listings, and yes, an agent can build that in an afternoon. What it cannot build is the several thousand trucks that dealers actually bothered to upload, which is the entire product. A private clone launches with zero inventory and zero buyers, so it answers no queries and sells no trucks. The only honest personal build is a tracker that sits on top of listings you already found: watchlists, price history, diesel of a spreadsheet with better manners. Useful if you are shopping for one truck, worthless as a replacement.
the project pack4 files · fastest path to a working personal build
You are building a lean indie version of Europe-Camions. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # Europe-Camions indie build ## Goal Build the smallest trustworthy replacement for the core Europe-Camions workflow for one developer or a tiny team. ## Scope A local watchlist app where you record trucks you are considering, track asking price changes over time, compare cost per kilometre and mileage, and get flagged when something you saved moves. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - The inventory: thousands of vehicles from dealers across several countries - The buyer side, so nothing you list gets seen - Dealer vetting and the loose trust layer that comes with a known marketplace - Multilingual reach across French, German, Dutch and Spanish speaking buyers - Cross referencing by make, axle configuration, euro emission class and body type on real data If those capabilities are essential, use Europe-Camions instead of pretending the gap is solved. ===== AGENTS.md ===== # Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan ## Original build brief Build a local truck shopping tracker called RigWatch. Single user, runs on my laptop, no accounts, no cloud, no telemetry. Stack, no substitutions: Node 20, TypeScript, Express, better-sqlite3, EJS templates, plain CSS. No React, no ORM, no Docker. Data model in SQLite: - vehicle: id, title, make, model, year, mileage_km, engine_power_hp, axle_config, euro_class, body_type, country, dealer_name, source_url, notes, status (watching | contacted | rejected | bought), created_at - price_point: id, vehicle_id, amount_cents, currency, seen_on (date) - alert_event: id, vehicle_id, kind (price_drop | price_rise | stale), message, created_at, seen (bool) Features, all server rendered: 1. Add and edit a vehicle by hand, including pasting a source URL. Optional: if a URL is given, fetch the page server side and try to prefill title and price from Open Graph tags and JSON-LD only. If that fails, leave fields blank and say so. Respect robots.txt, honour a 5 second timeout, do not crawl beyond the single URL given. 2. Record a new price point for a vehicle at any time. Show a sparkline or a simple bar list of price history plus total change since first seen. 3. List view with filters: make, country, euro class, year range, mileage range, status. Sort by price, mileage, price per 1000 km. 4. Compare view: pick two to four vehicles, render a side by side table of every field plus a computed value score (price divided by remaining useful mileage, with the assumed end of life km configurable in .env). 5. A single command, npm run check, that re-fetches every vehicle with a source_url, records a new price_point when the parsed price differs, writes alert_events for changes and for anything untouched in 30 days, and prints a summary. No background scheduler, no email. 6. CSV import and export of vehicles so a spreadsheet stays the source of truth if I want. Out of scope, do not build: messaging sellers, payments, user auth, public listing pages, scraping search result pages, translation, image hosting beyond storing one image URL string. Config in .env: PORT, DB_PATH, DEFAULT_CURRENCY, END_OF_LIFE_KM. Commit a .env.example, never a .env. Deliver: npm install then npm run dev serving on localhost, a seed script with 8 fake trucks, and a README with the three commands and a one paragraph note that this tracks listings found elsewhere and is not a marketplace. ## Required capabilities - Node 20 and a terminal - Listings you enter yourself, or feeds you have permission to fetch - No account or cloud service needed ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden. ===== .env.example ===== # Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
You are building a lean indie version of Europe-Camions. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # Europe-Camions indie build ## Goal Build the smallest trustworthy replacement for the core Europe-Camions workflow for one developer or a tiny team. ## Scope A local watchlist app where you record trucks you are considering, track asking price changes over time, compare cost per kilometre and mileage, and get flagged when something you saved moves. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - The inventory: thousands of vehicles from dealers across several countries - The buyer side, so nothing you list gets seen - Dealer vetting and the loose trust layer that comes with a known marketplace - Multilingual reach across French, German, Dutch and Spanish speaking buyers - Cross referencing by make, axle configuration, euro emission class and body type on real data If those capabilities are essential, use Europe-Camions instead of pretending the gap is solved. ===== AGENTS.md ===== # Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan ## Original build brief Build a local truck shopping tracker called RigWatch. Single user, runs on my laptop, no accounts, no cloud, no telemetry. Stack, no substitutions: Node 20, TypeScript, Express, better-sqlite3, EJS templates, plain CSS. No React, no ORM, no Docker. Data model in SQLite: - vehicle: id, title, make, model, year, mileage_km, engine_power_hp, axle_config, euro_class, body_type, country, dealer_name, source_url, notes, status (watching | contacted | rejected | bought), created_at - price_point: id, vehicle_id, amount_cents, currency, seen_on (date) - alert_event: id, vehicle_id, kind (price_drop | price_rise | stale), message, created_at, seen (bool) Features, all server rendered: 1. Add and edit a vehicle by hand, including pasting a source URL. Optional: if a URL is given, fetch the page server side and try to prefill title and price from Open Graph tags and JSON-LD only. If that fails, leave fields blank and say so. Respect robots.txt, honour a 5 second timeout, do not crawl beyond the single URL given. 2. Record a new price point for a vehicle at any time. Show a sparkline or a simple bar list of price history plus total change since first seen. 3. List view with filters: make, country, euro class, year range, mileage range, status. Sort by price, mileage, price per 1000 km. 4. Compare view: pick two to four vehicles, render a side by side table of every field plus a computed value score (price divided by remaining useful mileage, with the assumed end of life km configurable in .env). 5. A single command, npm run check, that re-fetches every vehicle with a source_url, records a new price_point when the parsed price differs, writes alert_events for changes and for anything untouched in 30 days, and prints a summary. No background scheduler, no email. 6. CSV import and export of vehicles so a spreadsheet stays the source of truth if I want. Out of scope, do not build: messaging sellers, payments, user auth, public listing pages, scraping search result pages, translation, image hosting beyond storing one image URL string. Config in .env: PORT, DB_PATH, DEFAULT_CURRENCY, END_OF_LIFE_KM. Commit a .env.example, never a .env. Deliver: npm install then npm run dev serving on localhost, a seed script with 8 fake trucks, and a README with the three commands and a one paragraph note that this tracks listings found elsewhere and is not a marketplace. ## Required capabilities - Node 20 and a terminal - Listings you enter yourself, or feeds you have permission to fetch - No account or cloud service needed ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden. ===== .env.example ===== # Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
You are building a production product version of Europe-Camions. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== PRODUCT.md ===== # Europe-Camions product brief ## Problem The software here is a search form over a database of listings, and yes, an agent can build that in an afternoon. What it cannot build is the several thousand trucks that dealers actually bothered to upload, which is the entire product. A private clone launches with zero inventory and zero buyers, so it answers no queries and sells no trucks. The only honest personal build is a tracker that sits on top of listings you already found: watchlists, price history, diesel of a spreadsheet with better manners. Useful if you are shopping for one truck, worthless as a replacement. ## Product outcome A local watchlist app where you record trucks you are considering, track asking price changes over time, compare cost per kilometre and mileage, and get flagged when something you saved moves. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - Node 20 and a terminal - Listings you enter yourself, or feeds you have permission to fetch - No account or cloud service needed ## Explicit non-goals for v1 - The inventory: thousands of vehicles from dealers across several countries - The buyer side, so nothing you list gets seen - Dealer vetting and the loose trust layer that comes with a known marketplace - Multilingual reach across French, German, Dutch and Spanish speaking buyers - Cross referencing by make, axle configuration, euro emission class and body type on real data ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees. ===== ARCHITECTURE.md ===== # Architecture ## Starting brief Build a local truck shopping tracker called RigWatch. Single user, runs on my laptop, no accounts, no cloud, no telemetry. Stack, no substitutions: Node 20, TypeScript, Express, better-sqlite3, EJS templates, plain CSS. No React, no ORM, no Docker. Data model in SQLite: - vehicle: id, title, make, model, year, mileage_km, engine_power_hp, axle_config, euro_class, body_type, country, dealer_name, source_url, notes, status (watching | contacted | rejected | bought), created_at - price_point: id, vehicle_id, amount_cents, currency, seen_on (date) - alert_event: id, vehicle_id, kind (price_drop | price_rise | stale), message, created_at, seen (bool) Features, all server rendered: 1. Add and edit a vehicle by hand, including pasting a source URL. Optional: if a URL is given, fetch the page server side and try to prefill title and price from Open Graph tags and JSON-LD only. If that fails, leave fields blank and say so. Respect robots.txt, honour a 5 second timeout, do not crawl beyond the single URL given. 2. Record a new price point for a vehicle at any time. Show a sparkline or a simple bar list of price history plus total change since first seen. 3. List view with filters: make, country, euro class, year range, mileage range, status. Sort by price, mileage, price per 1000 km. 4. Compare view: pick two to four vehicles, render a side by side table of every field plus a computed value score (price divided by remaining useful mileage, with the assumed end of life km configurable in .env). 5. A single command, npm run check, that re-fetches every vehicle with a source_url, records a new price_point when the parsed price differs, writes alert_events for changes and for anything untouched in 30 days, and prints a summary. No background scheduler, no email. 6. CSV import and export of vehicles so a spreadsheet stays the source of truth if I want. Out of scope, do not build: messaging sellers, payments, user auth, public listing pages, scraping search result pages, translation, image hosting beyond storing one image URL string. Config in .env: PORT, DB_PATH, DEFAULT_CURRENCY, END_OF_LIFE_KM. Commit a .env.example, never a .env. Deliver: npm install then npm run dev serving on localhost, a seed script with 8 fake trucks, and a README with the three commands and a one paragraph note that this tracks listings found elsewhere and is not a marketplace. ## Boundaries Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors. ## Production baseline - Configuration: validated at startup with safe local defaults where possible. - Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts. - Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test. ## Decision records For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it. ===== AGENTS.md ===== # Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone. ===== MILESTONES.md ===== # Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations. ===== OPERATIONS.md ===== # Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted Europe-Camions capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
README.md
# Europe-Camions indie build ## Goal Build the smallest trustworthy replacement for the core Europe-Camions workflow for one developer or a tiny team. ## Scope A local watchlist app where you record trucks you are considering, track asking price changes over time, compare cost per kilometre and mileage, and get flagged when something you saved moves. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - The inventory: thousands of vehicles from dealers across several countries - The buyer side, so nothing you list gets seen - Dealer vetting and the loose trust layer that comes with a known marketplace - Multilingual reach across French, German, Dutch and Spanish speaking buyers - Cross referencing by make, axle configuration, euro emission class and body type on real data If those capabilities are essential, use Europe-Camions instead of pretending the gap is solved.
AGENTS.md
# Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs".
BUILD_PLAN.md
# Build plan ## Original build brief Build a local truck shopping tracker called RigWatch. Single user, runs on my laptop, no accounts, no cloud, no telemetry. Stack, no substitutions: Node 20, TypeScript, Express, better-sqlite3, EJS templates, plain CSS. No React, no ORM, no Docker. Data model in SQLite: - vehicle: id, title, make, model, year, mileage_km, engine_power_hp, axle_config, euro_class, body_type, country, dealer_name, source_url, notes, status (watching | contacted | rejected | bought), created_at - price_point: id, vehicle_id, amount_cents, currency, seen_on (date) - alert_event: id, vehicle_id, kind (price_drop | price_rise | stale), message, created_at, seen (bool) Features, all server rendered: 1. Add and edit a vehicle by hand, including pasting a source URL. Optional: if a URL is given, fetch the page server side and try to prefill title and price from Open Graph tags and JSON-LD only. If that fails, leave fields blank and say so. Respect robots.txt, honour a 5 second timeout, do not crawl beyond the single URL given. 2. Record a new price point for a vehicle at any time. Show a sparkline or a simple bar list of price history plus total change since first seen. 3. List view with filters: make, country, euro class, year range, mileage range, status. Sort by price, mileage, price per 1000 km. 4. Compare view: pick two to four vehicles, render a side by side table of every field plus a computed value score (price divided by remaining useful mileage, with the assumed end of life km configurable in .env). 5. A single command, npm run check, that re-fetches every vehicle with a source_url, records a new price_point when the parsed price differs, writes alert_events for changes and for anything untouched in 30 days, and prints a summary. No background scheduler, no email. 6. CSV import and export of vehicles so a spreadsheet stays the source of truth if I want. Out of scope, do not build: messaging sellers, payments, user auth, public listing pages, scraping search result pages, translation, image hosting beyond storing one image URL string. Config in .env: PORT, DB_PATH, DEFAULT_CURRENCY, END_OF_LIFE_KM. Commit a .env.example, never a .env. Deliver: npm install then npm run dev serving on localhost, a seed script with 8 fake trucks, and a README with the three commands and a one paragraph note that this tracks listings found elsewhere and is not a marketplace. ## Required capabilities - Node 20 and a terminal - Listings you enter yourself, or feeds you have permission to fetch - No account or cloud service needed ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden.
.env.example
# Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
PRODUCT.md
# Europe-Camions product brief ## Problem The software here is a search form over a database of listings, and yes, an agent can build that in an afternoon. What it cannot build is the several thousand trucks that dealers actually bothered to upload, which is the entire product. A private clone launches with zero inventory and zero buyers, so it answers no queries and sells no trucks. The only honest personal build is a tracker that sits on top of listings you already found: watchlists, price history, diesel of a spreadsheet with better manners. Useful if you are shopping for one truck, worthless as a replacement. ## Product outcome A local watchlist app where you record trucks you are considering, track asking price changes over time, compare cost per kilometre and mileage, and get flagged when something you saved moves. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - Node 20 and a terminal - Listings you enter yourself, or feeds you have permission to fetch - No account or cloud service needed ## Explicit non-goals for v1 - The inventory: thousands of vehicles from dealers across several countries - The buyer side, so nothing you list gets seen - Dealer vetting and the loose trust layer that comes with a known marketplace - Multilingual reach across French, German, Dutch and Spanish speaking buyers - Cross referencing by make, axle configuration, euro emission class and body type on real data ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees.
ARCHITECTURE.md
# Architecture ## Starting brief Build a local truck shopping tracker called RigWatch. Single user, runs on my laptop, no accounts, no cloud, no telemetry. Stack, no substitutions: Node 20, TypeScript, Express, better-sqlite3, EJS templates, plain CSS. No React, no ORM, no Docker. Data model in SQLite: - vehicle: id, title, make, model, year, mileage_km, engine_power_hp, axle_config, euro_class, body_type, country, dealer_name, source_url, notes, status (watching | contacted | rejected | bought), created_at - price_point: id, vehicle_id, amount_cents, currency, seen_on (date) - alert_event: id, vehicle_id, kind (price_drop | price_rise | stale), message, created_at, seen (bool) Features, all server rendered: 1. Add and edit a vehicle by hand, including pasting a source URL. Optional: if a URL is given, fetch the page server side and try to prefill title and price from Open Graph tags and JSON-LD only. If that fails, leave fields blank and say so. Respect robots.txt, honour a 5 second timeout, do not crawl beyond the single URL given. 2. Record a new price point for a vehicle at any time. Show a sparkline or a simple bar list of price history plus total change since first seen. 3. List view with filters: make, country, euro class, year range, mileage range, status. Sort by price, mileage, price per 1000 km. 4. Compare view: pick two to four vehicles, render a side by side table of every field plus a computed value score (price divided by remaining useful mileage, with the assumed end of life km configurable in .env). 5. A single command, npm run check, that re-fetches every vehicle with a source_url, records a new price_point when the parsed price differs, writes alert_events for changes and for anything untouched in 30 days, and prints a summary. No background scheduler, no email. 6. CSV import and export of vehicles so a spreadsheet stays the source of truth if I want. Out of scope, do not build: messaging sellers, payments, user auth, public listing pages, scraping search result pages, translation, image hosting beyond storing one image URL string. Config in .env: PORT, DB_PATH, DEFAULT_CURRENCY, END_OF_LIFE_KM. Commit a .env.example, never a .env. Deliver: npm install then npm run dev serving on localhost, a seed script with 8 fake trucks, and a README with the three commands and a one paragraph note that this tracks listings found elsewhere and is not a marketplace. ## Boundaries Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors. ## Production baseline - Configuration: validated at startup with safe local defaults where possible. - Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts. - Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test. ## Decision records For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it.
AGENTS.md
# Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone.
MILESTONES.md
# Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations.
OPERATIONS.md
# Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted Europe-Camions capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
$ choose a build depth, inspect the files, then open the complete pack in your agent · this prompt is generated from the build plan · improve it via PR
Dealers pay because that is where the buyers already look, and buyers show up because that is where the trucks are. Neither side is paying for the search UI, which is unremarkable, they are paying for the aggregation. Personal software cannot manufacture an audience of fleet buyers in Poland or Spain, so the value never transfers to a self-hosted copy.
xThe inventory: thousands of vehicles from dealers across several countries
xThe buyer side, so nothing you list gets seen
xDealer vetting and the loose trust layer that comes with a known marketplace
xMultilingual reach across French, German, Dutch and Spanish speaking buyers
xCross referencing by make, axle configuration, euro emission class and body type on real data
Nothing worth pointing at. That's why the prompt exists.
share on X ↗"I just replaced Europe-Camions with one prompt"
Vibecode Europe-Camions
Not really. Europe-Camions's value is not the code: The moat is marketplace liquidity: years of dealer inventory on one side and cross border buyers on the other. See the honest breakdown above.
How much does Europe-Camions cost?
Europe-Camions's pricing is usage-based or varies by plan · Seller FAQ states two formulas: private sellers / low-volume sellers pay per published ad (unit rates shown on the site homepage, not readable to fetchers), professionals get volume forfaits arranged by phone. The CGV say the subscription price is invoiced per the quote issued by Via Mobilis and signed by the client, renewed monthly by tacit renewal. Credit-pack rates are only visible inside the My.Via-Mobilis account area..
What do I lose by replacing Europe-Camions?
Honestly: The inventory: thousands of vehicles from dealers across several countries; The buyer side, so nothing you list gets seen; Dealer vetting and the loose trust layer that comes with a known marketplace; Multilingual reach across French, German, Dutch and Spanish speaking buyers; Cross referencing by make, axle configuration, euro emission class and body type on real data. If any of those are load-bearing for you, keep paying.
Is there an open-source alternative to Europe-Camions?
No mature open-source alternative worth pointing at, which is exactly why the one-shot prompt on this page exists.