Life Manager

August 12, 2026 Β· View on GitHub

Life Manager manages your body, mind, and money. It is a personal manager that turns goals into completed real-world actions. It acts within delegated boundaries, verifies what happened, and reports the result in plain language with evidence in Telegram.

OrganWhat Life Manager manages
DailyCalendar, event and accelerator applications, job applications, priorities, and follow-through
Physical / MentalRoutines, wellbeing, and continuity of care
FinancialNet worth, cash flow, spending, income opportunities, and risk-managed investing

Open Life Manager Β· Start in Telegram Β· View the source

Start locally and keep your data on your machine; move to the web/cloud service when you want an always-on manager. Both surfaces use the same core, evidence ledger, and human-readable reporting contract. Life Manager never guarantees wealth or investment returns, and it never reports an attempted action as completed without a receipt.

Life Manager is the product. Anicca is the company name only when a form explicitly asks for it.

License: MIT

🌐 ζ—₯本θͺžη‰ˆ README はこけら β†’

Repository SSOT: this repository, Daisuke134/life-manager, is the only Life Manager code, spec, release, workflow, and deployment source. Daisuke134/life-manager-v0 is a read-only migration source until its required-code and runtime-reference counts reach zero. The current ordered execution plan and remaining work are maintained in docs/superpowers/specs/2026-08-01-dais-life-manager-five-phase-execution-spec.md; repository consolidation history remains in docs/superpowers/specs/2026-07-19-anicca-one-repo-consolidation-spec.md.

Quick start

Use it β€” cloud (nothing to install)

Start in Telegram, or open the web app. The always-on service runs the scheduler, the connectors, and the authenticated /panel; you talk to it in Telegram and it reports back there with receipts.

Run it yourself β€” local (your machine holds the data)

Requires Docker. The local stack is Postgres + an object store + the API, scheduler, and worker β€” the same core the cloud runs.

git clone https://github.com/Daisuke134/life-manager ~/life-manager && cd ~/life-manager
./scripts/local-up.sh

That is the whole thing. It writes deploy/local/.env if you don't have one (generating a password for the local object store instead of shipping one), brings up postgres Β· object store Β· api Β· scheduler Β· worker, and waits until every service reports healthy before printing anything β€” so "it started" means it can serve, not just that containers exist. First run builds the image and takes a few minutes.

./scripts/local-up.sh status    what is running
./scripts/local-up.sh logs      follow the logs
./scripts/local-up.sh down      stop it (your data survives)

The API listens on http://localhost:18788 and the worker exposes health on :18790 (both overridable in deploy/local/.env). Your data stays in the local Postgres and object store β€” nothing is shipped anywhere by running this.

Secrets are referenced, never inlined. Jobs carry secret://… references and resolve them from the local keychain or a tenant vault; see apps/life-manager/.env.example for the shape (TELEGRAM_BOT_TOKEN_REF, POSTIZ_ACCESS_TOKEN_REF, REVENUECAT_API_KEY_REF, …). Connect your own Telegram bot token this way to talk to a local instance.

Not what you wanted?

If you came here for the self-funded agent β€” the wallet-holding loop that earns its own compute β€” that is a different thing and it lives in docs/agent-economy.md. It shares this repository and this core, but it is not the product described above.

One product, two execution surfaces

Life Manager is one product in one repository. β€œLocal Life Manager” and the web app are not separate products or repositories; they are two execution surfaces powered by the same core, capabilities, and state contracts.

                              LIFE MANAGER
                    one product Β· one repository
                                 β”‚
             β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
             β”‚                                       β”‚
     LOCAL / SELF-HOSTED                      WEB / CLOUD
     deploy/local/compose.yaml                 apps/landing
          β”‚                                  onboarding UI
          β–Ό                                       β”‚
     apps/life-manager                             β–Ό
     api Β· scheduler Β· worker            apps/life-manager
          β”‚                              Telegram Β· voice
          β–Ό                              scheduler Β· /panel
     postgres Β· object store                       β”‚
     (your machine)                                β–Ό
             β”‚                              user-scoped services
             β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                                 β”‚
                shared economy and infrastructure
        runtime/loop Β· runtime/compute-proxy Β· services/x402-*
