TOOL_CATALOG.md

# Meta Tool Catalog

This file is a grounded inventory of the tool surface available right now.

It is split into three layers:

1. Live Codex tools available in this session
2. Installed skills and connectors available to this environment
3. Open-source app and workflow surfaces discovered in the local workspace

This is not a claim about "every tool any AI has ever used on earth." That is not enumerable from local evidence. This is the honest, source-backed catalog of what is available here.

## 1. Live Codex Tool Surface

These are the tools exposed directly to this Codex session.

### Built-in web and media

- `web.search_query` - internet search
- `web.open` - open search results or URLs
- `web.click` - follow links on opened pages
- `web.find` - find text on opened pages
- `web.screenshot` - PDF screenshots
- `web.image_query` - image search
- `web.finance` - market quotes
- `web.weather` - weather lookup
- `web.sports` - schedules and standings
- `web.time` - timezone lookup
- `image_gen.imagegen` - generate or edit bitmap images

### Local execution and editing

- `functions.exec_command` - shell execution
- `functions.write_stdin` - interact with running shell sessions
- `functions.apply_patch` - edit files safely with patches
- `functions.view_image` - inspect local images
- `functions.load_workspace_dependencies` - discover bundled runtimes and libraries

### Planning and orchestration

- `functions.update_plan`
- `functions.get_goal`
- `functions.create_goal`
- `functions.update_goal`
- `functions.request_user_input` only when enabled in mode
- `multi_tool_use.parallel` - parallel developer-tool execution

### MCP and discovery

- `functions.list_mcp_resources`
- `functions.list_mcp_resource_templates`
- `functions.read_mcp_resource`
- `tool_search.tool_search_tool` - deferred tool and connector discovery

### Repo/app navigation

- `codex_app.navigate_to_codex_page`
- `codex_app.read_thread_terminal`

### Plugin management

- `functions.list_available_plugins_to_install`
- `functions.request_plugin_install`

## 2. Installed Skills in This Environment

These are higher-level operating manuals and helper packs available to Codex in this desktop environment.

### Core platform and infra

- `agents-sdk`
- `cloudflare`
- `cloudflare-email-service`
- `cloudflare-one`
- `cloudflare-one-migrations`
- `durable-objects`
- `sandbox-sdk`
- `workers-best-practices`
- `wrangler`
- `turnstile-spin`

### OpenAI and Codex

- `openai-docs`
- `plugin-creator`
- `skill-creator`
- `skill-installer`

### Browser and UI control

- `browser:control-in-app-browser`
- `chrome:control-chrome`
- `web-perf`
- `imagegen`

### Data, docs, and artifacts

- `pdf:pdf`
- `presentations:Presentations`
- `spreadsheets:Spreadsheets`
- `template-creator:template-creator`

### Business and app connectors

- `airtable:airtable-cli`
- `airtable:airtable-filters`
- `airtable:airtable-overview`
- `github:github`
- `github:gh-address-comments`
- `github:gh-fix-ci`
- `github:yeet`
- `linear:linear`
- `slack:slack`
- `slack:slack-channel-summarization`
- `slack:slack-daily-digest`
- `slack:slack-notification-triage`
- `slack:slack-outgoing-message`
- `slack:slack-reply-drafting`
- `canva:canva-branded-presentation`
- `canva:canva-resize-for-all-social-media`
- `canva:canva-translate-design`

### Payments and external service work

- `stripe-best-practices`
- `stripe-projects`
- `upgrade-stripe`

## 3. Workspace-Discovered App Surface

The local workspace includes a resurrected workflow system here:

- [cipher-workflow app catalog](C:\Users\jessi\Desktop\bobs control repo\shadow-orchestrator\.resurrect-workspace\cipher-workflow\src\lib\app-catalog.ts)
- [cipher-workflow node registry](C:\Users\jessi\Desktop\bobs control repo\shadow-orchestrator\.resurrect-workspace\cipher-workflow\src\config\node-components.ts)
- [cipher-workflow logos](C:\Users\jessi\Desktop\bobs control repo\shadow-orchestrator\.resurrect-workspace\cipher-workflow\public\logos)

What is verifiable from source:

- `42` connector/logo assets are present in `public/logos`
- `113` app presets are declared in `app-catalog.ts`
- the universal dialog claims `70+ apps with 400+ operations`
- `39` registered workflow node imports exist in `node-components.ts`

## 4. Workspace Connector Logos

These connectors are visually provisioned in the local workflow stack:

