fraim 2.0.362-next.4 → 2.0.362

package/dist/registry/stubs/jobs/ai-employee/dev-ops/route-llm-spend-to-cloud-credits.md

@@ -0,0 +1,36 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: route-llm-spend-to-cloud-credits
+
+## Intent
+Stop paying for LLM usage out of cash burn. Take whatever LLM-using agent or codebase the user has today (Claude Code, Codex, Gemini CLI, an Anthropic SDK app, etc.) and redirect its traffic to a cloud where the user has free credits, so the credits absorb the spend instead of the company card. Per-shell flip - production traffic continues uninterrupted on the original provider until the user opts in.
+
+## Outcome
+- A verified routing configuration and instructions for selecting and reverting the chosen routing pair.
+- **Working flip script** at `~/.fraim/cloud-llm-flip/use-<cloud>-<provider>.<sh|ps1>` the user can dot-source per shell. Lives under the user's FRAIM home so the origin and purpose of the script is traceable, not a bare top-level dotfolder.
+- **The composed routing command already registered as a Hub configured agent** by the time this job completes - not a separate follow-on job the user has to remember to invoke. `create-hub-configured-agent` remains available for registering a command obtained outside this flow, but is not a required second step here.
+- **Verified live invoke** through the chosen cloud provider - no synthetic test passes.
+- **Zero secrets in repo** - bearer tokens / service accounts / API keys live outside the user's working trees.
+
+## Steps
+1. Phase 1: `detect-llm-spend`
+2. Phase 2: `select-cloud-target`
+3. Phase 3: `configure-cloud-provider`
+4. Phase 4: `configure-agent-routing`
+5. Phase 5: `verify-live-invoke`
+6. Phase 6: `document-routing-protocol`
+7. Phase 7: `submit`
+8. Phase 8: `address-feedback`
+9. Phase 9: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "route-llm-spend-to-cloud-credits" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/dev-ops/run-on-remote-hub.md

@@ -0,0 +1,30 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: run-on-remote-hub
+
+## Intent
+Run a FRAIM job on a registered remote hub and relay its progress, coaching, and outcome back to the local manager surface.
+
+## Outcome
+- A remote FRAIM job runs to completion on the specified hub.
+- Phase updates from the remote run are mirrored locally in the pizza tracker.
+- Coaching input from the local manager is forwarded to the remote run.
+- The remote run's `reviewHandoff` is surfaced locally for manager review.
+
+## Steps
+1. Phase 1: `scoping`
+2. Phase 2: `connect`
+3. Phase 3: `execute`
+4. Phase 4: `complete`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "run-on-remote-hub" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/dev-ops/set-up-cloud-cost-alerts.md

@@ -0,0 +1,34 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: set-up-cloud-cost-alerts
+
+## Intent
+Get warned before cloud credits run out so the user is never surprised by a card charge. Two-tier guardrail: a zero-spend tripwire that fires the instant any paid usage starts after credits exhaust, and a tiered cost budget for trajectory visibility once the user is intentionally spending. Distinct from `cloud-cost-optimization` — that job reduces existing spend; this one prevents surprise spend.
+
+## Outcome
+- Final artifact: `docs/cloud-cost-alerts/<cloud>-{DATE}.md` capturing what was configured and how to test/edit.
+- **Zero-spend tripwire** active: alert email goes out the instant actual usage exceeds the sub-cent threshold (i.e., the moment credits stop covering it).
+- **Tiered budget** active (optional): alerts at 50% / 80% / 100% of a user-chosen monthly limit.
+- **Confirmed delivery**: a test email has actually arrived in the user's inbox.
+
+## Steps
+1. Phase 1: `platform-selection`
+2. Phase 2: `verify-authentication`
+3. Phase 3: `configure-zero-spend-tripwire`
+4. Phase 4: `configure-tiered-budget`
+5. Phase 5: `verify-alert-delivery`
+6. Phase 6: `submit`
+7. Phase 7: `address-feedback`
+8. Phase 8: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "set-up-cloud-cost-alerts" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/dev-ops/setup-remote-hub.md

@@ -0,0 +1,32 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: setup-remote-hub
+
+## Intent
+Provision a remote machine, install the FRAIM Hub runtime, and register it as a reachable host in the local Hub.
+
+## Outcome
+- A cloud VM (Azure by default) running the FRAIM Hub server on port 3000.
+- The remote Hub is accessible with an auth token protecting its `/api/ai-hub/*` routes.
+- The local Hub shows the new host as `online` in `GET /api/ai-hub/hosts/:id/health`.
+
+## Steps
+1. Phase 1: `authenticate`
+2. Phase 2: `provision`
+3. Phase 3: `install`
+4. Phase 4: `configure`
+5. Phase 5: `start`
+6. Phase 6: `register`
+7. Phase 7: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "setup-remote-hub" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/dev-ops/slo-design-and-implementation.md