PathRoleWhat it is not
apps/life-manager/The product core: Telegram, scheduling, calls, authenticated /panel, billing, and user workflows. Runs both locally (compose) and in the cloud (Railway)Not the whole repository
deploy/local/The local execution surface β€” compose stack, ports, local-only credentialsNot a separate β€œlocal edition” product
apps/landing/The Life Manager onboarding web subsetNot the old multi-product Anicca website
runtime/loop/, install.sh, start-local.shThe self-funded agent loop β€” see docs/agent-economy.mdNot how you start Life Manager
runtime/compute-proxy/, services/Self-pay inference and x402 settlement/API infrastructureNot user-facing apps
skills/Shared capabilities used by local and cloud executionNot independent products
apps/job-search-loop/, control-room/, adapters/Supporting operations, fleet documentation, and integrationsNot another Life Manager codebase
docs/, specs/Current SSOT, evidence, and retained architecture historyHistorical files are not automatically current authority

Some internal package names, environment variables, service labels, and older documents still use anicca. In this repository, Anicca is the company/technical namespace; Life Manager is the product. A remaining anicca identifier does not imply a second product or another canonical repository.

Connector agent β€” how event applications work

Connector is the local Life Manager agent that searches eight Tokyo event railsβ€”Luma, Connpass, Peatix, Meetup, Doorkeeper, Eventbrite, TECH PLAY, and KokuchProβ€”removes unsafe or conflicting candidates, applies through one owned browser page, verifies the provider result, and reports an evidence-backed outcome in Telegram. It is not a blind form-filler: a click is never treated as success by itself.

flowchart LR
    TRIGGER["Daily launchd trigger<br/>or supervised launchd kickstart"] --> ENTRY["run.sh<br/>single lock + heartbeat"]
    ENTRY --> CAL["Google Calendar<br/>14-day busy inventory"]
    CAL --> RAIL["One CloakBrowser target<br/>one owned page"]

    subgraph LOOP["Forward-only provider loop"]
        PROVIDERS["Luma β†’ Connpass β†’ Peatix β†’ Meetup<br/>β†’ Doorkeeper β†’ Eventbrite β†’ TECH PLAY β†’ KokuchPro"]
        DISCOVER["Provider discovery<br/>privacy-safe count audit"]
        GATE{"Free Β· open Β· Tokyo Β· in window<br/>and Calendar-safe?"}
        NEXT["Next candidate<br/>or next provider"]
        PROVIDERS --> DISCOVER --> GATE
        GATE -->|No| NEXT --> PROVIDERS
    end

    RAIL --> PROVIDERS
    GATE -->|Yes| NAV["Navigate on the same page"]
    NAV --> PRE{"Official parent / child-frame readback<br/>already registered?"}
    PRE -->|Yes| SUPPORT
    PRE -->|No| CACHE["Verified action cache"]
    CACHE -->|registered / pending| SUPPORT
    CACHE -->|not completed| DIRECT["Provider script-first action"]
    DIRECT -->|completed| POST
    DIRECT -->|effect unknown| CIRCUIT
    DIRECT -->|safe not completed| HARNESS["Bounded Browser Harness<br/>observe β†’ propose β†’ operate"]
    HARNESS -->|completed| POST{"Official parent / child-frame readback<br/>registered or pending?"}
    HARNESS -->|safe failure / auth required| NEXT
    POST -->|No / safe failure| NEXT
    POST -->|Yes| SUPPORT

    subgraph EVIDENCE["External proof β€” agent self-report is insufficient"]
        SUPPORT{"Evidence adapter<br/>available?"}
        PROVE["Provider receipt / state"] --> GCAL["Idempotent Calendar write<br/>plus independent readback"]
        GCAL --> PNG["Privacy-safe screenshot<br/>and SHA-256"]
        PNG --> TG["Telegram message + photo<br/>positive provider IDs"]
        TG --> BUNDLE["Durable applied_bundle"]
    end

    SUPPORT -->|Yes| PROVE
    SUPPORT -->|No| EVIDPENDING["Acceptance pending<br/>no applied_bundle claim"]

    NEXT -->|All exhausted| NOEFFECT["completed_no_effect<br/>healthy external write 0"]
    HARNESS -->|effect unknown| CIRCUIT["circuit_open<br/>effect unknown Β· evidence failure Β· safety threshold"]
    EVIDPENDING --> CIRCUIT
    BUNDLE --> REPORT["Durable wake report"]
    NOEFFECT --> REPORT
    CIRCUIT --> REPORT
    REPORT --> CLEAN["Release owned target and lock<br/>leave unrelated tabs untouched"]
    CLEAN --> TERMINAL{"Terminal result"}
    TERMINAL -->|applied_bundle / completed_no_effect| HEALTHY["worker_finished<br/>process exit 0"]
    TERMINAL -->|circuit_open| FAILED["worker_failed<br/>non-zero exit"]
    ENTRY -. startup / contract error .-> FAILED

