Concepts
Duties: what your team does
Duscode works like an engineering team with six duties: Build, Ship, Host, Watch, Maintain and Fix. What each one does today, what it asks you, and where to see it.
Duscode is your engineering team. Dus builds your software, runs it on your servers and keeps it healthy. You approve what matters: anything that costs money, goes public or can't be undone.
The work splits into six duties. Each one ends in something you can check yourself, never just Dus's word.
| Duty | What Dus does | What you decide | Where you see it |
|---|---|---|---|
| Build | Plans the work, writes code in your project's own framework, runs your checks | What to build; product choices | The chat, and the task's Proof of Work |
| Ship | Commits, opens the pull request, checks it with CI (or Local CI on your computer), fixes failures, merges | What goes into main | Shipping |
| Host | Puts your app on your own server or host, checks it's healthy, keeps a rollback | The first deploy, anything that costs money | Deploy |
| Watch | Checks your live systems, opens an incident when something breaks, acts within the limits you set | What Dus may do by himself | Watch |
| Maintain | Runs routine jobs on a schedule, each with a budget and a record | The schedule and the budget | Scheduled jobs |
| Fix | Finds the cause of a failure, proves it with a test, fixes it, shows the evidence | Whether the fix goes live | The chat and the Proof of Work |
Coming soon
One switch per duty, per project, so you can say "build and ship this one, but don't host it". Today every duty is available in every project, and Dus asks before each one that needs you.
How "done" is decided
Dus doesn't call a duty done because he says so. Every task records what actually ran: the commands and their exit codes, the tests, screenshots of the page, the live address after a deploy. That record is the Proof of Work. If something couldn't be checked, the proof says Not checked or Partially verified, with what's left.
What Dus always asks you
- Spending money: a paid service, a bigger plan, a top-up.
- Going public: the first deploy of an app, publishing a package, sending email to real people.
- Anything that can't be undone: deleting data, dropping a database table, force-pushing.
- Product choices: what the app should do, who it's for, how it should look.
He asks in plain words, with a recommendation and what happens either way. See When Dus needs you.
What Dus won't promise
Software fails sometimes, and so does Dus. When something goes wrong he says so plainly, shows the evidence, and either fixes it or tells you what he needs. Nothing makes a system impossible to break into; Dus builds to a recognised security standard and tests it (Security).