@@ -0,0 +1,34 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: slo-design-and-implementation
+
+## Intent
+Design user-journey-aligned SLIs and SLOs, calculate error budgets, implement burn-rate alerting, and replace noisy threshold alerts with meaningful on-call pages that carry triage context.
+
+## Outcome
+- **Reviewable deliverable**: A .pptx presentation at docs/dev-ops/slo-design-{YYYY-MM-DD}.pptx containing SLI/SLO definitions, error budget calculations, burn-rate alert specifications, and dashboard configuration with SLO status visualization.
+- **SLI/SLO Definitions**: At least 3 SLOs covering availability, latency, and correctness for key user journeys.
+- **Error Budgets**: 28-day rolling error budgets with explicit policy for how budget is spent.
+- **Burn-Rate Alerts**: Two-window alerting (1h fast-burn + 6h slow-burn) for each SLO.
+- **Dashboard Config**: Grafana or equivalent dashboard spec with SLO status, budget remaining, and burn rate.
+
+## Steps
+1. Phase 1: `slo-definition`
+2. Phase 2: `error-budget-calc`
+3. Phase 3: `burn-rate-alerting`
+4. Phase 4: `dashboard-setup`
+5. Phase 5: `slo-submission`
+6. Phase 6: `address-feedback`
+7. Phase 7: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "slo-design-and-implementation" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/engineering/application-replication-workflow.md

@@ -0,0 +1,42 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: application-replication-workflow
+
+## Intent
+To systematically discover, analyze, and document an existing web application for replication, then convert the analysis into actionable GitHub issues for implementation through standard FRAIM product-building workflows.
+
+## Outcome
+- **Comprehensive Analysis**: Complete `REPLICATION_ANALYSIS.md` report and `INDEX.md` in `docs/replicate/`.
+- **Structured GitHub Issues**: One issue per feature/use case, properly labeled, prioritized, and linked.
+- **Implementation Roadmap**: A phased plan for building the replicated application.
+- **Developer Guide**: Documentation on how to pick up and work on these issues.
+- **Final artifact set**: `REPLICATION_ANALYSIS.md`, `INDEX.md`, `IMPLEMENTATION_ROADMAP.md`, `GITHUB_ISSUES.md`, `DEVELOPER_GUIDE.md`, plus the screenshots directory. The per-phase JSON analyses and report files are working state and are removed once the master report consolidates them.
+
+## Steps
+1. Phase 1: `initialize-output-structure`
+2. Phase 2: `initial-site-scraping`
+3. Phase 3: `interactive-browser-analysis`
+4. Phase 4: `screenshot-organization`
+5. Phase 5: `technology-stack-analysis`
+6. Phase 6: `use-case-extraction`
+7. Phase 7: `master-report-generation`
+8. Phase 8: `prepare-issue-generation`
+9. Phase 9: `categorize-and-prioritize`
+10. Phase 10: `generate-github-issues`
+11. Phase 11: `link-and-organize-issues`
+12. Phase 12: `document-issues`
+13. Phase 13: `replication-submission`
+14. Phase 14: `address-feedback`
+15. Phase 15: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "application-replication-workflow" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/engineering/code-refactoring.md

@@ -0,0 +1,35 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: code-refactoring
+
+## Intent
+Improve the internal structure of code without altering its external behavior. This job enforces a strict "Green-Red-Green" cycle and ensures a test safety net exists before any implementation changes are made.
+
+## Outcome
+- **Clean Code**: Improved readability, maintainability, or performance.
+- **Passing Tests**: Proof that no regression occurred.
+- **Standardization**: Alignment with project patterns.
+
+## Steps
+1. Phase 1: `refactor-scoping`
+2. Phase 2: `refactor-test-safety-net`
+3. Phase 3: `refactor-tests`
+4. Phase 4: `refactor-implementation`
+5. Phase 5: `refactor-validate`
+6. Phase 6: `refactor-regression`
+7. Phase 7: `code-change-gate`
+8. Phase 8: `refactor-submission`
+9. Phase 9: `address-feedback`
+10. Phase 10: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "code-refactoring" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/engineering/codebase-analysis-and-ideation.md

