One endpoint. Two products. Every tool.

Free. Call it when the user asks what prodready can do, what to say, or says something you cannot map to a tool. Pass what they said in said (optional). Returns the flows this server offers, the plain phrases that start each, which tools they use, and — if said matched — the one flow to run now. No data leaves the machine.

Step one of a production-readiness and security review of the user's own codebase. Reach for this whenever someone asks whether the app they built is ready for real users, safe to launch, secure, safe to put customer data in, multi-tenant safe, or whether it will hold up when it gets traffic — and whenever they want a second opinion on something a coding tool generated for them.

This server is remote and cannot see the user's disk, so it does not guess and it does not ask for the code. It returns the exact read-only shell commands and file globs to run locally: one per detector in the prodready hardening catalogue — 25 numbered platform rules across wiring, configuration, multi-tenant isolation and row-level security, UI and internationalisation, operations, and compliance and lifecycle, plus the critical-rules set covering data integrity, API surface, state machines, auth and sessions, secrets, logging and tests.

Every command is read-only — grep and rg, find, ls, wc, head, cat, git, and their usual companions awk, sort and xargs. Nothing writes, nothing installs, and nothing a command does calls the network. Four checks carry a read-only query against the database's own catalogue; the plan marks those SQL> instead of $, they run only against a connection the user hands you, and no check depends on one. The credential detectors never print the line a match came from, so no secret value is read or sent.

By default the plan is every scoring probe plus the critical and high-severity detectors — the ones that decide whether the app is safe to put real users on. Pass depth:"full" for the whole catalogue, or depth:"stack" for just the commands that work out what the app is built on.

Run the steps, then hand what came back to prodready_assess for the graded report.

Step two: turn what prodready_probe's commands returned into a graded readiness report.

Gives back: findings mapped to the numbered rule each one breaks, with the evidence that proves it; a 0-100 score built from five dimensions of 20 — data, safety, tests, review, release — with a letter grade and a Green/Amber/Red standing; the checks that could not be evaluated, named rather than passed over; a link to the full report page in the prodready design (open it for the user — it is the deliverable, unlisted, kept seven days); and the next step: what closing the gaps would take, and what our SDLC covers that a scan cannot see. The scan is free.

Each finding names the gap and the consequence of leaving it in. It does not name the remedy: the diagnosis is free, the fix is the product. Do not ask this tool for a patch, a policy, a migration or a config — it has none to give, and it will not invent one.

Evidence is used for this one call and is never stored and never logged. Send counts, file paths and identifier names. Never send the contents of a .env, a key file, or any matched secret value.

Free. Step one of the 18-dimension technical due diligence of the user's own codebase — the deep review behind 'due diligence', 'deep review', 'audit the architecture'. Run prodready_probe and prodready_assess first if they have not run in this session (the end-to-end due diligence is both). Returns which dimensions apply to this stack and, for one dimension (or every applicable one when dimension is omitted — large), its 1-5 rubric, its checklist with item ids, the files and areas to read, and the exact JSON shape to hand back to prodready_dd_assess. Read-only; nothing is stored.

You read the code on this machine. Never send file contents, environment values or secrets: a finding is a checklist item id, a repository path (and line), a severity and a paraphrase of at most 200 characters naming the gap and its consequence — not a fix.

Free. Step two of the 18-dimension due diligence: hand back what you established per dimension with prodready_dd_brief. Validates it (unknown ids, scores outside 1-5, findings without a path are refused; a dimension with under 60% of its checklist answered is capped at 3 and marked partial; performance-load is scored only from load-test results you supply, otherwise it is 'not evaluated', never 1), then computes the weighted 1-5 score and grade, per-dimension risk (probability x impact), the 5x5 risk heatmap, compound risks across dimensions, the top findings and what could not be evaluated, and leaves a report page (link + six-character access code, seven days). Open the page for the user and give them the code.

The report names each gap, where it is and what it costs. It does not name the remedy and refuses fields that would carry one.

Whether the signed-in account holds the prodready SDLC licence, until when, where to unlock it, and what it contains. Free, and works before the licence is paid. Call it when an sdlc_* tool refuses, or when the user asks what the SDLC is.

Asks for the prodready SDLC licence for the signed-in account (monthly, cancel any time; the price is on prodready.si/pricing). The payment link is emailed to that address automatically; the sdlc_* tools unlock on this account the moment it is paid. Free. Call it when the user wants the SDLC after sdlc_licence_status or a refusal, never on their behalf without asking them first.

The projects on this account, with their ids. Works without an active licence, so a lapsed account can still find what to delete.

