Help me set up my own PocketContext Crew: a self-hosted workspace for one person coordinating several AI agents. Prefer the native binary on a suitable Linux server; keep Docker Compose as an alternative when I prefer it or want its packaged email-login and S3-backup setup. Crew stores shared memory, tasks and exact-draft human reviews. My agent tools supply models and execution. I perform external actions myself.

SETUP REVISION AND PINNED SOURCES
This is Crew setup prompt 2026-11-06 revision 3.
Native installation: PocketContext Crew v0.1.1, repository https://github.com/pocketcontext-labs/pocketcontext-crew, installation-guide commit 91798c1536cac18700af729f842c555b5d0c47c1. Read README.md, docs/native-install.md and deploy/native/ at that exact commit. Download only install.sh, checksums.txt and the matching pocketcontext-crew_0.1.1_linux_amd64.tar.gz or pocketcontext-crew_0.1.1_linux_arm64.tar.gz from that repository's v0.1.1 release. The installed file is pocketcontext-crew; its inherited version output begins with pocketcontext and must report 0.1.1 plus source revision 91798c1536cac18700af729f842c555b5d0c47c1. Verify checksums and the installed version before initialization. Never use upstream PocketContext installers, a mutable latest link or a source build as a silent substitute.
Docker alternative: use docs/install.md and deploy/compose/ at commit 91798c1536cac18700af729f842c555b5d0c47c1, with image ghcr.io/pocketcontext-labs/pocketcontext-crew@sha256:bf4097b3e5b3ed54af6c840228bc84462553803605135f5bbe011a875c730089. Set the Crew service image in the copied Compose configuration to this exact verified digest, replacing the template's older Crew image. Preserve the guide's separate proxy image pin.
Use fresh source checkouts and verify their exact commits; preserve existing checkouts. If a pinned artifact or guide cannot be retrieved or verified, report the failure and stop dependent work rather than inventing an installation.

CHOOSE THE PATH AFTER CHECKING THE HOST
Identify where your commands run and which machine will host Crew. Start with read-only inspection. Ask only for missing information: an existing Linux AMD64/ARM64 server I can administer, a fresh absolute project directory, a stable unprivileged service account, a domain and DNS access, and a private backup destination separate from the project. For the native path, require systemd 243+, Python 3.11+ for the backup helper and the guide's other prerequisites. For Docker, check Docker Engine and Compose 2.30+, then obtain the sole owner email, verified SMTP sender and private S3-compatible backup bucket. In both cases inspect existing installations, free disk, port 80/443 conflicts, firewall and DNS. Preserve existing services and data.
Recommend the binary on a suitable Linux server unless I have already chosen Docker. Explain the difference: native Crew serves HTTPS itself, uses password/reader-link owner access and needs a separately configured backup schedule; Docker uses Caddy, email login and its supervisor's S3 backups. Do not collect SMTP/S3 credentials for native installation unless I explicitly choose those external services for another purpose. Do not silently switch between paths or reuse a database from the other path. If I need paid resources, explain the provider, expected cost and exact resources before asking for authorization to create them.
This prompt's default is an always-on hosted workspace with remote MCP. A laptop-only or local-only installation does not provide remote MCP automatically. If my host cannot support a reachable HTTPS domain, explain the unmet requirement and keep remote connection pending; do not claim a tunnel or localhost is equivalent.