@@ -0,0 +1,32 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: codebase-analysis-and-ideation
+
+## Intent
+Provide a structured approach for analyzing an existing codebase and generating grounded, evidence-based improvement ideas. Ask: *"What **can** we build or improve based on what we actually have?"* (Bottom-up, technical reality). Strict accuracy is enforced — fabricating non-existent functionality is not tolerated.
+
+## Outcome
+- **Reviewable deliverable**: A .pptx presentation at docs/brainstorming/codebase-brainstorming-{YYYY-MM-DD}.pptx with sections for Currently Exists (with file paths), Architectural Patterns, Gaps and Opportunities, and Actionable Suggestions (grounded improvement ideas with evidence traces).
+- **Accurate Inventory**: A clear distinction between what exists and what could be built, with every claim traceable to a file path.
+- **Actionable Suggestions**: Realistic, incremental improvement ideas ready for conversion into implementation issues.
+
+## Steps
+1. Phase 1: `codebase-analysis`
+2. Phase 2: `categorized-analysis`
+3. Phase 3: `grounded-suggestions`
+4. Phase 4: `verification-and-validation`
+5. Phase 5: `codebase-ideation-submission`
+6. Phase 6: `address-feedback`
+7. Phase 7: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "codebase-analysis-and-ideation" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/engineering/create-architecture.md

@@ -0,0 +1,35 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: create-architecture
+
+## Intent
+To analyze the codebase and author a comprehensive architecture document that captures the system's design, tech stack, and architectural layers to serve as a map for development.
+
+## Outcome
+- Architecture document: `docs/architecture/architecture.md`, fully populated from the FRAIM architecture template.
+- FRAIM pointer: `fraim/config.json` updated so `customizations.architectureDoc` points to `docs/architecture/architecture.md`.
+- Verification complete:
+  - `docs/architecture/architecture.md` exists and is non-empty.
+  - `fraim/config.json` contains the correct `customizations.architectureDoc` path.
+
+## Steps
+1. Phase 1: `analyze-project-structure`
+2. Phase 2: `author-architecture-document`
+3. Phase 3: `review-and-save-architecture`
+4. Phase 4: `update-architecture-config`
+5. Phase 5: `verify-architecture-setup`
+6. Phase 6: `submit`
+7. Phase 7: `address-feedback`
+8. Phase 8: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "create-architecture" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/engineering/data-pipeline-design.md

@@ -0,0 +1,30 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: data-pipeline-design
+
+## Intent
+Design a production-grade data pipeline using Medallion Architecture (Bronze/Silver/Gold layers) that moves data from source systems to analytics-ready tables with documented quality contracts and SLA guarantees.
+
+## Outcome
+- **Reviewable deliverable**: A markdown RFC at `docs/rfcs/{issue_number}-{slug}-data-pipeline-design.md` defining Medallion layers, quality and PII controls, and service objectives.
+
+## Steps
+1. Phase 1: `pipeline-scoping`
+2. Phase 2: `medallion-architecture-design`
+3. Phase 3: `sla-definition`
+4. Phase 4: `pipeline-validation`
+5. Phase 5: `data-pipeline-submission`
+6. Phase 6: `address-feedback`
+7. Phase 7: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "data-pipeline-design" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/engineering/data-platform-architecture.md

@@ -0,0 +1,29 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: data-platform-architecture
+
+## Intent
+Design the end-to-end data platform architecture — from source connectors through the warehouse to analytics and ML consumers — that can scale from seed stage to Series B without a full rebuild.
+
+## Outcome
+- **Reviewable deliverable**: A markdown RFC at `docs/rfcs/{issue_number}-{slug}-data-platform-architecture.md` with the source map, warehouse recommendation, cost basis, and architecture diagram.
+
+## Steps
+1. Phase 1: `source-connector-mapping`
+2. Phase 2: `warehouse-selection`
+3. Phase 3: `architecture-validation`
+4. Phase 4: `data-platform-submission`
+5. Phase 5: `address-feedback`
+6. Phase 6: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "data-platform-architecture" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/engineering/data-quality-monitoring.md

@@ -0,0 +1,29 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: data-quality-monitoring
+
+## Intent
+Define schema contract validations, implement data quality alerting, and establish a quality monitoring framework that catches data issues before they reach analytics consumers or product surfaces.
+
+## Outcome
+- **Reviewable deliverable**: A markdown RFC at `docs/rfcs/{issue_number}-{slug}-data-quality-monitoring.md` with quality contracts, alert policy, and validation plan.
+
+## Steps
+1. Phase 1: `quality-contract-authoring`
+2. Phase 2: `alerting-setup`
+3. Phase 3: `quality-validation`
+4. Phase 4: `data-quality-submission`
+5. Phase 5: `address-feedback`
+6. Phase 6: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "data-quality-monitoring" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/engineering/database-schema-design.md

