RFC: Fullsend Deployment on zero-dot-force and Improving Unbound Force #1

sonupreetam · 2026-07-28T07:58:11Z

sonupreetam
Jul 28, 2026
Maintainer

RFC: Fullsend Deployment on zero-dot-force and Improving Unbound Force

Status: Draft / Open for Discussion
Author: @sonupreetam
Date: 2026-07-28
Audience: zero-dot-force contributors, unbound-force maintainers

0. Context

What is zero-dot-force?

zero-dot-force is the labs incubator for Unbound Force -- the superhero-themed AI agent swarm for software engineering. zero-dot-force is where experimental and early-stage projects incubate before graduating to the main unbound-force org.

Repo	Description	Language	Status
snake-eyes	Python analyzer for Gaze -- test quality analysis via side effect detection	Shell/Python	v0.x (early development)
.github	Organization-wide GitHub configuration	--	Active

What is snake-eyes?

snake-eyes detects observable side effects in Python functions and reports them to Gaze's universal scoring engine via JSON-RPC 2.0. It implements Gaze's external analyzer protocol with six methods: initialize, discover, analyze, complexity, coverage, shutdown.

Python 3.11+ codebase using ast, symtable, and astroid
Already uses UF tooling -- .opencode/, .specify/, .uf/, openspec/ directories present
Apache 2.0 licensed
Early stage (v0.x, 4 commits) -- ideal time to experiment

What is Unbound Force?

Unbound Force is an AI agent swarm where superhero personas (Gaze, Muti-Mind, Cobalt-Crush, The Divisor, Mx F) collaborate as a software development team. It has a constitution, specification pipelines (Speckit/OpenSpec), a 9-persona review council, convention packs, and a knowledge layer (Dewey). It is strong on agent design and governance but has gaps in execution infrastructure (no sandbox isolation, no secretless credential management, no autonomous event-driven dispatch).

What is Fullsend?

Fullsend is an autonomous agentic software development platform with six agents (triage, code, review, fix, retro, prioritize) that run the full SDLC autonomously via GitHub Actions. It is strong on production infrastructure (OpenShell sandbox, OIDC/WIF secretless auth, token mint, per-role GitHub Apps, container signing) but does not have UF's governance depth (constitution, spec pipelines, review council, convention packs).

1. Summary

This document proposes two things:

Deploy fullsend agents directly on zero-dot-force (starting with snake-eyes) to gain autonomous issue triage, code generation, review, fix, retro, and prioritization.
Use zero-dot-force as a playground to experiment with ideas from fullsend, unbound-force, and other projects in the GitHub ecosystem -- then port validated improvements back to unbound-force to enhance what UF already has.

zero-dot-force is the right place for this because it is the labs incubator. Breaking things here is acceptable. Breaking things in unbound-force is not. Experiments that prove their value on snake-eyes and future zero-dot-force repos graduate to UF proper.

2. Why Both? The Gap Analysis

Neither fullsend nor unbound-force is complete alone. Each excels where the other has gaps:

Concern	Fullsend	Unbound Force	Gap Owner
Autonomous event dispatch	CEL triggers, GitHub event-driven, zero human intervention	Slash-command triggered (`/review-council`, `/speckit.implement`)	UF lacks autonomous dispatch
Credential isolation	4-tier model, credentials never enter sandbox (ADR 0017)	No sandbox model, manual PATs	UF lacks credential isolation
Execution sandbox	OpenShell with L7 network policy, per-agent isolation	No execution isolation	UF lacks sandboxing
Token management	Centralized mint, OIDC/WIF, secretless repos	Manual PAT/token management	UF lacks secretless auth
Container security	Signed images (Sigstore), zero runtime installs	No container model	UF lacks container security
Multi-org support	Single mint serves multiple orgs	Single-org only	UF lacks multi-org
Forge abstraction	GitHub, GitLab, Forgejo via `forge.Client`	GitHub only	UF lacks forge portability
Constitution governance	No governance framework	5-principle constitution, CRITICAL violations block	Fullsend lacks governance
Specification pipelines	No spec workflow	Speckit (9 phases) + OpenSpec (4 phases), phase discipline	Fullsend lacks spec-driven dev
Multi-persona review	Single review agent, single pass	9 specialized Divisor personas in parallel, council verdict	Fullsend lacks review depth
Convention packs	Skills (ad hoc)	Dual-ownership packs (tool-owned + user-owned), severity tagging	Fullsend lacks structured conventions
Quality analysis	Coverage delta checks	Gaze: CRAP scores, side-effect detection, coverage ratchets, quadrants	Fullsend lacks deep quality analysis
Knowledge layer	No knowledge graph	Dewey: semantic search + graph traversal via MCP	Fullsend lacks knowledge indexing
Product ownership	Prioritize agent (RICE scoring)	Muti-Mind: backlog, stories, acceptance, GitHub sync	Comparable
Retrospectives	Retro agent (post-merge)	Mx F: coaching, sprint metrics, impediment tracking	Comparable

The thesis: deploy fullsend for the infrastructure UF lacks, then use zero-dot-force to experiment with bringing UF's governance strengths into fullsend's execution model -- and port the results back to UF.

3. Integration Checklist

Phase 0: Prerequisites

GCP Project -- Create or identify a GCP project with billing enabled
Enable GCP APIs -- iam.googleapis.com, cloudresourcemanager.googleapis.com, aiplatform.googleapis.com
Enable Vertex AI Models -- Claude Opus 4.6, Sonnet 4.6, Haiku 4.5
Grant IAM Roles -- roles/iam.workloadIdentityPoolAdmin, roles/resourcemanager.projectIamAdmin to the deploying user
Install CLIs -- gcloud (authenticated), fullsend (latest release), gh (authenticated)
Repository exists -- zero-dot-force/snake-eyes already exists with README, LICENSE, AGENTS.md, and UF tooling scaffolded

Phase 1: Token Mint Enrollment

Decision: Hosted vs Self-Managed Mint
- Hosted: Contact fullsend team with org/repo name (simpler, shared infrastructure)
- Self-managed: fullsend mint deploy --project <project> (full control, regulated environments)
Verify enrollment -- fullsend mint status

Phase 2: WIF (Workload Identity Federation) Setup

Provision WIF -- fullsend inference provision zero-dot-force/snake-eyes --project <gcp-project>
Record WIF Provider URL -- projects/<num>/locations/global/workloadIdentityPools/fullsend-inference/providers/gh-zero-dot-force-snake-eyes
Verify WIF -- fullsend inference status

Phase 3: GitHub App Installation

Install triage app -- https://github.com/apps/fullsend-ai-triage/installations/new
Install coder app -- https://github.com/apps/fullsend-ai-coder/installations/new
Install review app -- https://github.com/apps/fullsend-ai-review/installations/new
Install retro app -- https://github.com/apps/fullsend-ai-retro/installations/new
Install prioritize app -- https://github.com/apps/fullsend-ai-prioritize/installations/new
Grant repo access -- Each app has permissions scoped to the zero-dot-force org (specifically snake-eyes)

Phase 4: Repository Configuration

Run setup --

fullsend github setup zero-dot-force/snake-eyes \
  --inference-project "<gcp-project>" \
  --inference-wif-provider "<wif-provider-url>"

Verify .fullsend/ directory created with harness definitions, policies, workflows (note: .opencode/, .specify/, .uf/ already exist from UF scaffolding -- these coexist)
Verify GitHub Actions workflow -- shim workflow using pull_request_target
Verify secrets -- FULLSEND_GCP_PROJECT_ID, FULLSEND_GCP_WIF_PROVIDER set
Verify variables -- FULLSEND_MINT_URL, FULLSEND_GCP_REGION, FULLSEND_PER_REPO_INSTALL set

Phase 5: Security Hardening (MANDATORY)

