138 lines
8.1 KiB
Markdown
138 lines
8.1 KiB
Markdown
# Capella behavior creation study — 2026-09-10
|
||
|
||
Codex-9e8r6t /root/palette_finish. Bounded native reference study under the
|
||
revised PROJECT_GOAL; this is product evidence, not Studio acceptance.
|
||
|
||
## Environment and limits
|
||
|
||
Used the installed Capella 7.1 executable
|
||
`C:\Users\User\capella-7.1.0.202606231255-win32-win32-x86_64\capella\capella.exe`
|
||
through the Computer Use skill and `@oai/sky` only. Root granted exclusive native
|
||
input and closed its saved Studio instance first. Launch was 18:42 UTC; final
|
||
save and clean close were 18:56 UTC. Startup/project initialization consumed
|
||
several minutes and briefly showed Windows Not Responding. No helper/user stop
|
||
occurred. Fresh `sky.list_windows()` after Alt+F4 confirmed no Capella windows;
|
||
the input lease was explicitly released to root.
|
||
|
||
Selected actual returned launcher window 4326384 and workbench 3146748. Used
|
||
new workspace `.local/capella-creation-20260910`, native-created project
|
||
`Local Behavior Creation`, at 1010 × 760. Existing models were not opened or
|
||
changed. Screenshots were inspected as Computer Use tool evidence; no separate
|
||
screenshot archive is claimed. Saved XML provides independent semantic evidence.
|
||
No Studio production edits, Cargo runs, or unrelated product evaluation.
|
||
|
||
## Observed creation workflows
|
||
|
||
1. Project workflow → Operational Analysis → **Define Operational Activities
|
||
and describe Interactions** exposed three explicit task links: OABD activity
|
||
breakdown, OAIB activity interaction, and OAS activity scenario. Selecting
|
||
OAS opened **New Activity Scenario**, with one Name field defaulting to
|
||
`[OAS] OperationalCapability 1`. Entering `Dispatch response` and accepting
|
||
opened that scenario. Viewpoint was selected through the named entry point,
|
||
before naming; no general element catalog or secondary viewpoint picker was
|
||
required. The project became dirty before the Name dialog was accepted.
|
||
Saved XML confirms an automatically created OperationalCapability owns the
|
||
scenario. Cancellation side effects were not tested.
|
||
|
||
2. Inside the empty OAS, **Activities** followed by a canvas click opened a
|
||
**Transfer Dialog / Selection Wizard** with an eligible Operational Activities
|
||
tree, search fields, Available and Selected panes, and transfer arrows.
|
||
It contained Root Operational Activity in this fresh model. The dialog was
|
||
canceled. **Activity**, then a canvas point, instead created a new activity
|
||
and its visible lifeline without leaving the scenario. Saving confirmed
|
||
distinct Activity and InstanceRole identities and the representedInstance
|
||
reference. The new activity also acquired an explicit capability involvement.
|
||
This is stronger evidence than a tooltip alone for local missing-source
|
||
creation. Reusing an existing source through the transfer dialog was observed
|
||
up to selection UI, not completed in this pass.
|
||
|
||
3. System Analysis → **Refine System Functions, describe Functional Exchanges**
|
||
exposed SFBD functional breakdown, SDFB functional dataflow, and FS functional
|
||
scenario. FS opened **New Function Scenario** with default `[FS] Capability 1`;
|
||
accepting opened a functional scenario. Its palette contained **System
|
||
Function**, **Functions**, and functional exchange tools, corresponding to
|
||
the selected function viewpoint. XML confirms kind FUNCTIONAL under a new
|
||
Capability. Component/entity/interface viewpoints were not exercised here.
|
||
|
||
4. SDFB opened a Name dialog defaulting to `[SDFB] Root System Function`. Its
|
||
palette exposed Functions, Functional Exchanges, and Functional Chains as
|
||
insertion tools. The Functions tooltip explicitly distinguishes graphical
|
||
removal from deleting a semantic function. Accelerator choices included
|
||
Elements from Scenario and Functional Chain Elements; these were read, not
|
||
executed.
|
||
|
||
5. From that dataflow diagram, **F8 / Show in Project Explorer** revealed the
|
||
root System Function. Its context menu **Add Capella Element → Functional
|
||
Chain** created `FunctionalChain 1` immediately. Renamed it `Dispatch chain`.
|
||
On the chain, **New Diagram / Table → Functional Chain Description** opened
|
||
a second Name dialog with default `[SFCD] Dispatch chain`; accepting opened
|
||
the chain workspace. Thus the exercised path involved separate semantic
|
||
creation, naming, and first representation creation. It was an owner-filtered
|
||
menu, not a global type catalog, but still a substantial detour from the canvas.
|
||
|
||
6. In SFCD, **Function** under Involvements had the tooltip “Creates a new
|
||
Involvement Function referencing the selected Function.” A canvas point
|
||
opened **Select a Function to involve in Dispatch chain** with a filtered
|
||
System Functions tree/search. There was no visible Create new source action
|
||
in this picker. Canceled without adding an involvement. Other local tools
|
||
included Exchange, Exchange and Function, AND, AND Construct, Sequence Link,
|
||
and Function on Sequence Link. Their execution was outside this timebox.
|
||
|
||
## Saved evidence
|
||
|
||
Files remain in
|
||
`.local/capella-creation-20260910/Local Behavior Creation/`.
|
||
|
||
| Saved record | Identity / meaning |
|
||
| --- | --- |
|
||
| OperationalCapability 1 | `69d805a8-8a2f-4218-88f0-566bf0923e7f` |
|
||
| Dispatch response | `b8de31f0-378e-423a-855c-eba3551ca645`, INTERACTION, owned by that capability |
|
||
| OperationalActivity 1 | `30f0691c-a6d7-422d-abf2-fa1746e1b92b` |
|
||
| InstanceRole | `f1b80b8b-7770-4b9d-aad7-0eb8da9be902`, represents that activity |
|
||
| Capability involvement | `b9a781c1-ee73-49e0-a6ec-10d838f2b613`, involved activity reference |
|
||
| Root System Function | `92c6eca2-6fcb-43d9-baa1-bd7b26e633f0` |
|
||
| Dispatch chain | `4ae2255c-4c80-4173-b7f4-b5da43fafe97`, FunctionalChain owned by root function |
|
||
| Capability 1 | `41ef1a86-f1b8-4c62-9ad3-19357d622b04` |
|
||
| [FS] Capability 1 | `693543b9-e3f4-4fa1-a44c-efc5683f9d14`, FUNCTIONAL under Capability 1 |
|
||
|
||
Final SHA256:
|
||
|
||
- `Local Behavior Creation.capella`:
|
||
`829f7faa99907c1efd826c79289bd2a7f795cdab557ec91f3a7e13ddb93417e1`.
|
||
- `Local Behavior Creation.aird`:
|
||
`354a74cfac5abe29188f3b644e79f84af6136fc67f968be43b4f4c663c0392a8`.
|
||
|
||
## Proposed Studio application, distinguished from observations
|
||
|
||
Preferred alternative: one compact **New behavior** entry with a small set of
|
||
task choices; show only relevant name, viewpoint and ownership/context fields.
|
||
For a scenario, explicitly distinguish OA activities/entities and SA
|
||
functions/components. A task entry can preselect the appropriate viewpoint,
|
||
but the choice must stay visible. Starting a named process/chain should open its
|
||
authoring workspace directly after one validated command batch. A first view
|
||
can be explicit where the model separates it. Do not copy Capella's implicit
|
||
capability creation or its owner hierarchy into Studio: Studio's admitted
|
||
ownership and optional semantic context are authoritative.
|
||
|
||
Within scenario or chain authoring, a compact **Use existing / Create new**
|
||
source choice can preserve work context and filter candidates by layer and
|
||
viewpoint. The existing-source action must state that it creates a lifeline or
|
||
involvement referencing the source. New source creation should be explicit about
|
||
the source type and valid owner, preserve the pending authoring intent, and
|
||
return directly to it. Capella's exercised OAS provides evidence for this local
|
||
creation path; adding it to the chain picker is a proposed improvement.
|
||
|
||
A viable lower-complexity alternative is a contextual **Create missing source**
|
||
action that suspends and restores the current draft using the existing source
|
||
editor. It avoids duplicating field editors but requires reliable focus, raw
|
||
draft recovery and exact cancellation/history behavior. A single searchable
|
||
global command catalog remains useful for expert discovery; making it the only
|
||
creation route would retain the detour observed in current Studio.
|
||
|
||
Key findings were delivered directly to /root/release_audit while that worker
|
||
owned `behavior/creation.rs` and tests. OA process creation itself, component
|
||
viewpoints, completed source reuse, chain involvement persistence, and recovery/
|
||
Undo/Redo were not exercised in this bounded study; do not infer their success
|
||
from these observations. The current Studio workflow still requires its own
|
||
automated and native acceptance.
|