- Airtable
- Anthropic
- Asana
- ClickUp
- Discord
- Dropbox
- Email
- Firebase
- Gemini
- GitHub
- Google
- Google Sheets
- Google Form
- HubSpot
- Instagram
- Jira
- Linear
- LinkedIn
- Mailchimp
- Mistral
- Mixpanel
- Notion
- OpenAI
- Qwen
- RSS
- Salesforce
- SendGrid
- Shopify
- Slack
- SMS
- Spotify
- Stripe
- Supabase
- Telegram
- Trello
- Twitter
- Vercel API
- WhatsApp
- YouTube
- Zendesk
- Zoom

## 5. Implemented Workflow Node Types

These are not just icons. They are registered node types in the local workflow editor.

### Triggers

- Initial
- Manual Trigger
- Google Form Trigger
- Stripe Trigger
- Webhook Trigger
- Schedule Trigger

### AI model nodes

- Gemini
- OpenAI
- Anthropic
- Mistral
- Qwen

### Messaging and social execution

- Discord
- Slack
- Twitter
- Telegram
- LinkedIn
- Instagram
- WhatsApp
- Email
- SMS
- RSS Feed

### Productivity and developer execution

- Notion
- Google Sheets
- GitHub
- HTTP Request
- Universal App Node

### AI utility and chain nodes

- AI Agent
- AI Chain
- Summarizer
- Text Classifier
- Info Extractor
- Output Parser
- Document Loader
- Text Splitter
- AI Memory
- Embeddings
- Vector Store

## 6. Broader App Preset Families Found in Source

The local `app-catalog.ts` goes beyond the visible logos. It includes larger preset families across:

- CRM and sales
- Project management
- Communication
- Cloud storage
- Databases
- E-commerce
- Marketing
- Finance
- Productivity
- Developer tools
- Utilities
- AI and ML

Examples explicitly present in source include:

- HubSpot
- Salesforce
- Pipedrive
- Zoho CRM
- ActiveCampaign
- Copper
- Close CRM
- Freshsales
- Asana
- Jira
- Trello
- ClickUp
- Linear
- Monday.com
- Todoist
- Basecamp
- Zoom
- Calendly
- Cal.com
- Microsoft Teams
- Google Drive
- Dropbox
- Box
- OneDrive
- Airtable
- Supabase
- Firebase
- Shopify
- WooCommerce
- PayPal
- Mailchimp
- SendGrid
- Stripe
- Notion
- Make
- Zapier
- Smartsheet

## 7. What This Means Operationally

You effectively have three concentric layers:

1. Codex-native operator tools
2. Installed connector and skill layer
3. A local open-source workflow catalog that already models a large multi-app automation surface

That means you do not need to treat "tooling" as one thing. You already have:

- agent tooling
- browser tooling
- shell tooling
- editing tooling
- connector tooling
- workflow-node tooling
- webhook-trigger tooling
- universal REST app tooling

## 8. Gaps and Honest Limits

- I cannot prove "every tool AI has ever called on" from local evidence alone.
- Some presets in `app-catalog.ts` may be declared but not fully wired as dedicated first-class nodes.
- Some installed skills are manuals and workflows, not raw callable APIs by themselves.
- Some connectors need credentials before they become usable in practice.

## 9. Recommended Next Catalogs

If you want this pushed further, the next useful splits are:

1. `TOOL_CATALOG_RUNTIME.md` - only tools callable right now without extra credentials
2. `TOOL_CATALOG_CONNECTORS.md` - every third-party integration by auth model and transport
3. `TOOL_CATALOG_AGENTS.md` - every agent role, model endpoint, and workflow node in one matrix
4. `TOOL_CATALOG_UI.md` - every frontend surface, page, and launcher across your GitHub Pages estate

## 10. Second Layer: IBM and Enterprise Language Stack

This is not the live Codex tool surface. It is the second conceptual layer you asked to track: enterprise execution languages, automation languages, and orchestration DNA worth borrowing.

## 11. IBM Mainframe and Enterprise Languages

| Language | Purpose |
|---|---|
| COBOL | Enterprise business systems, banking, insurance, government workloads |
| REXX | Automation scripts, system utilities, TSO commands, ISPF tooling |
| JCL | Defines and runs batch jobs, controls datasets and execution flow |
| PL/I | Scientific, engineering, and enterprise applications |
| HLASM | Low-level system programming, hardware interaction |
| C / C++ | Systems programming and enterprise applications on z/OS |
| Java | Enterprise applications, APIs, and web workloads on IBM systems |

## 12. IBM Automation and Scripting Languages

| Language | Purpose |
|---|---|
| REXX | Mainframe automation scripting |
| CLIST | Older TSO command scripting language |
| Python | Modern automation, AI, cloud, and DevOps tooling |
| JavaScript / Node.js | Web tools, APIs, and automation services |
| Shell scripting | Linux and AIX automation |

