@rlabs-cl/arketum 0.0.0-stage → 1.0.1
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/CHANGELOG.md +140 -0
- package/LICENSE +42 -0
- package/README.md +67 -2
- package/THIRD-PARTY-NOTICES +2428 -0
- package/catalogo-de-ejemplo/agentes.yaml +11 -0
- package/catalogo-de-ejemplo/arquetipos/ajuste.yaml +54 -0
- package/catalogo-de-ejemplo/arquetipos/arquetipo-autor.yaml +72 -0
- package/catalogo-de-ejemplo/arquetipos/arquitectura-de-sistema.yaml +72 -0
- package/catalogo-de-ejemplo/arquetipos/despliegue-compose.yaml +104 -0
- package/catalogo-de-ejemplo/arquetipos/digestion.yaml +97 -0
- package/catalogo-de-ejemplo/arquetipos/documento-academico.yaml +131 -0
- package/catalogo-de-ejemplo/arquetipos/inventario-funcional.yaml +42 -0
- package/catalogo-de-ejemplo/arquetipos/levantamiento-de-infraestructura.yaml +117 -0
- package/catalogo-de-ejemplo/arquetipos/plan-de-migracion.yaml +40 -0
- package/catalogo-de-ejemplo/arquetipos/prd.yaml +62 -0
- package/catalogo-de-ejemplo/arquetipos/radio-de-alcance.yaml +141 -0
- package/catalogo-de-ejemplo/arquetipos/rca.yaml +68 -0
- package/catalogo-de-ejemplo/arquetipos/servicio-con-integracion.yaml +154 -0
- package/catalogo-de-ejemplo/carriles/ajuste.yaml +14 -0
- package/catalogo-de-ejemplo/carriles/arquetipo.yaml +13 -0
- package/catalogo-de-ejemplo/carriles/comprobacion.yaml +23 -0
- package/catalogo-de-ejemplo/carriles/correccion.yaml +25 -0
- package/catalogo-de-ejemplo/carriles/despliegue.yaml +36 -0
- package/catalogo-de-ejemplo/carriles/digestion.yaml +14 -0
- package/catalogo-de-ejemplo/carriles/funcionalidad.yaml +34 -0
- package/catalogo-de-ejemplo/carriles/migracion.yaml +27 -0
- package/catalogo-de-ejemplo/carriles/nuevo.yaml +30 -0
- package/catalogo-de-ejemplo/formas/aplicacion-por-capas.yaml +185 -0
- package/catalogo-de-ejemplo/formas/juego-terminal.yaml +161 -0
- package/catalogo-de-ejemplo/formas/monorepo-de-aplicaciones.yaml +207 -0
- package/catalogo-de-ejemplo/incluido.yaml +3 -0
- package/catalogo-de-ejemplo/stacks/go/e2e-terminal/e2e_http.py +36 -0
- package/catalogo-de-ejemplo/stacks/go/e2e-terminal/pytest.ini +5 -0
- package/catalogo-de-ejemplo/stacks/go/e2e-terminal/requirements.txt +2 -0
- package/catalogo-de-ejemplo/stacks/go/e2e-terminal/terminal_e2e.py +112 -0
- package/catalogo-de-ejemplo/stacks/go/e2e-terminal/terminal_prueba.py +118 -0
- package/catalogo-de-ejemplo/stacks/go/suelo-aplicacion-por-capas/requirements.txt +1 -0
- package/catalogo-de-ejemplo/stacks/go/suelo-aplicacion-por-capas/suelo.py +102 -0
- package/catalogo-de-ejemplo/stacks/go/suelo-aplicacion-por-capas/terminal_prueba.py +118 -0
- package/catalogo-de-ejemplo/stacks/go/suelo-juego-terminal/requirements.txt +1 -0
- package/catalogo-de-ejemplo/stacks/go/suelo-juego-terminal/suelo.py +86 -0
- package/catalogo-de-ejemplo/stacks/go/suelo-juego-terminal/terminal_prueba.py +118 -0
- package/catalogo-de-ejemplo/stacks/go.yaml +74 -0
- package/catalogo-de-ejemplo/stacks/python/e2e-terminal/e2e_http.py +36 -0
- package/catalogo-de-ejemplo/stacks/python/e2e-terminal/pytest.ini +5 -0
- package/catalogo-de-ejemplo/stacks/python/e2e-terminal/requirements.txt +2 -0
- package/catalogo-de-ejemplo/stacks/python/e2e-terminal/terminal_e2e.py +112 -0
- package/catalogo-de-ejemplo/stacks/python/e2e-terminal/terminal_prueba.py +118 -0
- package/catalogo-de-ejemplo/stacks/python/suelo-aplicacion-por-capas/requirements.txt +1 -0
- package/catalogo-de-ejemplo/stacks/python/suelo-aplicacion-por-capas/suelo.py +102 -0
- package/catalogo-de-ejemplo/stacks/python/suelo-aplicacion-por-capas/terminal_prueba.py +118 -0
- package/catalogo-de-ejemplo/stacks/python/suelo-juego-terminal/requirements.txt +1 -0
- package/catalogo-de-ejemplo/stacks/python/suelo-juego-terminal/suelo.py +86 -0
- package/catalogo-de-ejemplo/stacks/python/suelo-juego-terminal/terminal_prueba.py +118 -0
- package/catalogo-de-ejemplo/stacks/python.yaml +167 -0
- package/catalogo-de-ejemplo/stacks/typescript/e2e-node/app.mjs +182 -0
- package/catalogo-de-ejemplo/stacks/typescript/e2e-node/requirements.txt +1 -0
- package/catalogo-de-ejemplo/stacks/typescript/e2e-node/terminal_prueba.py +118 -0
- package/catalogo-de-ejemplo/stacks/typescript/e2e-node/terminal_puente.py +51 -0
- package/catalogo-de-ejemplo/stacks/typescript/e2e-node/vitest.config.mjs +12 -0
- package/catalogo-de-ejemplo/stacks/typescript/suelo-aplicacion-por-capas/requirements.txt +1 -0
- package/catalogo-de-ejemplo/stacks/typescript/suelo-aplicacion-por-capas/suelo.py +102 -0
- package/catalogo-de-ejemplo/stacks/typescript/suelo-aplicacion-por-capas/terminal_prueba.py +118 -0
- package/catalogo-de-ejemplo/stacks/typescript/suelo-juego-terminal/requirements.txt +1 -0
- package/catalogo-de-ejemplo/stacks/typescript/suelo-juego-terminal/suelo.py +86 -0
- package/catalogo-de-ejemplo/stacks/typescript/suelo-juego-terminal/terminal_prueba.py +118 -0
- package/catalogo-de-ejemplo/stacks/typescript.yaml +88 -0
- package/dist/mcp/arketum.js +3 -0
- package/dist/mcp/ci-cli.js +2 -0
- package/dist/mcp/cli.js +2 -0
- package/dist/mcp/comun-ZEXDDERM.js +1 -0
- package/dist/mcp/comun-ZTEHRDHC.js +1 -0
- package/dist/mcp/panel-cli.js +2 -0
- package/dist/mcp/telemetria-cli.js +1 -0
- package/package.json +33 -4
- package/server.json +15 -0
- package/telemetria.json +27 -0
package/CHANGELOG.md
ADDED
|
@@ -0,0 +1,140 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
Every published version of Arketum has an entry here with what changes for the
|
|
4
|
+
people who use it. Changes accumulate under `## Unreleased` as they are made and
|
|
5
|
+
move to the version's own section when it is published.
|
|
6
|
+
|
|
7
|
+
If a version changes the store format (the `.arketum/` folder), its entry says
|
|
8
|
+
the new format version and that the store has to be updated with the update
|
|
9
|
+
action (`action: actualizar_almacen`).
|
|
10
|
+
|
|
11
|
+
Versions follow semver: a fix bumps the patch, something new bumps the minor,
|
|
12
|
+
and a new store format or a renamed action bumps the major.
|
|
13
|
+
|
|
14
|
+
## Unreleased
|
|
15
|
+
|
|
16
|
+
## 1.0.1
|
|
17
|
+
|
|
18
|
+
### Fixes
|
|
19
|
+
|
|
20
|
+
- **License text.** The `LICENSE` shipped in 1.0.0 still opened with a draft
|
|
21
|
+
notice; it now carries only the license itself. The terms do not change.
|
|
22
|
+
|
|
23
|
+
## 1.0.0 — Initial release
|
|
24
|
+
|
|
25
|
+
The first public version. Arketum is an MCP server with a single tool, `build`,
|
|
26
|
+
that governs the lifecycle of software built with agents, from the request to a
|
|
27
|
+
verified close. The agent calls it at every step; each answer says where the
|
|
28
|
+
work stands, what comes next and with what context. Arketum runs nothing and
|
|
29
|
+
calls no model: it suggests, checks what it receives and records the person's
|
|
30
|
+
decisions with their provenance. Apart from the anonymous telemetry the person
|
|
31
|
+
opts into, it makes no network requests.
|
|
32
|
+
|
|
33
|
+
### Features
|
|
34
|
+
|
|
35
|
+
- **Projects** declared in `.arketum/proyecto.yaml`: the system's artifacts, each
|
|
36
|
+
with its archetype (or its stack and component), its root and its
|
|
37
|
+
dependencies; the declared scaffolding; the input documents; the catalogs and
|
|
38
|
+
the system shape.
|
|
39
|
+
- **Catalogs** from which archetypes, lanes, system shapes and stacks are
|
|
40
|
+
resolved by name: the project's own, personal ones and the bundled example
|
|
41
|
+
catalog, named rather than located (`{ incluido: ejemplo }`). No archetype
|
|
42
|
+
lives in Arketum's code.
|
|
43
|
+
- **Work units and lanes.** Every piece of work is a unit with a lane, a goal,
|
|
44
|
+
the chosen steps and, when it applies, a milestone (a deployment, a delivery or
|
|
45
|
+
a run). The example catalog brings the lanes `nuevo`, `funcionalidad`,
|
|
46
|
+
`ajuste`, `comprobacion`, `correccion`, `arquetipo`, `migracion`, `digestion`
|
|
47
|
+
and `despliegue`.
|
|
48
|
+
- **Gates decided by the person.** The person approves, adjusts or rejects what
|
|
49
|
+
is theirs: what gets built, clashes with what was already decided, the
|
|
50
|
+
deployment and, at the end of each unit, whether it turned out as wanted. Gates
|
|
51
|
+
reach the person through a form when the client supports it, through the chat
|
|
52
|
+
otherwise, and every decision records its channel and when it was made.
|
|
53
|
+
Process gates can be delegated, with or without a limit of units.
|
|
54
|
+
- **Requirements with versions and states**: functional, technical and decision
|
|
55
|
+
requirements, each with a short stable id, its statement, its acceptance
|
|
56
|
+
criterion and its version. The requirements index and the living PRD are
|
|
57
|
+
computed from the decisions stored one file per decision.
|
|
58
|
+
- **Descent of artifacts.** Each touched artifact is built from the general to
|
|
59
|
+
the particular, level by level (`L0` to at most `L4`), with coverage,
|
|
60
|
+
justification, granularity and archetype conformance checked at every step,
|
|
61
|
+
and fidelity to the file tree at the last one.
|
|
62
|
+
- **Evidence.** Executions, reports and declarations back each step; execution
|
|
63
|
+
evidence links the requirements it satisfies. When the system shape asks for
|
|
64
|
+
it, the floor checks and the full end-to-end suite are run through the real
|
|
65
|
+
path, with fixtures copied verbatim from the catalog.
|
|
66
|
+
- **Closing conditions.** Closing re-delivers every descent against the current
|
|
67
|
+
archetype and tree and checks the conditions; the project policy is fixed when
|
|
68
|
+
a unit starts, so whatever is edited by hand to close is not whitewashed.
|
|
69
|
+
- **Retroactive validation.** Closing a unit with its own requirements contrasts
|
|
70
|
+
what was built with the earlier requirements it touches: contradicted,
|
|
71
|
+
redundant, mergeable or obsolete.
|
|
72
|
+
- **Drift.** The status contrasts the tree with what was declared and names each
|
|
73
|
+
finding with its suggestion (legalize it through a gate or correct it with a
|
|
74
|
+
unit); functional drift re-runs the evidence copied from the requirements.
|
|
75
|
+
- **The person's panel**: a local web page (one per machine, on `127.0.0.1`)
|
|
76
|
+
with the state of each project, where the person sees what is waiting and
|
|
77
|
+
decides it.
|
|
78
|
+
- **The batch** (`tanda`): everything waiting for the person in the project,
|
|
79
|
+
gathered in one place: blocked units first, then gates, confirmations and
|
|
80
|
+
declarations.
|
|
81
|
+
- **Topics** (`tema`): what is left to talk about, in the person's own words or
|
|
82
|
+
proposed by the agent, optionally with the unit that would address it.
|
|
83
|
+
- **Audit**: on request, it groups requirements that pursue the same intention
|
|
84
|
+
and proposes a consolidated PRD as a topic; the gaps and drifts Arketum
|
|
85
|
+
computes become topics with their proposal.
|
|
86
|
+
- **Parallel or sequential work**: while a subagent builds what is ready, the
|
|
87
|
+
person keeps defining what comes next; a unit that cannot go on without the
|
|
88
|
+
person is marked blocked with its reason, without interrupting.
|
|
89
|
+
- **CI**: `arketum ci` re-runs the recorded evidence of the units a change
|
|
90
|
+
touches and re-checks their close.
|
|
91
|
+
- **Store format 1.** `.arketum/format.yaml` declares the store format version
|
|
92
|
+
(`version: 1`), written by Arketum. A store with a newer format than the one
|
|
93
|
+
Arketum knows is neither read nor written: every action, the status and the
|
|
94
|
+
panel refuse it and ask to update Arketum. `action: actualizar_almacen`
|
|
95
|
+
updates a store to the current format.
|
|
96
|
+
- **Anonymous usage telemetry, only if the person accepts.** Until the
|
|
97
|
+
installation decides, the question waits among the person's pending items (the
|
|
98
|
+
batch, the panel and the status), and the agent is asked once to put it to
|
|
99
|
+
them in the chat; it is answered in the chat (`action: telemetria` with
|
|
100
|
+
`acepta` and `cita`), the batch, the panel or the terminal
|
|
101
|
+
(`arketum telemetria --acepto` / `--no`), and once decided it is never asked
|
|
102
|
+
again. The decision is kept in `~/.arketum/`. Accepted, at most one summary a
|
|
103
|
+
day is sent after answering, with a 2-second limit and no retries: the
|
|
104
|
+
version, the install channel, the operating system family, the MCP client's
|
|
105
|
+
declared name, how many projects and days of use, and per project (by a hash
|
|
106
|
+
that cannot be reversed) its units per lane, its gates per channel with their
|
|
107
|
+
median wait and its topics. Never any text, path or name, and each event asks
|
|
108
|
+
the receiving service not to derive a location from the connection nor build
|
|
109
|
+
a person profile. `arketum telemetria` prints exactly what would be sent,
|
|
110
|
+
`--probar` sends one test event and says whether it arrived, and
|
|
111
|
+
`ARKETUM_TELEMETRIA=0` turns it off. It is the only thing that leaves the
|
|
112
|
+
machine; the destination is declared by the distribution, and a build without
|
|
113
|
+
it sends nothing.
|
|
114
|
+
|
|
115
|
+
### Flows
|
|
116
|
+
|
|
117
|
+
1. **Start.** Without `.arketum/`, any call returns how to start for that
|
|
118
|
+
folder: an empty folder opens a `nuevo` unit; a folder with only documents
|
|
119
|
+
starts from them as the project's base; a folder with code opens a
|
|
120
|
+
`digestion` unit that proposes the base structure for the person to confirm.
|
|
121
|
+
2. **Situate and open.** The agent classifies the request against the
|
|
122
|
+
requirements index and opens a unit with a lane and a goal; the person
|
|
123
|
+
confirms the lane and its steps, and Arketum takes a snapshot of the tree.
|
|
124
|
+
3. **Phase 1, elicitation.** The analyst (talks with the person) and the
|
|
125
|
+
architect (deduces the technical side) hand in their parts; the person
|
|
126
|
+
confirms in the PRD gate what will be done.
|
|
127
|
+
4. **Phase 2, implementation.** Architecture, the descent of each touched
|
|
128
|
+
artifact and the execution evidence, with the implementation roles the
|
|
129
|
+
system shape suggests.
|
|
130
|
+
5. **Small changes** go through the `ajuste` lane: the person's literal request,
|
|
131
|
+
a short radius and the inherited descent, with its size measured by Arketum.
|
|
132
|
+
6. **Deploy.** The `despliegue` lane starts with an infrastructure survey; what
|
|
133
|
+
the person has to obtain outside the session becomes a questionnaire, and the
|
|
134
|
+
deployment milestone is met when the person confirms it was deployed and ran.
|
|
135
|
+
Arketum never stores a secret, only its reference.
|
|
136
|
+
7. **Close**, with the closing conditions, the boundaries of each artifact and
|
|
137
|
+
the retroactive validation; then the person confirms whether it is what they
|
|
138
|
+
wanted.
|
|
139
|
+
8. **Keep going**: status, drift, the batch, topics and the audit, from the
|
|
140
|
+
agent or from the panel.
|
package/LICENSE
ADDED
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
LICENCIA DE USO DE ARKETUM
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 rlabs-cl. Todos los derechos reservados.
|
|
4
|
+
|
|
5
|
+
Arketum (el «Software») es software propietario de rlabs-cl. Esta licencia no
|
|
6
|
+
es una licencia de código abierto.
|
|
7
|
+
|
|
8
|
+
1. Concesión. rlabs-cl concede a quien recibe el Software, de forma no
|
|
9
|
+
exclusiva, intransferible y revocable, el derecho a instalarlo y usarlo, tal
|
|
10
|
+
como se distribuye, para su propio trabajo.
|
|
11
|
+
|
|
12
|
+
2. Lo que no se concede. Salvo autorización previa y por escrito de rlabs-cl,
|
|
13
|
+
no se concede el derecho a:
|
|
14
|
+
a) copiar el Software, salvo lo necesario para instalarlo y usarlo;
|
|
15
|
+
b) modificarlo, adaptarlo, traducirlo o crear obras derivadas de él;
|
|
16
|
+
c) redistribuirlo, publicarlo, venderlo, alquilarlo, prestarlo o ponerlo a
|
|
17
|
+
disposición de terceros, con o sin modificaciones;
|
|
18
|
+
d) descompilarlo, desensamblarlo o aplicarle ingeniería inversa, salvo en la
|
|
19
|
+
medida en que la ley aplicable lo permita expresamente pese a esta
|
|
20
|
+
limitación;
|
|
21
|
+
e) sublicenciarlo, ni ceder los derechos de esta licencia.
|
|
22
|
+
|
|
23
|
+
3. Componentes de terceros. El Software incluye componentes de terceros que se
|
|
24
|
+
rigen por sus propias licencias, recogidas en el fichero
|
|
25
|
+
THIRD-PARTY-NOTICES que lo acompaña. Esta licencia no limita los derechos
|
|
26
|
+
que esas licencias conceden sobre esos componentes.
|
|
27
|
+
|
|
28
|
+
4. Avisos. No se pueden quitar ni alterar los avisos de derechos de autor, de
|
|
29
|
+
esta licencia ni de THIRD-PARTY-NOTICES.
|
|
30
|
+
|
|
31
|
+
5. Sin garantía. EL SOFTWARE SE ENTREGA «TAL CUAL», SIN GARANTÍA DE NINGÚN
|
|
32
|
+
TIPO, EXPRESA O IMPLÍCITA, INCLUIDAS, SIN LIMITARSE A ELLAS, LAS DE
|
|
33
|
+
COMERCIABILIDAD, IDONEIDAD PARA UN FIN DETERMINADO Y NO INFRACCIÓN.
|
|
34
|
+
|
|
35
|
+
6. Limitación de responsabilidad. EN NINGÚN CASO rlabs-cl SERÁ RESPONSABLE DE
|
|
36
|
+
RECLAMACIONES, DAÑOS U OTRAS RESPONSABILIDADES, YA SEA POR CONTRATO, ACTO
|
|
37
|
+
ILÍCITO O DE OTRO MODO, QUE SURJAN DEL SOFTWARE, DE SU USO O DE OTRAS
|
|
38
|
+
OPERACIONES CON ÉL.
|
|
39
|
+
|
|
40
|
+
7. Terminación. Esta licencia termina sin aviso si se incumple cualquiera de
|
|
41
|
+
sus términos. Al terminar, hay que dejar de usar el Software y borrar las
|
|
42
|
+
copias que se tengan.
|
package/README.md
CHANGED
|
@@ -1,3 +1,68 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Arketum
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
**A verified lifecycle for software built with agents: from the request to a verified close.**
|
|
4
|
+
|
|
5
|
+
Arketum is an MCP server with a single tool, `build`. The agent calls it at every step; each answer says where the work stands, what comes next and with what context. Arketum runs nothing and calls no model: it suggests what to do, checks what it receives and records the person's decisions with their provenance.
|
|
6
|
+
|
|
7
|
+
What it ensures:
|
|
8
|
+
|
|
9
|
+
- what gets built answers what was asked, and the person confirms what will be done before it is built;
|
|
10
|
+
- every artifact is built from the general to the particular, checking coverage, justification, granularity and conformance to its archetype at each step, and faithful to the file tree;
|
|
11
|
+
- every file in the project is claimed by an archetype or is declared scaffolding, and no change escapes what the unit declared;
|
|
12
|
+
- requirements have versions and states, and every change is tied to one.
|
|
13
|
+
|
|
14
|
+
What it does not ensure: that the decisions are good. Checking that a decision was respected can be automated; judging its merit cannot.
|
|
15
|
+
|
|
16
|
+
## Install
|
|
17
|
+
|
|
18
|
+
Node.js 20 or later. Register this command as a stdio MCP server in your client:
|
|
19
|
+
|
|
20
|
+
```bash
|
|
21
|
+
npx -y @rlabs-cl/arketum
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
For example, in Claude Code:
|
|
25
|
+
|
|
26
|
+
```bash
|
|
27
|
+
claude mcp add --scope user arketum -- npx -y @rlabs-cl/arketum
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
Or in any MCP client:
|
|
31
|
+
|
|
32
|
+
```json
|
|
33
|
+
{
|
|
34
|
+
"mcpServers": {
|
|
35
|
+
"arketum": { "command": "npx", "args": ["-y", "@rlabs-cl/arketum"] }
|
|
36
|
+
}
|
|
37
|
+
}
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
Installed globally (`npm install -g @rlabs-cl/arketum`), the `arketum` executable is the same server; `arketum ci …` re-runs the recorded evidence of units in CI and `arketum panel …` starts the local status panel (one per machine, on `127.0.0.1`).
|
|
41
|
+
|
|
42
|
+
If your client cannot show forms to the person (elicitation), set `ARKETUM_GATES=chat` and the agent will ask the gate decisions in the chat.
|
|
43
|
+
|
|
44
|
+
## How it works
|
|
45
|
+
|
|
46
|
+
1. **Start.** In an empty folder, an existing project or a folder with only documents, the first call returns how to start: the minimal `.arketum/proyecto.yaml` and the first unit to open.
|
|
47
|
+
2. **Open a unit** with a lane (new project, feature, small fix, correction, deployment…) and a goal; the person confirms the lane and its steps.
|
|
48
|
+
3. **Phase 1, elicitation.** An analyst (talks with the person) and an architect (deduces the technical side) build the PRD; the person approves what will be built.
|
|
49
|
+
4. **Phase 2, implementation.** Each touched artifact descends its ladder level by level, and execution evidence links the requirements it satisfies.
|
|
50
|
+
5. **Close.** Arketum re-checks every descent against the current archetype and tree, and the closing conditions.
|
|
51
|
+
|
|
52
|
+
The person is asked what is theirs to decide; the process steps can be delegated. Everything Arketum remembers lives as plain text in the project's `.arketum/` folder.
|
|
53
|
+
|
|
54
|
+
What changes in each version, and the store format version it knows, is in `CHANGELOG.md`. Arketum's own messages are in Spanish for now.
|
|
55
|
+
|
|
56
|
+
## What it sends
|
|
57
|
+
|
|
58
|
+
Only if you accept: an anonymous usage summary, at most once a day. Until you decide, the question waits among your pending items (in the batch, the panel and the status), and your agent can ask you in the chat; without an answer, or with a no, nothing is counted or sent. Once you decide, it is never asked again. To opt in from your terminal:
|
|
59
|
+
|
|
60
|
+
```sh
|
|
61
|
+
arketum telemetria --acepto
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
The summary says the version, how it was installed, the operating system family, the name your MCP client declares, how many projects and days it was used and, per project (identified only by a hash that cannot be reversed), its units per lane, its gates per channel with how long they waited for you, and how many topics are open and closed. It never carries any text, path, name or code, and it asks the receiving service not to derive your location from the connection and not to build a person profile. `arketum telemetria` prints exactly what would be sent, `arketum telemetria --probar` sends one test event and tells you whether it arrived, `arketum telemetria --no` stops it, and `ARKETUM_TELEMETRIA=0` turns it off on this machine whatever was decided. Everything else stays on your machine.
|
|
65
|
+
|
|
66
|
+
## License
|
|
67
|
+
|
|
68
|
+
Proprietary software of rlabs-cl: you may use it, but not copy, modify, redistribute, decompile or sublicense its code; it comes without warranty. See `LICENSE`. Third-party dependencies are governed by their own licenses, listed in `THIRD-PARTY-NOTICES`.
|