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/1Password/typeshare 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.

GO — Healthy across the board

• Last commit 5d ago
• 12 active contributors
• Distributed ownership (top contributor 39% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{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 1Password/typeshare repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/1Password/typeshare.

What it runs against: a local clone of 1Password/typeshare — 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 1Password/typeshare | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 35 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of 1Password/typeshare. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/1Password/typeshare.git
#   cd typeshare
#
# 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 1Password/typeshare and re-run."
  exit 2
fi

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

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

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

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 35 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~5d)"
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/1Password/typeshare"
  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).

Typeshare is a code generation tool that synchronizes type definitions between Rust and multiple target languages (Swift, Go, Python, Kotlin, Scala, TypeScript) for seamless FFI without manual type duplication. It parses Rust types annotated with #[typeshare] macros and generates idiomatic equivalent types in each target language, solving the critical FFI problem of keeping types in sync across language boundaries. Monorepo with four workspace crates: annotation/ provides the #[typeshare] macro, core/ contains the parser and multi-language code generators, cli/ wraps core as a command-line tool (with its own arg parsing and config system in cli/src/), and lib/ provides the public API. Test data lives in core/data/tests/ with 60+ subdirectories, each containing input.rs and output.* files for snapshot-based testing across all target languages.

Systems engineers and library maintainers building cross-platform SDKs or native bindings in Rust who need to expose APIs to Swift, Go, Python, Kotlin, and other languages without manually rewriting type definitions in each language.

Actively maintained and production-ready. The project has published crates on crates.io for all four workspace members (typeshare, typeshare-core, typeshare-annotation, typeshare-cli), maintains comprehensive CI/CD via GitHub Actions (audit, release, doc deploy workflows in .github/workflows/), and includes an extensive test suite with 60+ snapshot test directories in core/data/tests/. Recent activity evident from Changelog.md and flake lock updates.

Low risk for a mature FFI project. Dependencies are minimal and well-known (log, flexi_logger for logging; syn/quote for Rust parsing). Single-maintainer risk appears mitigated by the 1Password organization backing. Breaking changes are tracked in CHANGELOG.md. Main risk is the tight coupling to Rust's syntax evolution and the complexity of maintaining correct code generation across seven target languages—language version mismatches could cause subtle compatibility issues.

Active development across type system enhancements, language backend improvements, and configuration options. The test directories show recent additions for features like algebraic enum decorators and constraint handling (decorators_config.toml, constraints_config.toml in cli/data/tests/). GitHub workflows indicate ongoing CI investment with audit and release automation.

git clone https://github.com/1Password/typeshare.git
cd typeshare
cargo build
cargo test

For CLI usage: cargo run --release --bin typeshare -- --help to see available options.

