Glossary

TaskSultan uses its own words for the things it builds and runs. This page is the list, with the meaning the repository gives each one. Where a term is capitalised in the product, it is capitalised here.

#The platform vocabulary

• automation: the thing a user builds, a TypeScript file in automations/ that declares what it is, which capabilities it needs and what its steps are.
• Robot: the executor. It is deliberately small: no designer, no AI and no business rules.
• Studio: the browser IDE and the desktop shell where automations are written and watched.
• Orchestrator: the queue, the scheduler, the credential vault, the robot registry and the record of what ran.
• Recorder: the tool that points at a screen element once and produces a Target the platform can find again.
• Action Centre: the human-in-the-loop seam. A human approves or rejects and the decision resumes the work.
• Target: a named element an automation addresses, kept in targets/ apart from the automation. A Target has a name, a description and an ordered list of ways to find the element.
• Target Repository: the module that exports the Targets and the helpers that reference one by id.
• Transaction: one unit of work handed to processTransaction.
• Job: a queued dispatch of an automation through the Orchestrator.
• Run: one execution of one automation.
• Suite: a set of tests over automations.
• Capability: a declared engine an automation needs (web, excel, files, api, database, email, pdf, desktop). A facade is present only when its capability is declared.
• Brief: the description a user hands the generator in order to produce an automation.
• Binding: a live element proven to match a semantic locator, unique and the same node.
• Vault: the credential store. Assets are addressed by name and resolved at run time.
• Environment: the label a Run or an activation is bound to (TS_ENVIRONMENT).
• Package: a portable .tspkg a Robot can execute without a Studio or a repository checkout.
• Run artifacts: the logs, traces, screenshots and summaries a Run writes to the artifacts root.

#Conversion vocabulary

The feasibility evaluator gives every authored activity one verdict.

• DIRECT: an existing surface does this today.
• COMPOSITE: the action maps, but a neighbouring artefact must be re-authored.
• MISSING: no engine exists for it.
• REFUSE: it would block an unattended run, so the platform declines to port it.
• UNCLASSIFIED: no rule matched the name. This blocks, exactly as MISSING does.
• METADATA: an element belonging to another activity, excluded from the coverage total.

Target synthesis classes: SYNTHESISED, SYNTHESISED_TEXT and SYNTHESISED_DESCRIPTOR carry a locator; NEEDS_REVIEW_ID is a test-id proposal a human confirms; REFUSED_AMBIGUOUS, REFUSED_POSITIONAL, REFUSED_NO_EVIDENCE and REFUSED_DYNAMIC are refusals; WINDOW and DESKTOP are out of scope.

Live binding classes: BOUND and BOUND_CHAINED; NEEDS_REVIEW_ID, REFUSED_AMBIGUOUS, NOT_FOUND and REFUSED_UNBINDABLE need a human.

• IR: the behaviour model. A typed, ordered tree of a workflow, parsed from XAML or from a coded workflow.
• codegen: the stage that lowers the IR into ordered named step functions, with TODO(conversion) markers carrying everything it refused.
• refusal code: the name a refusal is reported under, so a reader can quote it. The coded front end's codes begin CODED_; the codegen reports features such as ir-refusal, condition-refused, expression-refused, lane-unattributable, INVOKE_CODE_UNSUPPORTED and NET_METHOD_UNSUPPORTED.
• TODO(conversion): an inline marker in a staged automation naming a construct or feature that was not translated, counted in the emission manifest beside the file.

#Exceptions

The framework's error taxonomy is framework/errors.ts.

• SystemException: an infrastructure or flaky failure. It carries a code and a retryable flag and it is retried under the bounded policy. An error that is neither a business nor a system exception is wrapped in one with the code UNEXPECTED_ERROR, so a coding bug cannot loop forever.
• BusinessException: an expected, domain-level failure. It carries a code, it is never retried, the transaction is failed and the run continues.
• AbortRequested: raised internally when an operator asks a run to stop. It is not an error: it unwinds the run loop gracefully.

The Orchestrator's transaction records have their own pair, TransactionBusinessException and TransactionSystemException, with the same two meanings.

Three further names appear in the documentation's vocabulary: RetryableException, ConfigurationException and RefusedException. No source file in this repository defines or raises them yet, so they are named here and left undefined rather than described from assumption. The exception names the code does use are spelled exactly as the code spells them.