01
Current state
There is no active DewEngine role on this page
A careers route can easily imply more than the project can support. Listing a discipline, describing an ideal colleague, or adding an application button may look like an open position even when no approved role exists. This page avoids that ambiguity. It names no vacancy, start date, headcount target, engagement type, or selection process. When a genuine need is approved, the role should appear as a specific dated record rather than being reconstructed from general product ambitions.
02
Evidence first
A real posting must define the work and its authority
Any future listing should identify the problem to be owned, expected outcomes, reporting relationship, decision authority, employment or contracting basis, location constraints, working hours, and evaluation steps. It should also name who can answer questions and when applications close. Those details cannot be inferred from the repository's engineering roadmap. Publishing them only after approval protects candidates from investing time in a speculative position and protects the project from making accidental commitments.
03
Product context
The repository shows workstreams, not a staffing plan
DewEngine spans website content, a console preview, control-plane and worker services, a TypeScript SDK, local packaging, security boundaries, provider research, and release evidence. These areas explain the kind of product being developed, but they do not establish separate jobs or a team structure. A future posting may draw from one of those workstreams only when scope, budget authority, supervision, and a fair assessment process have been decided.
04
Candidate clarity
Compensation and conditions belong in the actual role
This placeholder makes no statement about salary, currency, equity, benefits, leave, equipment, remote work, office attendance, visas, probation, or working jurisdiction. Those are material conditions, not decorative details. If hiring begins, the applicable posting should disclose what can be disclosed, distinguish fixed terms from negotiable ones, and avoid ranges or benefits that have not been authorized. Candidates should not have to interpret marketing copy to learn the basic shape of an opportunity.
05
Assessment principles
Future evaluation should use the work that matters
A credible process would connect each assessment to the published outcomes of the role, tell candidates what to expect, minimize unpaid speculative work, and use consistent decision criteria. It should provide a way to request reasonable participation adjustments and explain how submitted materials will be handled. These are principles for designing a later process, not claims about a process operating now. No interview stages, response times, or candidate-data rules have been finalized for DewEngine.
06
Contact boundary
The general email is not an application portal
The site currently publishes roki@dewx.com for general conversation. That evidence does not turn the mailbox into a recruitment system or guarantee review, storage, deletion, acknowledgement, or a reply to unsolicited career material. Avoid sending identity documents, financial information, credentials, references, or other sensitive records. If a future role opens, its own posting should provide the authorized submission path and the privacy information relevant to candidates.
07
Publication standard
Close or update roles visibly when their state changes
A future careers page should distinguish open, paused, filled, and closed positions and attach a date to each change. Removing an application link while leaving recruitment language in place would still mislead readers. The site should also avoid evergreen talent-pool language unless a real intake purpose, review owner, retention rule, and opt-out path exist. Until those foundations are present, the accurate careers message is simply that no role is being advertised.