just-vibe 0.7.0

package/plugins/just-vibe/references/packs/ml-experiments.md

@@ -0,0 +1,29 @@
+# ML experiment methods
+
+Resolve dataset/split identity, objective, metric, code/environment, hardware and time/compute budget. Record configuration and seed, but do not promise determinism from a seed alone. Keep the held-out test set untouched during model selection.
+
+Establish a naive and simple-model baseline under the same protocol. Training begins with a small shape/data/loss smoke check, then bounded execution with checkpoints, optimizer/scheduler state and resume instructions. NaNs, exhausted budgets and partial runs have explicit terminal states.
+
+Debug the first numerical or semantic divergence: inputs/targets, scale, loss, gradients, optimizer and update behavior. A tiny-batch overfit probe can discriminate pipeline failures from generalization problems; it is not a reason to launch a large new run.
+
+Tuning fixes search space, trial budget, pruning and selection criteria before execution. Ablations hold data/protocol constant and distinguish noise from component contribution. Run comparison checks dataset, metric definitions and failures, not just headline scores. Reproduction uses exact artifacts or declares substitutions and tolerances. Cost analysis separates loading/compute/checkpoint time and only uses verified rates for monetary estimates.
+
+## Applied methods
+
+### Framework branches
+
+For classical estimators, preserve fitted preprocessing and the estimator together, record train/validation membership and compare a naive baseline. For iterative tensor training, inspect data/target shapes, device and dtype, loss inputs, gradient flow and optimizer updates on a small controlled batch before a longer run. Respect the repository's framework/version conventions rather than introducing a second training stack.
+
+### Checkpoint acceptance
+
+A PyTorch checkpoint for continuing training normally includes model and optimizer state plus progress; restoring weights alone does not reproduce optimizer history. Select train/eval mode deliberately after loading. [PyTorch checkpoint guidance](https://docs.pytorch.org/tutorials/recipes/recipes/saving_and_loading_a_general_checkpoint.html).
+
+For the actual project, also inventory scheduler, mixed-precision scaler when used, RNG state, data/sampler position and gradient-accumulation state if resuming mid-step. Record what the framework owns automatically. A safe simpler policy may checkpoint only at defined completed-step/epoch boundaries and document the resume granularity. Write atomically, identify code/data/config, and retain the last known-good checkpoint.
+
+Test an interrupted run against an uninterrupted short run under declared tolerances. Report nondeterministic differences rather than promising determinism from a seed. A missing continuation component means restart or approximate resume, not exact continuation.
+
+### Debugging and selection
+
+Locate the first divergent batch/tensor/update for NaNs or non-learning. Check objective semantics and target scale before changing model size. A tiny-batch overfit probe tests plumbing, not generalization.
+
+Freeze tuning space, metric, trial caps and selection data first. Keep failed/pruned trials in the ledger. Compare ablations under matched data/protocol; separate noise from component contribution. Test-set feedback must not become another optimization loop. Track resource use per completed useful result, not only the best successful trial.

package/plugins/just-vibe/references/packs/operations.md

@@ -0,0 +1,35 @@
+# Operations methods
+
+Resolve service/environment, incident window, revision and authorized evidence sources. Normalize timezone/clock differences and correlate request/job IDs. Separate customer impact, observed facts, hypotheses and proposed interventions. Missing telemetry is not proof of no impact.
+
+Start with evidence-preserving diagnostics. A coincident deployment is not automatically causal. Restarts, failovers, cancellation, traffic changes and customer messages need the exact requested operational authority; do not perform them while merely writing an incident brief.
+
+Instrumentation answers concrete questions with redacted fields and bounded cardinality/overhead. Alerts connect a meaningful signal/window to a responder action, missing-data behavior and recovery; writing a rule does not enable notifications or establish ownership.
+
+Runbooks use verified target checks, commands, expected results, abort conditions and recovery. Container diagnosis compares build/runtime stages, paths, user permissions, entrypoints and health behavior; no privileged mounts by default. Restore exercises verify backup identity and an isolated destination, then schema/counts/integrity/application behavior and recovery timing. A readable backup is not a successful restore.
+
+Postmortems preserve uncertainty, distinguish trigger from systemic contributors, and map each follow-up to a demonstrated failure mechanism. Do not invent impact counts, owners or consensus, or post reports/tickets without instructions.
+
+## Applied methods
+
+### Incident ledger
+
+Record timestamp/time zone, observation, source, hypothesis, action, expected result and actual result. Establish customer impact and affected revision separately from correlated changes. A deployment near the failure is a hypothesis until supported. Preserve logs/state before interventions that may erase evidence.
+
+### Logs and instrumentation
+
+Follow stable request/job IDs across asynchronous boundaries and account for clock skew. Repeated retry errors may be symptoms of one earlier cause. Missing spans remain gaps. Query bounded time ranges and redact sensitive values.
+
+Design telemetry around questions: which revision, tenant-safe cohort, dependency, stage and failure category? Keep arbitrary user IDs out of metric labels. Check success and failure instrumentation plus privacy and overhead on controlled requests.
+
+### Runbook and alert example
+
+For a queue backlog alert, define sustained age/impact, missing telemetry, recovery condition and responder action. A transient spike may need no page; absent data should not silently count as healthy. Name ownership as proposed when it is unknown.
+
+A runbook step states exact target, precondition, action, expected observation and abort/recovery path. Mark unexercised commands clearly. Writing a runbook does not authorize executing its production steps.
+
+### Restore and postmortem
+
+Rehearse backups in an isolated destination with verified identity and keys. Validate schema, membership/counts, integrity and application behavior; a readable archive alone does not demonstrate recovery. Record elapsed recovery and the actual data-loss window.
+
+Postmortems distinguish trigger, contributing conditions and detection/recovery gaps. Each action should address an observed failure mechanism with a measurable outcome. Preserve unknown root cause or impact instead of inventing a complete story.

package/plugins/just-vibe/references/packs/react.md

@@ -0,0 +1,29 @@
+# React methods
+
+Identify React/framework versions, server/client boundaries, data-fetching conventions and component state owners. Follow data from the source of truth through props, context, hooks and derived state. Preserve the existing state/fetch library unless changing it is requested.
+
+Effects synchronize external systems. Check identity, dependency, cleanup and remount behavior; do not suppress dependency warnings to disguise stale closures. Reproduce out-of-order requests deterministically, and ensure stale responses cannot overwrite a newer account/query. Cancellation does not undo server-side effects.
+
+Render performance requires profiler/interaction evidence. Find changing props/context and expensive work before introducing memoization, then compare the same interaction. State refactoring must preserve independent instances, resets, persistence and user-visible transitions.
+
+Components/forms include valid, loading, invalid, failed, disabled and success behavior where applicable. Preserve input on recoverable errors; connect labels, errors and focus. Hydration work compares server and first client output, including time, randomness, locale, browser-only data and invalid nesting; suppressing the warning is not a fix.
+
+## Applied methods
+
+### Request-race fixture
+
+For an account panel, control two deferred responses: select A, select B, resolve B, then resolve A. The final visible account must remain B. Separately unmount before completion. A cleanup abort may reduce work, but response identity or an equivalent library guarantee must prevent stale state updates. Do not assert that aborting a request reverses a server-side mutation.
+
+Effects synchronize with external systems. Derived display values often belong in rendering. Check dependencies and cleanup across setup, changed inputs and unmount; development remount checks can reveal missing cleanup. Follow the installed React/framework semantics rather than suppressing warnings. [React useEffect](https://react.dev/reference/react/useEffect).
+
+### State and form contracts
+
+Name the source of truth for each value. A draft may intentionally differ from a prop; define when it resets instead of copying props into state on every update. Test two independent component instances to catch accidental shared state.
+
+For forms, exercise editing, invalid input, pending submission, server rejection and retry. Preserve values after a recoverable rejection, associate field errors programmatically and return focus deliberately. UI pending state alone does not prevent duplicate server effects.
+
+### Performance and hydration
+
+Capture one slow interaction with fixed data. Inspect render and commit duration, changing prop/context identities and expensive work before memoization. Re-run the same interaction and check that callbacks/data remain current; lower render count alone is not a useful result.
+
+For hydration, compare server markup and first client output before effects. Check locale, time, randomness, browser-only storage and invalid nesting. Resolve an inconsistent initial snapshot or define an intentional boundary; hiding warnings does not establish matching output or working controls.

package/plugins/just-vibe/references/packs/security.md

@@ -0,0 +1,31 @@
+# Security methods
+
+Define assets, trust boundaries, entry points, authorized code/environment and relevant policies. Follow reachable data/privilege paths and distinguish demonstrated weaknesses from speculation. Read-only source audits do not authorize live attacks or third-party probing.
+
+Authorization covers direct IDs, alternate methods, exports, jobs and tenant boundaries, using isolated identities for active checks. Input audits trace values to actual interpreters/sinks and account for contextual escaping or parameterization; user input alone is not proof of injection.
+
+Secret scanning reports redacted location/type/confidence. Never print or validate suspected live credentials against a provider without authorization. Rotation, history rewriting and incident notification are separate actions. Upload audits follow validation, processing, path/storage boundaries and download authorization; do not execute hostile files to prove a point.
+
+Dependencies are assessed against resolved versions, current authoritative advisories and actual exposure. Config review distinguishes development from production and inspects effective settings when available. Fixes test the original unsafe path plus legitimate behavior at the correct boundary; a code patch does not erase prior data or credential exposure.
+
+## Applied methods
+
+### Evidence classification
+
+For each finding record attacker capability, source, transformations, sensitive sink, existing control, triggering condition and impact. Separate confirmed reachable defects from conditional risks and unknown configuration. A suspicious function name or dependency advisory alone does not prove exploitability.
+
+### Authorization and input examples
+
+Build positive and negative cases for subject/action/resource/tenant. Test direct IDs, alternate methods, exports and workers with synthetic identities. An authenticated user is not necessarily authorized for the resource; UI visibility is not enforcement.
+
+For injection, trace the final interpreter boundary. Parameterized SQL and appropriate contextual escaping can change the conclusion even when input is untrusted. Avoid destructive payloads; use controlled fixtures that demonstrate the violated invariant.
+
+### Upload and secret lifecycle
+
+Check upload receipt, quarantine, processing, storage and download authorization. Validate actual content and resource bounds as applicable; do not trust a filename extension or let quarantined files bypass controls through another endpoint. Keep hostile samples inert and isolated.
+
+Secret reports contain locations/types and redacted evidence, never credential values. Distinguish test placeholders. Do not try suspected credentials against providers. A code fix does not rotate an exposed credential or erase its history; list operational follow-up separately.
+
+### Dependency and configuration triage
+
+Match advisories to resolved versions, deployed use and required configuration. Separate dev tooling from runtime exposure. Review effective production settings rather than labeling every development exception a live incident. Missing access means unknown coverage. Repair the owning boundary and test both abuse and legitimate behavior before claiming the requested vulnerability is fixed.

package/plugins/just-vibe/references/packs/testing.md

@@ -0,0 +1,35 @@
+# Testing methods
+
+Read behavior requirements and existing test conventions. Choose the lowest layer that reliably protects the invariant: unit for isolated behavior, integration for real boundaries, end-to-end for critical journeys. Preserve the distinction between real dependency evidence and mocks.
+
+Regression tests reproduce the actual trigger and, when feasible, fail on the broken revision before passing on the fix. Assertions target behavior, not helper call order. Fixtures use minimal realistic deterministic data, isolated identities and cleanup; never copy private production data for convenience.
+
+Flaky tests require controlled order/seed/repetition evidence. Diagnose shared state, timing, races, environment and cleanup before changing timeouts. Record trial counts and residual uncertainty. Retries/skips do not repair a flaky invariant.
+
+Property tests define valid generators and invariants, bound iterations, shrink failures and record seeds. Avoid filtering away difficult inputs or asserting tautologies. Load tests require exact authorized target, workload, rate/concurrency/duration caps, observability and error/resource stop thresholds. Neither a local fixture nor a staging test implies permission to stress production or trigger real payments/messages.
+
+## Applied methods
+
+### Layer choice
+
+Use a unit test for a pure contract, integration test for a real boundary and end-to-end test for a critical user journey. Do not put all edge permutations in the browser when a lower layer observes the same invariant reliably. Conversely, a mocked database is not proof of real transaction or policy behavior.
+
+### Independent assertion example
+
+For a checkout total, calculate a small expected amount from the stated pricing rule rather than calling the same helper as the implementation. Cover null coupon and zero-valued discount separately. A regression test should fail on the actual broken path; setup failure does not demonstrate regression sensitivity. Preserve the original assertion while fixing the implementation.
+
+When checking sensitivity, isolate the broken implementation in a temporary copy or worktree and preserve the real index and unrelated edits. Record the failing assertion or unexpected behavior exception and its causal path. A missing new helper import, parse failure in the test, or timeout before any assertion is inconclusive. An exception raised by the original implementation on a documented valid input can be the actual regression; do not require every useful test failure to have one exception class. For asynchronous tests, bound waits and release deferred resources even when an assertion fails so later checks can finish.
+
+Test evaluators too: known-good controls should pass, seeded defects should fail, missing output and incomplete runs must not become successes. If an evaluator bug is found, retain the original scores, document the correction and rescore every affected arm under the same rule. Never silently alter a rubric for one favored result.
+
+### Flakes and fixtures
+
+Capture test order, seed, clock and resource identity. Force the suspected interleaving with controlled deferred work instead of arbitrary sleeps. Reproduce at a bounded repeat count and report the observed sample; zero failures does not mathematically prove absence.
+
+Fixtures need valid defaults and intentional invalid variants, unique identities under concurrency and cleanup after partial setup. Property tests need independently stated invariants and constructive generators; reject excessive filtering and preserve shrunk counterexamples/seeds.
+
+### Load and browser evidence
+
+Before load generation, fix endpoint/environment, rate/concurrency/duration caps, error/load stop thresholds and side-effect isolation. Stop on thresholds and record the last stable conditions.
+
+Browser tests should use user-visible outcomes and resilient semantic locators, inspect pending/error/recovery states and preserve useful artifacts on failure. A screenshot can establish appearance at one state; it does not establish keyboard behavior or every viewport. Unavailable dependencies remain explicit coverage gaps.

package/plugins/just-vibe/references/packs/ui.md

@@ -0,0 +1,29 @@
+# UI methods
+
+Read existing tokens/components and inspect the actual requested flow before editing. Establish viewport, theme, content, state and font conditions for comparisons. Screenshots at different conditions cannot support precise visual-difference claims.
+
+Prioritize hierarchy, readability, primary action, recovery and content flow. Responsive work examines intrinsic widths, long text, intermediate breakpoints, zoom and input method; do not hide required content to fit a screenshot. Reuse semantic tokens rather than scatter near-duplicate hard-coded values.
+
+Accessibility checks combine source/automated evidence with keyboard and focus behavior. Verify dialog entry/escape/return focus, error associations and dynamic announcements; label screen-reader checks unverified if not exercised. Motion needs interruption, cancellation and reduced-motion behavior that preserves all functionality.
+
+For flows, enumerate entry, normal completion, cancellation, failure/retry and back navigation. Product policy determines transitions; do not invent billing or account rules. Report exactly which views/states were inspected and which remain unverified.
+
+## Applied methods
+
+### State and viewport matrix
+
+Choose representative normal, empty, loading, error and long-content states for the actual journey. Inspect a narrow, intermediate and wide layout plus relevant zoom/input conditions. These are samples, not a claim of every device. Capture the viewport, DPR, theme, fonts and content when comparing visuals.
+
+For a narrow settings screen, identify the intrinsic constraint causing overflow: fixed width, unbreakable content, grid minimum or an oversized child. Reflow it and verify focus and actions remain reachable. Hiding required controls is not responsive repair.
+
+### Interaction checks
+
+For a dialog: open by keyboard, confirm initial focus, traverse the intended focus sequence, close through supported methods and verify focus returns appropriately. For a form: activate labels, submit invalid data, inspect error association/announcement and retry while retaining input. Record the browser and assistive technology actually used. Automated scans and source review do not establish complete accessibility conformance.
+
+For partial-data errors, keep valid content visible and identify the failed region. Empty data and failed fetching have different recovery actions. Motion must tolerate interruption and provide equivalent information with reduced motion enabled.
+
+### Tokens and visual comparison
+
+Use semantic tokens such as text-muted or surface-warning only when their roles remain coherent across themes and component states. Inspect representative specimens before broad adoption.
+
+For visual diffs, match capture conditions and suppress only justified nondeterminism. A dynamic timestamp can be masked; a shifting panel cannot be dismissed merely because its content is dynamic. Report user-impacting geometry and state differences rather than blindly accepting a changed snapshot.

package/plugins/just-vibe/references/packs/vercel.md

@@ -0,0 +1,29 @@
+# Vercel methods
+
+Resolve the exact team, project, deployment ID, environment and Git revision before diagnosing or mutating. Use available project/deployment metadata and logs via a connector or installed CLI; verify its supported read commands. Do not relink a project or create `.vercel` configuration just to inspect it.
+
+Compare repository root, framework, build command, output path, runtime/package-manager versions and variable **names/scopes** with deployment settings. A preview can differ from production and local builds. Locate the first failing build or runtime boundary rather than patching symptoms.
+
+Inspect redirect/rewrite precedence and framework routing together. Test read-only URLs only within the requested scope; preserve API routes and nested asset paths. Separate cold/warm/cache-hit/cache-miss timing before making performance claims.
+
+Environment reports contain names, required presence and target scope, never values. Avoid commands that download secrets as an incidental audit step. Preview creation, production promotion, DNS/alias changes and rollback are different actions. For releases verify deployed revision, health, schema compatibility and previous known-good target; reverting a deployment may not revert data.
+
+## Applied methods
+
+### Configuration diagnosis
+
+Start with exact team/project, deployment ID, Git SHA and environment. Compare project root with the package that owns the build script; inspect the monorepo install root separately. Record build command, output directory, framework preset and Node/package-manager versions from evidence. Do not relink the project just to discover its identity.
+
+For a local-success/deployment-failure case, locate the first causal build line. Compare resolved dependencies, runtime and working directory before editing application code. A dependency accidentally supplied through local hoisting may be absent from the deployed workspace.
+
+### Environment and runtime branches
+
+Record variable names, consumer and environment/branch scope. Build-time client substitution differs from server runtime lookup. A changed variable may require a new deployment; existing compiled assets do not update simply because project metadata changed. Preview, production and development are distinct environments. [Vercel environments](https://vercel.com/docs/deployments/environments).
+
+For a runtime failure, trace handler entry, validation, dependency acquisition, downstream wait and response. A build pass establishes no handler health. Compare cold/warm and cache-hit/cache-miss samples under equivalent region, payload and revision conditions before attributing latency.
+
+### Preview and release evidence
+
+Use supported read operations from the installed CLI/connector to locate matching deployments before creating another. After requested creation, verify SHA, URL, access protection, nested route, API path and asset content type. A protected preview may be healthy even when anonymous requests cannot inspect it.
+
+Keep a release gate table with candidate revision, checks, health, environment requirements, observability and rollback target. Code rollback does not reverse data changes. If the previous deployment cannot read the new schema, record that recovery limit before a readiness claim.

package/plugins/just-vibe/references/packs/vite.md

@@ -0,0 +1,29 @@
+# Vite methods
+
+Read the installed Vite, framework and plugin versions, lockfile, build scripts and config sources. Do not execute imported config during read-only review; configuration may contain arbitrary code. Consult version-specific primary migration/configuration documentation when editing options.
+
+Aliases must agree between TypeScript/editor resolution and runtime/build resolution. Environment loading depends on mode; client-exposed prefixes are not a place for secrets. Inspect generated assets for exposure only when existing or when a build is authorized, and redact values in findings.
+
+For HMR, follow file watcher → module graph → framework refresh → browser transport. Distinguish a full reload from preserved hot state. For assets, exercise dev and production output at root, nested and requested base paths. Public files and imported hashed assets have different path semantics.
+
+For bundles/chunks compare the same build mode and dependency versions. Trace large modules to imports, inspect duplicated modules and lazy boundaries, and measure transferred/compressed versus raw bytes explicitly. Avoid arbitrary chunking rules and blanket dependency removal. Verify deep links and lazy routes after changes.
+
+## Applied methods
+
+### Resolve the actual invocation
+
+Read the package script and workspace working directory before configuration. Record command, mode, root, envDir, base, aliases and framework plugins. Config may branch on build versus serve; static inspection does not authorize running arbitrary imported configuration code.
+
+Mode and NODE_ENV are separate inputs. Trace environment precedence against the installed Vite version and inspect names rather than values. Client-exposed variables are compiled into browser code; adding a public prefix to a secret is not a fix. Restart/rebuild requirements depend on where the value is read. [Vite environment and mode documentation](https://vite.dev/guide/env-and-mode).
+
+### Three concrete diagnoses
+
+1. Alias typechecks but fails at runtime: compare TypeScript paths with effective bundler resolution and the exact path/case present in the deployed filesystem.
+2. Images work at / but fail at /dashboard/: distinguish imported hashed assets from public files and runtime string concatenation. Inspect the emitted URL and test direct nested navigation, not only navigation from the root.
+3. HMR fails behind a proxy: trace watcher event, module invalidation, websocket connection and framework refresh boundary. Diagnose the missing boundary before relaxing host/filesystem restrictions.
+
+### Bundle and upgrade evidence
+
+A size comparison uses the same build conditions and distinguishes raw, compressed and transferred bytes. Map a large module to when a real route requests it. Splitting can reduce initial bytes while adding a network waterfall or changing module side-effect order; inspect route behavior after the change.
+
+For upgrades, check the target's migration notes plus Node and framework-plugin support. Verify development refresh, production build and a representative preview path. Keep unrelated major upgrades out of the change and do not claim success if a required plugin has no compatible version.

package/plugins/just-vibe/references/profile-reference.md

@@ -0,0 +1,155 @@
+# Engineering profiles
+
+112 task profiles. [Selection, scope and precedence](profiles.md). Read only the roles relevant to the request. Suggested workflows do not imply available tools or authorization.
+
+## Application engineering
+
+| Profile | Purpose |
+|---|---|
+| [Frontend engineer](profiles/frontend-engineer.md) | Build reliable browser features around user interaction and data flow. |
+| [Fullstack engineer](profiles/fullstack-engineer.md) | Deliver complete features across UI, API and persistence. |
+| [Backend engineer](profiles/backend-engineer.md) | Implement service behavior with explicit consistency and failure semantics. |
+| [Product engineer](profiles/product-engineer.md) | Turn a user problem into a small measurable product improvement. |
+| [Mobile engineer](profiles/mobile-engineer.md) | Build mobile experiences that survive lifecycle and network changes. |
+| [iOS engineer](profiles/ios-engineer.md) | Implement iOS features with lifecycle, concurrency and platform interaction in mind. |
+| [Android engineer](profiles/android-engineer.md) | Implement Android features with explicit state ownership and lifecycle handling. |
+| [Desktop application engineer](profiles/desktop-engineer.md) | Build reliable installed applications and native integrations. |
+| [API engineer](profiles/api-engineer.md) | Design interfaces with clear semantics and compatible evolution. |
+| [Integration engineer](profiles/integration-engineer.md) | Connect systems with explicit identity, delivery and reconciliation rules. |
+
+## Interface and experience
+
+| Profile | Purpose |
+|---|---|
+| [UI engineer](profiles/ui-engineer.md) | Implement visual components with complete interaction states. |
+| [UX engineer](profiles/ux-engineer.md) | Prototype and implement interaction flows that reduce user effort. |
+| [Design systems engineer](profiles/design-systems-engineer.md) | Maintain reusable tokens and components with clear adoption contracts. |
+| [Accessibility engineer](profiles/accessibility-engineer.md) | Find and repair barriers in real user interactions. |
+| [Web performance engineer](profiles/web-performance-engineer.md) | Improve browser performance from measured bottlenecks. |
+| [Creative technologist](profiles/creative-technologist.md) | Build expressive interactive experiences within practical constraints. |
+
+## Platform and infrastructure
+
+| Profile | Purpose |
+|---|---|
+| [Platform engineer](profiles/platform-engineer.md) | Create internal capabilities that make product teams more effective. |
+| [DevOps engineer](profiles/devops-engineer.md) | Improve build and delivery flow with reproducible operations. |
+| [Site reliability engineer](profiles/site-reliability-engineer.md) | Manage service reliability through measurable user impact and controlled recovery. |
+| [Cloud engineer](profiles/cloud-engineer.md) | Design and operate cloud resources around workload and identity requirements. |
+| [Infrastructure engineer](profiles/infrastructure-engineer.md) | Maintain reproducible compute, network and storage foundations. |
+| [Developer experience engineer](profiles/developer-experience-engineer.md) | Remove measurable friction from development and debugging. |
+| [Build and release engineer](profiles/build-release-engineer.md) | Produce reproducible, traceable artifacts and controlled releases. |
+| [Observability engineer](profiles/observability-engineer.md) | Make system behavior diagnosable with useful signals. |
+| [Network engineer](profiles/network-engineer.md) | Reason about connectivity, routing and protocol behavior. |
+| [FinOps engineer](profiles/finops-engineer.md) | Explain and reduce infrastructure cost without hiding service tradeoffs. |
+| [Storage engineer](profiles/storage-engineer.md) | Design durable storage behavior around access and recovery requirements. |
+| [Capacity planning engineer](profiles/capacity-engineer.md) | Plan service capacity from workload shape and constrained resources. |
+| [Edge computing engineer](profiles/edge-engineer.md) | Place execution and data near users or devices with explicit constraints. |
+| [Kubernetes engineer](profiles/kubernetes-engineer.md) | Operate container workloads with explicit scheduling and recovery behavior. |
+
+## Data and databases
+
+| Profile | Purpose |
+|---|---|
+| [Data engineer](profiles/data-engineer.md) | Build reliable data movement and transformations. |
+| [Analytics engineer](profiles/analytics-engineer.md) | Create trustworthy analytical models and shared business definitions. |
+| [Data scientist](profiles/data-scientist.md) | Answer empirical questions with defensible analysis and uncertainty. |
+| [Data analyst](profiles/data-analyst.md) | Produce clear, accurate answers from operational and analytical data. |
+| [Business intelligence engineer](profiles/business-intelligence-engineer.md) | Build dependable reporting models and dashboards. |
+| [Database engineer](profiles/database-engineer.md) | Design schemas and queries around integrity and workload. |
+| [Database reliability engineer](profiles/database-reliability-engineer.md) | Maintain database availability, recoverability and safe change. |
+| [Streaming data engineer](profiles/streaming-data-engineer.md) | Process continuous events with explicit time and delivery semantics. |
+| [Data platform engineer](profiles/data-platform-engineer.md) | Provide shared data infrastructure with usable governance and operations. |
+| [Data quality engineer](profiles/data-quality-engineer.md) | Detect and localize data failures that matter to downstream use. |
+| [Data governance engineer](profiles/data-governance-engineer.md) | Make data ownership, retention and permitted use technically enforceable. |
+| [Search engineer](profiles/search-engineer.md) | Improve retrieval relevance, latency and index correctness. |
+
+## Machine learning and AI
+
+| Profile | Purpose |
+|---|---|
+| [Machine learning engineer](profiles/machine-learning-engineer.md) | Turn a modeling task into a reproducible, deployable prediction system. |
+| [Applied AI engineer](profiles/applied-ai-engineer.md) | Use models to solve an application problem with measurable quality and fallback behavior. |
+| [Research engineer](profiles/research-engineer.md) | Make research ideas reproducible and experimentally testable. |
+| [Research scientist](profiles/research-scientist.md) | Evaluate novel hypotheses through rigorous experimental design. |
+| [MLOps engineer](profiles/mlops-engineer.md) | Operate reproducible model training and release workflows. |
+| [ML platform engineer](profiles/ml-platform-engineer.md) | Build shared infrastructure for model development and operation. |
+| [Inference engineer](profiles/inference-engineer.md) | Improve model serving efficiency while preserving output quality. |
+| [LLM engineer](profiles/llm-engineer.md) | Build reliable language-model applications with explicit evidence and tool boundaries. |
+| [Natural language processing engineer](profiles/nlp-engineer.md) | Model language tasks with careful data and evaluation semantics. |
+| [Computer vision engineer](profiles/computer-vision-engineer.md) | Build image and video models with valid spatial and temporal evaluation. |
+| [Speech and audio engineer](profiles/speech-engineer.md) | Build audio systems with explicit timing, speaker and acoustic assumptions. |
+| [Recommendation systems engineer](profiles/recommendation-engineer.md) | Rank useful items while respecting temporal and exposure effects. |
+| [Reinforcement learning engineer](profiles/reinforcement-learning-engineer.md) | Develop sequential decision systems with controlled interaction and evaluation. |
+| [AI evaluation engineer](profiles/ai-evaluation-engineer.md) | Measure model and agent behavior with independent, representative tests. |
+| [Responsible AI engineer](profiles/responsible-ai-engineer.md) | Investigate model harms and implement measurable risk controls. |
+| [ML data engineer](profiles/ml-data-engineer.md) | Build reproducible training data and point-in-time feature pipelines. |
+| [Agent systems engineer](profiles/agent-systems-engineer.md) | Build bounded agent workflows with explicit state and tool effects. |
+| [AI security engineer](profiles/ai-security-engineer.md) | Assess model-system trust boundaries and abuse paths. |
+| [Causal inference scientist](profiles/causal-inference-scientist.md) | Estimate intervention effects under explicit identification assumptions. |
+| [Experimentation engineer](profiles/experimentation-engineer.md) | Build trustworthy online experiments and measurement infrastructure. |
+
+## Security and privacy
+
+| Profile | Purpose |
+|---|---|
+| [Application security engineer](profiles/application-security-engineer.md) | Find and repair exploitable application trust-boundary failures. |
+| [Product security engineer](profiles/product-security-engineer.md) | Integrate threat-informed controls into product design and release. |
+| [Cloud security engineer](profiles/cloud-security-engineer.md) | Protect cloud identity, network and resource boundaries. |
+| [Detection engineer](profiles/detection-engineer.md) | Build actionable detections from observable attack behavior. |
+| [Security incident responder](profiles/security-incident-responder.md) | Contain and investigate security incidents while preserving evidence. |
+| [Privacy engineer](profiles/privacy-engineer.md) | Implement data minimization and lifecycle controls in software. |
+| [Identity and access engineer](profiles/identity-access-engineer.md) | Design authentication and authorization with explicit identity boundaries. |
+| [Software supply chain security engineer](profiles/supply-chain-security-engineer.md) | Protect dependency, build and artifact trust chains. |
+| [Security automation engineer](profiles/security-automation-engineer.md) | Automate repeatable security work with reviewable actions and recovery. |
+| [Cryptography engineer](profiles/cryptography-engineer.md) | Integrate established cryptographic mechanisms with sound key and protocol handling. |
+
+## Quality and technical leadership
+
+| Profile | Purpose |
+|---|---|
+| [QA automation engineer](profiles/qa-automation-engineer.md) | Turn important user behavior into reliable automated coverage. |
+| [Test infrastructure engineer](profiles/test-infrastructure-engineer.md) | Build fast, trustworthy test execution and fixture systems. |
+| [Performance engineer](profiles/performance-engineer.md) | Improve system performance from controlled measurements. |
+| [Senior software engineer](profiles/senior-software-engineer.md) | Own a bounded implementation with sound tradeoffs and maintainability. |
+| [Staff engineer](profiles/staff-engineer.md) | Resolve cross-team technical problems and make adoption practical. |
+| [Principal engineer](profiles/principal-engineer.md) | Guide long-term technical direction across systems and teams. |
+| [Software architect](profiles/software-architect.md) | Design system boundaries and contracts around actual quality requirements. |
+| [Solutions architect](profiles/solutions-architect.md) | Map a concrete business use case onto a workable technical system. |
+| [Enterprise architect](profiles/enterprise-architect.md) | Align shared systems, capabilities and migration dependencies across an organization. |
+| [Data architect](profiles/data-architect.md) | Design data ownership, models and movement across systems. |
+| [Cloud architect](profiles/cloud-architect.md) | Design cloud topology and service choices from workload requirements. |
+| [Security architect](profiles/security-architect.md) | Design enforceable trust boundaries across a system. |
+| [Technical lead](profiles/tech-lead.md) | Coordinate a technical change through clear decisions and integration boundaries. |
+| [Engineering manager](profiles/engineering-manager.md) | Structure engineering planning around capacity, risk and delivery evidence. |
+| [Technical writer](profiles/technical-writer.md) | Create documentation that lets the intended reader complete a task. |
+| [Developer advocate](profiles/developer-advocate.md) | Create accurate developer examples and feedback grounded in real use. |
+| [Frontend architect](profiles/frontend-architect.md) | Design frontend boundaries and evolution across substantial applications. |
+| [ML systems architect](profiles/ml-architect.md) | Design the complete data-to-decision lifecycle across ML systems. |
+| [Platform architect](profiles/platform-architect.md) | Design shared platform capabilities and their long-term operating model. |
+| [Integration architect](profiles/integration-architect.md) | Design cross-system contracts and consistency boundaries. |
+
+## Systems and specialized computing
+
+| Profile | Purpose |
+|---|---|
+| [Systems software engineer](profiles/systems-engineer.md) | Build low-level software with explicit resource and concurrency behavior. |
+| [Distributed systems engineer](profiles/distributed-systems-engineer.md) | Design behavior under partial failure, concurrency and delayed information. |
+| [Embedded software engineer](profiles/embedded-engineer.md) | Implement constrained-device software with explicit timing and resource limits. |
+| [Firmware engineer](profiles/firmware-engineer.md) | Build boot, device-control and update logic with recoverable state transitions. |
+| [Robotics software engineer](profiles/robotics-engineer.md) | Integrate sensing, planning and actuation with explicit physical assumptions. |
+| [Controls software engineer](profiles/controls-engineer.md) | Implement feedback behavior with explicit dynamics and stability assumptions. |
+| [Gameplay engineer](profiles/gameplay-engineer.md) | Implement game rules and interaction with clear state and timing. |
+| [Game networking engineer](profiles/game-networking-engineer.md) | Build multiplayer behavior under latency, loss and untrusted clients. |
+| [Graphics engineer](profiles/graphics-engineer.md) | Implement rendering with measurable visual and resource behavior. |
+| [AR and VR engineer](profiles/xr-engineer.md) | Build spatial interfaces with careful tracking, latency and comfort constraints. |
+| [Compiler engineer](profiles/compiler-engineer.md) | Implement language transformations that preserve defined semantics. |
+| [Language runtime engineer](profiles/runtime-engineer.md) | Build execution machinery with explicit memory and concurrency semantics. |
+| [High-performance computing engineer](profiles/hpc-engineer.md) | Scale numerical workloads with measured compute and communication behavior. |
+| [Scientific software engineer](profiles/scientific-software-engineer.md) | Build reproducible computational tools that preserve scientific meaning. |
+| [Bioinformatics engineer](profiles/bioinformatics-engineer.md) | Build reproducible biological-data workflows with clear provenance. |
+| [Geospatial engineer](profiles/geospatial-engineer.md) | Implement spatial data processing with explicit coordinate and topology semantics. |
+| [Blockchain engineer](profiles/blockchain-engineer.md) | Implement ledger integrations with explicit finality and authority assumptions. |
+| [Protocol engineer](profiles/protocol-engineer.md) | Specify interoperable message and state-machine behavior. |
+| [IoT engineer](profiles/iot-engineer.md) | Connect constrained devices to services with resilient identity and synchronization. |
+| [Simulation engineer](profiles/simulation-engineer.md) | Build simulations that expose assumptions and support defensible comparisons. |

package/plugins/just-vibe/references/profiles/accessibility-engineer.md

@@ -0,0 +1,31 @@
+# Accessibility engineer
+
+Find and repair barriers in real user interactions.
+
+Apply [profile scope and precedence](../profiles.md). This role shapes task priorities; it is not a credential, permission grant or independent agent.
+
+## Priorities
+
+- Trace keyboard focus, semantics, labels and error recovery.
+- Distinguish automated findings from manual and assistive-technology evidence.
+
+## Decision rule
+
+Prefer native controls when they satisfy the behavior; custom widgets need complete interaction semantics.
+
+## Verify when relevant
+
+- Exercise keyboard entry, operation and exit.
+- Check relevant screen-reader behavior and contrast with available tools.
+
+## Boundary
+
+A clean automated scan is not a conformance claim.
+
+## Candidate workflows
+
+- [ui-accessibility](../../skills/ui-accessibility/SKILL.md)
+- [ui-flow](../../skills/ui-flow/SKILL.md)
+- [test-e2e](../../skills/test-e2e/SKILL.md)
+
+Example: Audit and repair a dialog and its focus restoration.

package/plugins/just-vibe/references/profiles/agent-systems-engineer.md

@@ -0,0 +1,31 @@
+# Agent systems engineer
+
+Build bounded agent workflows with explicit state and tool effects.
+
+Apply [profile scope and precedence](../profiles.md). This role shapes task priorities; it is not a credential, permission grant or independent agent.
+
+## Priorities
+
+- Separate planning, execution, observation and verified completion.
+- Carry user constraints and action authority through retries.
+
+## Decision rule
+
+Use deterministic state transitions when recovery or external effects require auditable bookkeeping.
+
+## Verify when relevant
+
+- Test interruption, duplicate actions and unavailable tools.
+- Verify original success criteria and budget preservation.
+
+## Boundary
+
+A role, plan or tool suggestion never grants new authority.
+
+## Candidate workflows
+
+- [llm-tools](../../skills/llm-tools/SKILL.md)
+- [llm-evals](../../skills/llm-evals/SKILL.md)
+- [auto](../../skills/auto/SKILL.md)
+
+Example: Design an agent that can recover from a failed diagnostic step.

package/plugins/just-vibe/references/profiles/ai-evaluation-engineer.md

@@ -0,0 +1,31 @@
+# AI evaluation engineer
+
+Measure model and agent behavior with independent, representative tests.
+
+Apply [profile scope and precedence](../profiles.md). This role shapes task priorities; it is not a credential, permission grant or independent agent.
+
+## Priorities
+
+- Separate fixtures, judge criteria and implementation instructions.
+- Track model, prompt, tools and dataset identities.
+
+## Decision rule
+
+Use executable assertions for verifiable behavior and calibrated human review for subjective criteria.
+
+## Verify when relevant
+
+- Check judge reliability, contamination and failure sensitivity.
+- Report missingness, repetitions and uncertainty.
+
+## Boundary
+
+Passing public fixtures is not a universal quality claim.
+
+## Candidate workflows
+
+- [llm-evals](../../skills/llm-evals/SKILL.md)
+- [ml-evaluate](../../skills/ml-evaluate/SKILL.md)
+- [test-regression](../../skills/test-regression/SKILL.md)
+
+Example: Create a held-out evaluation for a tool-using assistant.

package/plugins/just-vibe/references/profiles/ai-security-engineer.md

@@ -0,0 +1,31 @@
+# AI security engineer
+
+Assess model-system trust boundaries and abuse paths.
+
+Apply [profile scope and precedence](../profiles.md). This role shapes task priorities; it is not a credential, permission grant or independent agent.
+
+## Priorities
+
+- Trace instructions, retrieved content, tool inputs and sensitive outputs.
+- Separate model refusal behavior from enforced access controls.
+
+## Decision rule
+
+Enforce authorization outside model text when tools expose privileged data or actions.
+
+## Verify when relevant
+
+- Test indirect injection and cross-user data boundaries.
+- Verify controls against actual tool execution paths.
+
+## Boundary
+
+Do not equate a prompt-only defense with isolation.
+
+## Candidate workflows
+
+- [llm-injection](../../skills/llm-injection/SKILL.md)
+- [llm-tools](../../skills/llm-tools/SKILL.md)
+- [security-threat-model](../../skills/security-threat-model/SKILL.md)
+
+Example: Threat-model a retrieval assistant with write-capable tools.

package/plugins/just-vibe/references/profiles/analytics-engineer.md

@@ -0,0 +1,31 @@
+# Analytics engineer
+
+Create trustworthy analytical models and shared business definitions.
+
+Apply [profile scope and precedence](../profiles.md). This role shapes task priorities; it is not a credential, permission grant or independent agent.
+
+## Priorities
+
+- Define grain, keys and metric semantics before joins.
+- Separate staging, business entities and reporting aggregates.
+
+## Decision rule
+
+Model a reusable business entity when multiple reports share its definition.
+
+## Verify when relevant
+
+- Test uniqueness, referential integrity and aggregate reconciliation.
+- Verify incremental results match an equivalent full rebuild.
+
+## Boundary
+
+Do not silently redefine a business metric to simplify a query.
+
+## Candidate workflows
+
+- [data-contract](../../skills/data-contract/SKILL.md)
+- [data-quality](../../skills/data-quality/SKILL.md)
+- [db-query](../../skills/db-query/SKILL.md)
+
+Example: Create a consistent subscription revenue model.

package/plugins/just-vibe/references/profiles/android-engineer.md

@@ -0,0 +1,31 @@
+# Android engineer
+
+Implement Android features with explicit state ownership and lifecycle handling.
+
+Apply [profile scope and precedence](../profiles.md). This role shapes task priorities; it is not a credential, permission grant or independent agent.
+
+## Priorities
+
+- Separate durable data from activity and view state.
+- Account for process death, background work and permission changes.
+
+## Decision rule
+
+Use saved state for transient restoration and durable storage for user data that must survive process loss.
+
+## Verify when relevant
+
+- Exercise recreation, process loss and retry behavior.
+- Check text scaling, accessibility traversal and offline transitions.
+
+## Boundary
+
+Do not assume one emulator API level covers the supported device fleet.
+
+## Candidate workflows
+
+- [ui-states](../../skills/ui-states/SKILL.md)
+- [backend-jobs](../../skills/backend-jobs/SKILL.md)
+- [test-e2e](../../skills/test-e2e/SKILL.md)
+
+Example: Preserve a draft through activity recreation and process death.