harivansh-afk/betterNAS
1
1
Fork 0
mirror of https://github.com/harivansh-afk/betterNAS.git synced 2026-04-17 12:04:12 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

rename2

Browse source
This commit is contained in:
Harivansh Rathi 2026-04-01 02:28:45 +00:00
parent 12c53f3515
commit dc7969e579
37 changed files with 177 additions and 177 deletions
Download patch file Download diff file Expand all files Collapse all files

12
openspec/changes/scaffold-nextcloud-control-plane/specs/control-plane-service/spec.md
View file

@ -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.

22
openspec/changes/scaffold-nextcloud-control-plane/specs/nextcloud-shell-app/spec.md
View file

@ -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

10
openspec/changes/scaffold-nextcloud-control-plane/specs/workspace-scaffold/spec.md
View file

@ -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