Files
multi-agent-mux/deploy
GodopuandClaude Fable 5.1 e629cc137f fix(issue-12,8,7): keep broker password out of records, keep fresh install stamps, pack sibling workspaces
Issue #12 - MQTT_PASSWORD was copied into every job record, which any
sub-agent can read. BrokerConfig.to_registry_block no longer persists it;
broker_config_from_job layers the password back from the environment
(.mam.env) at connect time, so publish_event still connects from the record.
_atomic_write_record scrubs broker.password from any record it writes, and
`registry.py scrub-secrets [--dry-run]` migrates an existing registry.
auth_token/dispatch_token stay: the agent's own publish_event needs them.

Issue #8 - update.sh restored the pre-update asset_hashes.txt and version.txt
over the installer's fresh ones, so version.txt named the previous commit and
remove.sh backed up every pristine updated file as "locally modified". The
success path now keeps the installer's stamps and only merges install_state
keys the re-install did not write (gitignore_created); the failure path
still restores everything verbatim.

Issue #7 - the shim's new-session took the first same-cwd pane, always found
the full first workspace, judged it overflow and opened another workspace per
agent (4 + 1 + 1). It now walks every same-cwd workspace in pane order and
takes the first with an idle pane or room in its 2xK grid; a workspace is
created only when all are full (4 + 2).

Tests: test_issue7_workspace_packing.py (3; the mock herdr gains an opt-in
per-workspace 2x2 geometry), test_issue8_update_state.py (1, real
install+update cycle), test_issue12_registry_secrets.py (4); registry CLI
snapshot and help capture refreshed for the intentional scrub-secrets
subcommand; registry.md documents the broker block.

Refs #12 #8 #7

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VCgu9Fa9iT7TbJUSzdq4Ff
2026-09-13 11:23:19 +09:00
..

🚀 Multi-Agent Mux (MAM) Deployment & Gitea Integration

This directory contains packaging templates and installation scripts to deploy the Multi-Agent Mux framework into workspaces hosted on Gitea (or GitHub).


📁 Deployment Directory Structure

  • install.sh: A self-contained, idempotent remote shell installer (via curl) that checks system requirements (herdr, python3), sets up a local python virtual environment (.venv), and performs 3-way refresh with key-level registry merge (Rev.2).
  • install_mam.sh: A local-clone installer that copies rules/skills (.agents/), AGENTS.md, manifests, and asset hashes into target projects.
  • lib_ownership.sh: Single source of truth for framework-owned files and key-level registry files.
  • update.sh: In-place updater script installed into target .mam_deploy/update.sh.
  • remove.sh: Clean uninstaller script installed into target .mam_deploy/remove.sh.
  • generate-env.sh: Environment configuration bootstrap helper.
  • INSTALL.md: Detailed installation and quick-start user manual.
  • plugin.json: Metadata declaration file to register MAM as an installable plugin for AI Agent coding platforms.
  • gitea-ci.yml: CI/CD pipeline definition template for Gitea Actions (running ShellCheck linting, Python syntax checks, and pytest suite).

📦 How to Install and Deploy

1. Simple One-Liner Installation (from Gitea repository)

Once you push this repository to your Gitea instance, users can install it in their local workspace directory by running:

curl -fsSL https://git.godopu.com/tmpl/multi-agent-mux/raw/branch/main/deploy/install.sh | bash

Alternatively, if they have cloned the repository, they can execute:

bash deploy/install.sh

2. Local-Clone Installation

If you already have cloned this repository locally, you can port MAM to other local target projects:

bash deploy/install_mam.sh --target /path/to/your/project

Refer to INSTALL.md inside this directory for the full instructions and workflows.

Note

install_mam.sh automatically deploys .mam_deploy/update.sh and .mam_deploy/remove.sh into target workspaces, recording install manifests and asset hashes to enable clean updates and uninstalls.

3. Custom Fork / Private Mirror Installations

If you run a private mirror or fork, you can override the source URLs during installation using environment variables:

# Installing from a custom mirror (pipe prepends must be applied to the bash command)
curl -fsSL https://my-mirror.example.com/.../install.sh \
  | MAM_REPO_URL=https://my-mirror.example.com/me/multi-agent-mux.git \
    MAM_ARCHIVE_URL=https://my-mirror.example.com/me/multi-agent-mux/archive/main.tar.gz \
    bash

# Updating an existing workspace against a mirror
MAM_INSTALLER_URL=https://my-mirror.example.com/.../install.sh bash deploy/update.sh

4. Registering as a Workspace Plugin

To register these skills globally or for a specific workspace:

  • Workspace Level: Copy the .agents/ folder into your project root.
  • Global Level (Gemini/Antigravity): Register the plugin path in your global config file at ~/.gemini/config/skills.json:
    {
      "entries": [
        { "path": "/absolute/path/to/multi-agent-mux/.agents/skills" }
      ]
    }
    

5. Private NATS Broker & Submodule Integration (nats-docker)

For production deployments and private networks, MAM utilizes a dedicated NATS broker (nats:2.12-alpine with MQTT 3.1.1 and JetStream enabled). The container assets and deployment guides are managed in the nats-docker submodule:

# When cloning the repository with internal credentials:
git clone --recurse-submodules https://git.godopu.com/tmpl/multi-agent-mux.git

# Or initialize submodules in an existing clone:
git submodule update --init --recursive

Note

nats-docker is an optional submodule hosted in the private repository laa/nats-docker. If cloning without internal credentials, omit --recurse-submodules. The MAM framework functions out-of-the-box using standard MQTT brokers configured in .mam.env.

Refer to nats-docker/PRIVATE_SERVER.md and MESSAGING.md for detailed configuration, .mam.env generation, and security guidelines.


🤖 Gitea Actions CI/CD Setup

To automate testing and script linting on your Gitea repository:

  1. Ensure Gitea Actions is enabled on your Gitea instance.
  2. Copy the Gitea CI workflow to your workspace's workflow folder:
    mkdir -p .gitea/workflows
    cp deploy/gitea-ci.yml .gitea/workflows/ci.yml
    
  3. Commit and push to your Gitea repository. The pipeline will validate shell syntax and python file compilation on every push to main and pull requests.