## 13. IBM i (AS/400) Languages

| Language | Purpose |
|---|---|
| RPG / RPGLE | Business applications on IBM i |
| CL (Control Language) | IBM i system automation |
| COBOL | Business workloads |
| C / C++ | System and application development |
| Java | Modern IBM i applications |
| SQL PL | Database procedures |

## 14. IBM Database and Data Languages

| Language | Purpose |
|---|---|
| SQL | DB2 databases |
| SQL PL | Stored procedures and database logic |
| SPUFI commands | DB2 interactive SQL tooling |
| QMF scripting | Query and report automation |

## 15. IBM Legacy and Specialized Languages

| Language | Purpose |
|---|---|
| Easytrieve | Report generation and data processing |
| Natural | Enterprise application development, often alongside IBM environments |
| Assembler | Hardware-level programming |
| BASIC / Pascal | Historical IBM platforms |

## 16. Orchestration DNA to Borrow

If the goal is an agent orchestration language with mainframe discipline, the useful borrow points are:

| Source | Borrowed strength |
|---|---|
| REXX | readable automation rules |
| JCL | workflow and job orchestration |
| Regex | pattern matching and event detection |
| COBOL | strong data structures and business rules |
| SQL | state and memory queries |
| Assembler or Rust-style execution | deterministic low-level execution |

That gives you a design direction closer to:

- REXX-style readable control flow
- JCL-style execution staging and dispatch
- regex-driven routing and extraction
- COBOL-style record discipline
- SQL-backed state access
- deterministic kernel execution under a tighter systems layer

In plain terms: a modern agent language shaped like `REXX + JCL + regex + typed systems core`.

## 17. Third Layer: GPU, NVIDIA, and Parallel Compute Stack

This layer tracks the compute-side execution model that complements the IBM enterprise control layer.

## 18. GPU and CUDA Programming

| Language / Layer | Use |
|---|---|
| CUDA C/C++ | NVIDIA's primary GPU programming model; write kernels that run directly on GPUs |
| CUDA Fortran | GPU acceleration for scientific computing |
| PTX | NVIDIA's low-level virtual assembly language for GPUs |
| SASS | Actual NVIDIA GPU machine instructions |

Example CUDA kernel:

```cpp
__global__ void add(int *a, int *b, int *c) {
    int i = threadIdx.x;
    c[i] = a[i] + b[i];
}
```

## 19. AI and Machine Learning Stack

| Language / Layer | Use |
|---|---|
| Python | Dominant AI development language |
| C++ | Framework backends, inference engines, and high performance runtime code |
| CUDA Python | Python interface to CUDA |
| Triton | GPU kernel programming language created by OpenAI, widely used with NVIDIA GPUs |
| PyTorch (Python/C++) | Deep learning framework heavily optimized for NVIDIA GPUs |

## 20. NVIDIA Hardware and System Languages

| Language / Layer | Use |
|---|---|
| Verilog / SystemVerilog | Designing digital hardware and chips |
| VHDL | Hardware description, less common in NVIDIA workflows |
| C | Embedded systems, firmware, and drivers |
| C++ | Drivers, runtimes, robotics, and graphics systems |

## 21. Graphics and Simulation Languages

| Language / Layer | Use |
|---|---|
| GLSL | GPU shader programming |
| HLSL | Graphics shaders in the DirectX ecosystem |
| OpenCL C | General GPU computing |
| OptiX programs | Ray tracing development |
| USD / Python | 3D scenes and simulation workflows |

## 22. Robotics and Autonomous Systems

| Language / Layer | Use |
|---|---|
| Python | AI pipelines and robotics scripts |
| C++ | Real-time robotics systems |
| CUDA | Accelerated perception and simulation |
| ROS (C++/Python) | Robot operating system stack |

## 23. NVIDIA Stack DNA

If the IBM side is:

- JCL -> orchestrate jobs
- REXX -> automate systems
- COBOL -> process business logic

Then the NVIDIA side is closer to:

- CUDA -> orchestrate computation
- PTX -> control GPU execution
- tensor compute -> accelerate AI math
- Python -> compose intelligence

For an agent language or agent OS, the NVIDIA-inspired borrow points are:

| Source | Borrowed strength |
|---|---|
| CUDA | parallel agent execution |
| PTX | low-level agent instructions |
| tensor compute | accelerated inference and scoring |
| Triton | custom AI kernel paths |
| Python | AI model composition and tooling |
| C++ / Rust style runtime discipline | deterministic high-performance execution |

## 24. Plasma Mamba 8B Combo Architecture

