If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/rubyonjets/jets shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Slowing — last commit 6mo ago

• Last commit 6mo ago
• 6 active contributors
• MIT licensed
• Tests present
• ⚠ Slowing — last commit 6mo ago
• ⚠ Single-maintainer risk — top contributor 90% of recent commits
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live rubyonjets/jets repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/rubyonjets/jets.

What it runs against: a local clone of rubyonjets/jets — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in rubyonjets/jets | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 214 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of rubyonjets/jets. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/rubyonjets/jets.git
#   cd jets
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of rubyonjets/jets and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "rubyonjets/jets(\\.git)?\\b" \\
  && ok "origin remote is rubyonjets/jets" \\
  || miss "origin remote is not rubyonjets/jets (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "lib/jets.rb" \\
  && ok "lib/jets.rb" \\
  || miss "missing critical file: lib/jets.rb"
test -f "lib/jets/cli.rb" \\
  && ok "lib/jets/cli.rb" \\
  || miss "missing critical file: lib/jets/cli.rb"
test -f "lib/jets/cfn/deploy.rb" \\
  && ok "lib/jets/cfn/deploy.rb" \\
  || miss "missing critical file: lib/jets/cfn/deploy.rb"
test -f "lib/jets/cfn/builder/interface.rb" \\
  && ok "lib/jets/cfn/builder/interface.rb" \\
  || miss "missing critical file: lib/jets/cfn/builder/interface.rb"
test -f "lib/jets/api/client.rb" \\
  && ok "lib/jets/api/client.rb" \\
  || miss "missing critical file: lib/jets/api/client.rb"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 214 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~184d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/rubyonjets/jets"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Jets is a Ruby framework that deploys serverless applications to AWS Lambda with zero DevOps overhead. It packages Rails, Sinatra, or any Rack application and orchestrates CloudFormation infrastructure, automatically handling Lambda function creation, API Gateway routing, and resource management—letting developers deploy production serverless apps with jets deploy. Monolithic gem structure: lib/jets/ contains the core engine split by concern—lib/jets/cfn/ handles CloudFormation template generation (builder, bootstrap, delete), lib/jets/api/ wraps the Jets API client, lib/jets/aws_services/ abstracts AWS SDK calls (S3, CloudFormation, Lambda info), and lib/jets/autoloaders/ manages Rails/Gem autoloading. Entry point is exe/jets CLI binary.

Ruby developers (Rails, Sinatra, Rack) who want to run serverless applications on AWS Lambda without managing CloudFormation templates, Docker containers, or infrastructure code. Target users are teams adopting serverless who want Rails-like conventions applied to Lambda.

Actively maintained and production-ready. The project has reached v6.0+ (major version maturity), demonstrates professional structure with GitHub issue templates, CHANGELOG, and contribution guidelines. The large Ruby codebase (~340KB) and presence in the ecosystem (BoltOps badge integration) indicate active development, though exact commit recency and CI status are not visible in the provided data.

Dependencies on AWS CloudFormation and Lambda pricing models create operational risk; breaking changes between major versions (evidenced by v6.0 release) may require migration. The focus on AWS-only deployment creates vendor lock-in. Single-maintainer governance (BoltOps/Tony Junkes) is a sustainability risk, though the project appears funded and actively marketed.

The file structure suggests active development in CloudFormation orchestration (cfn/builder with parent/genesis patterns), AWS service abstraction (aws_services with stack status, S3 bucket, helpers), and API integration (agree, client, signature validation, project/release/stack resources). No specific PR or milestone data visible, but the organized issue templates and recent v6.0 version indicate ongoing feature work.

Clone the repo: git clone https://github.com/rubyonjets/jets.git && cd jets. Install dependencies: bundle install (Gemfile present). No server startup is needed; this is a gem. To use in a project: gem 'jets', '>= 6.0' in Gemfile, then bundle exec jets init and bundle exec jets deploy.

Daily commands: This is a gem, not an app. To test locally: bundle install && bundle exec rspec (Rakefile and .rspec present indicate test suite). To use in a Rails/Sinatra app: add to Gemfile, run bundle exec jets init to scaffold config, then bundle exec jets deploy to deploy to AWS (requires AWS credentials in environment).