Daily commands: Development: cargo build builds all workspace members. For the CLI: cargo run --bin typeshare -- --help. Tests: cargo test runs all snapshot tests. Specific language test: check core/data/tests/*/output.swift (or .go, .py, .kt, .scala, .ts) for expected output per language.

• core/src/lib.rs: Entry point for the code generation engine; contains or re-exports all language generators
• annotation/src/lib.rs: Defines the #[typeshare] proc-macro that users apply to Rust types
• cli/src/main.rs: CLI entry point; orchestrates parsing, config loading, and invokes core generators
• cli/src/config.rs: TOML configuration parser; controls language-specific output options and naming conventions
• cli/src/parse.rs: Orchestrates Rust file parsing and feeds AST to core generators
• core/data/tests/: 60+ snapshot test directories with input.rs and language-specific outputs; golden test suite

For new language support: add output generator in core/src/gen/ (follow pattern of existing Swift/Go/Python generators). For new Rust type support: modify core/src/parse.rs and update snapshot tests in core/data/tests/. For CLI features: edit cli/src/args.rs (arguments) and cli/src/config.rs (TOML schema). For macros: annotation/src/lib.rs contains the proc-macro definition.

Proc-macro expansion happens at compile time in annotation/ crate—make sure rust-toolchain.toml is respected (both annotation and cli specify versions). Configuration is TOML-based and case-sensitive (cli/data/tests/ has examples). Type mapping between Rust and target languages is lossy by design (e.g., Rust's visibility modifiers don't always translate); read cli/README.md for language-specific caveats. Test snapshots are compared exactly—whitespace and formatting matter. The annotation macro doesn't actually generate code at macro-invocation time; code generation happens in the CLI pass.

• Proc-macro code generation — The #[typeshare] annotation in annotation/src/lib.rs is a compile-time procedural macro; understanding how Rust proc-macros work is essential to modifying the annotation system
• AST parsing and transformation — The entire core/ crate parses Rust AST using syn crate and transforms it into multiple language ASTs; this is the core algorithm of typeshare
• Multi-target code generation — Typeshare implements separate backends for Swift, Go, Python, Kotlin, Scala, TypeScript—understanding how to extend with a new language backend requires understanding the generator pattern
• Foreign Function Interface (FFI) — The entire purpose of typeshare is to solve FFI type synchronization; knowledge of how Rust calls C/native code is essential context
• Snapshot testing — The test suite relies entirely on snapshot testing (input.rs → output.swift pattern); changes to generators require updating snapshots in core/data/tests/
• Type mapping and isomorphism — The core challenge is mapping Rust types to semantically equivalent types in 7 languages with different type systems—not always a perfect 1:1 mapping
• Configuration as code (TOML) — Users control code generation behavior via TOML configs in cli/src/config.rs; the format and schema design directly impacts ease of use

• serde-rs/serde — De facto standard for Rust serialization; typeshare complements it by also handling FFI type definitions
• tauri-apps/tauri — Desktop framework that also needs bidirectional type sync between Rust and JavaScript; shares the cross-language FFI problem domain
• mozilla/uniffi-rs — Alternative FFI code generation tool focusing on procedural macros and runtime behavior; direct competitor addressing similar use case
• 1Password/typeshare-cli-go — If exists, would be the Go-specific wrapper or reference for typeshare in Go projects
• getsentry/sentry-rust — Large Rust library that also needs cross-language bindings; likely uses or is aligned with typeshare patterns

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 integration tests for Go code generation in core/data/tests

The repo has extensive test fixtures for Swift, Kotlin, Python, Scala, and TypeScript outputs (e.g., can_generate_algebraic_enum/output.swift, output.kt, output.py, output.scala, output.ts), but Go output files are sparse. Given Go is listed in go_config.toml, adding comprehensive Go output fixtures will ensure parity across languages and catch regressions in Go code generation.

• [ ] Audit core/data/tests/ directories for missing output.go files (compare against output.swift, output.ts, etc.)
• [ ] Create output.go fixtures for at least 5 test cases: can_generate_algebraic_enum, anonymous_struct_with_rename, can_apply_prefix_correctly, and 2 others
• [ ] Run typeshare CLI against input.rs files with go_config.toml to generate the expected outputs
• [ ] Ensure tests pass via the existing CI (likely in .github/workflows/ci.yml)

Add CLI unit tests for parse.rs and config.rs modules

cli/src/ contains parse.rs and config.rs which handle critical functionality (argument parsing and configuration loading), but no dedicated unit tests are evident in the file structure. These modules deserve focused test coverage to prevent regressions in CLI behavior and config validation.

• [ ] Review cli/src/parse.rs and cli/src/config.rs to identify public functions lacking tests (e.g., config parsing, default value handling)
• [ ] Create cli/src/parse_tests.rs and cli/src/config_tests.rs with unit tests covering: valid/invalid config files, CLI argument variants, and edge cases
• [ ] Use cli/data/tests/*.toml fixtures (constraints_config.toml, decorators_config.toml, etc.) as test data
• [ ] Integrate tests into the CI pipeline by verifying they run in .github/workflows/ci.yml

Add end-to-end test fixture for custom type mappings feature

The repo has cli/data/tests/mappings_config.toml which suggests type mapping configuration is a feature, but there's no corresponding test fixture directory (like core/data/tests/custom_type_mappings/) with input.rs and multi-language output files. This feature deserves dedicated E2E coverage.

• [ ] Create core/data/tests/custom_type_mappings/ directory
• [ ] Add input.rs with Rust types that exercise custom mapping rules (e.g., mapping Rust primitives to target language equivalents)
• [ ] Generate output files for all supported languages (output.swift, output.kt, output.py, output.scala, output.go, output.ts)
• [ ] Verify the test runs as part of the standard test suite (core tests likely execute automatically in CI)

• Add snapshot tests for edge cases in enum variant naming (check core/data/tests/ for enum patterns and add new test directories for underscores, numbers, reserved keywords across all 7 languages)
• Extend cli/src/config.rs to support per-language mapping overrides (e.g., custom type mappings like 'HashMap -> NSDictionary' for Swift) and add test cases in cli/data/tests/mappings_config.toml
• Add documentation to cli/README.md for the config schema—currently only cli/data/tests/ shows examples; write a reference guide for TOML options per language

The Typeshare codebase demonstrates a reasonably secure posture with modern Rust safety practices and basic configuration hardening. No critical vulnerabilities were identified. Main concerns are: (1) dependency versions could be more explicitly pinned for supply chain security, (2) release build doesn't explicitly enable overflow-checks which is important for FFI code generation, and (3) missing security reporting policy. The project would benefit from running 'cargo audit' in CI/CD and implementing SBOM generation for transparency. Overall security rating is good with minor improvements recommended for production hardening.

• Medium · Deprecated Log Crate Version — Cargo.toml (workspace.dependencies). The workspace dependencies specify 'log = "0.4"' without an upper bound. Version 0.4.x is from 2018-2020 era. While not critically vulnerable, newer versions (0.4.20+) may contain important fixes. Consider updating to the latest 0.4.x version to ensure all security patches are applied. Fix: Update to 'log = "0.4.20"' or latest stable 0.4.x version. Monitor for security advisories via 'cargo audit'.
• Low · Flexi Logger Version Constraint — Cargo.toml (workspace.dependencies). The workspace dependencies specify 'flexi_logger = "0.31"' which is an older version (released ~2023). Current versions are 0.28+ with 0.28.4 being relatively recent. Using older versions may miss important bug fixes and performance improvements. Fix: Update flexi_logger to the latest stable version. Run 'cargo update' and verify compatibility with existing code.
• Low · Missing Dependency Lock for Production — Cargo.toml (workspace.dependencies). The Cargo.lock file is present but workspace dependencies use flexible versioning (0.4, 0.31). While Cargo.lock prevents version drift, the flexible version constraints could still allow minor/patch updates. For a security-critical tool like Typeshare used for FFI type synchronization, this could introduce unexpected behavior. Fix: Consider pinning exact versions for dependencies (e.g., 'log = "=0.4.20"') or use version constraints with careful monitoring. Implement 'cargo audit' in CI/CD pipeline.
• Low · Limited Release Profile Security Hardening — Cargo.toml ([profile.release]). The release profile enables LTO and optimization but does not explicitly enable security features. Missing: overflow-checks for production builds, which could allow integer overflow bugs in FFI code generation to go undetected. Fix: Add 'overflow-checks = true' to the release profile to catch integer overflows. Consider adding 'strip = false' to preserve debug symbols for security analysis.
• Low · Test Profile Configuration Missing — Cargo.toml ([profile.test]). The [profile.test] section is empty. This means test builds use default settings. For a code generator used in FFI, ensuring tests run with maximum safety checks is important. Fix: Explicitly configure test profile: add 'overflow-checks = true', 'opt-level = 1', and ensure debug assertions are enabled to catch issues early.
• Low · No SECURITY.md Policy Found — Repository root. The repository does not include a SECURITY.md file for reporting security vulnerabilities responsibly. This makes it difficult for security researchers to report issues privately. Fix: Create SECURITY.md with clear instructions for reporting vulnerabilities, expected response timeframe, and whether a security mailing list exists.

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.