CODEOWNERS -- Add .fullsend/ to CODEOWNERS requiring maintainer review
```
/.fullsend/ @<org>/maintainers
```
Branch protection -- Require PR reviews, status checks, no force pushes on main
Sandbox policy review -- Review each agent's sandbox policy in .fullsend/
Agent subset -- Start with --agents triage,review for conservative rollout
Slash command testing -- Test /fs-triage on a sample issue

Phase 6: Graduated Rollout

Week 1-2: Triage + Review only. Monitor agent behavior, review outputs.
Week 3-4: Add Code agent. Verify PR quality, test coverage.
Week 5-6: Add Fix agent. Verify it addresses review findings correctly.
Week 7+: Add Retro + Prioritize. Full autonomous loop.
Ongoing: Monitor costs (Vertex AI, GitHub Actions minutes), review JSONL traces.

Phase 7: Customization

AGENTS.md -- Create repo-level agent instructions (conventions, architecture context)
Skills -- Add repo-specific skills for domain knowledge
Custom harness -- Adjust agent behavior via .fullsend/ config overlay
CEL triggers -- Configure which events trigger which agents

4. Security Impact Analysis

4.1 Threat Surface Changes

Integrating fullsend introduces these new attack surfaces:

Threat	Severity	Mitigation
Prompt injection via issues/PRs	HIGH	All user-provided text treated as untrusted. Input sanitization (invisible Unicode stripped). Agent output passes through SecretRedactor + JSON schema validation.
Compromised token mint	HIGH	Short-lived tokens scoped to installations. Mint is a high-value target -- compromise could affect all repos sharing that mint. Self-managed mint option for regulated environments.
Agent-to-agent injection	MEDIUM	Zero trust between agents (no agent trusts another's output by identity). Scripted deterministic pipelines. Harness-level output schema validation.
Credential exfiltration from sandbox	LOW (by design)	Credentials never enter the sandbox. 4-tier credential delivery model (prefetch, L7-gated REST, provider-based, host files). OpenShell enforces network policy.
Container escape	LOW	OpenShell requires `CAP_NET_ADMIN`. Pre-baked images (no runtime installs). Sigstore cosign verification.
Supply chain: model-as-toolchain	MEDIUM	The LLM is a supply chain component. A compromised model can inject vulnerabilities at authoring time. Mitigated by model diversity, authorship provenance, property-based testing.
Temporal split-payload attack	MEDIUM	Attacker poisons tests in one PR, exploits them in a later PR. Mitigated by cross-PR analysis in retro agent, review council multi-angle review.
Agent drift	LOW-MEDIUM	Slow behavioral degradation. Mitigated by harness-level output validation, JSONL trace auditing, periodic configuration review.
Social pressure exploitation	LOW	Emotional framing in comments causing disproportionate agent actions. Mitigated structurally: credentialed operations applied by deterministic post-scripts, not the agent.

4.2 Security Invariants (Non-Negotiable)

These invariants MUST hold at all times:

Credentials never enter agent sandboxes (ADR 0017)
Each agent gets its own sandbox with least-privilege policy (ADR 0020)
OpenShell sandbox is the sole security boundary, not tool-level controls (ADR 0027)
Zero trust between agents -- all inter-agent output treated as untrusted
Mint (not repo secrets) holds all credential material (ADR 0029)
Container image is pre-baked, signed, no runtime installs (ADR 0036)
Agent configuration is CODEOWNERS-guarded (ADR 0017)
All agent output passes through SecretRedactor + schema validation (ADR 0022)

4.3 What We Give Up

Trade-off	Explanation
Mint dependency	Agent operations stall if the mint is unreachable (availability SPOF)
GCP dependency	Inference requires GCP Vertex AI; no alternative inference providers currently supported
Privileged containers	OpenShell needs `CAP_NET_ADMIN`; may conflict with restrictive PodSecurityPolicies
Trust in shared apps	Using hosted mint means trusting fullsend-ai's GitHub Apps and mint infrastructure
LLM unpredictability	Agents may produce unexpected output; graduated approval policy is still unimplemented
Cost opacity	Vertex AI and GitHub Actions costs are usage-dependent and may spike

4.4 Required Security Controls

Before going live, these MUST be in place:

1. CODEOWNERS on /.fullsend/ requiring 2+ maintainer approvals
2. Branch protection: require PR reviews, require status checks, no force push
3. Agent subset: start with triage+review only (no write access to code)
4. JSONL trace review: audit agent reasoning traces weekly during rollout
5. Cost alerts: set GCP billing alerts on Vertex AI spend
6. Sandbox policy review: each agent's network/filesystem policy reviewed by security-aware maintainer
7. Incident response: document procedure for revoking agent access (uninstall GitHub Apps)

5. Cost Estimation

Component	Estimated Monthly Cost	Notes
Vertex AI inference	$50-500+	Highly variable. Depends on issue volume, model selection (Haiku vs Opus), token count per agent run.
GCP Cloud Function (mint)	$0-5	Minimal compute; mostly idle between token requests.
GCP Secret Manager	<$1	PEM storage for agent app keys.
GitHub Actions	$0-100+	Runner minutes. Free tier for public repos. Private repos use org allocation.
GCP WIF	$0	No direct charge for WIF; cost is in the services it authenticates to.

Cost controls:

Start with --agents triage,review (cheapest agents, read-heavy)
Use Haiku for triage, Sonnet for code/review (cheaper than Opus)
Set GCP billing alerts at $100, $250, $500

6. Inspiration from Unbound-Force Agent Architecture

Unbound-force's agent swarm offers design patterns worth integrating into our fullsend deployment through customization:

6.1 Constitution-Governed Agents

UF Pattern: A constitution with 5 principles governs all agent behavior. Constitution violations are CRITICAL severity and non-negotiable.

Fullsend Adaptation:

Create a CONSTITUTION.md in the repo root
Reference it in AGENTS.md so fullsend agents internalize the governance principles
Map UF's 5 principles to fullsend context:

UF Principle	Fullsend Equivalent
Autonomous Collaboration (artifact-based, no runtime coupling)	Already enforced -- agents coordinate through GitHub events, not direct communication
Composability First (each agent independently useful)	Already enforced -- each agent is a separate GitHub App with independent sandbox
Observable Quality (machine-parseable output with provenance)	Enforce via harness output schema validation (ADR 0022)
Testability (isolation, no shared mutable state)	Enforce via sandbox policies + coverage ratchets in CI
Security by Default (supply chain integrity, least privilege)	Core fullsend design (ADR 0017, 0020, 0027, 0029, 0036)

6.2 Multi-Persona Review Council

UF Pattern: The Divisor runs 9 specialized personas in parallel, each reviewing from a different angle (Guard, Architect, Adversary, SRE, Testing, Curator, Scribe, Herald, Envoy).

Fullsend Adaptation:

Customize the fullsend review agent using skills to emulate council perspectives

Create skills for each review angle:

.fullsend/skills/
  review-security.md      # Adversary: SQLi, XSS, auth, error handling
  review-architecture.md  # Architect: DRY/SOLID, conventions, tech debt
  review-operations.md    # SRE: performance, observability, scaling
  review-testing.md       # Testing: coverage strategy, assertion quality
  review-docs.md          # Curator: naming, API surface, documentation

Configure the review agent to load all skills per run
Tag findings with severity: [MUST], [SHOULD], [MAY] (UF convention)

6.3 Convention Packs

UF Pattern: Dual-ownership convention packs (tool-owned + user-owned) that agents read before writing or reviewing code.

Fullsend Adaptation:

Create .fullsend/conventions/ directory with:

default.md           # Language-agnostic coding standards
go.md                # Go-specific conventions (if applicable)
severity.md          # Finding severity definitions
project-specific.md  # Domain-specific rules

Reference in AGENTS.md so all agents read conventions before acting
Convention packs serve as the "law" that the review agent enforces

6.4 Specification-Driven Workflow

UF Pattern: Speckit (strategic, 9 phases) and OpenSpec (tactical, 4 phases) pipelines ensure changes are specified before implementation. Phase discipline is a hard rule.

Fullsend Adaptation:

Use GitHub issue templates to enforce specification before coding:
- feature-request.md -- requires problem statement, acceptance criteria, scope estimate
- bug-report.md -- requires reproduction steps, expected behavior, actual behavior
Configure the triage agent to reject issues that don't follow templates
Configure the code agent to require a linked, labeled issue before generating PRs
Enforce via CEL triggers: code agent only activates on ready-to-code labeled issues

6.5 Gaze-Inspired Quality Gates

UF Pattern: Gaze enforces coverage ratchets (coverage can only go up), CRAP score analysis, and side-effect classification.

Fullsend Adaptation:

Configure the review agent to check:
- Test coverage delta (reject PRs that decrease coverage)
- New functions without tests
- High cyclomatic complexity without justification
Add quality gate checks as required status checks in branch protection
Create a skill that analyzes CRAP scores and flags high-risk code

6.6 Artifact-Based Communication

UF Pattern: Heroes communicate through well-known artifact paths (.uf/artifacts/), not runtime coupling.

Fullsend Adaptation:

Agents already communicate through GitHub (issues, labels, PRs, comments)
Enhance by creating structured output expectations:
- Triage agent writes structured JSON labels
- Code agent references issue numbers in PR body
- Review agent uses structured finding format
- Retro agent files improvement issues with structured metadata

6.7 Workflow Lifecycle Management

UF Pattern: 6-stage feature lifecycle managed by /workflow commands.

Fullsend Adaptation:

Map to fullsend's event-driven flow:

Issue filed --> Triage (classify, label) --> Code (implement, PR)
     --> Review (multi-angle) --> Fix (address findings)
     --> Merge --> Retro (analyze, improve)

Add GitHub project board columns matching stages for visibility

7. zero-dot-force as Playground: Experiment, Validate, Port to UF

This is the core strategic idea. zero-dot-force is not just a place to deploy fullsend -- it is the proving ground where ideas from fullsend, UF, and the broader ecosystem are tested before they touch unbound-force proper.

7.1 The Flow: Playground to Production

                    ┌──────────────────────────────────────────────┐
                    │         External Inspiration                  │
                    │  fullsend, complytime, open-source ecosystem  │
                    └────────────────┬─────────────────────────────┘
                                     │
                                     ▼
              ┌──────────────────────────────────────────┐
              │        zero-dot-force (playground)       │
              │                                          │
              │  - Deploy fullsend agents directly       │
              │  - Experiment with new patterns          │
              │  - Test UF enhancement ideas             │
              │  - Break things safely                   │
              │  - Measure what works                    │
              └────────────────┬─────────────────────────┘
                               │ validated results
                               ▼
              ┌──────────────────────────────────────────┐
              │      unbound-force (production)          │
              │                                          │
              │  - Port proven patterns                  │
              │  - Enhance existing heroes               │
              │  - Upgrade infrastructure                │
              │  - Strengthen governance                 │
              └──────────────────────────────────────────┘

7.2 What to Experiment With on zero-dot-force

Each experiment is an idea from fullsend or elsewhere that could enhance UF. Run it on snake-eyes (and future zero-dot-force repos) first. If it works, write a spec and port it.

Experiment 1: Credential Isolation (from fullsend ADR 0017)

Problem in UF today: No credential isolation. Agents run with whatever PAT the user has. A compromised agent prompt could exfiltrate tokens.

Experiment: Deploy fullsend's secretless model on snake-eyes. Observe:

Does the OIDC/WIF/mint flow work for a Python project?
What is the operational overhead of managing WIF providers?
Can UF's heroes adopt a similar model without fullsend?

Port to UF if validated: Design a credential isolation layer for UF heroes. Could be lighter than fullsend's 4-tier model -- maybe a 2-tier model (prefetch + host-side REST) is enough for UF's slash-command-triggered model.

Experiment 2: Sandbox Isolation (from fullsend ADR 0020, 0036)

Problem in UF today: No execution sandbox. Agents have full filesystem and network access. A prompt injection could curl arbitrary endpoints or read ~/.ssh/.

Experiment: Run fullsend's OpenShell sandbox on snake-eyes. Observe:

Does the sandbox work with Python tooling (ast, astroid, pytest)?
What network policies are needed for pip install during development?
What is the cold start overhead?

Port to UF if validated: Add sandbox support to uf init scaffolding. Could use OpenShell directly or a lighter alternative. The Divisor council especially benefits -- 9 parallel personas each in their own sandbox.

Experiment 3: Autonomous Event-Driven Dispatch (from fullsend ADR 0041, 0061)

Problem in UF today: All agents are slash-command triggered. Nothing happens unless a human types /review-council or /speckit.implement. Issues sit untriaged. PRs sit unreviewed.

Experiment: Let fullsend's triage and review agents run autonomously on snake-eyes events. Observe:

Does autonomous triage add value or noise on a small repo?
Does autonomous review complement or conflict with /review-council?
What is the right threshold for autonomous action vs human-triggered?

Port to UF if validated: Add event-driven dispatch to UF. Not replacing slash commands, but layering autonomous triggers underneath. For example: auto-triage on issue open, auto-review-first-pass on PR open, but still require /review-council for the deep multi-persona pass.

Experiment 4: Gaze as a Fullsend Quality Gate

Problem: Fullsend's review agent checks coverage deltas but doesn't understand CRAP scores, side-effect classification, or test quality at UF's Gaze depth.

Experiment: Create a fullsend skill that runs gaze analyze --analyzer snake-eyes during review. This creates a feedback loop: snake-eyes (the project) analyzed by Gaze (the tool) powered by snake-eyes (the analyzer).

Port to UF if validated: Gaze becomes a first-class quality gate in any CI pipeline, not just UF agent workflows.

Experiment 5: Convention Pack Sharing Between Agent Systems

Problem: UF has convention packs (dual-ownership, severity-tagged). Fullsend has skills (ad hoc markdown files). If both run on the same repo, conventions fragment.

Experiment: Create a shared conventions/ directory on snake-eyes. Wire it to both .opencode/ agents (as convention packs) and .fullsend/ agents (as skills). Test whether a single source of truth for coding standards works across both systems.

Port to UF if validated: Standardize convention pack format so it works with any agent framework, not just UF's.

Experiment 6: Fullsend's Retro Agent Enhancing Mx F

Problem: Mx F does retrospectives manually via coaching sessions. Fullsend's retro agent runs automatically after every merge and files improvement issues.

Experiment: Let both run on snake-eyes. Compare the quality and actionability of fullsend's automated retro findings vs Mx F's coaching-driven insights.

Port to UF if validated: Give Mx F an automated retro capability -- running post-merge analysis automatically, then presenting findings during the next coaching session instead of discovering them manually.

Experiment 7: Multi-Persona Review as Fullsend Skills

Problem: Fullsend's review agent is a single pass. UF's Divisor is 9 specialized personas. Can fullsend achieve Divisor-level review depth?

Experiment: Create fullsend skills that emulate Divisor personas:

.fullsend/skills/
  review-guard.md        # Intent drift, constitution alignment
  review-architect.md    # Structure, DRY/SOLID, tech debt
  review-adversary.md    # Security, error handling, edge cases
  review-sre.md          # Performance, observability, scaling
  review-testing.md      # Test quality, coverage strategy

Port to UF if validated: Either adopt fullsend's review agent with UF persona skills, or enhance The Divisor with fullsend-style autonomous triggering.

Experiment 8: Living Design Documents (from complytime/fullsend)

Problem: UF has specs in specs/ and openspec/ but no living design document approach for cross-cutting architectural exploration.

Experiment: Adopt the fullsend/complytime living design document approach on zero-dot-force: vision docs, problem docs, ADRs, plans. (complytime already adopted this from fullsend.)

Port to UF if validated: Restructure unbound-force/unbound-force docs alongside the existing spec framework.

7.3 What NOT to Experiment With

Some things should stay as they are:

UF Constitution -- The 5 principles are proven. Don't weaken them. Fullsend should conform to the constitution, not the other way around.
Speckit/OpenSpec phase discipline -- The pipeline is validated. Don't replace it with fullsend's looser issue-to-PR model for planned work.
Hero identities -- Gaze, Muti-Mind, Cobalt-Crush, The Divisor, Mx F are established. Don't rebrand them. Enhance them.
Dewey knowledge layer -- Semantic search + graph traversal is a UF differentiator. Fullsend doesn't have it. Keep investing in Dewey.

7.4 Coexistence on snake-eyes

Both systems run side by side. No filesystem conflicts (.fullsend/ alongside .opencode/, .specify/, .uf/, openspec/). No trigger conflicts:

Trigger	System	When
Issue opened	Fullsend triage	Autonomous
PR opened	Fullsend review	Autonomous (first pass)
PR merged	Fullsend retro	Autonomous
`/review-council`	UF Divisor	Human-triggered (deep pass)
`/speckit.*`	UF Cobalt-Crush	Human-triggered (planned work)
`/opsx-*`	UF Cobalt-Crush	Human-triggered (tactical fixes)
`/gaze-*`	UF Gaze	Human-triggered (quality analysis)
`/unleash`	UF pipeline	Human-triggered (full autonomous pipeline)

8. Open Questions

Which fullsend agents to enable first? Recommendation: triage,review for 2-4 weeks, then expand.
Hosted vs self-managed mint? For a labs incubator, hosted mint is simpler. Self-managed if the experiment itself is about understanding mint operations.
Cost budget? snake-eyes is small enough that costs should be minimal. Set a ceiling before enabling code/fix agents.
Python-specific skills? snake-eyes is Python -- fullsend defaults are Go-focused. Need Python skills (pytest, type hints, ast patterns).
Experiment prioritization? Which of the 8 experiments to run first? Recommendation: start with snake-eyes: taxonomy (48 types), data models, and file discovery #3 (autonomous dispatch) and feat: scaffold snake-eyes JSON-RPC server with initialize/shutdown lifecycle #7 (multi-persona review as skills) -- they deliver the most visible value.
Graduation criteria? What does an experiment need to demonstrate before porting to UF? Recommendation: at least 4 weeks of stable operation on zero-dot-force, a written evaluation, and a spec/ADR drafted for UF.
Future zero-dot-force repos? Once validated on snake-eyes, template the fullsend setup for other incubator projects.
Upstream contributions to fullsend? If experiments produce generally useful patterns (e.g., convention pack format, Gaze integration), contribute them back to fullsend-ai/fullsend.

9. Decision Requested

Immediate (Deploy Fullsend)

Approve deployment of fullsend agents on zero-dot-force/snake-eyes
Approve phased rollout (triage+review first)
Approve security controls (CODEOWNERS, branch protection, JSONL audit)
Decide hosted vs self-managed mint
Set monthly cost ceiling for Vertex AI inference

Strategic (Playground for UF Improvement)

Approve zero-dot-force as the official experimentation ground for UF enhancements
Prioritize which experiments (1-8) to run first
Define graduation criteria for porting experiments to unbound-force
Assign owners for each experiment
Decide whether to open upstream PRs to fullsend for generally useful patterns

10. References

zero-dot-force Org: https://github.com/zero-dot-force
snake-eyes Repo: https://github.com/zero-dot-force/snake-eyes
Gaze (parent project): https://github.com/unbound-force/gaze
Gaze External Analyzer Protocol: feat: external analyzer protocol (JSON-RPC over stdin/stdout) for multi-language support unbound-force/gaze#95
Fullsend Documentation: https://fullsend.sh/docs
Fullsend GitHub: https://github.com/fullsend-ai/fullsend
Fullsend Getting Started: https://fullsend.sh/docs/guides/getting-started/
Fullsend Security Threat Model: https://fullsend.sh/docs/problems/security-threat-model.html
Fullsend Infrastructure Reference: https://fullsend.sh/docs/guides/infrastructure/infrastructure-reference.html
Unbound-Force: https://github.com/unbound-force/unbound-force
UF Constitution: https://github.com/unbound-force/unbound-force/blob/main/.specify/memory/constitution.md
UF AGENTS.md: https://github.com/unbound-force/unbound-force/blob/main/AGENTS.md
ComplyTime (fullsend adoption precedent): docs: adopt fullsend living design document approach complytime/complytime#11
Fullsend ADR 0017 (Credential Isolation): https://fullsend.sh/docs/ADRs/0017-credential-isolation-for-sandboxed-agents.html
Fullsend ADR 0020 (Composable Agents): https://fullsend.sh/docs/ADRs/0020-composable-single-responsibility-agents-with-individual-sandboxes.html
Fullsend ADR 0029 (Secretless Mint): https://fullsend.sh/docs/ADRs/0029-central-token-mint-secretless-fullsend.html
Fullsend ADR 0036 (Sandbox Architecture): https://fullsend.sh/docs/ADRs/0036-agent-execution-sandbox.html

Navigation Menu

zero-dot-force

RFC: Fullsend Deployment on zero-dot-force and Improving Unbound Force #1

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 0 comments

Select a reply

Uh oh!

zero-dot-force

RFC: Fullsend Deployment on zero-dot-force and Improving Unbound Force #1

Uh oh!

Uh oh!

sonupreetam Jul 28, 2026 Maintainer

RFC: Fullsend Deployment on zero-dot-force and Improving Unbound Force

0. Context

What is zero-dot-force?

What is snake-eyes?

What is Unbound Force?

What is Fullsend?

1. Summary

2. Why Both? The Gap Analysis

3. Integration Checklist

Phase 0: Prerequisites

Phase 1: Token Mint Enrollment

Phase 2: WIF (Workload Identity Federation) Setup

Phase 3: GitHub App Installation

Phase 4: Repository Configuration

Phase 5: Security Hardening (MANDATORY)

Phase 6: Graduated Rollout

Phase 7: Customization

4. Security Impact Analysis

4.1 Threat Surface Changes

4.2 Security Invariants (Non-Negotiable)

4.3 What We Give Up

4.4 Required Security Controls

5. Cost Estimation

6. Inspiration from Unbound-Force Agent Architecture

6.1 Constitution-Governed Agents

6.2 Multi-Persona Review Council

6.3 Convention Packs

6.4 Specification-Driven Workflow

6.5 Gaze-Inspired Quality Gates

6.6 Artifact-Based Communication

6.7 Workflow Lifecycle Management

7. zero-dot-force as Playground: Experiment, Validate, Port to UF

7.1 The Flow: Playground to Production

7.2 What to Experiment With on zero-dot-force

Experiment 1: Credential Isolation (from fullsend ADR 0017)

Experiment 2: Sandbox Isolation (from fullsend ADR 0020, 0036)

Experiment 3: Autonomous Event-Driven Dispatch (from fullsend ADR 0041, 0061)

Experiment 4: Gaze as a Fullsend Quality Gate

Experiment 5: Convention Pack Sharing Between Agent Systems

Experiment 6: Fullsend's Retro Agent Enhancing Mx F

Experiment 7: Multi-Persona Review as Fullsend Skills

Experiment 8: Living Design Documents (from complytime/fullsend)

7.3 What NOT to Experiment With

7.4 Coexistence on snake-eyes

8. Open Questions

9. Decision Requested

Immediate (Deploy Fullsend)

Strategic (Playground for UF Improvement)

10. References

Replies: 0 comments

sonupreetam
Jul 28, 2026
Maintainer