generated from coulomb/repo-seed
152 lines
5.2 KiB
Markdown
152 lines
5.2 KiB
Markdown
# SCOPE
|
|
|
|
> This file helps you quickly understand what this repository is about,
|
|
> when it is relevant, and when it is not.
|
|
> It is intentionally lightweight and may be incomplete.
|
|
|
|
---
|
|
|
|
## One-liner
|
|
|
|
HelixForge defines a capability-first development ecosystem for turning human intent into governed, reusable software capabilities.
|
|
|
|
---
|
|
|
|
## Core Idea
|
|
|
|
HelixForge joins discovery and delivery into one continuous loop: real-world
|
|
demands are explored in natural language, shaped into stable capabilities,
|
|
placed in an orthogonal architecture model, validated structurally and
|
|
semantically, implemented, and improved through feedback.
|
|
|
|
The repo is the early home for that intent, vocabulary, architecture schema,
|
|
and operating model. It is not yet an application implementation.
|
|
|
|
---
|
|
|
|
## In Scope
|
|
|
|
- HelixForge product intent, vision, and architectural commitments.
|
|
- Orthogonal Architecture Dimensions and OAS-compatible schema references.
|
|
- VSM-inspired vocabulary for classifying capabilities, relations, validation
|
|
rules, repository concerns, and future system elements.
|
|
- Workplans that shape HelixForge's first practical extensions and integrations.
|
|
- Guidance for future capability discovery, modeling, realization, validation,
|
|
and evolution artifacts.
|
|
|
|
---
|
|
|
|
## Out of Scope
|
|
|
|
- Running production services or hosting operational infrastructure directly.
|
|
- Owning Railiance infrastructure, cluster, platform, enablement, or app code.
|
|
- Replacing State Hub as the cross-repository memory and coordination surface.
|
|
- Replacing Inter-Hub as the interaction substrate for hub-based systems.
|
|
- Providing a stable SDK, API, CLI, UI, or runtime before implementation work
|
|
is explicitly scoped.
|
|
|
|
---
|
|
|
|
## Relevant When
|
|
|
|
- You need the HelixForge product thesis or capability-first operating model.
|
|
- You are modeling reusable capabilities from natural-language demand.
|
|
- You are checking how HelixForge maps Orthogonal Architecture Dimensions to
|
|
capability, service, platform, policy, automation, or intelligence elements.
|
|
- You are shaping an Inter-Hub extension pattern, such as the initial ops-hub
|
|
workplan.
|
|
|
|
---
|
|
|
|
## Not Relevant When
|
|
|
|
- You need deployable infrastructure code; use the relevant Railiance repos.
|
|
- You need State Hub implementation details; use `the-custodian/state-hub`.
|
|
- You need Inter-Hub API or UI implementation details; use `inter-hub`.
|
|
- You need deployable `ops-hub` implementation work; use `/home/worsch/ops-hub`
|
|
(`gitea-remote:coulomb/ops-hub.git`).
|
|
- You need a production-ready HelixForge runtime; this repo is not there yet.
|
|
|
|
---
|
|
|
|
## Current State
|
|
|
|
- Status: draft/concept
|
|
- Implementation: documentation and workplanning only
|
|
- Stability: evolving
|
|
- Usage: internal product and architecture shaping
|
|
|
|
The repository currently has no executable source tree, dependency manifest, or
|
|
test suite. `INTENT.md` is the main source of truth.
|
|
|
|
---
|
|
|
|
## How It Fits
|
|
|
|
- Upstream dependencies: Orthogonal Architecture Standard vocabulary and the
|
|
State Hub workplan/coordination model.
|
|
- Downstream consumers: future HelixForge implementation repos, Inter-Hub
|
|
extension work, `ops-hub`, and capability catalog/tooling efforts.
|
|
- Often used with: `inter-hub`, `the-custodian/state-hub`, Railiance ops repos,
|
|
and the `ops-hub` implementation repo.
|
|
|
|
---
|
|
|
|
## Terminology
|
|
|
|
- Preferred terms: capability, capability model, capability contract,
|
|
realization, validation, Orthogonal Architecture Dimensions, VSM-inspired
|
|
functions.
|
|
- Also known as: capability-first development ecosystem; intent-to-capability
|
|
forge.
|
|
- Potentially confusing terms: OAS means Orthogonal Architecture Standard here,
|
|
not OpenAPI Specification. Stack `S1`-`S5` placements are separate from VSM
|
|
System 1-5 tags.
|
|
|
|
---
|
|
|
|
## Related / Overlapping Repositories
|
|
|
|
- `inter-hub` - governed interaction substrate that HelixForge may extend.
|
|
- `ops-hub` - VSM Operations / System 1 Inter-Hub extension implementation;
|
|
local path `/home/worsch/ops-hub`.
|
|
- `the-custodian/state-hub` - cross-repo state, workstream, capability, and
|
|
progress index.
|
|
- `railiance-infra`, `railiance-cluster`, `railiance-platform`,
|
|
`railiance-enablement`, `railiance-apps` - operational stack referenced by
|
|
the first ops-hub workplan.
|
|
|
|
---
|
|
|
|
## Getting Oriented
|
|
|
|
- Start with: `INTENT.md`
|
|
- Key files / directories: `wiki/HelixForgeVision.md`,
|
|
`wiki/OrthogonalArchitectureSchema.md`, `workplans/`
|
|
- Entry points: `workplans/HF-WP-0001-establish-ops-hub-first-extension.md`
|
|
|
|
---
|
|
|
|
## Provided Capabilities
|
|
|
|
```capability
|
|
type: documentation
|
|
title: Capability-first architecture vocabulary
|
|
description: Defines the HelixForge vocabulary for capability discovery, modeling, contracts, realization, validation, and evolution across Orthogonal Architecture Dimensions.
|
|
keywords: [capability, architecture, OAS, VSM, validation]
|
|
```
|
|
|
|
```capability
|
|
type: other
|
|
title: Intent-to-capability operating model
|
|
description: Provides the product and process thesis for maturing natural-language demands into reusable, validated software capabilities.
|
|
keywords: [intent, discovery, delivery, reusable-capabilities, product-model]
|
|
```
|
|
|
|
---
|
|
|
|
## Notes
|
|
|
|
The existing workplan prefix is `HF-WP-`. Keep future workplans aligned with
|
|
that prefix unless the repository intentionally migrates its workplan naming.
|