• lib/jets.rb — Root entry point that initializes the Jets framework and loads all core modules.
• lib/jets/cli.rb — Main CLI dispatcher handling all command routing (deploy, build, init, etc.) that users interact with.
• lib/jets/cfn/deploy.rb — Core CloudFormation deployment orchestrator that manages infrastructure provisioning to AWS.
• lib/jets/cfn/builder/interface.rb — CloudFormation template builder interface defining how resources are generated and composed.
• lib/jets/api/client.rb — Jets API client for remote service communication, managing project deployments and releases.
• lib/jets/aws_services.rb — AWS service abstractions and helpers providing unified access to Lambda, CloudFormation, S3, and other AWS APIs.
• exe/jets — Executable entry point that bootstraps the CLI and routes commands to appropriate handlers.

• CLI Handler (Ruby Thor-like CLI framework) — Parses user commands and routes to appropriate command implementations
  • Failure mode: Invalid command arguments cause early exit with usage message
• CloudFormation Builder —

Add a new CLI command

1. Create a new command class in lib/jets/cli/ that inherits from lib/jets/cli/base.rb (lib/jets/cli/base.rb)
2. Implement execute method with your command logic (lib/jets/cli/your_command.rb)
3. Register the command in lib/jets/cli.rb by adding a route or command handler (lib/jets/cli.rb)
4. The command is automatically available via 'jets your_command' from the executable (exe/jets)

Add a new CloudFormation resource type

1. Create a new resource class under lib/jets/cfn/resource/ inheriting from lib/jets/cfn/resource.rb (lib/jets/cfn/resource.rb)
2. Define the resource properties and CloudFormation type in your resource class (lib/jets/cfn/resource/your_resource.rb)
3. The builder in lib/jets/cfn/builder/interface.rb will automatically discover and include your resource (lib/jets/cfn/builder/interface.rb)
4. Your resource will be rendered into the CloudFormation template during deployment (lib/jets/cfn/deploy.rb)

Add a new AWS service integration

1. Create a helper module or class in lib/jets/aws_services/ for your AWS service (lib/jets/aws_services/aws_helpers.rb)
2. Import the AWS SDK client and wrap service methods with error handling (lib/jets/aws_services/your_service.rb)
3. Register your service in lib/jets/aws_services.rb with memoization using global_memoist (lib/jets/aws_services.rb)
4. Use your service throughout the codebase via Aws module methods (lib/jets/aws_services/global_memoist.rb)

Add a new API endpoint for remote service

1. Create a new endpoint class under lib/jets/api/ inheriting from lib/jets/api/base.rb (lib/jets/api/base.rb)
2. Define HTTP methods (get, post, etc.) and request/response handling (lib/jets/api/your_endpoint.rb)
3. Register the endpoint in lib/jets/api/client.rb for discovery (lib/jets/api/client.rb)
4. Call your endpoint from CLI commands or other components via the client (lib/jets/api/client.rb)

• AWS CloudFormation — Infrastructure-as-code declarative approach for managing all AWS resources and ensuring reproducible deployments
• AWS Lambda — Serverless compute for running Ruby applications without managing servers; scales automatically
• CodeBuild — Managed CI/CD service for building and testing applications before deployment
• S3 — Artifact storage for Lambda deployment packages and CloudFormation templates
• Remote Jets API — Central service for managing releases, deployments, and project metadata across distributed deployments

• Deployment via CloudFormation stacks rather than direct API calls

  • Why: Ensures infrastructure repeatability, versioning, and easy rollback capabilities
  • Consequence: Slightly slower deployments (2-5 min) but gains operational safety and disaster recovery

• Remote Jets API for deployment coordination

  • Why: Centralizes deployment history, concurrency management, and release artifacts
  • Consequence: Introduces external dependency; requires network connectivity for deployments

• Resource discovery pattern for CloudFormation generation

  • Why: Allows declarative resource definitions without manual template assembly
  • Consequence: Framework complexity increases; debugging template issues requires understanding builder logic

• Does not provide local Lambda emulation or offline testing
• Does not handle authentication/authorization directly (delegates to AWS IAM)
• Does not manage non-AWS cloud providers or infrastructure
• Does not provide built-in monitoring/logging UI (integrates with CloudWatch)
• Does not handle database migrations or schema management