This is the synthesized architecture using the IBM control layer, NVIDIA compute layer, and modern model-architecture layer.

### Core thesis

The clean split is:

- IBM-style languages define workflow, governance, business logic, and batch discipline
- NVIDIA-style layers define parallel compute, accelerated inference, and low-level execution
- modern model architectures define reasoning, memory, specialization, and routing

### Model architecture layer

| Architecture | Role in the stack |
|---|---|
| Transformer | reasoning, attention, tool selection, structured generation |
| Mamba / SSM | persistent sequence memory, long-context efficiency, state tracking |
| MoE | specialist activation without paying full dense-model cost |
| RWKV / hybrid recurrent forms | lightweight persistent state and streaming behavior |

### Plasma Mamba 8B layout

`Plasma Mamba 8B` should be treated as a hybrid agent core, not a pure single-architecture bet.

Recommended split:

| Layer | Recommended role |
|---|---|
| Transformer block | deliberate reasoning, instruction following, synthesis |
| Mamba block | long-running memory, state carry, efficient context digestion |
| MoE routing head | specialist agent dispatch and domain specialization |
| CUDA / Triton kernels | accelerated inference and scoring paths |
| PTX-like intermediate layer | low-level deterministic agent instruction form |

### System architecture mapping

| System concern | Best fit |
|---|---|
| Agent interfaces | TypeScript or C# |
| Distributed runtime | Go |
| Secure execution core | Rust |
| AI tools and orchestration glue | Python |
| Enterprise workflow and policy | REXX + JCL + COBOL style design |
| State and memory | SQL + graph database |
| Accelerated intelligence layer | CUDA / Triton / tensor compute |

### SnapKitty-style control stack

A coherent control stack using your framing looks like this:

1. `JCL-style orchestration layer`
   - batch scheduling
   - staged workflow dispatch
   - job graph execution

2. `REXX-style readable automation layer`
   - policy rules
   - operator-readable control scripts
   - glue between modules

3. `Regex/event routing layer`
   - trigger detection
   - pattern classification
   - message and document extraction

4. `COBOL-style business rules layer`
   - record discipline
   - claims, law, finance, trust, and audit data structures
   - deterministic business logic

5. `Transformer reasoning layer`
   - synthesis
   - explanation
   - planning
   - tool choice

6. `Mamba memory layer`
   - persistent state tracking
   - long-range context compression
   - efficient sequence retention

7. `MoE specialist layer`
   - legal specialist
   - finance specialist
   - audit specialist
   - code specialist

8. `CUDA / Triton execution layer`
   - accelerated kernels
   - high-throughput inference
   - parallel scoring and dispatch

9. `PTX-like substrate layer`
   - compact intermediate instructions
   - deterministic execution target
   - future-proof backend portability

### Practical reading

If you want one sentence for the architecture:

`Plasma Mamba 8B = Transformer reasoning + Mamba memory + MoE specialization + CUDA-class execution under an IBM-style orchestration shell.`

That is the version that makes technical sense. It avoids random language sprawl and gives each layer a job.

## 25. Layer 4: Repo-to-Architecture Module Map

This layer answers three questions:
- which language belongs in which repo
- which layer belongs in frontend vs backend vs kernel
- what should be experimental vs production core

### Production core — never changes without a deed amendment

These are the kernel layer. Deterministic, WORM-sealed, no side effects that aren't auditable.

| Repo / File | Language | Layer | Role |
|---|---|---|---|
| `cartographer-agent/kernels/rexx-glue-kernel.rexx` | REXX | Kernel | Business action dispatch — 15 legal actions |
| `cartographer-agent/kernels/route-dispatch.rexx` | REXX | Kernel | Pattern match → kernel chain |
| `sovereign-glue.rexx` | REXX | Kernel | Master glue — domain detect → full chain |
| `cartographer-agent/kernels/carto-gate.lp` | ASP/Clingo | Kernel | Constitutional constraint — UNSAT on violation |
| `cartographer-agent/prolog/carto.pl` | Prolog | Kernel | Standing logic — pure Horn clauses |
| `bobs-control-repo/.../sovereign-alien-trust.pl` | Prolog | Kernel | Trust deed axioms — 13 rules, adversarial detection |
| `cartographer-agent/kernels/cobol-law-kernel.cob` | COBOL | Kernel | Financial transaction law |
| `cartographer-agent/runtime/dfa-engine.mjs` | JS | Kernel | O(n) tokenizer — PTX substrate of the stack |
| `mathrosetta/src/dispatcher.rs` | Rust | Kernel | Math solver routing — Z3/Lean4/Julia/SymPy |
| `mathrosetta/src/worm/chain.rs` | Rust | Kernel | WORM chain — Mamba memory equivalent |
| `snapkitty-chain/src/chain.mjs` | JS | Kernel | P2P chain — consensus, ZK, mempool |