The project document as JSON for the local dashboard (npx https://prodready.si/dl/prodready-dashboard.tgz), which reads it and renders every page on the user's own computer. Read-only; nothing is stored. No nonce, write token or email address is included. With a licence it also carries the spec labels and the derived views (next step, counts); without one it still returns your own project data. Pass if_version (the version you already hold) to get { unchanged: true } instead of the document when nothing changed.

Deletes the project document, its index entry and its report pages. Cannot be undone. Works without an active licence: your data stays deletable after the licence ends.

Creates a project on the user's account and returns its id with the discovery brief: what to establish about the product before any story is written. Start here for a new app, a rebuild, or when the user wants their project run through our delivery process. Pass brownfield: true for an app that already exists.

Invite people to work on one of your projects with you: they see and work on the same backlog, sprints, documents, decisions, reports and ledger, each with their own agent and their own licence. invite (owner: project_id + email; sends them a join link), accept (code from the invite), list (project_id), remove (owner: project_id + email), leave (member: project_id). Two people never build the same story: a story someone started stays theirs.

The structured brief for one part of our delivery process: how stories are written, refined, estimated, built, reviewed and audited, the gates between them, and how open business decisions ship. Read the relevant brief before doing that step.

Discovery: what the product is, for whom, and what the first release holds, scored per knowledge area (0-100 in all). start: send the kinds and labels of the documents that exist here (never their contents), brownfield, and the scan or due-diligence score when there is one; returns the discovery plan (mode, round budget, areas, round 1's business questions, the rules). round: after reading and asking, send each area's score (0-20) and a short summary (counts and names only), the assumptions made, the questions still open (a non-blocking one carries its assumption), answers the owner gave, risks and contradictions; returns the knowledge score, the gaps and the next round. finish: at 80 or more, the first-release line, the features with priority and whether each has rough acceptance criteria; records gate GD (pass or fail). Read sdlc_playbook discovery first. The user says: 'discovery', 'gather requirements', 'interview me', 'here are my docs', 'next round', 'what's missing', 'finish discovery'.

The scope baseline: the objective, what is in and out of scope, assumptions, integrations and the architecture in a line each. A field sent replaces that list; a field left out is kept. Returns the scope and what is still missing before a statement of work can be issued. The user says: 'record the scope', 'this is in scope / out of scope', 'what did we agree is not included'.

Issues a new version of the statement of work from the recorded scope, backlog, sprints, risks and architecture: summary, scope, solution, sprint plan, deliverables, effort in points (no hours, no money), risks, acceptance (gates by name), timeline. format page (default) writes a report page and returns REPORT PAGE and ACCESS CODE — give the user both; format text returns the text only. The version is draft while a story is unsized or Draft, or the first-release line is only assumed. Needs the scope (sdlc_scope_set) and at least one story. The user says: 'statement of work', 'SoW', 'proposal', 'give me something to sign off', 're-issue the SoW'.

The product vision in business language: 2-5 user journeys (steps that point at modules), 4-8 modules each with 2-5 features (features point at the stories that build them), and the connections between modules. Status is never sent: each feature is built / in progress / planned from its stories on every read. The server checks every reference, refuses paths and code in names, and returns the diff against the stored version and the gaps (features without stories, modules no journey uses). Read sdlc_playbook vision first. The user says: 'product vision', 'what are we building', 'feature map', 'refresh the vision'.

The user journeys as screens and links: personas, screens (persona, route, the features it serves, its wireframe page), links between screens, and the critical journeys that are walked before a sprint completes. The server binds stories to screens and returns coverage per screen and the gaps (screens without stories, interface stories without a screen, links to unknown screens). Read sdlc_playbook journeys first. The user says: 'user journeys', 'user flows', 'storyflow', 'map the journeys'.

Records the wireframes drawn in this repository (paths only, never images): the design tokens by name, the navigation per persona, every page with its persona, file under .prodready/wireframes/, features and states, and the clickable prototype. Returns what is missing (vision features without a page, pages without all four states) and, unless assign is false, gives interface stories without a design reference the page that shows them. Read sdlc_playbook wireframes and follow it first. The user says: 'wireframes', 'mock-ups', 'clickable prototype', 'design the screens'.

The architecture document: a summary, up to eight standard sections (system architecture, data flow, entities, state machines, interface structure, security, deployment, integrations), each with an optional diagram as mermaid, plantuml or dot text, the decision records (context, decision, alternatives, consequences) and architectural improvements. A section sent replaces that section; records and improvements patch by id; an improvement with to_backlog becomes a Draft story. Code is refused anywhere but a diagram's source. Returns the sections present and missing, the records, the gaps and the diff. Read sdlc_playbook design first. The user says: 'architecture document', 'SDD', 'system design', 'architecture decisions', 'ADR'.

Records documentation produced by a generator in this repository (interface reference, schema, components, architecture, setup): the output path, the generator's path, when it ran and how many items it covered. Documentation here is produced by software that can run again, never written by hand: an entry without a generator is refused, and a generator that is not idempotent or not timestamped is listed as an open item. One entry per type; a new one replaces it. Read sdlc_playbook generate_docs first. The user says: 'generate the docs', 'documentation', 'API docs', 'regenerate the docs'.

The UI contract: route registry (path, screen, layout, nav group), navigation, layouts, shared components and token rules. Versioned; merged into the stored contract unless replace is true. Refuses duplicate or near-duplicate paths and nav entries to unknown routes; reports violations by stored stories (routes outside the registry, near-duplicates, orphan routes). Stories are then checked against it. The user says: 'UI contract', 'route registry', 'lock the routes', 'shared components', 'UI ugovor'.

The whole backlog in one validated, atomic write: sprints (outlined, with goal, theme, outcomes and their stories) plus unassigned stories, and optionally the UI contract. depends_on may name a story of the same call as "#<n>" (1-based across the call). ≤ 60 stories. Checks route uniqueness and the contract, and the structure (foundation first, 3–8 stories per sprint, ≤ 5 points, a build-and-deploy check story per sprint). dry_run: true returns the same and stores nothing — show it to the user first. Any refusal stores nothing. Read sdlc_playbook backlog first. The user says: 'create the backlog', 'write the backlog', 'turn the requirements into stories', 'import my backlog', 'napravi backlog'.

Stores user stories on a project. Each is checked against the story template and stored as Draft; what it still lacks is listed. Routes that collide with another story's, or that are missing from the UI contract, are refused. Read sdlc_playbook story_writing first; for a whole backlog use sdlc_backlog_import.

Records the answers to the refinement checklist for one story, with optional field updates. When every item is answered and the story fits the template, it becomes Ready (gate G0); otherwise the open items come back. Also how a Blocked story is released after a person has re-scoped it. v2: reasoning and sources per checklist id, selections (the question set of the round: options, default, pick, why), decisions (business questions filed with the story; it may still become Ready and ships the behaviour switched off), paused (a question nobody can answer from the sources: the story stays Draft and a blocking question is filed). Inside an autonomous session every answer needs its own reasoning (20+ characters), selections are required, blanket reasons are refused, and a third failed round pauses the story.

Autonomous refinement: start opens a refinement session over the Draft stories of the backlog (or one sprint) and returns the brief for the first story — the checklist, the sources to read and the rule: answer from the sources; a real business question becomes a decision, never a question to the user. submit applies sdlc_refine v2 per story (≤ 5 per call; reasoning per answer, selections, decisions, paused) and returns the next brief; status lists the queue, the results and the open decisions ("answer D-n: <your answer>"); finish closes the session with the report { refined, paused, decisions_raised }. start needs the person's own go-ahead in authorised_words (for example 'refine the backlog on autopilot') unless an autonomous session is active.

Creates a sprint with one business goal and the refined stories that deliver it, or — with sprint_id — promotes an outlined sprint from the imported backlog once its stories are refined. Stories that have not passed refinement are refused.

Makes a planned sprint the active one and returns the sprint brief: the goal, the stories in build order and the cycle to follow.

Runs the preflight check (G2) on a story in the active sprint and, when it passes, moves it to In Development and returns the builder brief: execution rules, coding standards, the definition of done and the story itself.

Records the results of the project's own typecheck, lint, build and tests for a story in development, exactly as they came out. All four pass: the story moves to In QA (gate G3). A failure counts as one attempt; the third failed attempt blocks the story.

For a verified story: returns three reviewer briefs — architecture, security, functional — each with its own one-time nonce. Run each review in a fresh context (a separate sub-agent with no memory of the build), then submit each with sdlc_review_submit.

Records one reviewer's scores, findings and verdict, using the nonce issued to that reviewer for that story. When all three are in, the story is either cleared for Done (G4) or sent back to development with every finding as a task.

Marks a story Done once verify (G3) and the three-reviewer approval (G4) are on record, and records the pushed branch or commit (G6).

When no story in the active sprint is still in flight: returns the audit brief — five dimensions, what to check in each, and when the audit blocks.

Records the audit's five scores (0-5) and findings. Any dimension at 1 or below, or any critical finding, blocks the sprint until the findings are fixed and the audit is run again.

Completes an audited delivery sprint and records the critical user journeys walked end to end (G7), the merge (G6, scope sprint) and readiness after the sprint (G8: the sprint's recorded due-diligence and load-test runs; score 3 or more passes, 4 meets the target). Stories that did not reach Done return to the backlog; the retrospective follows (sdlc_sprint_retro). A hardening or hotfix sprint completes when every story is Done or escalated and a clean sdlc_bug_detect on it is newer than its last Done. The user says: 'complete the sprint', 'close the sprint', 'finish sprint 2', 'merge the sprint', 'zaključi sprint'.

The retrospective of a completed sprint: what went well, what to improve, what was blocked and why, and actual hours or points per story. The server tabulates estimates against actuals, stores the recalibration factor and says when sizes run outside the estimation bounds. The next delivery sprint does not start until the previous one has its retro. The user says: 'retro', 'retrospective', 'what did we deliver', 'what went wrong this sprint', 'retrospektiva'.

Adds a row to the decision register. kind business (default): a business question nobody has answered yet, who must answer it, and how the behaviour ships until then (switched off, or a conservative default). kind question: an open question with its urgency and the agent's best assumption. kind assumption: something the agent assumed, with its reasoning and confidence. Technical choices belong in the architecture document (sdlc_design_set), not here. Returns the register.

Records the answer to an open row with its date and returns the register. by owner (default) is the owner's own answer — pass their words in owner_words; by agent may only assume a non-blocking question. override: true changes a decided row by appending a new row. Stories built on a changed answer are re-opened or get a task, and the result lists them.

Adds or updates risks (with id: update). Scores probability × impact into bands (20–25 critical, 12–19 high, 6–11 medium, 1–5 low), flags duplicates by title, returns the sprint risk profile and buffer (10/20/30%) and which critical risks hold sdlc_sprint_start. A vague mitigation ('monitor', 'tbd', under 10 characters) is refused; accepting a risk needs a rationale and files a decision; spike: true drafts a spike story. The user says: 'risks', 'risk register', 'what could go wrong', 'add a risk', 'we accept that risk', 'rizici'.

A computed prediction (no model call): five dimensions × 20 — requirements clarity, technical feasibility, scope control, risk profile, delivery confidence — from your evidence plus what the project already records (stories, open questions, risks, the latest due diligence, verify and rework history). Grade A–F with RAG, hard caps and the delta against the last prediction. A grade F holds sdlc_sprint_start. The user says: 'will this succeed', 'success prediction', 'what are our chances', 're-score', 'hoće li uspjeti'.

Files one bug as a bug story ("Fix: …") with its severity, repro steps, expected and actual behaviour. With its evidence (error_summary, location path:line and category) and outside an active delivery sprint it is refined by the bug template (G0) and lands Ready; otherwise it lands Draft and is refined like any story. A report matching an open bug's check and location is attached to it. next fix_now (critical/high) leads to sdlc_hotfix_start. The user says: 'report a bug', 'there's a bug', 'this is broken', 'prijavi bug'.

Records a whole-suite sweep — typecheck, lint, build, tests and e2e as your agent ran them — and triages every failure into a proposed bug (build critical; typecheck and tests high; lint medium), grouped by area, deduplicated, with the hardening cycle (n of 3). Recorded as gate G3 with scope sprint (never a story's verify failure). Clean → the next step; failures → sdlc_sprint_harden; at cycle 3 the remaining bug stories are Blocked for a person. The user says: 'find bugs', 'what's broken?', 'is everything green?', 'bug sweep', 're-test'.

Opens a hardening sprint — restore a green suite, no new features — from a failing sdlc_bug_detect (detection_id, with the bug stories to fix, or the detection's own failures when stories is omitted) or from queued bugs (bug_ids). Bug stories from a detection are refined by the bug template (G0). Returns the hardening brief and the first story by severity. Cycle budget 3. The user says: 'harden it', 'hardening sprint', 'fix what's broken', 'make the build green', 'fix the queued bugs'.

The fast track for a critical or high bug: a hotfix sprint beside any active delivery sprint, holding one bug story marked hotfix. Preflight (G2), verify (G3, three attempts), the three reviews (G4, no shortcut) and push (G6) stay mandatory; then sdlc_bug_detect on the hotfix sprint and sdlc_sprint_complete. Pass story_id (an existing refined bug story) or bug (the sdlc_bug_report fields, with its evidence). The user says: 'hotfix', 'production is down', 'urgent fix', 'P0', 'SEV1', 'hitno popravi'.

Records a due-diligence run on this project — the fields from prodready_dd_assess (and optionally prodready_assess) — as DD-n: overall, grade, dimension scores, findings by severity and the top risks, never remedies. With the report_id of this account's due-diligence page from the last seven days the figures are taken from the server's own summary (server-scored); otherwise the run is self-attested. Updates the readiness and its trend toward the target of 4 out of 5. The user says: 'record the due diligence on the project', 'due-diligence trend', 'are we at 4 out of 5'.

Records k6-style load-test results (aggregate, per route, capacity): scored 1–5 with the due diligence's load-test bands, pass or fail against the thresholds (p95 800 ms, 5% errors by default), and a verdict against the previous run of the same profile. A run with sprint_id is that sprint's readiness load test (G8). Credentials only from environment variables; target_label is an environment name or bare host. Inside an unattended session only smoke runs, unless limits.perf names the profile and target. The user says: 'load test', 'performance test', 'how fast is it', 'capacity', 'run k6'.

Records the monitoring checklist (M-01…M-10: yes, no or n/a), the monitored targets and production incidents. Scores the monitoring, flags "armed but blind" when no target was seen in 24 hours, turns a SEV1 with its evidence into a critical bug story (next sdlc_hotfix_start) and reminds you of missing postmortems. The same incident twice within 15 minutes is refused. The user says: 'monitoring', 'alerts', 'is it monitored', 'incident', 'postmortem', 'uptime', 'on-call', 'nadzor'.

plan: a release (REL-n) of completed sprints with a derived changelog — Done stories by type, fixed bugs, decisions that ship switched off as known limitations, implemented change requests. Refused for a sprint that is not completed, already in a live release, or holding an open blocking question. advance: planned → staging (deployed to a non-production environment with a passing smoke check) → ready (rollback plan and a readiness score of 3 or more on record) → released (approved_by a role, merge_commit and a production deployment with a passing smoke check). rollback: released → rolled_back with a reason. Releasing and rolling back are a person's steps. Environment labels are names only — no URL, host or credentials. The user says: 'release', 'cut a release', 'ship version 1.2', 'ship it', 'deploy to staging', 'changelog', 'release notes', 'roll back', 'izdanje'.

submit: a change to the agreed scope (CR-nnn) — stories to add, modify or remove — with its impact computed: points added / removed / changed, stories and sprints affected, whether the active sprint is touched, the delta against the statement of work. At most 5 open at a time. decide (a person's step, reviewed_by a role): approved adds the new stories as Draft (origin change_request), applies the changes (the story is refined again), removes stories that have not started, and marks the SoW stale; rejected or deferred changes nothing. A story in flight or Done is not modified or removed (a Done story changes through a new story). The user says: 'change request', 'the client wants …', 'scope change', 'add this to the scope', 'drop that feature', 'zahtjev za promjenu'.

Read-only metrics computed from the project: per sprint the stories total / Done / Blocked / carried over, completion, points planned and done (velocity), verify failures (story G3 rows only), rework cycles, the review rejection rate, audit rounds, cycle time (median, p90), estimate accuracy from the retro, gate pass/fail counts, bottlenecks (top 5), retry root causes, per owner, tokens where the host reported them, the readiness trend and — with compare — the trend between sprints with neutral signals. Nothing is stored; the recommendations are yours, written into sdlc_sprint_retro improve. The user says: 'sprint analytics', 'velocity', 'how fast are we', 'burndown', 'how did the sprint go', 'bottlenecks', 'compare sprints', 'analitika'.

The board by state, the gate ledger summary, open decisions and questions, discovery, risks and documents, and the next allowed step. Call it whenever you are unsure what comes next. With story_id it prints that one story in full — how a builder, reviewer or auditor fetches a story a brief listed by id. With a reviewer's one-time nonce it prints that reviewer's brief and the story, so the host hands a reviewer only its nonce.

The project and sprint report as text, plus an unlisted page on mcp.prodready.si in the prodready design, kept for seven days. Open it for the user and give them the link.

The whole project as one self-contained HTML file for the user's own computer: board, backlog, sprints, gate ledger, reviews, decisions, audits, timeline, cost and report pages. Save the attached file as .prodready/dashboard.html in the repository and open it in the browser; call this again after each step to refresh it. Nothing is stored on the server. format "summary" returns the counts as text only.

Autonomous work. start opens a session (limits: stories, sprints, minutes; defaults 1 sprint and 240 minutes) — it needs the person's go-ahead in their own words (authorised_words, e.g. 'run it unattended for one sprint'). status returns the ONE next step of the loop: do exactly that step, then call status again; it pauses with needs_human when a blocking question or a Blocked story needs a person, stops at a limit, and lists the questions (blocking, pending with when each is assumed, assumed) — show them to the user every cycle and keep working. pause, resume, stop ('SDLC off') and compact manage the session; pause and stop work without a licence.