AWS credentials must be in environment (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) or configured in ~/.aws/ for deploy to work. CloudFormation stack naming is derived from Gemfile/config; changing project names mid-deployment can orphan stacks. Lambda cold-start performance and pricing model (request count, memory size, execution time) differs significantly from Rails on servers—no hidden startup costs but requires capacity planning. The API client (jets/api/) requires Jets platform authentication (api_key, account) which is separate from AWS credentials.

• CloudFormation Infrastructure as Code (IaC) — Jets generates CloudFormation templates to provision Lambda, API Gateway, and other resources; understanding CFN is essential to debug generated infrastructure and customize deployments
• AWS Lambda Cold Start and Warm Start — Ruby on Lambda has significant cold-start latency; Jets users must understand this performance characteristic when sizing memory and planning auto-scaling
• API Gateway Lambda Proxy Integration — Jets uses API Gateway Lambda Proxy to route HTTP requests to Lambda; the event/response envelope format must be understood for custom routing or non-standard HTTP needs
• Memoization with Global State (GlobalMemoist) — Jets caches AWS API calls (regions, account info) during a request lifecycle in global_memoist.rb; understanding this pattern prevents double API calls and understands shared state in serverless
• Builder Pattern for Template Generation — Jets uses builder pattern (cfn/builder/) to compose CloudFormation templates; understanding this abstraction is essential for adding custom resource types or extending deployment logic
• AWS CloudFormation Stack Dependencies and Outputs — Jets manages dependent CloudFormation stacks (parent/child architecture in genesis.rb); understanding stack references and cross-stack outputs is key for complex deployments

• boltops-tools/jets-rails — Official Rails integration gem (mentioned in README as jets-rails); sibling project providing Rails-specific Rack wrapper and conventions
• serverless/serverless — Industry-standard serverless framework for Node.js and Python; direct competitor with different language and architecture patterns for Lambda deployment
• rails/rails — Core Rails framework that Jets wraps and deploys; understanding Rails middleware and request lifecycle is essential for Jets integration
• boltops-tools/cfn-dump — BoltOps companion tool for introspecting CloudFormation templates; useful for debugging Jets-generated infrastructure code
• aws-samples/aws-lambda-ruby-runtime — AWS's official Ruby Lambda runtime; Jets depends on this for executing Ruby code in Lambda environments

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive test suite for lib/jets/cfn/resource/codebuild module

The CodeBuild resource module (lib/jets/cfn/resource/codebuild/) has multiple submodules handling project configuration (base.rb, ec2.rb, lambda.rb), environment variables (env.rb, format_env.rb), and IAM roles, but there's no visible test coverage. This is critical infrastructure code for CI/CD deployment. Adding tests would ensure reliability of CodeBuild project generation across different compute environments.

• [ ] Create spec/jets/cfn/resource/codebuild/project/base_spec.rb with tests for base project configuration
• [ ] Create spec/jets/cfn/resource/codebuild/project/ec2_spec.rb and lambda_spec.rb to test environment-specific configurations
• [ ] Create spec/jets/cfn/resource/codebuild/project/format_env_spec.rb to test environment variable formatting edge cases
• [ ] Create spec/jets/cfn/resource/codebuild/iam_role_spec.rb to test IAM role generation
• [ ] Add integration tests verifying CodeBuild project resources are correctly rendered in CloudFormation templates

Add GitHub Actions workflow for automated testing on multiple Ruby versions

The repo has .github/ISSUE_TEMPLATE and .github/PULL_REQUEST_TEMPLATE but no CI workflow files (.github/workflows/). For a critical deployment framework like Jets that supports multiple Ruby versions, automated testing on Ruby 2.7, 3.0, 3.1, and 3.2+ is essential. This prevents regressions across version compatibility.

• [ ] Create .github/workflows/test.yml with matrix strategy for Ruby versions [2.7, 3.0, 3.1, 3.2, 3.3]
• [ ] Add bundler install and 'rake spec' execution steps
• [ ] Configure workflow to run on pull_request and push to main branches
• [ ] Add badge to README.md linking to workflow status

Add unit tests for lib/jets/api module with focus on client communication

The lib/jets/api/ directory contains critical code for communicating with Jets deployment APIs (client.rb, config.rb, error.rb, sig.rb, response.rb) but lacks visible test coverage. These modules handle authentication signatures, API responses, and configuration—areas prone to subtle bugs. Thorough tests would ensure API contract stability.

