From dc7969e579ad19f58f0f3abf81b6222aa871105f Mon Sep 17 00:00:00 2001 From: Harivansh Rathi Date: Wed, 1 Apr 2026 02:28:45 +0000 Subject: [PATCH] rename2 --- README.md | 4 +-- .../appinfo/info.xml | 16 +++++----- .../composer.json | 4 +-- .../css/betternascontrolplane.css} | 0 .../img/app-dark.svg | 0 .../img/app.svg | 0 .../lib/AppInfo/Application.php | 2 +- .../lib/Controller/ApiController.php | 6 ++-- .../lib/Controller/PageController.php | 10 +++---- .../lib/Service/ControlPlaneClient.php | 4 +-- .../lib/Service/ControlPlaneConfig.php | 6 ++-- .../lib/Settings/Admin.php | 8 ++--- .../lib/Settings/AdminSection.php | 6 ++-- .../templates/admin.php | 6 ++-- .../templates/index.php | 8 ++--- birdseye.txt | 16 +++++----- docker/compose.dev.yml | 4 +-- docs/current-architecture.md | 16 +++++----- docs/platform-foundation.md | 30 +++++++++---------- exapps/control-plane/src/config.ts | 2 +- exapps/control-plane/src/index.ts | 2 +- nextcloud.txt | 2 +- .../define-platform-foundation/design.md | 30 +++++++++---------- .../define-platform-foundation/proposal.md | 18 +++++------ .../specs/control-plane-core/spec.md | 12 ++++---- .../specs/device-access-layer/spec.md | 6 ++-- .../specs/nextcloud-substrate/spec.md | 18 +++++------ .../standalone-control-plane-web/spec.md | 14 ++++----- .../define-platform-foundation/tasks.md | 4 +-- .../design.md | 26 ++++++++-------- .../proposal.md | 14 ++++----- .../specs/control-plane-service/spec.md | 12 ++++---- .../specs/nextcloud-shell-app/spec.md | 22 +++++++------- .../specs/workspace-scaffold/spec.md | 10 +++---- .../scaffold-nextcloud-control-plane/tasks.md | 10 +++---- phase1.txt | 4 +-- scripts/dev-up | 2 +- 37 files changed, 177 insertions(+), 177 deletions(-) rename apps/{ainas-controlplane => betternas-controlplane}/appinfo/info.xml (53%) rename apps/{ainas-controlplane => betternas-controlplane}/composer.json (70%) rename apps/{ainas-controlplane/css/ainascontrolplane.css => betternas-controlplane/css/betternascontrolplane.css} (100%) rename apps/{ainas-controlplane => betternas-controlplane}/img/app-dark.svg (100%) rename apps/{ainas-controlplane => betternas-controlplane}/img/app.svg (100%) rename apps/{ainas-controlplane => betternas-controlplane}/lib/AppInfo/Application.php (91%) rename apps/{ainas-controlplane => betternas-controlplane}/lib/Controller/ApiController.php (80%) rename apps/{ainas-controlplane => betternas-controlplane}/lib/Controller/PageController.php (79%) rename apps/{ainas-controlplane => betternas-controlplane}/lib/Service/ControlPlaneClient.php (93%) rename apps/{ainas-controlplane => betternas-controlplane}/lib/Service/ControlPlaneConfig.php (76%) rename apps/{ainas-controlplane => betternas-controlplane}/lib/Settings/Admin.php (76%) rename apps/{ainas-controlplane => betternas-controlplane}/lib/Settings/AdminSection.php (80%) rename apps/{ainas-controlplane => betternas-controlplane}/templates/admin.php (83%) rename apps/{ainas-controlplane => betternas-controlplane}/templates/index.php (77%) diff --git a/README.md b/README.md index d452c2c..f41d497 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -# aiNAS +# betternas image @@ -8,4 +8,4 @@ The intended boundary is documented in `docs/architecture.md`. The short version - Nextcloud remains an upstream storage and client-compatibility backend. - The custom Nextcloud app is a shell and adapter layer. -- aiNAS business logic lives in the control-plane service. +- betternas business logic lives in the control-plane service. diff --git a/apps/ainas-controlplane/appinfo/info.xml b/apps/betternas-controlplane/appinfo/info.xml similarity index 53% rename from apps/ainas-controlplane/appinfo/info.xml rename to apps/betternas-controlplane/appinfo/info.xml index acad986..8a8a78c 100644 --- a/apps/ainas-controlplane/appinfo/info.xml +++ b/apps/betternas-controlplane/appinfo/info.xml @@ -2,13 +2,13 @@ betternascontrolplane - aiNAS Control Plane - Thin aiNAS shell app for Nextcloud integration - Provides aiNAS-branded entry points inside Nextcloud while delegating business logic to the aiNAS control plane. + betternas Control Plane + Thin betternas shell app for Nextcloud integration + Provides betternas-branded entry points inside Nextcloud while delegating business logic to the betternas control plane. 0.1.0 AGPL-3.0-or-later - aiNAS - AinasControlplane + betternas + betternasControlplane integration @@ -16,15 +16,15 @@ betternascontrolplane - aiNAS + betternas betternascontrolplane.page.index app.svg link - OCA\AinasControlplane\Settings\Admin - OCA\AinasControlplane\Settings\AdminSection + OCA\betternasControlplane\Settings\Admin + OCA\betternasControlplane\Settings\AdminSection diff --git a/apps/ainas-controlplane/composer.json b/apps/betternas-controlplane/composer.json similarity index 70% rename from apps/ainas-controlplane/composer.json rename to apps/betternas-controlplane/composer.json index 2bdea52..5217552 100644 --- a/apps/ainas-controlplane/composer.json +++ b/apps/betternas-controlplane/composer.json @@ -1,10 +1,10 @@ { "name": "betternas/betternascontrolplane", - "description": "aiNAS Nextcloud shell app", + "description": "betternas Nextcloud shell app", "license": "AGPL-3.0-or-later", "autoload": { "psr-4": { - "OCA\\AinasControlplane\\": "lib/" + "OCA\\betternasControlplane\\": "lib/" } }, "require": { diff --git a/apps/ainas-controlplane/css/ainascontrolplane.css b/apps/betternas-controlplane/css/betternascontrolplane.css similarity index 100% rename from apps/ainas-controlplane/css/ainascontrolplane.css rename to apps/betternas-controlplane/css/betternascontrolplane.css diff --git a/apps/ainas-controlplane/img/app-dark.svg b/apps/betternas-controlplane/img/app-dark.svg similarity index 100% rename from apps/ainas-controlplane/img/app-dark.svg rename to apps/betternas-controlplane/img/app-dark.svg diff --git a/apps/ainas-controlplane/img/app.svg b/apps/betternas-controlplane/img/app.svg similarity index 100% rename from apps/ainas-controlplane/img/app.svg rename to apps/betternas-controlplane/img/app.svg diff --git a/apps/ainas-controlplane/lib/AppInfo/Application.php b/apps/betternas-controlplane/lib/AppInfo/Application.php similarity index 91% rename from apps/ainas-controlplane/lib/AppInfo/Application.php rename to apps/betternas-controlplane/lib/AppInfo/Application.php index 6c2d2c8..dfe13ef 100644 --- a/apps/ainas-controlplane/lib/AppInfo/Application.php +++ b/apps/betternas-controlplane/lib/AppInfo/Application.php @@ -2,7 +2,7 @@ declare(strict_types=1); -namespace OCA\AinasControlplane\AppInfo; +namespace OCA\betternasControlplane\AppInfo; use OCP\AppFramework\App; use OCP\AppFramework\Bootstrap\IBootContext; diff --git a/apps/ainas-controlplane/lib/Controller/ApiController.php b/apps/betternas-controlplane/lib/Controller/ApiController.php similarity index 80% rename from apps/ainas-controlplane/lib/Controller/ApiController.php rename to apps/betternas-controlplane/lib/Controller/ApiController.php index 78e52d9..382cd2a 100644 --- a/apps/ainas-controlplane/lib/Controller/ApiController.php +++ b/apps/betternas-controlplane/lib/Controller/ApiController.php @@ -2,10 +2,10 @@ declare(strict_types=1); -namespace OCA\AinasControlplane\Controller; +namespace OCA\betternasControlplane\Controller; -use OCA\AinasControlplane\AppInfo\Application; -use OCA\AinasControlplane\Service\ControlPlaneClient; +use OCA\betternasControlplane\AppInfo\Application; +use OCA\betternasControlplane\Service\ControlPlaneClient; use OCP\AppFramework\Http\Attribute\ApiRoute; use OCP\AppFramework\Http\Attribute\NoAdminRequired; use OCP\AppFramework\Http\DataResponse; diff --git a/apps/ainas-controlplane/lib/Controller/PageController.php b/apps/betternas-controlplane/lib/Controller/PageController.php similarity index 79% rename from apps/ainas-controlplane/lib/Controller/PageController.php rename to apps/betternas-controlplane/lib/Controller/PageController.php index f8c3d92..d45920e 100644 --- a/apps/ainas-controlplane/lib/Controller/PageController.php +++ b/apps/betternas-controlplane/lib/Controller/PageController.php @@ -2,11 +2,11 @@ declare(strict_types=1); -namespace OCA\AinasControlplane\Controller; +namespace OCA\betternasControlplane\Controller; -use OCA\AinasControlplane\AppInfo\Application; -use OCA\AinasControlplane\Service\ControlPlaneClient; -use OCA\AinasControlplane\Service\ControlPlaneConfig; +use OCA\betternasControlplane\AppInfo\Application; +use OCA\betternasControlplane\Service\ControlPlaneClient; +use OCA\betternasControlplane\Service\ControlPlaneConfig; use OCP\AppFramework\Controller; use OCP\AppFramework\Http\Attribute\FrontpageRoute; use OCP\AppFramework\Http\Attribute\NoAdminRequired; @@ -33,7 +33,7 @@ class PageController extends Controller { Application::APP_ID, 'index', [ - 'appName' => 'aiNAS Control Plane', + 'appName' => 'betternas Control Plane', 'controlPlaneUrl' => $this->controlPlaneConfig->getBaseUrl(), 'snapshot' => $this->controlPlaneClient->fetchSnapshot(), ], diff --git a/apps/ainas-controlplane/lib/Service/ControlPlaneClient.php b/apps/betternas-controlplane/lib/Service/ControlPlaneClient.php similarity index 93% rename from apps/ainas-controlplane/lib/Service/ControlPlaneClient.php rename to apps/betternas-controlplane/lib/Service/ControlPlaneClient.php index da6e916..bade3f3 100644 --- a/apps/ainas-controlplane/lib/Service/ControlPlaneClient.php +++ b/apps/betternas-controlplane/lib/Service/ControlPlaneClient.php @@ -2,7 +2,7 @@ declare(strict_types=1); -namespace OCA\AinasControlplane\Service; +namespace OCA\betternasControlplane\Service; use OCP\Http\Client\IClientService; use OCP\Http\Client\IResponse; @@ -33,7 +33,7 @@ class ControlPlaneClient { 'version' => $versionResponse['body'], ]; } catch (\Throwable $exception) { - $this->logger->warning('Failed to reach aiNAS control plane', [ + $this->logger->warning('Failed to reach betternas control plane', [ 'exception' => $exception, 'url' => $baseUrl, ]); diff --git a/apps/ainas-controlplane/lib/Service/ControlPlaneConfig.php b/apps/betternas-controlplane/lib/Service/ControlPlaneConfig.php similarity index 76% rename from apps/ainas-controlplane/lib/Service/ControlPlaneConfig.php rename to apps/betternas-controlplane/lib/Service/ControlPlaneConfig.php index 0b443d0..baa7643 100644 --- a/apps/ainas-controlplane/lib/Service/ControlPlaneConfig.php +++ b/apps/betternas-controlplane/lib/Service/ControlPlaneConfig.php @@ -2,9 +2,9 @@ declare(strict_types=1); -namespace OCA\AinasControlplane\Service; +namespace OCA\betternasControlplane\Service; -use OCA\AinasControlplane\AppInfo\Application; +use OCA\betternasControlplane\AppInfo\Application; use OCP\IAppConfig; class ControlPlaneConfig { @@ -14,7 +14,7 @@ class ControlPlaneConfig { } public function getBaseUrl(): string { - $environmentUrl = getenv('AINAS_CONTROL_PLANE_URL'); + $environmentUrl = getenv('betternas_CONTROL_PLANE_URL'); if (is_string($environmentUrl) && $environmentUrl !== '') { return rtrim($environmentUrl, '/'); } diff --git a/apps/ainas-controlplane/lib/Settings/Admin.php b/apps/betternas-controlplane/lib/Settings/Admin.php similarity index 76% rename from apps/ainas-controlplane/lib/Settings/Admin.php rename to apps/betternas-controlplane/lib/Settings/Admin.php index 927bfb4..1c59159 100644 --- a/apps/ainas-controlplane/lib/Settings/Admin.php +++ b/apps/betternas-controlplane/lib/Settings/Admin.php @@ -2,11 +2,11 @@ declare(strict_types=1); -namespace OCA\AinasControlplane\Settings; +namespace OCA\betternasControlplane\Settings; -use OCA\AinasControlplane\AppInfo\Application; -use OCA\AinasControlplane\Service\ControlPlaneClient; -use OCA\AinasControlplane\Service\ControlPlaneConfig; +use OCA\betternasControlplane\AppInfo\Application; +use OCA\betternasControlplane\Service\ControlPlaneClient; +use OCA\betternasControlplane\Service\ControlPlaneConfig; use OCP\AppFramework\Http\TemplateResponse; use OCP\Settings\ISettings; diff --git a/apps/ainas-controlplane/lib/Settings/AdminSection.php b/apps/betternas-controlplane/lib/Settings/AdminSection.php similarity index 80% rename from apps/ainas-controlplane/lib/Settings/AdminSection.php rename to apps/betternas-controlplane/lib/Settings/AdminSection.php index caab8b9..b46f5d1 100644 --- a/apps/ainas-controlplane/lib/Settings/AdminSection.php +++ b/apps/betternas-controlplane/lib/Settings/AdminSection.php @@ -2,9 +2,9 @@ declare(strict_types=1); -namespace OCA\AinasControlplane\Settings; +namespace OCA\betternasControlplane\Settings; -use OCA\AinasControlplane\AppInfo\Application; +use OCA\betternasControlplane\AppInfo\Application; use OCP\IL10N; use OCP\IURLGenerator; use OCP\Settings\IIconSection; @@ -21,7 +21,7 @@ class AdminSection implements IIconSection { } public function getName(): string { - return $this->l->t('aiNAS'); + return $this->l->t('betternas'); } public function getPriority(): int { diff --git a/apps/ainas-controlplane/templates/admin.php b/apps/betternas-controlplane/templates/admin.php similarity index 83% rename from apps/ainas-controlplane/templates/admin.php rename to apps/betternas-controlplane/templates/admin.php index e3ae9cb..493a681 100644 --- a/apps/ainas-controlplane/templates/admin.php +++ b/apps/betternas-controlplane/templates/admin.php @@ -2,7 +2,7 @@ declare(strict_types=1); -use OCA\AinasControlplane\AppInfo\Application; +use OCA\betternasControlplane\AppInfo\Application; use OCP\Util; Util::addStyle(Application::APP_ID, 'betternascontrolplane'); @@ -15,9 +15,9 @@ $version = $snapshot['version']['version'] ?? 'unreachable';

