Claude
031d6d5a3d
De återstående dokumenten — VISION, MVP, DEMO, DRIFT och MASTER-PROMPT — får engelska versioner, och de svenska blir översättningar med samma notis som systembeskrivningen redan hade. DRIFT.md heter nu OPERATIONS.md; ett svenskt filnamn på ett engelskt dokument hade varit inkonsekvent. Dokumentationen är därmed 33 filer: sexton dokument med engelska som källa, sexton svenska syskon, och systembeskrivningen dessutom på tyska, danska och norska. Två fel hittades under översättningen, båda rättade i bägge språken: DRIFT.md pekade ut .github/workflows/ci.yml som Guidad Felsöknings CI och sa tre rader längre ned att samma fil tillhör Semantika och inte rörs. Det stämde innan CI flyttades till egen Gitea; rätt fil är .gitea/workflows/felsokning.yml. MVP.md kallade styrdokumentet Master Prompt v1.0 men länkade till v2.0. Att översätta ett dokument är den grundligaste läsning det får. Båda felen hade överlevt flera genomgångar av samma text på svenska. Kodidentifierare, miljövariabler, sökvägar och UI-etiketter står oöversatta i de engelska versionerna. Att skriva "Create demo case" i demomanuset hade gjort manuset obrukbart — knappen heter "Skapa demoärende". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt
8.1 KiB
Guidad Felsökning — Master Prompt v2.0
Canonical version. Swedish: MASTER-PROMPT.sv.md.
Production Ready AI Wrapper Platform (MVP/Beta)
This is a product directive, not a technical specification. The vision and the reasoning behind it are in VISION.md; v1.0 is in the version history. Detailed module specifications: communication model (voice/PTT), Live Share, verified checklists, case brief, work log and time tracking, customer report.
Project
Build a production-ready SaaS platform named Guidad Felsökning.
The platform is a wrapper on top of the Claude API (Anthropic) and works as a professional tool for mechanics and service technicians.
The model is operated by the platform, not by the customer. The Claude API keys are platform secrets in the backend and are never exposed to customers or clients — the guidance is part of the service. The backend owns the system prompt, the model selection and the response schema, so the rules cannot be circumvented from the client side.
The model orchestra. We run several Claude models in our infrastructure and route per task — the backend owns the routing table, so it can be adjusted without client changes:
| Task | Model | Rationale |
|---|---|---|
| Guidance (a response to each piece of documentation) | Claude Sonnet 5 | Many calls, latency-sensitive on the workshop floor |
| Review (contradictions and gaps across the whole record) | Claude Opus 5, high effort | The deepest reasoning — quality before latency |
| Handover summary (risks and uncertainties) | Claude Sonnet 5, low effort | Balance |
| Methodology classification of the fault description | Claude Haiku 4.5 | Pure classification — fastest and cheapest |
All tasks share the same base rules (below) and the same classified response schema. On a declined request the call automatically falls back to Anthropic's recommended reserve model. The system should not replace technical competence or the manufacturer's documentation, but guide the user through a structured diagnostic process, document all work, and create full traceability.
The goal is to launch a stable, simple beta version worth paying for.
Product philosophy
The product should feel like a tool from a major industrial supplier: simple, stable, extremely fast, professional, predictable, clear, minimal.
No toy. No unnecessary design. No experimental features. Everything should feel robust.
Roles
System administrator
Normally one or more people at the customer. Permissions: manage the organisation, API keys, integrations, create and remove users, roles, permissions, export, security settings, billing, logs.
Technician
Can create cases, continue cases, take over cases, write, speak, photograph, record video, measure, and export reports.
Supervisor
Can additionally see all cases, reassign cases, follow status, read reports, and produce statistics.
Multi-tenancy
Each customer is its own tenant with its own users, API keys, integrations, cases, database logic and security. No data may be mixed between customers.
Simple onboarding
The first time a customer logs in:
- Create the company
- Add a logo
- Add users
- Add any integrations
Done. The whole onboarding should take less than five minutes. The guidance is part of the service — the customer handles no model keys.
Dashboard
Show only what matters: My cases · In progress · Waiting · Done · Start new case.
New case
Identify the object by registration number, VIN, machine number, QR code, barcode, OCR, photo or manual identification. The object is verified before diagnosis starts.
Guidance
The system works step by step. Not long answers. One check at a time:
Check fuse F24. → The user answers. → The system moves on.
Rules
The model may never invent facts, pretend to know, or guess. It must distinguish Observation, Verified, Hypothesis and Recommendation. Every answer must carry a clear confidence level.
Communication model
Speech in, text out. All voice input goes through speech-to-text on a push-to-talk basis — no background listening, no voice agent, never automatic sending. The transcription is always editable before it is saved to the work log. See the module for the full specification.
Camera support
Photo, video, OCR, image analysis and object identification: tyres, type plates, serial numbers, labels, components, measuring instruments.
Work log
Everything is logged: time, user, object, comment, photo, video, measured value, question, answer, result. Nothing may disappear. The log must be audit-proof.
Time reporting
Once the object is identified, the working time starts. After a longer period of inactivity the system asks for a short description of what was done. The final report shows the total time distributed across activities (road test, diagnosis, administration …).
Case brief
The system always maintains a living summary. When another technician opens the case, it automatically shows: what the customer describes, what has been done, what has been verified, what remains, the recommended next steps and the total working time.
Verified checklists
A check item is not complete merely by ticking a box — every check collects evidence and context (observation, measured value, photo) with minimum requirements adapted to the type of check. See the module.
Collaboration
Several technicians can work at the same time. Everyone sees images, video, measurements, notes, the generated summary, status and recommendations.
Customer report and Live Share
The customer report is generated automatically (object, fault description, images, tests, measured values, checks performed, time, recommendation, next step) and shared as a PDF, a link or via the API. Each case can additionally be published through a secure, permission-controlled share link that updates in real time — see the Live Share module. Every export is versioned (version, date, time, who, format).
API first
Build the whole system API-first. All resources must be creatable, readable, updatable, exportable and integrable. Document the APIs with OpenAPI/Swagger.
Integrations
Prepare an integration framework for DMS, ERP, CRM, electronic service books, time reporting, invoicing, parts systems and manufacturer systems via the customer's own credentials. A modular integration architecture so that new integrations can be added without affecting the core platform.
Infrastructure
Build for production. Example target architecture: AWS, Kubernetes, Docker, PostgreSQL, Redis, object storage, CDN, autoscaling, load balancing, backup, central logging, monitoring, CI/CD, infrastructure as code.
Security
Role-based access, encryption at rest and in transit, secure API authentication, audit logs, the principle of least privilege, secure handling of API keys and secrets. Design the system so that it can meet relevant requirements, for example GDPR, depending on how the customer uses the service.
Beta focus
Prioritise a small number of features at high quality over many half-finished ones.
The MVP must contain: login, organisation (tenant), user management, start a case, object identification, guided diagnosis, camera and image analysis, work log, time reporting, case brief, customer report, API, administration.
All other functionality is planned for later versions.
Ultimate goal
Build a platform that feels as obvious to a mechanic or service technician as a diagnostic instrument does today. Focus on speed, clarity, methodical guidance and traceable documentation. When a user opens the app it should feel like a reliable professional tool — not like a general-purpose chat. It should be easy to get started, easy to collaborate, and easy to show the customer exactly how the diagnosis was carried out.