@@ -0,0 +1,30 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: database-schema-design
+
+## Intent
+Design a production-grade database schema that is normalized for data integrity, indexed for query performance, and documented with a migration plan — so the schema is correct from the start rather than requiring painful rewrites after data accumulates.
+
+## Outcome
+- **Reviewable deliverable**: A markdown RFC at `docs/rfcs/{issue_number}-{slug}-database-schema-design.md` with the ERD, normalization decisions, and reversible migration plan.
+
+## Steps
+1. Phase 1: `requirements-gathering`
+2. Phase 2: `schema-design`
+3. Phase 3: `normalization-review`
+4. Phase 4: `migration-plan`
+5. Phase 5: `schema-submission`
+6. Phase 6: `address-feedback`
+7. Phase 7: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "database-schema-design" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/engineering/feature-implementation.md

@@ -0,0 +1,39 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: feature-implementation
+
+## Intent
+Implement bug fixes and features with scoped planning, real validation, and full follow-through — starting either from an issue with no code yet, or from an already-open pull request that needs to reach green and merged.
+
+## Outcome
+- **Working Code**: Features implemented or bugs fixed.
+- **Tests**: The required automated coverage for the change.
+- **Verification**: Proof that the implementation matches the approved spec/design.
+- **Green, Merged-Ready PR**: For the already-open-PR seed, CI passing and reviewer feedback resolved through the same enforced security/quality/completeness gates as a from-scratch change.
+
+## Steps
+1. Phase 1: `implement-scoping` (also identifies the seed: an issue with no code yet, or an already-open PR)
+2. Phase 2: `implement-repro` (Bugs only)
+3. Phase 3: `implement-tests` (Features and undertested bugs)
+4. Phase 4: `implement-code`
+5. Phase 5: `implement-validate`
+6. Phase 6: `implement-security-review`
+7. Phase 7: `implement-regression`
+8. Phase 8: `implement-quality`
+9. Phase 9: `implement-completeness-review`
+10. Phase 10: `implement-architecture-update`
+11. Phase 11: `implement-submission`
+12. Phase 12: `address-feedback` (reached through `implement-submission`)
+13. Phase 13: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "feature-implementation" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/engineering/github-org-setup.md

@@ -0,0 +1,32 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: github-org-setup
+
+## Intent
+Prepare or execute GitHub organization setup with explicit approval gates for org creation, billing, ownership, domain verification, security settings, and invites.
+
+## Outcome
+- Setup plan or approved execution log at `docs/company-creation/github/{company-name}-org-setup-{YYYY-MM-DD}.md`.
+- Confirmed or unresolved org slug, billing owner, domain, owner/admin list, security baseline, and repo policy defaults.
+- If execution is approved and authorized, the org exists with verified settings and invite status recorded.
+
+## Steps
+1. Phase 1: `presence-context-load`
+2. Phase 2: `slug-and-plan-decision`
+3. Phase 3: `execution-plan-review`
+4. Phase 4: `execute-org-creation`
+5. Phase 5: `verification-and-handoff`
+6. Phase 6: `address-feedback`
+7. Phase 7: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "github-org-setup" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/engineering/gitlabs-to-github.md

@@ -0,0 +1,44 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: gitlabs-to-github
+
+## Intent
+Migrate one or more repositories from GitLab to GitHub with controlled risk, explicit user approvals, and validation at every phase.
+
+## Outcome
+- Repositories, branches, tags, and history are migrated.
+- Issues/work items, release artifacts, and metadata are migrated or intentionally mapped.
+- CI/CD, secrets, environments, webhooks, and automations are migrated and validated.
+- Team access model, branch protection, and governance requirements.
+- Cutover is executed with rollback protection and post-cutover validation.
+
+## Steps
+1. Phase 1: `intake-and-discovery`
+2. Phase 2: `scope-and-success-criteria`
+3. Phase 3: `access-and-change-freeze`
+4. Phase 4: `backup-and-export-baseline`
+5. Phase 5: `create-github-target-foundation`
+6. Phase 6: `migrate-git-history-and-branches`
+7. Phase 7: `migrate-issues-mrs-and-releases`
+8. Phase 8: `port-ci-cd-and-environments`
+9. Phase 9: `migrate-integrations-and-automation`
+10. Phase 10: `dry-run-validation`
+11. Phase 11: `cutover-readiness-review`
+12. Phase 12: `execute-cutover`
+13. Phase 13: `post-cutover-validation`
+14. Phase 14: `hypercare-and-decommission`
+15. Phase 15: `submit`
+16. Phase 16: `address-feedback`
+17. Phase 17: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "gitlabs-to-github" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/engineering/google-workspace-setup.md

