Devine vocabulary for product, code, specs, and sprint work.
- Product and brand
- Pet state and scoring
- Activity and game loop
- daily.dev integration
- Share and privacy
- Workflow
The project name for the daily.dev-powered rubber duck companion app. Devine turns developer reading and engagement signals into pet state, quests, and shareable progress.
The product tagline is “Define your stack, develop your mind.” It frames the app as a developer learning habit product rather than a generic pet game.
The central virtual pet and companion. It represents the user's learning habit through visual state, speech bubbles, seniority level, health, energy, quests, and power-ups.
A first-class app mode that lets judges and contributors try Devine without connecting a real daily.dev Personal Access Token. Demo mode is required to keep the live demo reliable when credentials or daily.dev API access are unavailable.
The app mode where a user connects a daily.dev Personal Access Token and Devine uses available personalized daily.dev data. Connected mode must degrade gracefully when daily.dev requests fail.
The 60-second hackathon demonstration path that shows the landing page, dashboard, simulated activity, game-state changes, and a public share snapshot.
The fast-moving daily habit metric earned from reading and engagement actions. The documented daily target is 50 energy.
The pet's survivability and visual condition state. Health is clamped between 0 and 100 and changes faster than seniority.
The named visual condition derived from health. The documented states are Thriving, Stable, Tired, Sick, Critical, and Hibernating.
The lowest recoverable health state. It replaces permanent death so a user can return after missing learning targets.
The displayed maturity narrative based on a rolling 7-day learning-quality score. Seniority changes more slowly than health.
A 0 to 100 score based on recent reading consistency, topic variety, curation, discussion, social contribution, and deep technology signals.
The lowest seniority level for low or shallow learning behavior. It appears in docs and product language as a satirical developer maturity state.
The seniority level for passive reading or recoverable midpoint behavior. The default judge demo persona starts here.
The seniority level for active curation and grounded learning behavior.
The highest seniority level for reflective, high-quality engagement.
Interactions with topics such as architecture, system design, distributed systems, security, AI, machine learning, DevOps, cloud, database, performance, and observability.
The process of standardizing tags before scoring. Examples include lowercasing, converting spaces to hyphens, and mapping aliases such as ml to machine-learning.
A normalized record of a learning or engagement action. Events may come from daily.dev data, in-app Devine tracking, or demo simulation.
The maximum amount of daily credit a repeated action type can earn. Caps prevent farming and encourage varied learning behavior.
The daily energy threshold needed to keep the duck stable or improve health. The documented target is 50 energy.
The health decay applied when a user opens the dashboard after missing learning targets. The MVP calculates this on dashboard open instead of using background jobs.
A short-term task that nudges the user toward better learning behavior. The documented quest types include daily quests, one personalized quest, and a weekly five-day learning streak quest.
A quest selected from the user's weakest seniority component. It nudges the user toward balanced learning habits.
An inventory item earned through quests and used manually. Power-ups affect energy or health but must not directly change seniority score.
A power-up that adds energy.
A power-up that restores health.
A power-up that doubles the next read reward.
A power-up that doubles the next comment or share reward.
A power-up that helps recover from Critical or Hibernating health ranges.
A dashboard recommendation for the most useful action type or topic to improve the user's current learning habit.
Positive guidance that encourages curation, discussion, or stopping after useful reading instead of endless passive browsing.
Playful duck copy generated from templates and lightweight context such as seniority, health state, top tags, recent bookmarks, and weakest score area.
The developer content platform that supplies the content and personalization context for Devine.
A user-provided daily.dev Bearer token used for personalized API access. Tokens must be stored encrypted server-side and never exposed to the browser.
The process of testing whether a submitted daily.dev token works before marking a connection active.
The user's ability to disconnect daily.dev and delete stored token data from Devine.
An optional app-owned token reserved for fallback, demo, or non-personal content access. It must not be used to infer personal user behavior.
A daily.dev API constraint that connected-mode requests must respect. Rate-limit failures should produce recoverable user-facing states.
A degraded but usable behavior path when daily.dev data is unavailable. Demo mode and stored share pages must continue to work without daily.dev.
A static public record of a user's Devine state at one point in time. It does not update unexpectedly after creation.
An unauthenticated route that renders a share snapshot from a public snapshot ID.
The allowlisted data shape exposed on public share pages. It includes aggregate fields such as seniority level, seniority score, health state, top tags, speech bubble, generated date, and powered-by attribution.
Detailed user activity such as raw events, article lists, comments, user IDs, daily.dev profile IDs, tokens, and credentials. Private activity must not appear in public share snapshots.
A deletion model where share snapshots can be marked deleted while preserving enough metadata for retention and audit behavior.
The process for removing old soft-deleted share data while preserving required private event, token history, and audit retention boundaries.
A shippable engineering task listed in docs/TASK_BREAKDOWN.md. Cards cite acceptance criteria and source docs.
A testable requirement identified by an AC ID under docs/business/. Code changes should trace back to relevant acceptance criteria.
A card that proves frontend and backend work together end-to-end in the running app.
The full merge gate defined in package.json: type checking, linting, formatting, unit tests, E2E tests, and build.
The local-only guarded endpoint for resetting development state. It must not be reachable in production.