### Backend runtime — stable but evolvable

These serve requests, translate between layers, and orchestrate kernel calls.

| Repo / File | Language | Layer | Role |
|---|---|---|---|
| `agentos/src/sovereign-daemon/main.go` | Go | Backend | HTTP daemon — execute, sign, validate endpoints |
| `cartographer-agent/runtime/corpus_store.ml` | OCaml | Backend | Knowledge retrieval — 9-chapter law corpus |
| `cartographer-agent/runtime/route-dispatch.mjs` | JS | Backend | JS mirror of REXX router — used by browser UI |
| `cartographer-agent/runtime/trust-deed-generator.mjs` | JS | Backend | Deed forge — EIN → Prolog + plain English deed |
| `cartographer-agent/runtime/summon-envelope.mjs` | JS | Backend | Agent summon envelope — WORM-sealed dispatch |
| `workers/meta-webhook.js` | JS (Cloudflare Worker) | Backend | Meta webhook receiver — KV store + /feed endpoint |
| `kernel-registry.json` | JSON | Backend | Registry — every kernel's path, invoke, domain, complexity |

### Frontend — ephemeral, agent-facing, user translation layer

The agent is only alive here. Dies at session end. The kernel persists. The deed persists. The UI does not.

| Repo / File | Language | Layer | Role |
|---|---|---|---|
| `cartographer-agent/docs/mylaw.html` | HTML/JS/Tau Prolog | Frontend | MyLaw — Facebook 2009 UI, BOB messenger, wall posts |
| `cartographer-agent/docs/carto-live.html` | HTML/JS/Tau Prolog | Frontend | CARTO engine — developer-facing, purple/gold theme |
| `cartographer-agent/docs/shakespearean-code.html` | HTML/JS | Frontend | Shakespearean DSL demo |
| `mathrosetta/src/wasm.rs` | Rust → WASM | Frontend | Math IR in browser — Rust compiled to WASM |
| `.newrepos/snapkitty-clojure-lisp-bridge/` | Clojure/ClojureScript | Frontend | Lisp/symbolic wire format — inter-agent protocol |

### Experimental — not production, high upside

These are research beds. Real assets but not load-bearing yet.

| Repo / File | Language | Layer | Role |
|---|---|---|---|
| `mathrosetta/src/emitters/lean4.rs` | Rust | Experimental | Lean4 proof output — full certificate generation |
| `mathrosetta/src/emitters/coq.rs` | Rust | Experimental | Coq output — alternative proof backend |
| `mathrosetta/src/nlp/mod.rs` | Rust | Experimental | NaturalParser — phrase → MathIR, 11 phrases wired |
| `prism-skills/` | Various | Experimental | PSI pipeline — admission, canonical, seal, sha256d |
| `qec-discovery/` | APL + Fortran | Experimental | Quantum error correction research |
| `pnp-attack/` | APL + Fortran | Experimental | P≠NP formal attack — not a claim, a proof attempt |
| `resonance-math/` | Various | Experimental | Resonance axiom system |
| `.qwen/skills/` | Various | Experimental | Qwen skill pack — 9 auto-skills for routing tests |
| `S_AUTOCODE/` | Various | Experimental | AUTOCODE lineage — the origin system |

### What this means for build prioritization

Three rules from this map:

**Rule 1: Never Python in the kernel layer.**
Python belongs in the NVIDIA/AI tooling layer (training, fine-tuning, embeddings). It does not belong in the REXX/Prolog/COBOL kernel chain. The kernel must be deterministic and auditable. Python is not that.

**Rule 2: The frontend is the translation layer. It is not the product.**
mylaw.html, carto-live.html — these are how humans touch the kernels. The kernels are the product. The UI can be rebuilt in an afternoon. The sovereign-alien-trust.pl took months.

**Rule 3: Experimental repos are batteries. Production repos are the circuit.**
qec-discovery, pnp-attack, resonance-math — these are energy storage. They prove mathematical properties that will eventually flow into the kernel layer as new axioms. Don't rush them into production. Let them complete their proofs first.

### The one sentence this all reduces to

`The kernel layer computes truth. The backend layer routes it. The frontend layer translates it. The agent reads the translation and dies. The WORM chain remembers everything.`

That is the full architecture. IBM gave us the orchestration discipline. NVIDIA gave us the execution speed. Mamba gave us the memory model. SnapKitty gave us the deed that governs it all.