Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions app-catalog/catalog.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -579,6 +579,12 @@ apps:
version: 1.22.0
name: Gitea (LXC)
description: "Self-hosted Git server in an isolated LXC container"
- id: taosr1
type: service
category: agent-bridge
version: 0.1.0
name: taOSr1
description: "Rabbit R1 push-to-talk bridge to the taOS Personal Agent (PA) via the agent-as-a-model surface. Three agent slots."
- id: code-server
type: dev-tool
version: 4.96.0
Expand Down
58 changes: 58 additions & 0 deletions app-catalog/services/taosr1/manifest.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
id: taosr1
name: taOSr1
type: service
category: agent-bridge
version: 0.1.0
backend: lxc
description: "Rabbit R1 push-to-talk bridge to the taOS Personal Agent (PA). Provisions an LXC running the taOSr1 shim, which relays R1 utterances to the taOS agent-as-a-model surface (/v1/chat/completions) and streams replies back. Three agent slots let you assign which taOS agents answer on the R1."
homepage: https://github.com/jaylfc/taOSr1
license: MIT
Comment on lines +1 to +9

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

1. Readme not updated for taosr1 📜 Skill insight § Compliance

This PR adds a new catalog manifest (app-catalog/services/taosr1/manifest.yaml) but does not
update README.md accordingly (or otherwise document-review gate it). This violates the doc-gate
requirement for catalog manifest changes and can leave user-facing docs out of sync with the shipped
catalog.
Agent Prompt
## Issue description
A new catalog manifest was added under `app-catalog/`, but the PR does not update `README.md` as required by the doc-gate rule (or otherwise indicate doc review via a `Docs-Reviewed:` commit trailer).

## Issue Context
This PR introduces a new catalog entry for `taosr1`.

## Fix Focus Areas
- app-catalog/services/taosr1/manifest.yaml[1-9]
- README.md[223-225]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


requires:
ram_mb: 256
disk_mb: 200
ports: [7901]
inputs:
- name: taos_base_url
label: "taOS controller URL"
type: url
required: true
default: "http://192.168.6.123:6969"
description: "The taOS controller the shim relays to (agent-as-a-model surface)."
Comment on lines +16 to +21

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Informational

4. Private ip default url 🐞 Bug ⚙ Maintainability

taos_base_url defaults to http://192.168.6.123:6969, which is a deployment-specific private LAN
address and is likely to be wrong outside the author’s network. This increases the chance users
install with a non-working default and end up with a broken bridge until they manually correct it.
Agent Prompt
### Issue description
The taosr1 manifest ships an environment-specific private-LAN default (`192.168.6.123`) for `taos_base_url`. Catalog defaults should be broadly valid or omitted.

### Issue Context
Other service manifests with required inputs (e.g. gitea-lxc’s `admin_password`) do not hardcode site-local network defaults.

### Fix Focus Areas
- app-catalog/services/taosr1/manifest.yaml[16-21]
- app-catalog/services/gitea-lxc/manifest.yaml[16-20]

### What to change
- Remove the `default:` value, or replace it with a documented generic placeholder (e.g. `http://<controller-host>:6969`) that forces explicit configuration.
- If there is a known stable controller address in taOS deployments, set the default to that documented value instead.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

- name: consent_key
label: "Agent-model consent key"
type: secret
required: true
description: "Consent key minted by the owner (taOS /api/agent-model-keys)."

install:
method: lxc

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CRITICAL: LXCInstaller is hardcoded for Gitea — this manifest cannot install the taOSr1 shim

The LXCInstaller (tinyagentos/installers/lxc_installer.py) is hardcoded to deploy Gitea: it downloads the Gitea binary, writes gitea.service, creates /etc/gitea/, runs gitea migrate, and creates a git admin user. It ignores this manifest's repo, service_name, ui_port (7901), and state_paths. A store install of taosr1 will produce a running Gitea container on port 3000, not the taOSr1 shim.

Additionally, the LXC install path requires admin_password in the request body (store_install.py:454), but the manifest does not declare it as an input. The store UI will not prompt for it, and installation will fail with 400 admin_password is required for LXC installs.


Reply with @kilocode-bot fix it to have Kilo Code address this issue.

image: images:debian/bookworm
memory_limit: "256MiB"
cpu_limit: 1
ports:
http: 7901
# The shim + a tiny slot-assignment UI run inside the container.
repo: https://github.com/jaylfc/taOSr1
service_name: taosr1
Comment on lines +11 to +37

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

2. Lxc install path incompatible 🐞 Bug ≡ Correctness