Admin settings

-

aiNAS control-plane wiring

+

betternas control-plane wiring

- The local scaffold wires this app to the control plane through the AINAS_CONTROL_PLANE_URL environment variable in the Nextcloud container. + The local scaffold wires this app to the control plane through the betternas_CONTROL_PLANE_URL environment variable in the Nextcloud container.

diff --git a/apps/ainas-controlplane/templates/index.php b/apps/betternas-controlplane/templates/index.php similarity index 77% rename from apps/ainas-controlplane/templates/index.php rename to apps/betternas-controlplane/templates/index.php index 287a10d..7b5527b 100644 --- a/apps/ainas-controlplane/templates/index.php +++ b/apps/betternas-controlplane/templates/index.php @@ -2,7 +2,7 @@ declare(strict_types=1); -use OCA\AinasControlplane\AppInfo\Application; +use OCA\betternasControlplane\AppInfo\Application; use OCP\Util; Util::addStyle(Application::APP_ID, 'betternascontrolplane'); @@ -15,10 +15,10 @@ $error = $snapshot['error'] ?? null;
-

aiNAS inside Nextcloud

+

betternas inside Nextcloud

- This shell app stays intentionally thin. It exposes aiNAS entry points inside Nextcloud and delegates business logic to the external control-plane service. + This shell app stays intentionally thin. It exposes betternas entry points inside Nextcloud and delegates business logic to the external control-plane service.

