aiongside 0.1.0-beta.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +157 -0
- package/dist/bin.js +31382 -0
- package/package.json +23 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 moseoh
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/README.md
ADDED
|
@@ -0,0 +1,157 @@
|
|
|
1
|
+
# AIongside
|
|
2
|
+
|
|
3
|
+
A local-first workspace where people and AI share everyday work context, Records, Overviews, and rules.
|
|
4
|
+
|
|
5
|
+
The first goal is simple local work management. The second goal is a validation layer that turns damaged Records, missed updates, and inconsistent generated Views into mechanical failures.
|
|
6
|
+
|
|
7
|
+
## Status
|
|
8
|
+
|
|
9
|
+
- MVP CLI implemented.
|
|
10
|
+
- Workspace initialization, work item creation, status movement, dependency management, cancellation, safe discard, and validation implemented.
|
|
11
|
+
- Editable workspace templates implemented.
|
|
12
|
+
- npm packaging and release validation implemented. The first npm release is pending.
|
|
13
|
+
- TypeScript monorepo managed with Bun.
|
|
14
|
+
- Shared Claude and Codex plugin source included.
|
|
15
|
+
- Local Web UI reserved for the distant future.
|
|
16
|
+
- TUI excluded from product scope.
|
|
17
|
+
|
|
18
|
+
## Quick start
|
|
19
|
+
|
|
20
|
+
After the first npm release, install AIongside with Node.js 22 or later:
|
|
21
|
+
|
|
22
|
+
```sh
|
|
23
|
+
npm install --global aiongside
|
|
24
|
+
aiongside --help
|
|
25
|
+
aiongside init ./example
|
|
26
|
+
aiongside --root ./example check
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
The installed CLI runs on Node.js without requiring Bun. Node.js 22 and 24 are tested for every release candidate.
|
|
30
|
+
|
|
31
|
+
To run from source before the first release:
|
|
32
|
+
|
|
33
|
+
```sh
|
|
34
|
+
bun install
|
|
35
|
+
bun run build
|
|
36
|
+
node packages/cli/dist/bin.js init ./example
|
|
37
|
+
node packages/cli/dist/bin.js --root ./example work new "First Work"
|
|
38
|
+
node packages/cli/dist/bin.js --root ./example check
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
## Templates
|
|
42
|
+
|
|
43
|
+
`aiongside init` creates editable Markdown templates:
|
|
44
|
+
|
|
45
|
+
```text
|
|
46
|
+
.aiongside/templates/
|
|
47
|
+
record.md
|
|
48
|
+
overview.md
|
|
49
|
+
plan.md
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
Edit these files with any text editor. New work items use the current workspace templates. AIongside generates YAML frontmatter separately, so template customization cannot remove machine-owned metadata.
|
|
53
|
+
|
|
54
|
+
`record.md` and `overview.md` must retain the `{{title}}` placeholder. `aiongside check` reports missing template files and invalid placeholders. Initialization never overwrites an existing template file.
|
|
55
|
+
|
|
56
|
+
## Workspace files
|
|
57
|
+
|
|
58
|
+
```text
|
|
59
|
+
work/<ID>/
|
|
60
|
+
record.md
|
|
61
|
+
overview.md
|
|
62
|
+
plan.md # Created when the work item moves to active
|
|
63
|
+
references/
|
|
64
|
+
deliverables/
|
|
65
|
+
evidence/
|
|
66
|
+
views/
|
|
67
|
+
open.md
|
|
68
|
+
closed.md
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
`record.md` is the canonical work document. It owns status, progress, decisions, and outcomes. `overview.md` is the short human-readable entry point and does not duplicate dynamic state. `plan.md` is optional and is created when a work item moves to `active`.
|
|
72
|
+
|
|
73
|
+
Each new work item includes three user-owned content directories:
|
|
74
|
+
|
|
75
|
+
- `references/`: material received from outside the work, such as official documents, vendor replies, source files, and links.
|
|
76
|
+
- `deliverables/`: outputs produced for delivery, such as reports, instructions, presentations, spreadsheets, and exports.
|
|
77
|
+
- `evidence/`: results observed directly in the current environment, such as logs, query results, screenshots, measurements, and command output.
|
|
78
|
+
|
|
79
|
+
AIongside requires these directories but does not constrain their file names, formats, or nested structure. Their contents are never rewritten automatically. File paths and exact bytes in all three directories are covered by the completion seal, so changing them while work remains `done` fails validation. Direct edits do not update Record metadata or generated Views.
|
|
80
|
+
|
|
81
|
+
Older workspaces may contain `reports/` instead of `deliverables/` and may not contain `evidence/`. AIongside does not move or delete those files automatically. Review the existing content, move delivery outputs into a new `deliverables/` directory, and create `evidence/` before running further mutations.
|
|
82
|
+
|
|
83
|
+
Views are generated from Record metadata and must not be edited directly. `aiongside check` compares each View with a deterministic rendering of current Records. Missing, stale, manually modified, or line-ending-converted Views fail validation without changing files. Run `aiongside view rebuild` for explicit recovery.
|
|
84
|
+
|
|
85
|
+
## Work status
|
|
86
|
+
|
|
87
|
+
AIongside uses five statuses:
|
|
88
|
+
|
|
89
|
+
- `inbox`: captured but not currently being worked.
|
|
90
|
+
- `active`: work, review, or verification that can proceed now.
|
|
91
|
+
- `waiting`: no action can proceed until an external response or condition changes.
|
|
92
|
+
- `done`: completion requirements were reviewed and sealed.
|
|
93
|
+
- `cancelled`: intentionally stopped while retaining the Record.
|
|
94
|
+
|
|
95
|
+
Every status can move to every other status. Preview a move before applying it:
|
|
96
|
+
|
|
97
|
+
```sh
|
|
98
|
+
aiongside work move AIO-001 waiting --dry-run --json
|
|
99
|
+
aiongside work move AIO-001 waiting \
|
|
100
|
+
--waiting-reason "Waiting for approval" \
|
|
101
|
+
--resume-when "Approval is received"
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
The JSON preview lists stable `requiredInputs`, questions, CLI options, changes, and warnings. Transition answers are written to machine-owned Record frontmatter, not the customizable template body.
|
|
105
|
+
|
|
106
|
+
Moving to `done` validates review signals stored in Record frontmatter. Confirm them after reviewing the corresponding Record content:
|
|
107
|
+
|
|
108
|
+
```sh
|
|
109
|
+
aiongside work confirm AIO-001 scope completion
|
|
110
|
+
aiongside work confirm AIO-001 verification
|
|
111
|
+
aiongside work confirm AIO-001 outcome knowledge
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
- Only `done` requires `scope`, `completion`, `verification`, `outcome`, and `knowledge`.
|
|
115
|
+
- Only `done` requires every ID in `needs` to be `done`.
|
|
116
|
+
- Leaving `done` requires `--reopen-reason` or `--cancellation-reason`, invalidates the completion seal, and resets verification, outcome, and knowledge confirmations.
|
|
117
|
+
- Changing completion-relevant content while the status remains `done` fails `aiongside check`.
|
|
118
|
+
|
|
119
|
+
`needs` contains stable work item IDs in Record frontmatter. Manage it through the CLI instead of editing frontmatter directly:
|
|
120
|
+
|
|
121
|
+
```sh
|
|
122
|
+
aiongside work needs add AIO-002 AIO-001
|
|
123
|
+
aiongside work needs remove AIO-002 AIO-001
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
Adding a dependency rejects missing, duplicate, self-referencing, and cyclic relationships. Removing an absent relationship succeeds without changing files. Reopen `done` work before changing its dependencies. Confirmations are mechanical review signals; they do not prove that prose is true or complete.
|
|
127
|
+
|
|
128
|
+
## Commands
|
|
129
|
+
|
|
130
|
+
```text
|
|
131
|
+
aiongside init
|
|
132
|
+
aiongside work new <title>
|
|
133
|
+
aiongside work confirm <id> <checks...>
|
|
134
|
+
aiongside work move <id> <status> --dry-run --json
|
|
135
|
+
aiongside work move <id> <status> [transition options]
|
|
136
|
+
aiongside work needs add <id> <dependency-id>
|
|
137
|
+
aiongside work needs remove <id> <dependency-id>
|
|
138
|
+
aiongside work cancel <id> --cancellation-reason <text>
|
|
139
|
+
aiongside work discard <id> --dry-run
|
|
140
|
+
aiongside view rebuild
|
|
141
|
+
aiongside check
|
|
142
|
+
```
|
|
143
|
+
|
|
144
|
+
## Development
|
|
145
|
+
|
|
146
|
+
```sh
|
|
147
|
+
bun run check
|
|
148
|
+
bun run package:check
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
Node.js 22 and 24 are supported. Development uses Node.js 24.
|
|
152
|
+
|
|
153
|
+
Publishing requires an npm owner for `aiongside` and an npm Trusted Publisher restricted to `moseoh/aiongside` and `.github/workflows/publish.yml`. A published GitHub Release must use a tag that exactly matches `v<package-version>`. The release workflow rejects version mismatches, existing npm versions, package validation failures, and Node.js 22 or 24 smoke-test failures before publishing.
|
|
154
|
+
|
|
155
|
+
## License
|
|
156
|
+
|
|
157
|
+
[MIT](LICENSE)
|