INSTALL THE NATIVE BINARY (DEFAULT)
Follow the pinned native guide and release installer for the detected Linux architecture. Use a fresh project folder and a distinct pocketcontext-crew executable. Refuse to overwrite an existing executable or initialize over an existing database. Verify the Crew release version and source revision, then initialize a new single-owner project. Generate or collect the password privately and pass it through the supported stdin path; never print or retain it in chat, shell arguments or logs.
Configure one unprivileged systemd service using the guide's stable private runtime paths. Enable native HTTPS and MCP with the required domain and explicit database path. Grant only the guide's required ability to bind ports 80/443. Do not add Docker, Caddy, SMTP or an identity provider to this path. Stop any initialization server cleanly before starting the service; maintain one writer and preserve its data and runtime paths. Install and enable the documented daily backup timer and helper, using a separate private destination. Install the backup and service-control helpers root-owned as documented, without granting the application user general sudo access. Backups stop a previously active service cleanly, verify the database and copied files, retain the matching executable and restart the service even after a copy failure. An already-stopped service is skipped. Monitor backup and restart failures; neither is a successful backup. Verify a triggered backup and restoration before declaring setup complete. The initial helper retains all snapshots: document this and monitor disk capacity; do not invent automatic pruning. A snapshot on the same server alone is not protection against losing that server; agree on a separate-device or off-host copy before claiming that protection.
For owner access, use the password privately or generate a fresh short-lived reader sign-in link with the supported open --public command. Show that access-granting link only in this setup conversation and ask me to confirm browser access. Keep passwords and reusable owner tokens out of chat and never give them to connected agents. Do not launch a remote host's local browser or present its localhost address as a user-reachable URL.

INSTALL WITH DOCKER (WHEN CHOSEN)
Follow the pinned Docker guide instead of mixing it with native instructions. Use a dedicated installation directory, unique stable Compose project and new volume, private environment files, the sole owner email, verified SMTP sender and dedicated private S3 bucket with scoped credentials. Keep the Crew backend private behind Caddy. Initialize explicitly, wait for health, stop the initializing writer cleanly and start normal serve on the same volume and exact image. Never leave init as the restart command. Verify real inbox delivery and owner sign-in; SMTP authentication alone is insufficient.

PROTECT AND VERIFY BOTH PATHS
Keep credentials in private local configuration or an authorized secret manager, with restrictive file permissions and outside Git. Never print environment values, complete rendered Compose configuration, passwords, SMTP keys, backup credentials, email codes or OAuth tokens. Record only safe operating metadata. If interrupted, inspect the recorded stage and existing state, preserve the project/volume and follow the selected guide's recovery steps. Never delete data or rerun initialization to hide a failure.
Verify normal restart and persistence; the HTTPS sign-in page from outside the host with normal certificate verification; the appropriate /api/bundle/auth-mode response; and anonymous denial on POST /api/crew/read and /mcp. Check /up for Docker only; native HTTPS does not expose that hosted health route. Ask me to confirm owner browser sign-in. Connect my selected agent client to https://MY_DOMAIN/mcp using its current official remote Streamable HTTP/OAuth instructions. Let me approve consent in my signed-in browser. Verify the client discovers crew_read and crew_write and can create/read a clearly labeled synthetic bucket, note and task, revise the note once and read its history. Never substitute an owner token for MCP OAuth. An endpoint health check does not establish a working client connection.
Follow the selected guide's backup and isolated restoration procedure. Verify the snapshot/archive and restored synthetic note/history, using a fresh destination and the matching binary or image. Keep the production writer separate and do not publish the restored copy or let it send mail or alter production backup retention. Do not restore over live data. Before native restoration or upgrades, stop the backup timer, wait for an active backup job to finish and stop Crew cleanly. Native snapshots exclude machine-local OAuth grants, keys, profiles, certificates and private working caches. Recovery uses a fresh runtime account/home and requires new certificates and OAuth consent; owner credentials remain in the database, so do not claim all browser sessions are revoked. Do not restore machine-private state by guessing cache paths. Follow the Docker guide's separate credential-reset behavior for that path. Keep synthetic records for the checks and offer to archive them afterward.

HANDOFF
Return my workspace URL and MCP endpoint, selected installation method, exact release/source or image pin, safe project/service/backup locations, backup schedule and retention, and stop/start, restore and deliberate upgrade instructions. Explain the brief backup outage and any unverified off-host copy or recovery limitations. Do not enable automatic version upgrades. Report actual results and pending public TLS, owner-login, client-consent or restore checks separately. Offer starter agents/buckets after I can sign in. Explain that bucket responsibility is behavioral, human review decisions belong to my owner login, and approval does not publish, send, pay or complete the task. Use synthetic data only during installation.