• [ ] Create spec/jets/api/client_spec.rb testing API client initialization and request methods
• [ ] Create spec/jets/api/sig_spec.rb to verify request signature generation with known test vectors
• [ ] Create spec/jets/api/response_spec.rb to test response parsing and error handling
• [ ] Create spec/jets/api/error_spec.rb to test custom error classes and messages
• [ ] Add mock/stub tests for lib/jets/api/config.rb configuration loading

• Add comprehensive unit test coverage for lib/jets/api/sig.rb (signature validation) and lib/jets/api/error.rb—currently no visible test files shown in structure; critical for security
• Document the CloudFormation builder pattern by adding RDoc comments to lib/jets/cfn/builder/interface.rb and parent/genesis.rb, with examples of custom resource generation
• Add Lambda environment variable validation logic in lib/jets/aws_services/aws_info.rb to detect misconfiguration early and fail with helpful error messages (e.g., missing AWS_REGION)

The Jets framework shows a moderate security posture with potential concerns around API validation, secrets management in CloudFormation, and IAM policy handling. Critical areas to address include comprehensive dependency vulnerability scanning (no lock file provided), input validation for API interactions, and ensuring CloudFormation templates don't leak sensitive information. The codebase lacks visible security documentation and secure-by-default configurations. Implementing stricter validation, leveraging AWS security services properly, and adding security guidelines would significantly improve the overall security score.

• Medium · Potential Unvalidated External API Calls — lib/jets/api/client.rb, lib/jets/api/base.rb. The codebase contains API client implementation (lib/jets/api/client.rb) that communicates with external services. Without visible request validation and sanitization code, there's a risk of Server-Side Request Forgery (SSRF) or injection attacks if user input is passed to API endpoints. Fix: Implement strict input validation for all API parameters, use allowlisting for URLs, validate and sanitize all user-provided input before passing to API calls, and implement rate limiting.
• Medium · Missing Dependency Vulnerability Assessment — Gemfile (content not provided). No package dependency file (Gemfile.lock, package.json, etc.) was provided for analysis. This prevents verification of known security vulnerabilities in third-party dependencies used by the Jets framework. Fix: Provide and regularly audit Gemfile.lock. Use 'bundle audit' and 'bundler-audit' tools to identify vulnerable dependencies. Keep all gems updated and monitor security advisories.
• Medium · Potential Sensitive Information Exposure in CloudFormation Templates — lib/jets/cfn/, lib/jets/cfn/iam/, lib/jets/cfn/resource/. The codebase handles CloudFormation templates (lib/jets/cfn/) and IAM policies (lib/jets/cfn/iam/). There's a risk that sensitive credentials, API keys, or secrets could be embedded in generated templates or logs if proper handling is not implemented. Fix: Never hardcode secrets in templates. Use AWS Secrets Manager or Parameter Store. Implement secret masking in logs. Review all template generation code to ensure secrets are handled via proper AWS services.
• Medium · IAM Policy Management Risk — lib/jets/cfn/iam/policy.rb, lib/jets/cfn/iam/managed_policy.rb. The framework manages IAM policies (lib/jets/cfn/iam/policy.rb and managed_policy.rb). Over-permissive policies could be generated, violating the principle of least privilege if policy validation is insufficient. Fix: Implement strict policy validation, follow principle of least privilege, provide policy examples with minimal required permissions, add warnings for overly permissive policies, and include policy review documentation.
• Low · Potential Code Injection via Dynamic Code Loading — lib/jets/autoloaders/gem.rb, lib/jets/autoloaders/main.rb. The autoloaders module (lib/jets/autoloaders/) uses dynamic code loading patterns. If combined with user input, this could lead to arbitrary code execution vulnerabilities. Fix: Ensure all dynamically loaded code sources are validated and controlled. Use allowlisting for autoloadable modules. Avoid loading code from user-controlled paths.
• Low · Missing Security Headers Configuration — lib/jets/, configuration files. As a web framework (supports Rails, Sinatra, Rack apps), the framework should provide guidance or defaults for security headers but no evidence is visible in the file structure. Fix: Document and provide defaults for security headers (HSTS, CSP, X-Frame-Options, etc.). Include secure-by-default middleware configurations in generated projects.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.