You picked the thin tree with a panel at the bottom, and you said why: two parts, one for the model and one for the drawings, except now the model leads. Only the drawings of the thing you selected are shown, which gives it air. The file the thing lives in is written out in full.
★This is the fourth version. The third was read line by line against the SysML specification and against the tool's own code by someone who did not write it, and nine things it claimed were wrong. They are corrected below, and every one of them is marked.
★ marks what changed after an independent review on 6 August 2026. Every starred sentence, row, caption or list item is new or rewritten because of that review. Nothing else on the page was touched, so a star always means look here.
ONE THING ON THIS PAGE NO LONGER SHIPS: the Open icon drawn on every file row. It was removed on 8 August 2026 on the owner's instruction — "I always end up in the same view. To me those buttons should not exist. Remove them." Every file row and path line below still draws it; read them as one icon short. Copy path is unchanged, and everything else on the page is as built.
It was not mis-wired: each row handed its own file to the ordinary open. It was aimed at the wrong thing. You select an element and press a control that can only take you to a file — and on the shipped course model, ten of sixteen packages declare no member of their own, so the index names the same file for all of them and every press landed on the same front page. The behaviour worth having here is a reveal: go to the board of the thing you selected. It does not exist yet.
You clicked a thing in the tree. The panel underneath tells you the two things you always want to know about it: which file it is written in, and which drawings of it you have saved. Here it is with two drawings, which is the ordinary case.
The 2 on the tree row is the count of those drawings. It is the only thing the tree gained, and it is what lets you see which parts of the model have been drawn without clicking any of them.
This is what you see almost all the time. The rest of this page is what changes when something is different — when the thing has no drawings, when you select the model instead of a part, when you click that blue file name, when the model is brand new, or when you want to add something.
One thing that is not on this screen: imports. ★An import belongs to the namespace it is written in, and it is written in one particular file. The Explorer lets you read and edit imports on the file, so that there is never any doubt which file a line is in — one click away, on the blue name above. That click is drawn further down, before and after, because you said you could not tell when imports were supposed to appear.
Still in force from your first review: no Files section anywhere · icons and never words in the panel body · imports on files rather than packages · the file chosen first when creating a namespace, offering only the namespaces inside it · three kinds of namespace · searchable pickers instead of long lists.
★None of it changes the shape you chose. All of it changes something the page said that was not true, and one of them changes what you should fund first.
.kerml files exist. The tool has always read them and the page never drew one. It does now.The Renderings section at the top is gone. The tree carries the model and nothing else — one line per thing, no drawings nested inside it, no file names fighting the element names for room. Everything about the selected row appears underneath, always in the same place, with room for real buttons.
A small number on a row says how many saved drawings that thing has, so you can still see at a glance which parts of the model have been drawn. That number is the only thing the tree gains.
★Two counts can appear on a tree row, and they are drawn so they can never be confused. Drawings are a filled blue pill of bare digits — 2 — and they can sit on anything. Files are a dashed grey chip that always carries a small page, 10, and only a package or the model ever has one. Same corner of the row, deliberately different object: the old page drew both as the same badge, so 10 files and 10 drawings read identically.
Rule one — a package is not a file. In your pilot the package CrisisResponse is opened in ten files; every file in the model reopens it to add its own part. So a package row can never show one file name and be telling the truth, and a new namespace has to answer in which file. ★It is also why imports are edited on a file: an import is owned by a namespace and written in a particular file, and since the same namespace is reopened in ten files, only the file can say without ambiguity which line you are about to change.
Rule two — one tree, one panel, and nothing else standing. The tree shows the model. It never shows storage. Anything that is not a piece of your model — a file, a folder, a drawing — appears only in the panel, only when something you selected mentions it. This is the rule your review added, and it is the reason this shape won in the first place.
Removed, from every screen. A permanent Files list was a second column of names competing with the model for the same eye and the same vertical room, and it listed storage next to meaning. Here is what replaces it.
Normally the panel's subject is the tree row you selected. But every file name written in the panel is a place you can go. Click one and the file becomes the subject, with a chevron back to where you came from. The tree does not move and nothing expands — you have not left the model, you have looked at one of its files for a moment.
That gives three doors to a file, and each one appears exactly where you already wanted it:
CrisisResponse, one for a package written in a single place..sysml and every .kerml under the model folder. That line already says 10 files; now the count is the way in.★A file is a place to look, never a place the tool has been. This is the rule that stops the panel quietly growing a second history beside the real one, and it has three parts that must all hold:
.kerml among the files★ASysT has always read .kerml files — the scan that finds a model's files accepts both extensions, and has since long before this design. Every screen on this page uses your pilot, and your pilot happens to contain ten .sysml files and no .kerml, so the page could show the rule only by lying about your model or by drawing a different one. It draws a different one.
★Wherever this page says “all the model's files”, it means both. The model's list, a package's list, the file picker in the create dialog, and the file that becomes the panel's subject: a .kerml is an ordinary file everywhere, with the same two icons and the same panel.
★One deliberate exception, and it is a choice rather than an oversight: the New file dialog creates .sysml only. Writing SysML is what the tool is for, a beginner picking .kerml by accident would get a file whose grammar refuses almost everything they then try, and a .kerml you already have is read, listed and inspected exactly like the rest. If you ever want to author kernel files, that dialog gains one more choice and nothing else on this page changes.
The model line is the one place where a complete list of files is honest, because a model is its files — everything below that line is meaning, not storage. Putting the list behind the count costs one click and zero permanent rows.
Nothing about creating needed the section. ＋ New file sits on the model's file list and on any package's file list, the ＋ in the title bar offers it from anywhere, and right-clicking any row offers it with that row pre-filled. A standing list was never the way in — it was just a place to look at.
The one thing lost is browsing files you have not otherwise touched — a file that declares nothing you have selected. The model's own list covers it, one click from the top line, and it is the rarer need by a wide margin.
I verified, and you were right to make me. The last version said every row of a kind carried the same actions and did not draw it: a file listed under a package carried four actions, the same file mentioned one line above an element carried two, and one file line carried duplicate — the very mix-up your first review caught. Saying the rule and drawing something else is worse than not having the rule.
So the rule is now one you can check by looking. ★Three kinds of row in the panel carry actions, and each of the three has exactly one set, in the same order, at the right edge, in every screen on this page.
★Not every row is one of the three. The panel also draws rows that are pure reading and carry no actions at all — the list of what a file declares, and the list of what a deletion would break. They are not exceptions to the rule; they are rows with nothing to do, and they must never grow a stray icon. Three kinds of row act; the rest only tell you something.
| Kind of row | Its actions — always these, always in this order | What clicking the name itself does |
|---|---|---|
| A file — anywhere it is named: under an element, under a package, under the model, and the path line of the file's own panel | open copy path | Makes that file the panel's subject, with a chevron back. |
| A drawing | opens here duplicate rename delete | Opens that drawing. |
| An import | follow delete | Follows it — the same as the first icon, which exists so a broken one has something to grey. |
Three more rules hold it in place:
Why a file row stops at two icons, and where the other two went. A file is named in passing all over the panel — under the element you selected, under a package, in the model's list. Renaming or deleting from a passing mention is a footgun: you are looking at a part, and one slip removes a file you never asked to see. So a file gains rename and delete only when the file itself is the panel's subject — when you have gone there deliberately — and then they appear as named buttons at the bottom of its panel, exactly where the model already keeps Rename… and Delete… of the model. Same shape, same place, one rule for both. Screen 5 draws it.
This is the standing rule of the whole tool, not a decision made for the Explorer: an unavailable option rendered as absent teaches the user the tool is broken, and rendered greyed with its reason teaches them the rule.
How to check I kept my word. Every action group on this page was extracted and grouped by what it draws. There are three groups and only three: two icons on every file, four on every drawing, two on every import. If you ever see a fourth, it is a bug in this page.
The panel body is pictures. The problem was never that the actions were drawn as pictures — it was that two different actions were drawn as the same picture: two squares meant copy this path on a file line and make a second drawing from this one on a rendering row. Two silhouettes that cannot be confused replaced it, and each picture now means exactly one thing everywhere in the tool.
This version finishes the job: rename, delete, follow and the opens-here mark used to be keyboard symbols borrowed from a font, which drew differently on every machine and sat oddly next to real drawings. They are drawn icons now, in the same weight as the rest.
★The rule is “every row action is a picture”, and it was written down as “every action”, which the page itself contradicts three screens later with buttons reading Rename…, Delete… and ＋ New file. Both are right and the line between them is the useful part: an icon acts on one line in a list — this drawing, this import, this file among ten — where a word beside every line would drown the list. A word acts on the whole panel — the file you are looking at, the model you are in — where there is one of it, room for a sentence, and a consequence worth reading before you press.
A clipboard is a tall shape with a clip on top; the duplicate is two squares stepped diagonally. At eleven pixels they read apart at a glance, which the old pair did not. And duplicate is now the only icon that appears on drawings and nowhere else — a file cannot be duplicated from this panel at all.
An action a row cannot do keeps its place at thirty-five percent, and hovering it says why. The three cases are listed one section up.
The words did not disappear, they moved. Every icon says its word on hover, and right-clicking any row gives that row's actions written out in full — the same actions, never more. The panel body stays pictures; the explanation is one gesture away. Nobody has to guess from a shape alone, and nobody has to read a sentence to press a button.
You see imports when you are looking at a file. ★An import is owned by a namespace and written in a particular file. The Explorer edits imports through the file panel so that the line you are looking at has one unambiguous place on disk. Select a part, a package or the model and there are none, on purpose. Click a file name and they are there.
That is the whole rule, and the click is short: the file name is on the very first line of the panel, on every element you select. It is blue. Clicking it swaps the panel over to that file, and the file's panel has an Imports section. Here are those two moments side by side.
One click, and it is the click you were already going to make — the file name is the first thing the panel says about anything you select, and the only place in the whole design where a file is reached is a name like this one. Nothing about imports has its own door.
You are right about where they belong, and here is the exact reason — ★which the earlier version of this page got wrong. ★It said a package does not have imports, its files do. That is not how SysML works: an import is owned by the namespace body it is written in — a package body, or the body of a definition — and the file only records where it was typed. Ownership and location are two different questions, and this design answers the second one.
★So the choice stands and only its justification changed, and the practical reason is the strong one: the same namespace reopened in ten files carries ten different sets of import lines. Ask a package panel for “its imports” and there is no single true list to draw. Ask a file, and there is exactly one answer, and it is the one you can edit without wondering which of ten files you just changed.
CrisisResponse is opened in ten files, and each of those ten can write its own imports for it. There are ten possible answers to “the imports of this package” and no single one is true, so the panel shows none and points at the files instead. Only the starting file writes any at all, in your pilot.A package panel already lists the files that open it. Printing their imports there would repeat the same ten file names in a second list, sorted differently, to say something each of those files says better itself. So the package panel says it in one line — ★imports are written inside namespace bodies, one file at a time; open a file above for the ones written in it — and stops.
Because a file is not flat either. Model/20_domain/Domain.sysml writes six import lines in three different namespace bodies: three in Domain, one in Domain::PhysicalDisaster, two in Domain::CyberSecurity. A flat list of six would tell you the file has six imports and hide the only thing you need to know about them — which is what each one is in scope for. Screen 5 draws all six.
CrisisResponse::CrisisSystem, in your use-case file, is a part definition and not a package — and following that opens the part definition, on the board a part definition normally opens on. Same icon, two destinations, and the line itself tells you which.★The old wording said Follow “opens that package”, and for the second kind of line that is simply not what would happen. The tool can already tell the two apart — the star is carried as a flag on every import it reads — so the rule is: follow lands on the natural surface of whatever the line resolves to, and only a namespace import necessarily lands on a package board.
What ASysT does with imports today is navigation, and only navigation. Following one opens what it names as its own drawing; it never pours that content into the one you are looking at. That is right, and this design does not change it.
★The limit that used to be here is GONE — the row can now be the typed line. This page used to warn that the tool did not have the author's own words, only a sentence it rebuilt from the pieces it kept, which for instance wrote private on a line that never had it. The engine now sends the statement exactly as typed, never reconstructed, and says separately when the visibility word was not written — so the row can be truthful about how an import was written as well as what it imports.
Adding an import writes one line at the top of the body you picked, in the file you are on, and nothing else. It does not exist yet — the smallest model write on this page, which is why it is near the end of the order and not the start.
★The earlier version of this page put the import screen among the free ones — “everything needed already arrives”. It does not, and this is the one correction that changes what you should fund first.
★What the engine sends today about an import is: which namespace owns it, what it points at, where the target was found, whether it is public or private, whether it has a star, and a sentence rebuilt from those pieces. Three things it never sends are exactly the three this screen is built on.
★So grouping by file, showing the line as typed, and deleting one line safely are all blocked on the same small piece of engine work, and it must come before the screen that uses it. What it has to carry, at minimum:
★It is a small piece of work — the scan that finds these lines is already reading the file when it finds them, so it is holding every one of these facts and throwing most of them away. But it is engine work, it has to be done first, and pretending otherwise is how a two-day estimate becomes a two-week surprise.
Nine, each drawn as the real panel. The tree above is the same in all of them — the model, and only the model; only the selection and the panel change. The first is the screen at the top of this page, repeated here with its whole tree so the rest can be read against it.
What you are looking at: the system definition of the pilot, selected in the tree. It has two saved drawings — the one that shows its parts, and the one that shows how its ports are wired inside. The first carries the mark saying this is where the model opens, so its house is greyed.
The 2 on the row is why you can scan the tree and see that OperationalStatus has drawings and RespondToIncident has none, without clicking either.
The words Definition and Inner structure are the kind of diagram, in the tool's own vocabulary. The names after them — parts-exposed, port-connection — are yours.
The file name is blue because it is a place you can go. Clicking it turns the panel into screen 5; the two icons beside it act without going anywhere.
Everything on this screen exists today except the file line and its two icons. The engine already knows which file declares each element; the Explorer simply never shows it.
What you are looking at: an action definition nobody has drawn yet. Stripped to a heading and one button, because everything the old version explained is now done by the tool instead of said to the user.
The first change you make to a board with no saved drawing creates one, named after the item. Move a box on RespondToIncident and a rendering called RespondToIncident exists from that moment — no button, no dialog, no name to invent.
So the button above is not the normal way in. It is for the person who wants a named drawing before touching anything — starting a second variant deliberately, or naming the empty one for later.
Half of this works today and it is the invisible half: a board's arrangement is already saved for you whether or not it has a name. What is missing is the naming — today the automatic save goes to the model's default arrangement, so the Renderings list stays empty even though nothing was lost.
What you are looking at: the answer to “where did the Files section go”. Click the model's name at the top of the Explorer and its files are the panel's subject — ★all ten, in folder order, every .sysml and every .kerml the model folder contains, each row carrying the same two icons every file carries anywhere: open it, copy its path.
★Choose another starting file… is the way out of the one refusal this design cannot avoid. The model names one file to start on, and that file therefore cannot be deleted — its Delete… is greyed on its own panel. Greying it and stopping there leaves you stuck: the tool has told you no and given you nothing to do about it. This button is the something. Point the model at a different file and the old one becomes ordinary, and deletable, on the spot.
The old section was always there, taking rows from the tree whether you cared about files or not. This appears when you ask for it and vanishes when you select something else. The tree above never changes shape, and it still shows only the model.
It also has room the section never had. Ten full paths, not ten truncated basenames; the mark on the starting file; a greyed bin with its reason; and the ＋ that adds an eleventh, at the top of the very list you are reading.
None of the actions here exist. The list itself is only reading, and the engine already has every path. New file, rename and delete are three separate pieces of work and they are in the build order below.
What you are looking at: the top package of your pilot. This is the screen that proves the design, because it is the one no other shape could hold honestly.
Not a count, not a truncated name — the actual list, in folder order, every row with the same two icons: open it, copy its path. Renaming and deleting are not offered here, on purpose — you get them by clicking the file, when it is the thing you are looking at rather than one of ten names you are scanning. The first row carries the mark saying the model starts there; it is the only one whose name is written down in the model's settings, which is why its Delete is greyed on its own panel and renaming it has to repair that setting.
Your correction lands here. ★A namespace body owns its imports and a file records where they were typed — and this package's body is reopened in ten files, so there are ten sets of them and no single honest list to draw. So this panel counts them and points at the files, and each file shows its own, grouped by the body they sit in. Printing them here would repeat the same ten file names in a second list to say something worse.
The panel scrolls and its top edge can be dragged, so a package with thirty files is long rather than lying.
None of the actions on this screen exist yet. New file, rename a file, delete a file, new package inside — four separate pieces of work. The list of files itself is only reading, and is the cheapest thing on this whole page.
What you are looking at: one of the ten files, reached by clicking its name on the package panel one screen up. The chevron at the top goes straight back. The tree did not move — the row you came from is marked with a grey bar, so the model is still exactly where you left it.
★The list is nested exactly as the file is, and every package line says package body in this file — nothing more. The earlier version labelled one line “declared here” and another “reopened here”, and the tool cannot tell them apart.
★Deciding which file first declares a package would need an authority, and there is none: the tool finds packages by walking the folder, so “the first one” is whichever file the walk reached first — which is alphabetical order. Rename a file and the answer changes, with nothing about the model having changed at all. That has been measured on this project, in both directions, and it is written up as a trap because on your own model it happens to give the right answer by coincidence.
★So the page stops claiming it. Every line says where a body is, which is a fact; none claims which body came first, which is a guess. If the model's settings ever name a primary file for a package, that is an authority and the label can come back — with that setting behind it, not a sort order.
This file writes three import lines for Domain, one for PhysicalDisaster and two for CyberSecurity. Flattened into a list of six they would all look like properties of the file; grouped, each one sits under the scope it serves, which is the only thing about an import that matters.
The path line carries the same two icons a file carries everywhere — open it, copy its path. Rename… and Delete… are at the bottom, as written words on buttons, and they are here because this is the screen where the file is the thing you are looking at. On a passing mention — under a part, under a package, in the model's list — they do not exist, because deleting a file you only glanced at is the kind of accident a design should make unreachable rather than confirm.
It is the same arrangement the model already uses: the model's panel puts Rename… and Delete… of the model at the bottom, under This model. One rule, two subjects. Screen 9 shows what Delete does.
Renaming a file is not free: when it is the file the model starts on, the model's settings name it and the rename must repair that in the same breath — and on that one file the Delete… button is greyed, with that sentence on it. Renaming from outside ASysT today is worse than unsupported: several checks fail with a raw system error.
A model starts empty on purpose.
What you are looking at: the very first thing a new user sees. One empty file, no package, nothing declared — because you decided on 2 August that a new model must open on nothing and must not invent a package. “Don't make a package! because maybe I don't want to make a package.”
A blank tree next to a model name reads as a failure to load. Four words turn it into a fact.
Not because there is a Files section — there is none. The model is what is selected, and a model's panel lists its files. It happens to be the most useful thing on screen on day one: from the first second the user sees that a model is files, that there is one, and where a second would go.
It is the only one of the three that needs no vocabulary. A newcomer who does not yet know what a package is can start, the first thing they draw lands in the file above, and — by your autosave rule — it is saved under its own name the moment they move it.
Careful with this screen: today a new model can only be made from the open-a-project window, and only inside the model you already have open, which the outer model then swallows. Making a model properly is its own piece of work.
Agreed, and neither exists today. Here is where the control lives, what it asks, and what it writes — and none of it needs a Files section to hang off.
One always-there plus, in the Explorer's own title bar. Whatever is selected pre-fills the answer, so you almost never have to change it. The same menu appears on right-click on any row, with that row as the target. And each item also appears where it naturally belongs: ＋ New inside… on a selected package, ＋ New file on the model's and on a package's file list.
The plus never greys out and never disappears. That is deliberate: the old Explorer had a plus that was permanently disabled, so it was removed altogether, and with it the last hint that anything could be added at all.
With Domain selected, New namespace… opens with the file and the enclosing namespace already filled from where Domain lives. Select nothing and it starts from the model's starting file.
One item is called New namespace rather than New package because the dialog it opens can write three different things — see the next screen.
Yes. The old order asked for the namespace and then the file, which lets you name a combination that does not exist — a namespace whose body is not open in the file you picked — and then refuses it after you have answered both. Choosing the file first makes that combination unreachable instead of invalid.
★And the dialog now actually asks it first. The last version put Kind at the top and the file second, so a page whose whole argument was “file first” drew a dialog that asked something else first. The four questions are numbered on the screen, in the order they are answered: the file, then what is inside it, then what kind of thing to write, then its name. Kind sits third because it is the only one that depends on nothing — it can be answered at any moment, so it goes after the two that must be answered in order.
It also makes the second question small. The whole pilot has many namespaces; Domain.sysml contains exactly four, so the picker is four lines and “the top of the file”. A dialog that asks a short question is a dialog nobody has to think about.
You asked for this and the ten-file pilot already needs it. Each opens as a small tree with a filter box: type dom and the tree keeps what matches. The file picker ends with ＋ A new file…, which chains into the next screen and writes the whole nesting there instead.
★The last version said “three, because the grammar accepts three”, and that is not so: the grammar accepts a fourth, standard library package, and the SysML standard library is written in it. Three is a decision, not a limit, and it is the right one — see the last bullet.
standard library package — which the grammar does accept and which the tool reads perfectly well when it meets one. It marks a package as part of the SysML standard library itself. Writing one in your own model claims a status your model does not have, and there is no case where a person building a system model wants it. Excluded on purpose, and this is the sentence that says so.The trap the file question exists to avoid. There is a tempting shortcut — ask the model's settings which file a package belongs to. On your own model that shortcut gives the right answer by accident, and on the next model it is wrong. Where the neighbours already live is the honest measure, and it is the rule the tool already uses when it writes a new declaration; the dialog's job is to make it visible and changeable.
State today: nothing like this exists. A package can only be created as an option when a whole model is created, and even then only one, at the top.
.sysml and every .kerml under the model folder already belongs to the model.
What you are looking at: adding an eleventh file to the pilot. The dialog is short because the model boundary is generous: ★put a .sysml or a .kerml under the model folder and it is in the model. There is no list to add it to and nothing to declare.
★This dialog creates .sysml files only, even though the model happily contains .kerml ones and the tool reads them. Writing SysML is what ASysT is for; a .kerml file is a lower-level kernel file whose grammar would refuse most of what a person types after choosing it, and offering the choice would cost a beginner an afternoon. It is one line of the dialog away the day you want it — nothing else in this design assumes an extension.
Same picker, same filter box; it offers every folder the model already uses and a new one at the end. Folders are yours to organise — ASysT reads no meaning into them.
Same reason a new model opens on nothing: the starting content is your first gesture, not ours. The other two exist because reopening the top package is what nine of your ten files actually do, and typing it by hand every time is a chore.
Choosing “a new namespace” here answers both of your questions at once — a new file and a new namespace, in one step. Picking “＋ A new file…” in the namespace dialog's file picker arrives at this same screen from the other direction. That is the right shape for two things so often done together.
State today: no path in the engine creates a new file inside an existing model. Every writer rewrites a file that already exists. The only thing that lands a new file is dropping one on the window, and that puts it in a folder named after the file — which joins the model only by luck.
4 places in 3 other files would point at nothing:
What you are looking at: the hardest of the three delete cases. The other two are quiet by design: an empty file goes with no question, and a file nothing else names goes with a count of what left. ★All three land in a bin, never straight to nothing — and the bin has to be somewhere the model does not look.
★“A bin inside the model” would not have deleted anything. A model is not a list of files: it is every .sysml and .kerml under its folder. So a deleted file dropped into a folder inside the model would still be found, still opened, still merged into the model — the boxes would not go away, the names would not stop resolving, and the only thing that would have changed is that you could no longer see the file that was causing it. The quietest possible bug.
★Two doors out, and the tool already has both. The walk that finds a model's files stops at a folder carrying its own model settings, and it also skips a short list of folder names it knows are not model content. The bin must use one of those two, or sit outside the model folder entirely — and whichever is chosen belongs written down beside the delete code, because the day someone renames that folder, deletion silently stops deleting.
★Restoring is then the honest reverse: the file moves back to where it was, and only then is it part of the model again.
The correction, and it changes the answer. The reason written down for refusing this third case was that the language server accepts a name pointing at nothing without complaining — so once the file was gone, the model would look fine and be broken, with no way to find out.
That was measured on 3 August and it is false. The server does report the missing name, with the name in it. ASysT was throwing that detail away before it reached the screen, so it arrived looking like one more style warning among eighty-three others.
So the refusal was never a rule — it was caution built on a guess nobody had checked. With the damage listable, delete with a warning becomes the honest behaviour. The list above is the price of admission: no list, no delete.
This is also why the delete work sits near the end of the build order. It is not the hardest to write — it is the one that needs something else finished first.
★Nothing in the first three versions of this page said how any of it works for someone who cannot hover, or what a flat list of files does when a model is not your pilot. Both follow from decisions the page has already made — icons instead of words, and a list instead of a count — so both are this design's problem, not somebody else's.
★The panel body is pictures, and the page says twice that the word appears on hover and on right-click. Those are the two gestures a keyboard does not have, a touch screen does not have, and a screen reader does not have. If they are the only doors, the panel is a row of unlabelled shapes for everyone who does not use a mouse — which is the exact failure the icons were meant to avoid.
★Every screen on this page draws your pilot, and its ten full paths are a genuinely good list — readable, complete, no truncation, no scrolling. The same design at three hundred files is a wall of monospace that has to be scrolled past to reach the buttons underneath it, and the argument that beat the Files section — that a full list is more honest than a count — stops being true at the point where nobody can read it.
dom, keep what matches.This is the state of the tool, not the state of the design. Most of this page is not built. A design that pretends otherwise is worse than no design.
| What you want to do | State | Where it lives in this design | What it writes | What it refuses |
|---|---|---|---|---|
| Renderings — a saved arrangement of one diagram | ||||
| Several drawings of the same element | works | The Renderings list in the panel. No limit — the old cap of one was removed on 2 August. | One file per drawing, filed under the element and the kind of diagram. Your model text is never touched. | Nothing. A name with spaces or accents becomes a safe file name quietly. |
| Create a drawing | works | ＋ New on the Renderings heading, and the single button in the empty state. | Snapshots the board you are on — positions, colours, sizes, routes, folds — under the name you type. | An empty name. |
| Get a drawing without asking for one — the first change names it after the item | partly | Nowhere to click: it happens on your first change to a board that has none. | ★The same snapshot, saved under the element's own name instead of into the board's own unnamed file. BUILT — the first change to a board with no drawing now names one after the item. | Nothing. If a drawing of that name exists, that one is simply the one being edited. |
| Duplicate a drawing — start a new one from an existing one | partly | The two-squares icon on a rendering row. The one you asked for by name. | Would copy the one file under a new name. Nothing else changes; the original keeps its mark. | An empty name; a name already used for the same element and the same kind of diagram. |
| Rename a drawing | works | The rename icon on its row. | Moves the one file. The “opens here” mark and the memory of which drawing you last used follow it. | An empty name. A board's own unnamed arrangement has no name to change. |
| Delete a drawing | works | The delete icon on its row, with a confirmation. | Removes that one file. Every other drawing of the same element stays. | A board's own unnamed arrangement cannot be deleted — it is your live work, not a saved copy. |
| Files inside a model — no standing list anywhere | ||||
| See all the files of a model | missing | Click the model's name at the top of the Explorer. Never a Files section. | Nothing — it only reads. | — |
| See which files open one package | missing | The file list on the package's panel — ten lines for CrisisResponse. |
Nothing — it only reads. | — |
| See which file an element lives in | missing | The first line of the panel, always, and the file name is a link. | Nothing — it only reads. The engine already knows. | — |
| Look at one file — what it declares, what it imports | missing | Click any file name in the panel; it becomes the subject, with a chevron back. The tree does not move. | Nothing — it only reads. | — |
| Copy a file's path | missing | The clipboard icon, on every file row. Never the two-squares icon again. | Nothing — clipboard only. | — |
| Add a new file to the model | missing | The ＋ in the title bar, and ＋ New file on the model's and on a package's file list. | One .sysml inside the model folder, with whatever starting line you chose. Nothing has to be registered. |
A name already taken; a folder outside the model. |
| Rename a file | missing | Rename… at the bottom of that file’s own panel — reached by clicking its name. Never on a passing mention. | Moves the file, and repairs the model's settings when the renamed file is the one the model starts on. | A name already taken. Renaming from outside ASysT today makes several checks fail with a raw system error. |
| Delete a file | missing | Delete… at the bottom of that file’s own panel — greyed with its reason on the file the model starts on. Never on a passing mention. | Three cases: empty goes with no question; unnamed-by-anyone goes with a count; named-by-others goes with the list of what breaks. Always into a bin inside the model. | The starting file, until it is no longer the starting file. The third case cannot be offered until the tool can list the damage. |
| Namespaces and imports | ||||
| Create a package, a namespace or a library package | partly | The ＋ in the title bar; ＋ New inside… on a selected package. Kind, then file, then what is inside that file, then the name. | Two lines inside one existing file, in the body you picked. The file is proposed from where the neighbours live and is changeable. | An empty name; a name already used in that namespace; a name that is not a legal identifier. |
| See a file's imports | missing | The Imports section on a file, grouped by the body each line sits in. Never on a package — a package points at its files instead. | Nothing — it only reads. The engine already sends every import line with its owner and its target. | — |
| Follow an import | partly | The follow icon on an import row. Today the only place is a menu on a package box on the canvas. | Nothing — it opens the named package as its own drawing. Nothing is poured into the drawing you were on. | A target ASysT cannot find is greyed with the reason, not hidden. |
| Add an import | missing | The ＋ on a file's Imports heading, into the body you pick. | One line at the top of that body, in that file. | A duplicate of a line already there; a target that resolves to nothing. |
| The model itself | ||||
| Create a model | partly | Only from the open-a-project window, never from the Explorer. | A folder, its settings file, and one empty .sysml — with no package inside, by your decision of 2 August. |
A folder outside the project you have open — which means the only legal spot is inside the model you already have, and that one then swallows it. |
| Rename a model | partly | Rename… on the model panel. Nowhere in the interface today; the name is a field in the model's settings file. | Would change that field; the folder name would be a second, separate question. | — |
| Delete a model | missing | Delete… on the model panel. Nothing in the tool deletes a model file, a settings file or a model folder. | Would move the folder to a bin, never straight to nothing. | Deleting the model you are looking at should close it first. |
| Related, and it changes what deleting can promise | ||||
| Be told a reference now points at nothing | partly | After any delete, rename or dissolve, as a list that stays until it is empty. | Nothing — it only reads. | — |
| Rename an element of the model | partly | On the canvas. | Rewrites the file that declares it. | A rename that ought to touch the other files mentioning the name is still open work, and it is the highest-priority write item in the project. |
In order, shortest first. The first four cost nothing in the engine — the information is already there and simply never reaches the screen. Everything from the fifth on is a real write, and a write is where the cost is.
asyst-FIVE-SPECS-CLICK-A-DRAWING), and the whole two-pane split the section lived in had to be retired with it. Cheap in code, not free.import X::* { … } body, so a delete has something safe to cut, and two identical imports in two files stay two records..sysml in an existing model. Once it exists, a file needs no registering, which makes this smaller than it sounds.Where I would stop and look at it. After step four. That is the whole shape you chose — the thin tree, the panel, the file line, the file as a subject, the drawings of the selected thing, the imports where they belong — and not one line of it is a write. It is the version you can use every day and tell me what is wrong with, before anything expensive is built on top of a guess.
Step five is your autosave rule and it is worth pulling forward if it can be made safe, because it deletes a screen rather than adding one. Steps six to eight are the useful half of the creation work: copy a drawing, add a file, add a namespace. Everything after that is deletion and renaming, and they are worth doing properly rather than early.