The new taosr1 manifest declares install.method: lxc, but the backend LXC install route requires
admin_password and calls a Gitea-specific LXCInstaller that hardcodes Gitea setup and proxies to
container port 3000, so taosr1 cannot be installed or routed correctly. The Store UI also does not
send any manifest inputs (taos_base_url/consent_key), so even a successful install would have no way
to configure the shim from the catalog inputs.
Agent Prompt
### Issue description
`app-catalog/services/taosr1/manifest.yaml` declares an LXC-backed service, but taOS’s current LXC install path (`backend == "lxc"`) requires `admin_password` and uses `LXCInstaller`, which is Gitea-specific (installs gitea, creates `git` user, proxies to `127.0.0.1:3000`). This makes `taosr1` installs fail (400 due to missing `admin_password`) or provision the wrong software/port, and it also means required manifest inputs (`taos_base_url`, `consent_key`) are never sent from the Store UI and never reach the installer.

### Issue Context
- The Store frontend currently posts `{ app_id, target_remote, variant_id? }` only; it does not collect or submit `requires.inputs` values.
- The backend `backend == "lxc"` branch enforces `admin_password` and forwards only `admin_password/taos_username/taos_email` to `LXCInstaller`.
- `LXCInstaller` is coded specifically for Gitea and proxies to container port 3000.

### Fix Focus Areas
- app-catalog/services/taosr1/manifest.yaml[11-42]
- tinyagentos/routes/store_install.py[453-506]
- tinyagentos/installers/lxc_installer.py[165-330]
- desktop/src/apps/StoreApp/index.tsx[430-435]

### What to change
- Either:
  1) Introduce a *generic* `LXCServiceInstaller` that:
     - Reads container internal port(s) from `install.ports` (e.g. `http: 7901`) instead of hardcoding 3000.
     - Uses `install.repo` (and/or a declared install command/script) to install and start the taosr1 shim inside the container.
     - Uses `install.service_name` for systemd management (start/stop) and migration.
     - Accepts and applies `requires.inputs` values (e.g. writes config under `/etc/taosr1/` in `state_paths`).
     - Installs any packages needed for health checks if health checks are used.
  2) Or create a taosr1-specific install method (e.g. `method: script` or a new `method: taosr1-lxc`) with a matching installer implementation.

- Update the Store UI + backend install request contract so users can provide `requires.inputs` at install time (or explicitly move these inputs into a post-install configuration flow, and remove `required: true` if they are not actually supplied at install).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

state_paths:
- /etc/taosr1/
- /home/taosr1/.hermes/
ui_port: 7901
ui_path: "/"

lifecycle:
health_check: "curl -sf http://localhost:7901/healthz"

slots: 3
slot_assignments:
# Populated by the user in the app UI; each slot maps to a taOS agent id.
# The shim reads these and routes R1 push-to-talk per active slot.
method: taos_agent_picker

Comment on lines +47 to +52

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

3. Slot metadata discarded 🐞 Bug ≡ Correctness

The taosr1 manifest adds top-level slots and slot_assignments, but the catalog loader
(AppManifest.from_dict) does not preserve unknown manifest keys, so these fields are dropped and
cannot be used by the API/UI. Any slot-based UX driven from manifest metadata will therefore not
work.
Agent Prompt
### Issue description
`app-catalog/services/taosr1/manifest.yaml` introduces `slots` and `slot_assignments`, but `tinyagentos.registry.AppManifest.from_dict` only copies an explicit allowlist of fields and does not include these keys. As a result, `slots` metadata is silently discarded when the catalog loads, and it cannot be surfaced to `/api/store/catalog` or any UI.

### Issue Context
The manifest is intended to describe a 3-slot agent assignment UI, but the backend’s manifest model currently cannot represent these new fields.

### Fix Focus Areas
- app-catalog/services/taosr1/manifest.yaml[47-52]
- tinyagentos/registry.py[24-81]
- tinyagentos/routes/store.py[149-167]

### What to change
- Extend `AppManifest` to include `slots: int = 0` and `slot_assignments: dict = field(default_factory=dict)` (or a single `ui`/`extensions` dict, if you prefer namespacing).
- Populate these fields in `from_dict`.
- Add the fields to the `/api/store/catalog` and `/api/store/app/{app_id}` responses (and any frontend TS types) if the Store/UI needs them for rendering.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

hardware_tiers:
arm-npu-16gb: full
arm-cpu-8gb: full
x86-cuda-12gb: full
cpu-only: full
apple-silicon: full
Loading