stateDiagram-v2
    [*] --> Discovered
    Discovered --> Skipped: paid / closed / out of window / conflict
    Discovered --> Absent: eligible and not registered
    Discovered --> Registered: official pre-readback
    Absent --> Registered: one verified final effect
    Absent --> EffectUnknown: mutation happened, readback not proven
    Registered --> EvidenceSupport
    EvidenceSupport --> AppliedBundle: adapter + provider + Calendar + artifact + Telegram verified
    EvidenceSupport --> AcceptancePending: adapter or live bundle unavailable
    Skipped --> ReportedNoEffect
    EffectUnknown --> CircuitOpen
    AcceptancePending --> CircuitOpen
    AppliedBundle --> Cleaned
    ReportedNoEffect --> Cleaned
    CircuitOpen --> Cleaned
    Cleaned --> [*]
ProviderProduction railAcceptance status
LumaDiscovery, action, readback, evidenceLive bundle proven
ConnpassDiscovery, action, readback, evidenceLive bundle proven
PeatixDiscovery, action, readback, evidenceLive bundle proven
MeetupDiscovery, action, readback, evidenceConnected; current strict candidates conflict with Calendar
DoorkeeperDiscovery, action, readback, evidenceConnected; all four current eligible candidates conflict with Calendar, so live bundle remains pending
EventbriteThree-page discovery, ticket/attendee/final action, child-frame readback, evidenceConnected; current production inventory has no eligible candidate, so external write is correctly zero
TECH PLAYRSS/detail discovery, input/review/final action, registered readback, evidenceConnected; all three current eligible candidates conflict with Calendar, so live bundle remains pending
KokuchProOfficial listing/detail discovery, strict free/Tokyo/open gate, entry/login readback, bounded HarnessConnected; current official first page has no event inside the 14-day window. Login is classified as auth_required and safely hands off without private-value or retry effects

Safety invariants: one schedule owner, one browser target per wake, final mutation at most once, effect_unknown means no retry, private form values never enter action history, and only an applied_bundle proves a new completed application. completed_no_effect is a healthy process result with zero new external writes. Current evidence and remaining gates live in the Connector execution SSOT.

Current canonical acceptance: PR #1936 established the production baseline at 4f1960592, and follow-up PR #1947 merged the final documentation plus provider-specific fallback budget fix at f1a13b2e7. The post-baseline production wake traversed all seven configured providers and KokuchPro on one owned page, reused existing bundles without a duplicate external effect, delivered a positive Telegram receipt, restored the exact unrelated browser pages, released the lock, and exited zero. Generic providers now fail closed above the Browser Harness 10-step limit while TECH PLAY retains its reviewed 15-step flow. The only remaining event-rail work is conditional: Meetup, Doorkeeper, Eventbrite, and TECH PLAY need a future Calendar-safe live candidate before their first real applied_bundle can be proven.

What's real today (honest)

CapabilityStatus
Local stack (deploy/local/compose.yaml) β€” postgres Β· object store Β· api Β· scheduler Β· workerRuns β€” the five services come up healthy and stay up (observed running for days on the maintainer's machine).
Cloud service (apps/life-manager, node server.js on Railway)Deployed β€” the scheduler and API are the same code the local stack runs.
Telegram reporting with receiptsLive β€” every report carries a message id, and a send that fails is not recorded as sent.
Calendar, connectors, coverage (lib/calendar-*, lib/connector-*)Implemented, coverage still moving β€” per-connector state and gaps are tracked in the execution spec rather than claimed here.
Financial organ (net worth, cash flow, payouts, ledgers)Partial β€” the ledger and payout jobs exist; their current health is tracked in the execution spec. Nothing here is an investment guarantee.
The self-funded agent economySeparate track β€” status and on-chain evidence in docs/agent-economy.md.

North Star (immutable)

Reduce suffering.
No killing (Pāṇātipātā veramaαΉ‡Δ«).

These two lines are SHA-256 hash-pinned and cannot be changed by any skill, self-edit loop, or PR.