@@ -42,7 +42,7 @@ $error = $snapshot['error'] ?? null;

Boundary

  • Nextcloud provides file and client primitives.
    • -
  • aiNAS owns control-plane policy and orchestration.
    • +
  • betternas owns control-plane policy and orchestration.
  • The shell app only adapts between the two.
diff --git a/birdseye.txt b/birdseye.txt index 93d6503..3899d41 100644 --- a/birdseye.txt +++ b/birdseye.txt @@ -1,12 +1,12 @@ -# aiNAS decision scaffold +# betternas decision scaffold STEAL NOW OWN NOW ------------------- ------------------- - Nextcloud server aiNAS control plane - Nextcloud desktop aiNAS product API - Nextcloud iOS aiNAS policy model - Nextcloud external storage aiNAS device model - Nextcloud sharing UI aiNAS mount model + Nextcloud server betternas control plane + Nextcloud desktop betternas product API + Nextcloud iOS betternas policy model + Nextcloud external storage betternas device model + Nextcloud sharing UI betternas mount model LATER ----------------------- @@ -20,10 +20,10 @@ +--> Nextcloud web shell/app --------\ | - login/session | | - file/share UI | - | - thin aiNAS entry page | + | - thin betternas entry page | | - OCS route | | v - +--> Nextcloud desktop/iOS ----> aiNAS control plane ----> storage backends + +--> Nextcloud desktop/iOS ----> betternas control plane ----> storage backends - Finder presence - devices - NAS / SMB / S3 - sync / virtual files - policies - NFS / WebDAV - mobile app - shares/mounts - local/ZFS/etc diff --git a/docker/compose.dev.yml b/docker/compose.dev.yml index fd21281..11a7303 100644 --- a/docker/compose.dev.yml +++ b/docker/compose.dev.yml @@ -30,7 +30,7 @@ services: dockerfile: exapps/control-plane/Dockerfile environment: PORT: 3000 - AINAS_VERSION: local-dev + betternas_VERSION: local-dev NEXTCLOUD_BASE_URL: http://nextcloud ports: - "3001:3000" @@ -61,7 +61,7 @@ services: REDIS_HOST: redis NEXTCLOUD_ADMIN_USER: admin NEXTCLOUD_ADMIN_PASSWORD: admin - AINAS_CONTROL_PLANE_URL: http://control-plane:3000 + betternas_CONTROL_PLANE_URL: http://control-plane:3000 ports: - "8080:80" volumes: diff --git a/docs/current-architecture.md b/docs/current-architecture.md index 0e9879f..f9a212e 100644 --- a/docs/current-architecture.md +++ b/docs/current-architecture.md @@ -1,18 +1,18 @@ -# aiNAS Architecture Boundary +# betternas Architecture Boundary ## Core Decision -aiNAS treats Nextcloud as an upstream backend, not as the place where aiNAS product logic should accumulate. +betternas treats Nextcloud as an upstream backend, not as the place where betternas product logic should accumulate. That leads to three explicit boundaries: 1. `apps/betternas-controlplane/` is a thin shell inside Nextcloud. -2. `exapps/control-plane/` owns aiNAS business logic and internal APIs. +2. `exapps/control-plane/` owns betternas business logic and internal APIs. 3. `packages/contracts/` defines the interface between the shell app and the control plane. ## Why This Boundary Exists -Forking `nextcloud/server` would force aiNAS to own upstream patching and compatibility work too early. Pushing aiNAS logic into a traditional Nextcloud app would make the product harder to evolve outside the PHP monolith. The scaffold in this repository is designed to avoid both traps. +Forking `nextcloud/server` would force betternas to own upstream patching and compatibility work too early. Pushing betternas logic into a traditional Nextcloud app would make the product harder to evolve outside the PHP monolith. The scaffold in this repository is designed to avoid both traps. ## Responsibilities @@ -22,12 +22,12 @@ The shell app is responsible for: - navigation entries - branded entry pages inside Nextcloud - admin-facing integration surfaces -- adapter calls into the aiNAS control plane +- adapter calls into the betternas control plane The shell app is not responsible for: - storage policy rules - orchestration logic -- aiNAS-native RBAC decisions +- betternas-native RBAC decisions - product workflows that may later be reused by desktop, iOS, or standalone web clients ### Control-plane service @@ -35,7 +35,7 @@ The shell app is not responsible for: The control plane is responsible for: - domain logic - policy decisions -- internal APIs consumed by aiNAS surfaces +- internal APIs consumed by betternas surfaces - Nextcloud integration adapters kept at the service boundary ### Shared contracts @@ -48,7 +48,7 @@ The local development stack uses Docker Compose so developers can bring up: - Nextcloud - PostgreSQL - Redis -- the aiNAS control-plane service +- the betternas control-plane service The Nextcloud shell app is mounted as a custom app and enabled through `./scripts/dev-up`. diff --git a/docs/platform-foundation.md b/docs/platform-foundation.md index cdf6d47..add1435 100644 --- a/docs/platform-foundation.md +++ b/docs/platform-foundation.md @@ -1,14 +1,14 @@ -# aiNAS Platform Foundation +# betternas Platform Foundation -This document is the north-star planning artifact for the next phase of aiNAS. +This document is the north-star planning artifact for the next phase of betternas. -The scaffold phase is done. We now have a verified local Nextcloud runtime, a thin Nextcloud shell app, and a minimal aiNAS control-plane service. The next phase is about deciding what we will steal from Nextcloud, what we will own ourselves, and how the product should evolve without turning Nextcloud into the center of the system. +The scaffold phase is done. We now have a verified local Nextcloud runtime, a thin Nextcloud shell app, and a minimal betternas control-plane service. The next phase is about deciding what we will steal from Nextcloud, what we will own ourselves, and how the product should evolve without turning Nextcloud into the center of the system. ## Product Stance -aiNAS is not "a custom Nextcloud theme." +betternas is not "a custom Nextcloud theme." -aiNAS is a storage control plane with: +betternas is a storage control plane with: - its own product semantics - its own API - its own web surface @@ -19,13 +19,13 @@ Nextcloud remains valuable, but it is an upstream substrate and reference implem ## High-Level Model ```text - aiNAS platform model + betternas platform model users / browser / desktop / mobile / cli | v +--------------------------+ - | aiNAS control plane | + | betternas control plane | |--------------------------| | identity | | workspaces | @@ -80,11 +80,11 @@ Nextcloud is also a strong source of reference implementations: The desktop client is especially high leverage because the official docs describe it as appearing as a dedicated location in the Finder sidebar, with offline controls, file previews, sharing, server-side actions, and automatic change detection. -## What aiNAS Must Own +## What betternas Must Own Even with heavy reuse, the product still needs its own control plane. -aiNAS should own: +betternas should own: - the domain model for users, devices, workspaces, storage sources, shares, policies, and mount profiles - the product API used by future web, desktop, and mobile surfaces - device and mount orchestration semantics @@ -161,7 +161,7 @@ This mode should be treated as a later capability unless it becomes the immediat The working assumption for the next phase is: -- aiNAS is the system of record for product semantics +- betternas is the system of record for product semantics - Nextcloud is the upstream file/share/storage substrate This keeps the architecture clean and avoids accidentally letting the adapter become the product. @@ -169,15 +169,15 @@ This keeps the architecture clean and avoids accidentally letting the adapter be ## Recommended Delivery Sequence 1. Define the Nextcloud substrate we are officially adopting. -2. Define the aiNAS control-plane domain model and API. +2. Define the betternas control-plane domain model and API. 3. Build the first real control-plane backend around Postgres and Redis. 4. Build a standalone Next.js control-plane web app. -5. Deepen the Nextcloud adapter so it mirrors aiNAS-owned semantics. +5. Deepen the Nextcloud adapter so it mirrors betternas-owned semantics. 6. Only then decide how much custom device and mount orchestration we need. ## Decision Matrix -| Area | Use Nextcloud first | Own in aiNAS | +| Area | Use Nextcloud first | Own in betternas | |---|---|---| | file and sharing web UX | yes | later, only if needed | | storage backend aggregation | yes | overlay policy, source catalog, and orchestration | @@ -186,7 +186,7 @@ This keeps the architecture clean and avoids accidentally letting the adapter be | product API | no | yes | | device model | no | yes | | mount model | no | yes | -| policy / RBAC semantics | baseline from Nextcloud is acceptable | real product semantics belong in aiNAS | +| policy / RBAC semantics | baseline from Nextcloud is acceptable | real product semantics belong in betternas | | admin/control UI | partial in Nextcloud | full standalone control plane should be ours | ## Open Questions @@ -195,7 +195,7 @@ These questions should be explicitly resolved in the next planning change: - Is v1 cloud-drive-first, mount-first, or hybrid? - Which storage backends are in scope first: SMB, S3, WebDAV, local, or all of them? -- What should aiNAS identity own in v1 versus what should be delegated to Nextcloud users/groups? +- What should betternas identity own in v1 versus what should be delegated to Nextcloud users/groups? - Should Nextcloud remain part of the end-user workflow in v1, or mostly act as a backend adapter? - When do we fork or brand the desktop and mobile clients, if ever? diff --git a/exapps/control-plane/src/config.ts b/exapps/control-plane/src/config.ts index d3e3381..4eeb1cb 100644 --- a/exapps/control-plane/src/config.ts +++ b/exapps/control-plane/src/config.ts @@ -14,7 +14,7 @@ export function loadConfig(env: NodeJS.ProcessEnv = process.env): ControlPlaneCo return { port, - version: env.AINAS_VERSION ?? "0.1.0-dev", + version: env.betternas_VERSION ?? "0.1.0-dev", nextcloudBaseUrl: normalizeBaseUrl(env.NEXTCLOUD_BASE_URL ?? "http://nextcloud") }; } diff --git a/exapps/control-plane/src/index.ts b/exapps/control-plane/src/index.ts index 7df43a2..4fd2849 100644 --- a/exapps/control-plane/src/index.ts +++ b/exapps/control-plane/src/index.ts @@ -5,6 +5,6 @@ const config = loadConfig(); const app = createApp(config); app.listen(config.port, "0.0.0.0", () => { - console.log(`aiNAS control plane listening on port ${config.port}`); + console.log(`betternas control plane listening on port ${config.port}`); }); diff --git a/nextcloud.txt b/nextcloud.txt index 17e675d..c34adfe 100644 --- a/nextcloud.txt +++ b/nextcloud.txt @@ -11,7 +11,7 @@ # basic non-verified structure off the top of my head -aiNAS/ +betternas/ docker/ compose.dev.yml nextcloud/ diff --git a/openspec/changes/define-platform-foundation/design.md b/openspec/changes/define-platform-foundation/design.md index 5e44861..9a4f56f 100644 --- a/openspec/changes/define-platform-foundation/design.md +++ b/openspec/changes/define-platform-foundation/design.md @@ -1,9 +1,9 @@ ## Context -aiNAS now has a verified local scaffold: +betternas now has a verified local scaffold: - a stock Nextcloud runtime -- a thin aiNAS app inside Nextcloud -- a minimal aiNAS control-plane service +- a thin betternas app inside Nextcloud +- a minimal betternas control-plane service - shared contracts That scaffold proves the direction, but it does not yet answer the more important product questions. We need to decide what the actual backend is, what should remain delegated to Nextcloud, how the standalone product should take shape, and which work has the highest leverage. @@ -14,7 +14,7 @@ The user goal is clear: build "file storage everywhere" with native-feeling acce **Goals** - Define which primitives we will adopt from Nextcloud versus own ourselves. -- Define the aiNAS control plane as the long-term system of record for product semantics. +- Define the betternas control plane as the long-term system of record for product semantics. - Define the first real backend domain at a high level. - Define the first standalone web product direction outside Nextcloud. - Define how device-native access fits into the architecture without forcing premature implementation. @@ -27,9 +27,9 @@ The user goal is clear: build "file storage everywhere" with native-feeling acce ## Core Decisions -### 1. aiNAS owns product semantics +### 1. betternas owns product semantics -aiNAS should be the system of record for: +betternas should be the system of record for: - workspaces - devices - storage sources @@ -54,20 +54,20 @@ Nextcloud is valuable because it already provides: - a desktop client with Finder integration - a mobile app -aiNAS should deliberately reuse those primitives where they reduce time-to-product, while keeping product-specific logic outside of Nextcloud. +betternas should deliberately reuse those primitives where they reduce time-to-product, while keeping product-specific logic outside of Nextcloud. Rationale: - highest leverage path - strongest reference implementations - avoids rebuilding low-differentiation components too early -### 3. The control plane should remain a standalone aiNAS service +### 3. The control plane should remain a standalone betternas service -The current ExApp-compatible service is useful, but the long-term shape should be a standalone aiNAS backend that happens to have a Nextcloud adapter, not a backend that is conceptually trapped inside the AppAPI/ExApp model. +The current ExApp-compatible service is useful, but the long-term shape should be a standalone betternas backend that happens to have a Nextcloud adapter, not a backend that is conceptually trapped inside the AppAPI/ExApp model. Rationale: - the control plane should be reusable by future standalone clients -- aiNAS will likely want richer event, device, and auth flows than a pure Nextcloud extension mindset encourages +- betternas will likely want richer event, device, and auth flows than a pure Nextcloud extension mindset encourages - keeping the service standalone reduces accidental architectural lock-in ### 4. Start with one modular backend service @@ -128,13 +128,13 @@ Rationale: ## High-Level Architecture ```text - aiNAS target architecture + betternas target architecture browser / desktop / mobile / cli | v +---------------------------+ - | aiNAS control plane | + | betternas control plane | |---------------------------| | identity + sessions | | workspaces | @@ -208,10 +208,10 @@ This is intentionally high level. The exact path layout, auth model, and payload ## Risks / Trade-offs -- If we let Nextcloud users/groups become the permanent product identity model, aiNAS will be harder to evolve independently. +- If we let Nextcloud users/groups become the permanent product identity model, betternas will be harder to evolve independently. - If we overbuild the control plane before deciding which Nextcloud primitives we are actually keeping, we may duplicate useful substrate capabilities unnecessarily. - If we force a custom device agent too early, we may spend time on native integration before proving the backend and product semantics. -- If we defer too much ownership to Nextcloud, the product may never fully become aiNAS. +- If we defer too much ownership to Nextcloud, the product may never fully become betternas. ## Sequencing @@ -229,5 +229,5 @@ Recommended change sequence: - Is v1 cloud-drive-first, mount-first, or explicitly hybrid? - Which storage backends are in scope first? - How much identity should be delegated to Nextcloud in v1? -- Should end users interact directly with Nextcloud in v1, or mostly through aiNAS surfaces? +- Should end users interact directly with Nextcloud in v1, or mostly through betternas surfaces? - When, if ever, should the desktop or mobile clients be branded or forked? diff --git a/openspec/changes/define-platform-foundation/proposal.md b/openspec/changes/define-platform-foundation/proposal.md index 061c8d9..10ab85e 100644 --- a/openspec/changes/define-platform-foundation/proposal.md +++ b/openspec/changes/define-platform-foundation/proposal.md @@ -1,11 +1,11 @@ ## Why -The scaffold phase is complete, but the repo still lacks a clear product-level plan for how aiNAS should evolve beyond a thin Nextcloud shell and a minimal backend stub. Before implementing more code, we need planning artifacts that define the system of record, the role Nextcloud should play, the control-plane domain we intend to own, and the delivery sequence for the first real product capabilities. +The scaffold phase is complete, but the repo still lacks a clear product-level plan for how betternas should evolve beyond a thin Nextcloud shell and a minimal backend stub. Before implementing more code, we need planning artifacts that define the system of record, the role Nextcloud should play, the control-plane domain we intend to own, and the delivery sequence for the first real product capabilities. ## What Changes -- Add a north-star planning layer for the aiNAS platform. -- Define the Nextcloud substrate that aiNAS will adopt instead of rebuilding from scratch. +- Add a north-star planning layer for the betternas platform. +- Define the Nextcloud substrate that betternas will adopt instead of rebuilding from scratch. - Define the first high-level control-plane domain model and service contracts. - Define the intended standalone web control-plane direction outside Nextcloud. - Define the future device access layer boundary, including the distinction between cloud-drive style access and true remote mounts. @@ -13,10 +13,10 @@ The scaffold phase is complete, but the repo still lacks a clear product-level p ## Capabilities ### New Capabilities -- `nextcloud-substrate`: A documented contract for which server, storage, sharing, and client primitives aiNAS will adopt from Nextcloud. -- `control-plane-core`: A documented contract for the first real aiNAS backend domain model and API surface. -- `standalone-control-plane-web`: A documented contract for the future Next.js web console that will become the aiNAS product surface outside Nextcloud. -- `device-access-layer`: A documented contract for how aiNAS will eventually support native device access, including mount and sync modes. +- `nextcloud-substrate`: A documented contract for which server, storage, sharing, and client primitives betternas will adopt from Nextcloud. +- `control-plane-core`: A documented contract for the first real betternas backend domain model and API surface. +- `standalone-control-plane-web`: A documented contract for the future Next.js web console that will become the betternas product surface outside Nextcloud. +- `device-access-layer`: A documented contract for how betternas will eventually support native device access, including mount and sync modes. ### Modified Capabilities - None. @@ -25,5 +25,5 @@ The scaffold phase is complete, but the repo still lacks a clear product-level p - Affected code: planning artifacts only - Affected systems: architecture, product sequencing, service boundaries, implementation roadmap -- Dependencies: Nextcloud server, Nextcloud desktop/iOS references, aiNAS control-plane service, future Postgres/Redis-backed product metadata -- APIs: establishes the intended aiNAS-owned API and adapter boundaries at a high level before implementation +- Dependencies: Nextcloud server, Nextcloud desktop/iOS references, betternas control-plane service, future Postgres/Redis-backed product metadata +- APIs: establishes the intended betternas-owned API and adapter boundaries at a high level before implementation diff --git a/openspec/changes/define-platform-foundation/specs/control-plane-core/spec.md b/openspec/changes/define-platform-foundation/specs/control-plane-core/spec.md index 05841cd..b6e4372 100644 --- a/openspec/changes/define-platform-foundation/specs/control-plane-core/spec.md +++ b/openspec/changes/define-platform-foundation/specs/control-plane-core/spec.md @@ -1,11 +1,11 @@ ## ADDED Requirements -### Requirement: aiNAS control plane as product system of record -The system SHALL define an aiNAS-owned control plane as the authoritative home for product-level domain concepts. +### Requirement: betternas control plane as product system of record +The system SHALL define an betternas-owned control plane as the authoritative home for product-level domain concepts. #### Scenario: Product semantics require persistence -- **WHEN** aiNAS needs to represent devices, workspaces, storage sources, shares, mount profiles, policies, or audit history -- **THEN** the planning artifacts MUST place those concepts inside the aiNAS control-plane domain model +- **WHEN** betternas needs to represent devices, workspaces, storage sources, shares, mount profiles, policies, or audit history +- **THEN** the planning artifacts MUST place those concepts inside the betternas control-plane domain model ### Requirement: High-level domain contracts The platform SHALL define a first high-level contract map for core entities and API categories before implementation proceeds. @@ -17,9 +17,9 @@ The platform SHALL define a first high-level contract map for core entities and ### Requirement: Standalone service posture The control plane SHALL remain architecturally standalone even if it is temporarily packaged or surfaced through Nextcloud-compatible mechanisms. -#### Scenario: aiNAS backend is consumed by multiple surfaces +#### Scenario: betternas backend is consumed by multiple surfaces - **WHEN** a standalone web app, Nextcloud shell, or future device client needs backend behavior -- **THEN** the design MUST treat the control plane as a reusable aiNAS service rather than as logic conceptually trapped inside the Nextcloud app model +- **THEN** the design MUST treat the control plane as a reusable betternas service rather than as logic conceptually trapped inside the Nextcloud app model ### Requirement: Single modular backend first The platform SHALL prefer one modular backend service before splitting the control plane into multiple distributed services. diff --git a/openspec/changes/define-platform-foundation/specs/device-access-layer/spec.md b/openspec/changes/define-platform-foundation/specs/device-access-layer/spec.md index ebca0df..e62ea41 100644 --- a/openspec/changes/define-platform-foundation/specs/device-access-layer/spec.md +++ b/openspec/changes/define-platform-foundation/specs/device-access-layer/spec.md @@ -4,7 +4,7 @@ The platform SHALL explicitly distinguish between cloud-drive style access and true remote mount behavior. #### Scenario: Device access strategy is discussed -- **WHEN** aiNAS plans device-native access on macOS or mobile +- **WHEN** betternas plans device-native access on macOS or mobile - **THEN** the planning artifacts MUST state whether the capability is based on cloud-drive style client behavior, true remote mounts, or both ### Requirement: Defer custom native agent work until justified @@ -15,8 +15,8 @@ The platform SHALL not require a custom device-native agent for the first backen - **THEN** the design MUST allow heavy reuse of Nextcloud client references before requiring a custom native device daemon ### Requirement: Keep future device agent possible -The architecture SHALL preserve a clear boundary where a future aiNAS-owned device access layer can be introduced without rewriting the control plane. +The architecture SHALL preserve a clear boundary where a future betternas-owned device access layer can be introduced without rewriting the control plane. #### Scenario: Product later adds login-time mounts or stronger native behavior -- **WHEN** aiNAS decides to add explicit mount orchestration or device-native workflows +- **WHEN** betternas decides to add explicit mount orchestration or device-native workflows - **THEN** the design MUST place that behavior in a device access layer separate from the core control-plane domain diff --git a/openspec/changes/define-platform-foundation/specs/nextcloud-substrate/spec.md b/openspec/changes/define-platform-foundation/specs/nextcloud-substrate/spec.md index c5f0f0c..c4f6ec8 100644 --- a/openspec/changes/define-platform-foundation/specs/nextcloud-substrate/spec.md +++ b/openspec/changes/define-platform-foundation/specs/nextcloud-substrate/spec.md @@ -1,29 +1,29 @@ ## ADDED Requirements ### Requirement: Nextcloud substrate boundary -The system SHALL explicitly define which storage, sharing, and client primitives aiNAS adopts from Nextcloud and which concerns remain aiNAS-owned. +The system SHALL explicitly define which storage, sharing, and client primitives betternas adopts from Nextcloud and which concerns remain betternas-owned. #### Scenario: Product planning references Nextcloud capabilities -- **WHEN** aiNAS decides whether to build or reuse a capability -- **THEN** the planning artifacts MUST classify the capability as either Nextcloud substrate, aiNAS-owned logic, or a later optional fork/reference path +- **WHEN** betternas decides whether to build or reuse a capability +- **THEN** the planning artifacts MUST classify the capability as either Nextcloud substrate, betternas-owned logic, or a later optional fork/reference path ### Requirement: Reuse external storage backends The platform SHALL treat Nextcloud external storage support as the first candidate substrate for connecting backend storage systems. -#### Scenario: aiNAS selects initial backend storage types -- **WHEN** aiNAS chooses the first storage backends to support +#### Scenario: betternas selects initial backend storage types +- **WHEN** betternas chooses the first storage backends to support - **THEN** the plan MUST assume reuse of Nextcloud-supported external storage backends before proposing custom storage ingestion infrastructure ### Requirement: Reuse desktop and mobile references first The platform SHALL treat the public Nextcloud desktop and iOS clients as the first reference implementations for cloud-drive style access before planning fully custom clients. -#### Scenario: aiNAS evaluates native device access +#### Scenario: betternas evaluates native device access - **WHEN** the product needs Finder-style or mobile file access - **THEN** the plan MUST document whether Nextcloud clients are being used directly, referenced, branded later, or intentionally replaced ### Requirement: Keep Nextcloud as substrate, not system of record -The platform SHALL not let Nextcloud become the long-term system of record for aiNAS-specific product semantics. +The platform SHALL not let Nextcloud become the long-term system of record for betternas-specific product semantics. #### Scenario: New product concept is introduced -- **WHEN** aiNAS introduces workspaces, devices, policies, mount profiles, or similar product concepts -- **THEN** the design MUST model those concepts in aiNAS-owned contracts rather than relying on implicit Nextcloud-only representations +- **WHEN** betternas introduces workspaces, devices, policies, mount profiles, or similar product concepts +- **THEN** the design MUST model those concepts in betternas-owned contracts rather than relying on implicit Nextcloud-only representations diff --git a/openspec/changes/define-platform-foundation/specs/standalone-control-plane-web/spec.md b/openspec/changes/define-platform-foundation/specs/standalone-control-plane-web/spec.md index 44dc09d..f97135a 100644 --- a/openspec/changes/define-platform-foundation/specs/standalone-control-plane-web/spec.md +++ b/openspec/changes/define-platform-foundation/specs/standalone-control-plane-web/spec.md @@ -1,22 +1,22 @@ ## ADDED Requirements -### Requirement: Standalone aiNAS web surface +### Requirement: Standalone betternas web surface The platform SHALL plan for a standalone web control-plane surface outside Nextcloud. #### Scenario: Product UI expands beyond an embedded shell -- **WHEN** aiNAS needs an admin or product control interface that is larger than a thin Nextcloud page -- **THEN** the plan MUST place that interface in an aiNAS-owned standalone web application +- **WHEN** betternas needs an admin or product control interface that is larger than a thin Nextcloud page +- **THEN** the plan MUST place that interface in an betternas-owned standalone web application -### Requirement: Web UI consumes aiNAS API -The standalone web application SHALL be designed to consume aiNAS-owned backend contracts rather than Nextcloud internals directly. +### Requirement: Web UI consumes betternas API +The standalone web application SHALL be designed to consume betternas-owned backend contracts rather than Nextcloud internals directly. #### Scenario: Web product feature requires backend data - **WHEN** the standalone web surface needs workspaces, devices, shares, or policies -- **THEN** it MUST obtain those concepts through the aiNAS control-plane API design rather than by binding directly to Nextcloud internal models +- **THEN** it MUST obtain those concepts through the betternas control-plane API design rather than by binding directly to Nextcloud internal models ### Requirement: Preserve Nextcloud shell as adapter The presence of a standalone web app SHALL not remove the need for the thin Nextcloud shell as an adapter and embedded entry surface. -#### Scenario: aiNAS still needs a presence inside Nextcloud +#### Scenario: betternas still needs a presence inside Nextcloud - **WHEN** the broader product grows outside the Nextcloud UI - **THEN** the shell app MUST remain conceptually limited to integration and entry-point responsibilities rather than absorbing the full standalone product diff --git a/openspec/changes/define-platform-foundation/tasks.md b/openspec/changes/define-platform-foundation/tasks.md index d302ef4..6269e55 100644 --- a/openspec/changes/define-platform-foundation/tasks.md +++ b/openspec/changes/define-platform-foundation/tasks.md @@ -1,7 +1,7 @@ ## 1. Planning and boundary definition - [ ] 1.1 Review the new planning artifacts and resolve the remaining open questions around v1 product mode, identity ownership, and first storage backends -- [ ] 1.2 Confirm the official Nextcloud primitives aiNAS will adopt in v1 and which ones are only reference implementations +- [ ] 1.2 Confirm the official Nextcloud primitives betternas will adopt in v1 and which ones are only reference implementations - [ ] 1.3 Confirm the control plane as the system of record for product semantics ## 2. Control-plane architecture planning @@ -19,5 +19,5 @@ ## 4. Follow-on implementation changes - [ ] 4.1 Propose the next implementation change for defining the Nextcloud substrate in concrete runtime terms -- [ ] 4.2 Propose the implementation change for the first real aiNAS control-plane backend +- [ ] 4.2 Propose the implementation change for the first real betternas control-plane backend - [ ] 4.3 Propose the implementation change for the standalone control-plane web UI diff --git a/openspec/changes/scaffold-nextcloud-control-plane/design.md b/openspec/changes/scaffold-nextcloud-control-plane/design.md index 448adcb..e2f58a4 100644 --- a/openspec/changes/scaffold-nextcloud-control-plane/design.md +++ b/openspec/changes/scaffold-nextcloud-control-plane/design.md @@ -1,16 +1,16 @@ ## Context -aiNAS is starting as a greenfield project with a clear product boundary: we want our own storage control plane, product UX, and business logic while using Nextcloud as an upstream backend for file storage, sync primitives, sharing primitives, and existing client compatibility. The repository is effectively empty today, so this change needs to establish both the architectural stance and the initial developer scaffold. +betternas is starting as a greenfield project with a clear product boundary: we want our own storage control plane, product UX, and business logic while using Nextcloud as an upstream backend for file storage, sync primitives, sharing primitives, and existing client compatibility. The repository is effectively empty today, so this change needs to establish both the architectural stance and the initial developer scaffold. -The main constraint is maintenance ownership. Forking `nextcloud/server` would move security patches, upstream upgrade churn, and internal compatibility risk onto aiNAS too early. At the same time, pushing all product logic into a traditional Nextcloud app would make our business rules hard to evolve and tightly couple the product to the PHP monolith. The design therefore needs to leave us with a thin in-Nextcloud surface and a separate aiNAS-owned service layer. +The main constraint is maintenance ownership. Forking `nextcloud/server` would move security patches, upstream upgrade churn, and internal compatibility risk onto betternas too early. At the same time, pushing all product logic into a traditional Nextcloud app would make our business rules hard to evolve and tightly couple the product to the PHP monolith. The design therefore needs to leave us with a thin in-Nextcloud surface and a separate betternas-owned service layer. ## Goals / Non-Goals **Goals:** -- Create a repository scaffold that supports local development with vanilla Nextcloud and aiNAS-owned services. +- Create a repository scaffold that supports local development with vanilla Nextcloud and betternas-owned services. - Define a thin Nextcloud shell app that handles navigation, branded entry points, and backend integration hooks. -- Define an aiNAS control-plane service boundary for business logic, policy, and orchestration. -- Keep interfaces typed and explicit so future web, desktop, and iOS clients can target aiNAS services rather than Nextcloud internals. +- Define an betternas control-plane service boundary for business logic, policy, and orchestration. +- Keep interfaces typed and explicit so future web, desktop, and iOS clients can target betternas services rather than Nextcloud internals. - Make the initial architecture easy to extend without forcing a Nextcloud core fork. **Non-Goals:** @@ -23,7 +23,7 @@ The main constraint is maintenance ownership. Forking `nextcloud/server` would m ### 1. Use vanilla Nextcloud as an upstream backend, not a fork -aiNAS will run a stock Nextcloud instance in local development and future environments. We will extend it through a dedicated aiNAS app and service integrations instead of modifying core server code. +betternas will run a stock Nextcloud instance in local development and future environments. We will extend it through a dedicated betternas app and service integrations instead of modifying core server code. Rationale: - Keeps upstream upgrades and security patches tractable. @@ -36,7 +36,7 @@ Alternatives considered: ### 2. Keep the Nextcloud app thin and treat it as an adapter shell -The generated Nextcloud app will own aiNAS-specific UI entry points inside Nextcloud, settings pages, and integration hooks, but SHALL not become the home of core business logic. It will call aiNAS-owned APIs/services for control-plane decisions. +The generated Nextcloud app will own betternas-specific UI entry points inside Nextcloud, settings pages, and integration hooks, but SHALL not become the home of core business logic. It will call betternas-owned APIs/services for control-plane decisions. Rationale: - Keeps PHP app code small and replaceable. @@ -46,12 +46,12 @@ Rationale: Alternatives considered: - Put most logic directly in the app: rejected because it couples product evolution to the monolith. -### 3. Scaffold an aiNAS control-plane service from the start +### 3. Scaffold an betternas control-plane service from the start The repo will include a control-plane service that exposes internal HTTP APIs, owns domain models, and encapsulates policy and orchestration logic. In the first scaffold, this service may be packaged in an ExApp-compatible container, but the code structure SHALL keep Nextcloud-specific integration at the boundary rather than in domain logic. Rationale: -- Matches the product direction of aiNAS owning the control plane. +- Matches the product direction of betternas owning the control plane. - Gives one place for RBAC, storage policy, and orchestration logic to live. - Supports future desktop, iOS, and standalone web surfaces without coupling them to Nextcloud-rendered pages. @@ -66,7 +66,7 @@ The initial scaffold will create clear top-level directories for infrastructure, Initial structure: - `docker/`: local orchestration and container assets - `apps/betternas-controlplane/`: generated Nextcloud shell app -- `exapps/control-plane/`: aiNAS control-plane service, packaged for Nextcloud-compatible dev flows +- `exapps/control-plane/`: betternas control-plane service, packaged for Nextcloud-compatible dev flows - `packages/contracts/`: shared schemas and API contracts - `docs/`: architecture and product model notes - `scripts/`: repeatable developer entry points @@ -82,7 +82,7 @@ Alternatives considered: ### 5. Standardize on a Docker-based local platform first -The first scaffold will target a Docker Compose development environment that starts Nextcloud, its required backing services, and the aiNAS control-plane service. This gives a repeatable local runtime before we decide on production deployment. +The first scaffold will target a Docker Compose development environment that starts Nextcloud, its required backing services, and the betternas control-plane service. This gives a repeatable local runtime before we decide on production deployment. Rationale: - Aligns with Nextcloud's easiest local development path. @@ -95,7 +95,7 @@ Alternatives considered: ## Risks / Trade-offs -- [Nextcloud coupling leaks into aiNAS service design] → Keep all Nextcloud-specific API calls and payload translation in adapter modules at the edge of the control-plane service. +- [Nextcloud coupling leaks into betternas service design] → Keep all Nextcloud-specific API calls and payload translation in adapter modules at the edge of the control-plane service. - [The shell app grows into a second control plane] → Enforce a rule that product decisions and persistent domain logic live in the control-plane service, not the Nextcloud app. - [ExApp packaging constrains future independence] → Structure the service so container packaging is a deployment concern rather than the application architecture. - [Initial repo layout may be wrong in details] → Optimize for a small number of strong boundaries now; revisit internal package names later without collapsing ownership boundaries. @@ -116,5 +116,5 @@ Rollback strategy: - Should the first control-plane service be implemented in Go, Python, or Node/TypeScript? - What authentication boundary should exist between the Nextcloud shell app and the control-plane service in local development? -- Which parts of future sharing and RBAC behavior should remain delegated to Nextcloud, and which should be modeled natively in aiNAS? +- Which parts of future sharing and RBAC behavior should remain delegated to Nextcloud, and which should be modeled natively in betternas? - Do we want the first web product surface to live inside Nextcloud pages, outside Nextcloud as a separate frontend, or both? diff --git a/openspec/changes/scaffold-nextcloud-control-plane/proposal.md b/openspec/changes/scaffold-nextcloud-control-plane/proposal.md index cc6d32e..be6e9a4 100644 --- a/openspec/changes/scaffold-nextcloud-control-plane/proposal.md +++ b/openspec/changes/scaffold-nextcloud-control-plane/proposal.md @@ -1,21 +1,21 @@ ## Why -aiNAS needs an initial architecture and repository scaffold that lets us build our own storage control plane without inheriting the maintenance cost of a Nextcloud core fork. We want to move quickly on product-specific business logic, but still stand on top of a mature backend for files, sync, sharing primitives, and existing clients. +betternas needs an initial architecture and repository scaffold that lets us build our own storage control plane without inheriting the maintenance cost of a Nextcloud core fork. We want to move quickly on product-specific business logic, but still stand on top of a mature backend for files, sync, sharing primitives, and existing clients. ## What Changes -- Create an initial aiNAS platform scaffold centered on vanilla Nextcloud running in Docker for local development. -- Define a thin Nextcloud app shell that owns aiNAS-specific integration points, branded surfaces, and adapters into the Nextcloud backend. -- Define a control-plane service boundary where aiNAS business logic, policy, and future orchestration will live outside the Nextcloud monolith. +- Create an initial betternas platform scaffold centered on vanilla Nextcloud running in Docker for local development. +- Define a thin Nextcloud app shell that owns betternas-specific integration points, branded surfaces, and adapters into the Nextcloud backend. +- Define a control-plane service boundary where betternas business logic, policy, and future orchestration will live outside the Nextcloud monolith. - Establish a repository layout for Docker infrastructure, Nextcloud app code, ExApp/service code, and shared API contracts. - Document the decision to treat Nextcloud as an upstream backend dependency rather than a forked application baseline. ## Capabilities ### New Capabilities -- `workspace-scaffold`: Repository structure and local development platform for running aiNAS with Nextcloud, service containers, and shared packages. -- `nextcloud-shell-app`: Thin aiNAS app inside Nextcloud for navigation, settings, branded entry points, and backend integration hooks. -- `control-plane-service`: External aiNAS service layer that owns business logic and exposes internal APIs used by the Nextcloud shell and future clients. +- `workspace-scaffold`: Repository structure and local development platform for running betternas with Nextcloud, service containers, and shared packages. +- `nextcloud-shell-app`: Thin betternas app inside Nextcloud for navigation, settings, branded entry points, and backend integration hooks. +- `control-plane-service`: External betternas service layer that owns business logic and exposes internal APIs used by the Nextcloud shell and future clients. ### Modified Capabilities - None. diff --git a/openspec/changes/scaffold-nextcloud-control-plane/specs/control-plane-service/spec.md b/openspec/changes/scaffold-nextcloud-control-plane/specs/control-plane-service/spec.md index 4dc026f..fe327ba 100644 --- a/openspec/changes/scaffold-nextcloud-control-plane/specs/control-plane-service/spec.md +++ b/openspec/changes/scaffold-nextcloud-control-plane/specs/control-plane-service/spec.md @@ -1,18 +1,18 @@ ## ADDED Requirements ### Requirement: Dedicated control-plane service -The system SHALL provide an aiNAS-owned control-plane service that is separate from the Nextcloud shell app and owns product domain logic. +The system SHALL provide an betternas-owned control-plane service that is separate from the Nextcloud shell app and owns product domain logic. -#### Scenario: aiNAS adds a new control-plane rule +#### Scenario: betternas adds a new control-plane rule - **WHEN** a new business rule for storage policy, RBAC, orchestration, or future client behavior is introduced - **THEN** the rule MUST be implemented in the control-plane service rather than as primary logic inside the Nextcloud app ### Requirement: Client-agnostic internal API -The control-plane service SHALL expose internal APIs that can be consumed by the Nextcloud shell app and future aiNAS clients without requiring direct coupling to Nextcloud internals. +The control-plane service SHALL expose internal APIs that can be consumed by the Nextcloud shell app and future betternas clients without requiring direct coupling to Nextcloud internals. -#### Scenario: New aiNAS client consumes control-plane behavior -- **WHEN** aiNAS adds a web, desktop, or iOS surface outside Nextcloud -- **THEN** that surface MUST be able to consume control-plane behavior through documented aiNAS service interfaces +#### Scenario: New betternas client consumes control-plane behavior +- **WHEN** betternas adds a web, desktop, or iOS surface outside Nextcloud +- **THEN** that surface MUST be able to consume control-plane behavior through documented betternas service interfaces ### Requirement: Nextcloud backend adapter boundary The control-plane service SHALL isolate Nextcloud-specific integration at its boundary so that storage and sharing backends remain replaceable over time. diff --git a/openspec/changes/scaffold-nextcloud-control-plane/specs/nextcloud-shell-app/spec.md b/openspec/changes/scaffold-nextcloud-control-plane/specs/nextcloud-shell-app/spec.md index f32b2c6..ee3b5a3 100644 --- a/openspec/changes/scaffold-nextcloud-control-plane/specs/nextcloud-shell-app/spec.md +++ b/openspec/changes/scaffold-nextcloud-control-plane/specs/nextcloud-shell-app/spec.md @@ -1,22 +1,22 @@ ## ADDED Requirements -### Requirement: aiNAS shell app inside Nextcloud -The system SHALL provide a dedicated aiNAS shell app inside Nextcloud that establishes branded entry points for aiNAS-owned product surfaces. +### Requirement: betternas shell app inside Nextcloud +The system SHALL provide a dedicated betternas shell app inside Nextcloud that establishes branded entry points for betternas-owned product surfaces. -#### Scenario: aiNAS surface is visible in Nextcloud -- **WHEN** the aiNAS app is installed in a local development environment -- **THEN** Nextcloud MUST expose an aiNAS-branded application surface that can be used as the integration shell for future product flows +#### Scenario: betternas surface is visible in Nextcloud +- **WHEN** the betternas app is installed in a local development environment +- **THEN** Nextcloud MUST expose an betternas-branded application surface that can be used as the integration shell for future product flows ### Requirement: Thin adapter responsibility -The aiNAS shell app SHALL act as an adapter layer and MUST keep core business logic outside the Nextcloud monolith. +The betternas shell app SHALL act as an adapter layer and MUST keep core business logic outside the Nextcloud monolith. #### Scenario: Product decision requires domain logic - **WHEN** the shell app needs information about policy, orchestration, or future product rules -- **THEN** it MUST obtain that information through aiNAS-owned service boundaries instead of embedding the decision logic directly in the app +- **THEN** it MUST obtain that information through betternas-owned service boundaries instead of embedding the decision logic directly in the app ### Requirement: Nextcloud integration hooks -The aiNAS shell app SHALL provide the minimal integration hooks required to connect aiNAS-owned services to Nextcloud runtime surfaces such as navigation, settings, and backend access points. +The betternas shell app SHALL provide the minimal integration hooks required to connect betternas-owned services to Nextcloud runtime surfaces such as navigation, settings, and backend access points. -#### Scenario: aiNAS needs a Nextcloud-native entry point -- **WHEN** aiNAS introduces a new product flow that starts from a Nextcloud-rendered page -- **THEN** the shell app MUST provide a supported hook or page boundary where the flow can enter aiNAS-controlled logic +#### Scenario: betternas needs a Nextcloud-native entry point +- **WHEN** betternas introduces a new product flow that starts from a Nextcloud-rendered page +- **THEN** the shell app MUST provide a supported hook or page boundary where the flow can enter betternas-controlled logic diff --git a/openspec/changes/scaffold-nextcloud-control-plane/specs/workspace-scaffold/spec.md b/openspec/changes/scaffold-nextcloud-control-plane/specs/workspace-scaffold/spec.md index 39cbfe2..72c3b04 100644 --- a/openspec/changes/scaffold-nextcloud-control-plane/specs/workspace-scaffold/spec.md +++ b/openspec/changes/scaffold-nextcloud-control-plane/specs/workspace-scaffold/spec.md @@ -1,22 +1,22 @@ ## ADDED Requirements ### Requirement: Repository boundary scaffold -The repository SHALL provide a top-level scaffold that separates infrastructure, Nextcloud app code, aiNAS-owned service code, shared contracts, documentation, and automation scripts. +The repository SHALL provide a top-level scaffold that separates infrastructure, Nextcloud app code, betternas-owned service code, shared contracts, documentation, and automation scripts. #### Scenario: Fresh clone exposes expected boundaries - **WHEN** a developer inspects the repository after applying this change - **THEN** the repository MUST include dedicated locations for Docker runtime assets, the Nextcloud shell app, the control-plane service, shared contracts, documentation, and scripts ### Requirement: Local development platform -The repository SHALL provide a local development runtime that starts a vanilla Nextcloud instance together with its required backing services and the aiNAS control-plane service. +The repository SHALL provide a local development runtime that starts a vanilla Nextcloud instance together with its required backing services and the betternas control-plane service. #### Scenario: Developer boots the local stack - **WHEN** a developer runs the documented local startup flow -- **THEN** the system MUST start Nextcloud and the aiNAS service dependencies without requiring a forked Nextcloud build +- **THEN** the system MUST start Nextcloud and the betternas service dependencies without requiring a forked Nextcloud build ### Requirement: Shared contract package -The repository SHALL include a shared contract location for schemas and service interfaces used between the Nextcloud shell app and aiNAS-owned services. +The repository SHALL include a shared contract location for schemas and service interfaces used between the Nextcloud shell app and betternas-owned services. #### Scenario: Interface changes are modeled centrally -- **WHEN** aiNAS defines an internal API or payload exchanged between the shell app and the control-plane service +- **WHEN** betternas defines an internal API or payload exchanged between the shell app and the control-plane service - **THEN** the schema MUST be represented in the shared contracts location rather than duplicated ad hoc across codebases diff --git a/openspec/changes/scaffold-nextcloud-control-plane/tasks.md b/openspec/changes/scaffold-nextcloud-control-plane/tasks.md index cab1374..269debe 100644 --- a/openspec/changes/scaffold-nextcloud-control-plane/tasks.md +++ b/openspec/changes/scaffold-nextcloud-control-plane/tasks.md @@ -2,19 +2,19 @@ - [x] 1.1 Create the top-level repository structure for `docker/`, `apps/`, `exapps/`, `packages/`, `docs/`, and `scripts/` - [x] 1.2 Add a Docker Compose development stack for vanilla Nextcloud and its required backing services -- [x] 1.3 Add the aiNAS control-plane service container to the local development stack +- [x] 1.3 Add the betternas control-plane service container to the local development stack - [x] 1.4 Add repeatable developer scripts and documentation for booting and stopping the local stack ## 2. Nextcloud shell app scaffold -- [x] 2.1 Generate the aiNAS Nextcloud app scaffold into `apps/betternas-controlplane/` -- [x] 2.2 Configure the shell app with aiNAS branding, navigation entry points, and basic settings surface -- [x] 2.3 Add an adapter layer in the shell app for calling aiNAS-owned service endpoints +- [x] 2.1 Generate the betternas Nextcloud app scaffold into `apps/betternas-controlplane/` +- [x] 2.2 Configure the shell app with betternas branding, navigation entry points, and basic settings surface +- [x] 2.3 Add an adapter layer in the shell app for calling betternas-owned service endpoints - [x] 2.4 Verify the shell app installs and loads in the local Nextcloud runtime ## 3. Control-plane service scaffold -- [x] 3.1 Scaffold the aiNAS control-plane service in `exapps/control-plane/` +- [x] 3.1 Scaffold the betternas control-plane service in `exapps/control-plane/` - [x] 3.2 Add a minimal internal HTTP API surface with health and version endpoints - [x] 3.3 Create a dedicated Nextcloud adapter boundary inside the service for backend integrations - [x] 3.4 Wire local service configuration so the shell app can discover and call the control-plane service diff --git a/phase1.txt b/phase1.txt index f348e33..deac548 100644 --- a/phase1.txt +++ b/phase1.txt @@ -1,7 +1,7 @@ -aiNAS repo +betternas repo │ apps/betternas-controlplane │ PHP Nextcloud app - │ - nav entry: "aiNAS" + │ - nav entry: "betternas" │ - page route: /index.php/apps/betternascontrolplane/ │ - OCS route: /ocs/v2.php/apps/betternascontrolplane/api/status │ - job today: call control-plane and render a thin shell diff --git a/scripts/dev-up b/scripts/dev-up index 269403a..bced1ab 100755 --- a/scripts/dev-up +++ b/scripts/dev-up @@ -63,4 +63,4 @@ fi nextcloud_occ app:enable --force betternascontrolplane >/dev/null echo "Nextcloud: http://localhost:8080" -echo "aiNAS control plane: http://localhost:3001" +echo "betternas control plane: http://localhost:3001"