@@ -0,0 +1,34 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: google-workspace-setup
+
+## Intent
+Provision a Google Workspace tenant on the company's primary domain end-to-end — sign up, verify the domain, publish mail and auth DNS records, harden the admin baseline, and create users, groups, and a shared drive ready for the founding team.
+
+## Outcome
+- A provisioned Workspace tenant on the chosen tier with billing configured.
+- Domain verified, MX/SPF/DKIM/DMARC records published, mail delivery confirmed.
+- Admin baseline enforced: 2SV required, hardware keys on super admins, advanced threat protection on, context-aware access default applied.
+- At least two super admins, founding-team user accounts created, groups and aliases created, shared drive initialized.
+- Execution log at `docs/go-to-market/presence/google-workspace/{company-name}-workspace-setup-{YYYY-MM-DD}.md`.
+
+## Steps
+1. Phase 1: `presence-context-load`
+2. Phase 2: `tier-and-dns-decision`
+3. Phase 3: `execution-plan-review`
+4. Phase 4: `execute-provisioning`
+5. Phase 5: `verification-and-handoff`
+6. Phase 6: `address-feedback`
+7. Phase 7: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "google-workspace-setup" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/engineering/issue-preparation.md

@@ -0,0 +1,28 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: issue-preparation
+
+## Intent
+Prepare a clean, isolated development environment for a specific issue so implementation can start safely and immediately.
+
+## Outcome
+- **Isolated Worktree**: New issue worktree created for the issue (`{PROJECT_NAME} - Issue {issue_number}`).
+- **Feature Branch**: Branch `feature/{issue_number}-{slug}` created and pushed by script.
+- **Ready Environment**: Dependencies installed (unless skipped) and workspace ready for execution phases.
+
+## Steps
+1. Phase 1: `environment-setup`
+2. Phase 2: `branch-creation`
+3. Phase 3: `workspace-verification`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "issue-preparation" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.

package/dist/registry/stubs/jobs/ai-employee/engineering/large-refactor-plan.md

@@ -0,0 +1,36 @@
+<!-- FRAIM_DISCOVERY_STUB -->
+
+# FRAIM Job: large-refactor-plan
+
+## Intent
+Sequence a refactor too large for one `code-refactoring` run into safe, right-sized, independently-shippable slices, with a test-coverage go/no-go up front and a closing security/quality/test gate for the whole initiative once every slice has merged. This job only plans: it never edits code itself.
+
+## Outcome
+- **Coverage Go/No-Go**: An explicit adequate/inadequate verdict on existing test coverage across the target modules, before any slicing is allowed.
+- **Migration Order**: A dependency-derived, safe order for moving modules, with any circular dependencies called out as atomic units.
+- **Slice Plan**: An ordered list of right-sized slices, each following an expand → migrate → contract discipline with an explicit boundary-test spec.
+- **Closing Gate**: A named set of checks (`security-review`, `codebase-quality-assessment`, `test-quality-assessment`) to run against the full end-state diff once every slice merges.
+- **Durable Plan**: A reviewable plan document at `docs/refactors/{slug}-plan.md`.
+- **Filed Issues (on approval only)**: One GitHub issue per slice, in priority/execution order, each linking back to the plan and its boundary-test requirement.
+
+## Steps
+1. Phase 1: `initiative-scoping`
+2. Phase 2: `test-coverage-gate`
+3. Phase 3: `module-dependency-mapping`
+4. Phase 4: `slice-sizing-and-sequencing`
+5. Phase 5: `closing-gate-definition`
+6. Phase 6: `plan-submission`
+7. Phase 7: `address-feedback`
+8. Phase 8: `retrospective`
+
+---
+
+> [!IMPORTANT]
+> **For AI Agents:** Do NOT attempt to execute this job based on the Intent/Outcome above.
+> This stub is for discoverability only. The actual job has multiple phases with
+> detailed steps, validation criteria, and required skills.
+>
+> To get full phase-by-phase instructions, call:
+> `get_fraim_job({ job: "large-refactor-plan" })`
+>
+> Then follow all phases using `seekMentoring` at each phase transition.