Merge branch 'open199-css' of https://github.com/nasa/openmctweb into open199-css

.circleci/config.yml

@@ -1,330 +0,0 @@
-version: 2.1
-orbs:
-  node: circleci/node@5.2.0
-  browser-tools: circleci/browser-tools@1.3.0
-executors:
-  pw-focal-development:
-    docker:
-      - image: mcr.microsoft.com/playwright:v1.48.1-focal
-    environment:
-      NODE_ENV: development # Needed to ensure 'dist' folder created and devDependencies installed
-      PERCY_POSTINSTALL_BROWSER: 'true' # Needed to store the percy browser in cache deps
-      PERCY_LOGLEVEL: 'debug' # Enable DEBUG level logging for Percy (Issue: https://github.com/nasa/openmct/issues/5742)
-      PERCY_PARALLEL_TOTAL: 2
-  ubuntu:
-    machine:
-      image: ubuntu-2204:current
-      docker_layer_caching: true
-commands:
-  build_and_install:
-    description: 'All steps used to build and install.'
-    parameters:
-      node-version:
-        type: string
-    steps:
-      - checkout
-      - node/install:
-          node-version: << parameters.node-version >>
-      - node/install-packages
-  generate_and_store_version_and_filesystem_artifacts:
-    description: 'Track important packages and files'
-    steps:
-      - run: |
-          [[ $EUID -ne 0 ]] && (sudo mkdir -p /tmp/artifacts && sudo chmod 777 /tmp/artifacts) || (mkdir -p /tmp/artifacts && chmod 777 /tmp/artifacts)
-          printenv NODE_ENV >> /tmp/artifacts/NODE_ENV.txt || true
-          npm -v >> /tmp/artifacts/npm-version.txt
-          node -v >> /tmp/artifacts/node-version.txt
-          ls -latR >> /tmp/artifacts/dir.txt
-      - store_artifacts:
-          path: /tmp/artifacts/
-  download_verify_codecov_cli:
-    description: 'Download and verify Codecov CLI'
-    steps:
-      - run:
-          name: Download and verify Codecov CLI
-          command: |
-            # Download Codecov CLI
-            curl -Os https://cli.codecov.io/latest/linux/codecov
-
-            # Import Codecov's GPG key
-            curl https://keybase.io/codecovsecurity/pgp_keys.asc | gpg --no-default-keyring --keyring trustedkeys.gpg --import
-
-            # Download and verify the SHA256SUM and its signature
-            curl -Os https://cli.codecov.io/latest/linux/codecov.SHA256SUM
-            curl -Os https://cli.codecov.io/latest/linux/codecov.SHA256SUM.sig
-            gpgv codecov.SHA256SUM.sig codecov.SHA256SUM
-
-            # Verify the checksum
-            shasum -a 256 -c codecov.SHA256SUM
-
-            # Make the codecov executable
-            [[ $EUID -ne 0 ]] && sudo chmod +x codecov || chmod +x codecov
-            ./codecov --help
-  generate_e2e_code_cov_report:
-    description: 'Generate e2e code coverage artifacts and publish to codecov.io. Needed to that we can ignore the exit code status of the npm run test'
-    parameters:
-      suite:
-        type: string
-    steps:
-      - run: npm run cov:e2e:report || true
-      - download_verify_codecov_cli
-      - run:
-          name: Upload coverage report to Codecov
-          command: |
-            ./codecov --verbose upload-process --disable-search \
-              -t $CODECOV_TOKEN \
-              -n 'e2e-<<parameters.suite>>'-${CIRCLE_WORKFLOW_ID} \
-              -F e2e-<<parameters.suite>> \
-              -f ./coverage/e2e/lcov.info
-jobs:
-  npm-audit:
-    parameters:
-      node-version:
-        type: string
-    executor: pw-focal-development
-    steps:
-      - build_and_install:
-          node-version: <<parameters.node-version>>
-      - run: npm audit --audit-level=low
-      - generate_and_store_version_and_filesystem_artifacts
-  lint:
-    parameters:
-      node-version:
-        type: string
-    executor: pw-focal-development
-    steps:
-      - build_and_install:
-          node-version: <<parameters.node-version>>
-      - run: npm run lint
-      - generate_and_store_version_and_filesystem_artifacts
-  unit-test:
-    parameters:
-      node-version:
-        type: string
-    executor: pw-focal-development
-    steps:
-      - build_and_install:
-          node-version: <<parameters.node-version>>
-      - browser-tools/install-chrome:
-          replace-existing: false
-      - run:
-          command: |
-            mkdir -p dist/reports/tests/
-            TESTFILES=$(circleci tests glob "src/**/*Spec.js")
-            echo "$TESTFILES" | circleci tests run --command="xargs npm run test" --verbose
-      - download_verify_codecov_cli
-      - run:
-          name: Upload coverage report to Codecov
-          command: |
-            ./codecov --verbose upload-process --disable-search \
-              -t $CODECOV_TOKEN \
-              -n 'unit-test'-${CIRCLE_WORKFLOW_ID} \
-              -F unit \
-              -f ./coverage/unit/lcov.info
-      - store_test_results:
-          path: dist/reports/tests/
-      - store_artifacts:
-          path: coverage
-      - when:
-          condition:
-            equal: [42, 42] # Always generate version artifacts regardless of test failure https://discuss.circleci.com/t/make-custom-command-run-always-with-when-always/38957/2
-          steps:
-            - generate_and_store_version_and_filesystem_artifacts
-  e2e-test:
-    parameters:
-      suite: #ci or full
-        type: string
-    executor: pw-focal-development
-    parallelism: 8
-    steps:
-      - build_and_install:
-          node-version: lts/hydrogen
-      - when: #Only install chrome-beta when running the 'full' suite to save $$$
-          condition:
-            equal: ['full', <<parameters.suite>>]
-          steps:
-            - run: npx playwright install chrome-beta
-      - run:
-          command: |
-            mkdir test-results
-            TESTFILES=$(circleci tests glob "e2e/**/*.spec.js")
-            echo "$TESTFILES" | circleci tests run --command="xargs npm run test:e2e:<<parameters.suite>>" --verbose --split-by=timings
-      - when:
-          condition:
-            equal: [42, 42] # Always run codecov reports regardless of test failure https://discuss.circleci.com/t/make-custom-command-run-always-with-when-always/38957/2
-          steps:
-            - generate_e2e_code_cov_report:
-                suite: <<parameters.suite>>
-      - store_test_results:
-          path: test-results/results.xml
-      - store_artifacts:
-          path: test-results
-      - store_artifacts:
-          path: coverage
-      - store_artifacts:
-          path: html-test-results
-      - when:
-          condition:
-            equal: [42, 42] # Always generate version artifacts regardless of test failure https://discuss.circleci.com/t/make-custom-command-run-always-with-when-always/38957/2
-          steps:
-            - generate_and_store_version_and_filesystem_artifacts
-  e2e-mobile:
-    executor: pw-focal-development
-    steps:
-      - build_and_install:
-          node-version: lts/hydrogen
-      - run: npm run test:e2e:mobile
-      - when:
-          condition:
-            equal: [42, 42] # Always run codecov reports regardless of test failure https://discuss.circleci.com/t/make-custom-command-run-always-with-when-always/38957/2
-          steps:
-            - generate_e2e_code_cov_report:
-                suite: full
-      - store_test_results:
-          path: test-results/results.xml
-      - store_artifacts:
-          path: test-results
-      - store_artifacts:
-          path: coverage
-      - store_artifacts:
-          path: html-test-results
-      - when:
-          condition:
-            equal: [42, 42] # Always generate version artifacts regardless of test failure https://discuss.circleci.com/t/make-custom-command-run-always-with-when-always/38957/2
-          steps:
-            - generate_and_store_version_and_filesystem_artifacts
-  e2e-couchdb:
-    executor: ubuntu
-    steps:
-      - build_and_install:
-          node-version: lts/hydrogen
-      - run: npx playwright@1.48.1 install #Necessary for bare ubuntu machine
-      - run: |
-          export $(cat src/plugins/persistence/couch/.env.ci | xargs)
-          docker compose -f src/plugins/persistence/couch/couchdb-compose.yaml up --detach
-          sleep 3
-          bash src/plugins/persistence/couch/setup-couchdb.sh
-      - run: sh src/plugins/persistence/couch/replace-localstorage-with-couchdb-indexhtml.sh #Replace LocalStorage Plugin with CouchDB
-      - run: npm run test:e2e:couchdb
-      - when:
-          condition:
-            equal: [42, 42] # Always run codecov reports regardless of test failure https://discuss.circleci.com/t/make-custom-command-run-always-with-when-always/38957/2
-          steps:
-            - generate_e2e_code_cov_report:
-                suite: full #add to full suite
-      - store_test_results:
-          path: test-results/results.xml
-      - store_artifacts:
-          path: test-results
-      - store_artifacts:
-          path: coverage
-      - store_artifacts:
-          path: html-test-results
-      - when:
-          condition:
-            equal: [42, 42] # Always generate version artifacts regardless of test failure https://discuss.circleci.com/t/make-custom-command-run-always-with-when-always/38957/2
-          steps:
-            - generate_and_store_version_and_filesystem_artifacts
-  mem-test:
-    executor: pw-focal-development
-    steps:
-      - build_and_install:
-          node-version: lts/hydrogen
-      - run: npm run test:perf:memory
-      - store_test_results:
-          path: test-results/results.xml
-      - store_artifacts:
-          path: test-results
-      - store_artifacts:
-          path: html-test-results
-      - when:
-          condition:
-            equal: [42, 42] # Always run codecov reports regardless of test failure https://discuss.circleci.com/t/make-custom-command-run-always-with-when-always/38957/2
-          steps:
-            - generate_and_store_version_and_filesystem_artifacts
-  perf-test:
-    executor: pw-focal-development
-    steps:
-      - build_and_install:
-          node-version: lts/hydrogen
-      - run: npm run test:perf:localhost
-      - run: npm run test:perf:contract
-      - store_test_results:
-          path: test-results/results.xml
-      - store_artifacts:
-          path: test-results
-      - store_artifacts:
-          path: html-test-results
-      - when:
-          condition:
-            equal: [42, 42] # Always run codecov reports regardless of test failure https://discuss.circleci.com/t/make-custom-command-run-always-with-when-always/38957/2
-          steps:
-            - generate_and_store_version_and_filesystem_artifacts
-  visual-a11y:
-    parameters:
-      suite:
-        type: string # ci or full
-    executor: pw-focal-development
-    parallelism: 2
-    steps:
-      - build_and_install:
-          node-version: lts/iron
-      - run: SHARD="$((${CIRCLE_NODE_INDEX}+1))"; npm run test:e2e:visual:<<parameters.suite>> -- --shard=${SHARD}/${CIRCLE_NODE_TOTAL}
-      - store_test_results:
-          path: test-results/results.xml
-      - store_artifacts:
-          path: test-results
-      - store_artifacts:
-          path: html-test-results
-      - when:
-          condition:
-            equal: [42, 42] # Always generate version artifacts regardless of test failure https://discuss.circleci.com/t/make-custom-command-run-always-with-when-always/38957/2
-          steps:
-            - generate_and_store_version_and_filesystem_artifacts
-
-workflows:
-  overall-circleci-commit-status: #These jobs run on every commit
-    jobs:
-      - lint:
-          name: node22-lint
-          node-version: '22'
-      - unit-test:
-          name: node18-chrome
-          node-version: lts/hydrogen
-      - e2e-test:
-          name: e2e-ci
-          suite: ci
-      - e2e-mobile
-      - visual-a11y:
-          name: visual-a11y-ci
-          suite: ci
-      - perf-test
-      - mem-test
-
-  the-nightly: #These jobs do not run on PRs, but against master at night
-    jobs:
-      - unit-test:
-          name: node22-chrome-nightly
-          node-version: '22'
-      - unit-test:
-          name: node18-chrome
-          node-version: lts/hydrogen
-      - npm-audit:
-          node-version: lts/hydrogen
-      - e2e-test:
-          name: e2e-full-nightly
-          suite: full
-      - e2e-mobile
-      - perf-test
-      - mem-test
-      - visual-a11y:
-          name: visual-a11y-nightly
-          suite: full
-      - e2e-couchdb
-    triggers:
-      - schedule:
-          cron: '0 0 * * *'
-          filters:
-            branches:
-              only:
-                - master

.cspell.json

@@ -1,499 +0,0 @@
-{
-  "version": "0.2",
-  "language": "en,en-us",
-  "words": [
-    "gress",
-    "doctoc",
-    "minmax",
-    "openmct",
-    "datasources",
-    "Sinewave",
-    "deregistration",
-    "unregisters",
-    "codecov",
-    "carryforward",
-    "Chacon",
-    "Straub",
-    "OWASP",
-    "Testathon",
-    "Testathons",
-    "testathon",
-    "npmjs",
-    "treeitem",
-    "timespan",
-    "Timespan",
-    "spinbutton",
-    "popout",
-    "textbox",
-    "tablist",
-    "Telem",
-    "codecoverage",
-    "browserless",
-    "networkidle",
-    "nums",
-    "mgmt",
-    "faultname",
-    "gantt",
-    "sharded",
-    "MMOC",
-    "codegen",
-    "viewports",
-    "updatesnapshots",
-    "browsercontexts",
-    "miminum",
-    "testcase",
-    "testsuite",
-    "domcontentloaded",
-    "Tracefile",
-    "lcov",
-    "linecov",
-    "Browserless",
-    "webserver",
-    "yamcs",
-    "quickstart",
-    "subobject",
-    "autosize",
-    "Horz",
-    "vehicula",
-    "Praesent",
-    "pharetra",
-    "Duis",
-    "eget",
-    "arcu",
-    "elementum",
-    "mauris",
-    "Donec",
-    "nunc",
-    "quis",
-    "Proin",
-    "elit",
-    "Nunc",
-    "Aenean",
-    "mollis",
-    "hendrerit",
-    "Vestibulum",
-    "placerat",
-    "velit",
-    "augue",
-    "Quisque",
-    "mattis",
-    "lectus",
-    "rutrum",
-    "Fusce",
-    "tincidunt",
-    "nibh",
-    "blandit",
-    "urna",
-    "Nullam",
-    "congue",
-    "enim",
-    "Morbi",
-    "bibendum",
-    "Vivamus",
-    "imperdiet",
-    "Pellentesque",
-    "cursus",
-    "Aliquam",
-    "orci",
-    "Suspendisse",
-    "amet",
-    "justo",
-    "Etiam",
-    "vestibulum",
-    "ullamcorper",
-    "Cras",
-    "aliquet",
-    "Mauris",
-    "Nulla",
-    "scelerisque",
-    "viverra",
-    "metus",
-    "condimentum",
-    "varius",
-    "nulla",
-    "sapien",
-    "Curabitur",
-    "tristique",
-    "Nonsectetur",
-    "convallis",
-    "accumsan",
-    "lacus",
-    "posuere",
-    "turpis",
-    "egestas",
-    "feugiat",
-    "tortor",
-    "faucibus",
-    "euismod",
-    "pathing",
-    "testcases",
-    "Noneditable",
-    "listitem",
-    "Gantt",
-    "timelist",
-    "timestrip",
-    "networkevents",
-    "fetchpriority",
-    "persistable",
-    "Persistable",
-    "persistability",
-    "Persistability",
-    "testdata",
-    "Testdata",
-    "metdata",
-    "timeconductor",
-    "contenteditable",
-    "autoscale",
-    "Autoscale",
-    "prepan",
-    "sinewave",
-    "cyanish",
-    "driv",
-    "searchbox",
-    "datetime",
-    "timeframe",
-    "recents",
-    "recentobjects",
-    "gsearch",
-    "Disp",
-    "Cloc",
-    "noselect",
-    "requestfailed",
-    "viewlarge",
-    "Imageurl",
-    "thumbstrip",
-    "checkmark",
-    "Unshelve",
-    "autosized",
-    "chacskaylo",
-    "numberfield",
-    "OPENMCT",
-    "Autoflow",
-    "Timelist",
-    "faultmanagement",
-    "GEOSPATIAL",
-    "geospatial",
-    "plotspatial",
-    "annnotation",
-    "keystrings",
-    "undelete",
-    "sometag",
-    "containee",
-    "composability",
-    "mutables",
-    "Mutables",
-    "composee",
-    "handleoutsideclick",
-    "Datetime",
-    "Perc",
-    "autodismiss",
-    "filetree",
-    "deeptailor",
-    "keystring",
-    "reindex",
-    "unlisten",
-    "symbolsfont",
-    "ellipsize",
-    "TIMESYSTEM",
-    "Metadatas",
-    "unsub",
-    "callbacktwo",
-    "unsubscribetwo",
-    "telem",
-    "unemitted",
-    "granually",
-    "timesystem",
-    "metadatas",
-    "iteratees",
-    "metadatum",
-    "printj",
-    "sprintf",
-    "unlisteners",
-    "amts",
-    "reregistered",
-    "hudsonfoo",
-    "onclone",
-    "autoflow",
-    "xdescribe",
-    "mockmct",
-    "Autoflowed",
-    "plotly",
-    "relayout",
-    "Plotly",
-    "Yaxis",
-    "showlegend",
-    "textposition",
-    "xaxis",
-    "automargin",
-    "fixedrange",
-    "yaxis",
-    "Axistype",
-    "showline",
-    "bglayer",
-    "autorange",
-    "hoverinfo",
-    "dotful",
-    "Dotful",
-    "cartesianlayer",
-    "scatterlayer",
-    "textfont",
-    "ampm",
-    "cdef",
-    "horz",
-    "STYLEABLE",
-    "styleable",
-    "afff",
-    "shdw",
-    "braintree",
-    "vals",
-    "Subobject",
-    "Shdw",
-    "Movebar",
-    "inspectable",
-    "Stringformatter",
-    "sclk",
-    "Objectpath",
-    "Keystring",
-    "duplicatable",
-    "composees",
-    "Composees",
-    "Composee",
-    "callthrough",
-    "objectpath",
-    "createable",
-    "noneditable",
-    "Classname",
-    "classname",
-    "selectedfaults",
-    "accum",
-    "newpersisted",
-    "Metadatum",
-    "MCWS",
-    "YAMCS",
-    "frameid",
-    "containerid",
-    "mmgis",
-    "PERC",
-    "curval",
-    "viewbox",
-    "mutablegauge",
-    "Flatbush",
-    "flatbush",
-    "Indicies",
-    "Marqueed",
-    "NSEW",
-    "nsew",
-    "vrover",
-    "gimbled",
-    "Pannable",
-    "unsynced",
-    "Unsynced",
-    "pannable",
-    "autoscroll",
-    "TIMESTRIP",
-    "TWENTYFOUR",
-    "FULLSIZE",
-    "intialize",
-    "Timestrip",
-    "spyon",
-    "Unlistener",
-    "multipane",
-    "DATESTRING",
-    "akhenry",
-    "Niklas",
-    "Hertzen",
-    "Kash",
-    "Nouroozi",
-    "Bostock",
-    "BOSTOCK",
-    "Arnout",
-    "Kazemier",
-    "Karolis",
-    "Narkevicius",
-    "Ashkenas",
-    "Madhavan",
-    "Iskren",
-    "Ivov",
-    "Chernev",
-    "Borshchov",
-    "painterro",
-    "sheetjs",
-    "Yuxi",
-    "ACITON",
-    "localstorage",
-    "Linkto",
-    "Painterro",
-    "Editability",
-    "filteredsnapshots",
-    "Fromimage",
-    "muliple",
-    "notebookstorage",
-    "Andpage",
-    "pixelize",
-    "Quickstart",
-    "indexhtml",
-    "youradminpassword",
-    "chttpd",
-    "sourcefiles",
-    "USERPASS",
-    "XPUT",
-    "adipiscing",
-    "eiusmod",
-    "tempor",
-    "incididunt",
-    "labore",
-    "dolore",
-    "aliqua",
-    "perspiciatis",
-    "iteree",
-    "submodels",
-    "symlog",
-    "Plottable",
-    "antisymlog",
-    "docstrings",
-    "webglcontextlost",
-    "gridlines",
-    "Xaxis",
-    "Crosshairs",
-    "telemetrylimit",
-    "xscale",
-    "yscale",
-    "untracks",
-    "swatched",
-    "NULLVALUE",
-    "unobserver",
-    "unsubscriber",
-    "drap",
-    "Averager",
-    "averager",
-    "movecolumnfromindex",
-    "callout",
-    "Konqueror",
-    "unmark",
-    "hitarea",
-    "Hitarea",
-    "Unmark",
-    "controlbar",
-    "reactified",
-    "perc",
-    "DHMS",
-    "timespans",
-    "timeframes",
-    "Timesystems",
-    "Hilite",
-    "datetimes",
-    "momentified",
-    "ucontents",
-    "TIMELIST",
-    "Timeframe",
-    "Guirk",
-    "resizeable",
-    "iframing",
-    "Btns",
-    "Ctrls",
-    "Chakra",
-    "Petch",
-    "propor",
-    "phoneandtablet",
-    "desktopandtablet",
-    "Imgs",
-    "UNICODES",
-    "datatable",
-    "csvg",
-    "cpath",
-    "cellipse",
-    "xlink",
-    "cstyle",
-    "bfill",
-    "ctitle",
-    "eicon",
-    "interactability",
-    "AFFORDANCES",
-    "affordance",
-    "scrollcontainer",
-    "Icomoon",
-    "icomoon",
-    "configurability",
-    "btns",
-    "AUTOFLOW",
-    "DATETIME",
-    "infobubble",
-    "thumbsbubble",
-    "codehilite",
-    "vscroll",
-    "bgsize",
-    "togglebutton",
-    "Hacskaylo",
-    "noie",
-    "fullscreen",
-    "horiz",
-    "menubutton",
-    "SNAPSHOTTING",
-    "snapshotting",
-    "PAINTERRO",
-    "ptro",
-    "PLOTLY",
-    "gridlayer",
-    "xtick",
-    "ytick",
-    "subobjects",
-    "Ucontents",
-    "Userand",
-    "Userbefore",
-    "brdr",
-    "ALPH",
-    "Recents",
-    "Qbert",
-    "Infobubble",
-    "haslink",
-    "VPID",
-    "vpid",
-    "updatedtest",
-    "KHTML",
-    "Chromezilla",
-    "Safarifox",
-    "deregistering",
-    "hundredtized",
-    "dhms",
-    "unthrottled",
-    "Codecov",
-    "dont",
-    "mediump",
-    "sinonjs",
-    "generatedata",
-    "grandsearch",
-    "websockets",
-    "swgs",
-    "memlab",
-    "devmode",
-    "blockquote",
-    "blockquotes",
-    "Blockquote",
-    "Blockquotes",
-    "oger",
-    "lcovonly",
-    "gcov",
-    "WCAG",
-    "stackedplot",
-    "Andale",
-    "unnormalized",
-    "checksnapshots",
-    "specced",
-    "composables",
-    "countup",
-    "darkmatter",
-    "Undeletes",
-    "SSSZ"
-  ],
-  "dictionaries": ["npm", "softwareTerms", "node", "html", "css", "bash", "en_US", "en-gb", "misc"],
-  "ignorePaths": [
-    "package.json",
-    "dist/**",
-    "package-lock.json",
-    "node_modules",
-    "coverage",
-    "*.log",
-    "html-test-results",
-    "test-results"
-  ]
-}

.eslintrc.cjs

@@ -1,192 +0,0 @@
-const LEGACY_FILES = ['example/**'];
-/** @type {import('eslint').Linter.Config} */
-const config = {
-  env: {
-    browser: true,
-    es2024: true,
-    jasmine: true,
-    amd: true,
-    node: true
-  },
-  globals: {
-    _: 'readonly',
-    __webpack_public_path__: 'writeable',
-    __OPENMCT_VERSION__: 'readonly',
-    __OPENMCT_BUILD_DATE__: 'readonly',
-    __OPENMCT_REVISION__: 'readonly',
-    __OPENMCT_BUILD_BRANCH__: 'readonly'
-  },
-  plugins: ['prettier', 'unicorn', 'simple-import-sort'],
-  extends: [
-    'eslint:recommended',
-    'plugin:compat/recommended',
-    'plugin:vue/vue3-recommended',
-    'plugin:you-dont-need-lodash-underscore/compatible',
-    'plugin:prettier/recommended',
-    'plugin:no-unsanitized/DOM'
-  ],
-  parser: 'vue-eslint-parser',
-  parserOptions: {
-    parser: '@babel/eslint-parser',
-    requireConfigFile: false,
-    allowImportExportEverywhere: true,
-    ecmaVersion: 'latest',
-    ecmaFeatures: {
-      impliedStrict: true
-    },
-    sourceType: 'module'
-  },
-  rules: {
-    'simple-import-sort/imports': 'warn',
-    'simple-import-sort/exports': 'warn',
-    'vue/no-deprecated-dollar-listeners-api': 'warn',
-    'vue/no-deprecated-events-api': 'warn',
-    'vue/no-v-for-template-key': 'off',
-    'vue/no-v-for-template-key-on-child': 'error',
-    'vue/component-name-in-template-casing': ['error', 'PascalCase'],
-    'prettier/prettier': 'error',
-    'you-dont-need-lodash-underscore/omit': 'off',
-    'you-dont-need-lodash-underscore/throttle': 'off',
-    'you-dont-need-lodash-underscore/flatten': 'off',
-    'you-dont-need-lodash-underscore/get': 'off',
-    'no-bitwise': 'error',
-    curly: 'error',
-    eqeqeq: 'error',
-    'guard-for-in': 'error',
-    'no-extend-native': 'error',
-    'no-inner-declarations': 'off',
-    'no-use-before-define': ['error', 'nofunc'],
-    'no-caller': 'error',
-    'no-irregular-whitespace': 'error',
-    'no-new': 'error',
-    'no-shadow': 'error',
-    'no-undef': 'error',
-    'no-unused-vars': [
-      'error',
-      {
-        vars: 'all',
-        args: 'none'
-      }
-    ],
-    'no-console': 'off',
-    'new-cap': [
-      'error',
-      {
-        capIsNew: false,
-        properties: false
-      }
-    ],
-    'dot-notation': 'error',
-
-    // https://eslint.org/docs/rules/no-case-declarations
-    'no-case-declarations': 'error',
-    // https://eslint.org/docs/rules/max-classes-per-file
-    'max-classes-per-file': ['error', 1],
-    // https://eslint.org/docs/rules/no-eq-null
-    'no-eq-null': 'error',
-    // https://eslint.org/docs/rules/no-eval
-    'no-eval': 'error',
-    // https://eslint.org/docs/rules/no-implicit-globals
-    'no-implicit-globals': 'error',
-    // https://eslint.org/docs/rules/no-implied-eval
-    'no-implied-eval': 'error',
-    // https://eslint.org/docs/rules/no-lone-blocks
-    'no-lone-blocks': 'error',
-    // https://eslint.org/docs/rules/no-loop-func
-    'no-loop-func': 'error',
-    // https://eslint.org/docs/rules/no-new-func
-    'no-new-func': 'error',
-    // https://eslint.org/docs/rules/no-new-wrappers
-    'no-new-wrappers': 'error',
-    // https://eslint.org/docs/rules/no-octal-escape
-    'no-octal-escape': 'error',
-    // https://eslint.org/docs/rules/no-proto
-    'no-proto': 'error',
-    // https://eslint.org/docs/rules/no-return-await
-    'no-return-await': 'error',
-    // https://eslint.org/docs/rules/no-script-url
-    'no-script-url': 'error',
-    // https://eslint.org/docs/rules/no-self-compare
-    'no-self-compare': 'error',
-    // https://eslint.org/docs/rules/no-sequences
-    'no-sequences': 'error',
-    // https://eslint.org/docs/rules/no-unmodified-loop-condition
-    'no-unmodified-loop-condition': 'error',
-    // https://eslint.org/docs/rules/no-useless-call
-    'no-useless-call': 'error',
-    // https://eslint.org/docs/rules/no-nested-ternary
-    'no-nested-ternary': 'error',
-    // https://eslint.org/docs/rules/no-useless-computed-key
-    'no-useless-computed-key': 'error',
-    // https://eslint.org/docs/rules/no-var
-    'no-var': 'error',
-    // https://eslint.org/docs/rules/one-var
-    'one-var': ['error', 'never'],
-    // https://eslint.org/docs/rules/default-case-last
-    'default-case-last': 'error',
-    // https://eslint.org/docs/rules/default-param-last
-    'default-param-last': 'error',
-    // https://eslint.org/docs/rules/grouped-accessor-pairs
-    'grouped-accessor-pairs': 'error',
-    // https://eslint.org/docs/rules/no-constructor-return
-    'no-constructor-return': 'error',
-    // https://eslint.org/docs/rules/array-callback-return
-    'array-callback-return': 'error',
-    // https://eslint.org/docs/rules/no-invalid-this
-    'no-invalid-this': 'error', // Believe this one actually surfaces some bugs
-    // https://eslint.org/docs/rules/func-style
-    'func-style': ['error', 'declaration'],
-    // https://eslint.org/docs/rules/no-unused-expressions
-    'no-unused-expressions': 'error',
-    // https://eslint.org/docs/rules/no-useless-concat
-    'no-useless-concat': 'error',
-    // https://eslint.org/docs/rules/radix
-    radix: 'error',
-    // https://eslint.org/docs/rules/require-await
-    'require-await': 'error',
-    // https://eslint.org/docs/rules/no-alert
-    'no-alert': 'error',
-    // https://eslint.org/docs/rules/no-useless-constructor
-    'no-useless-constructor': 'error',
-    // https://eslint.org/docs/rules/no-duplicate-imports
-    'no-duplicate-imports': 'error',
-
-    // https://eslint.org/docs/rules/no-implicit-coercion
-    'no-implicit-coercion': 'error',
-    //https://eslint.org/docs/rules/no-unneeded-ternary
-    'no-unneeded-ternary': 'error',
-    'unicorn/filename-case': [
-      'error',
-      {
-        cases: {
-          pascalCase: true
-        },
-        ignore: ['^.*\\.(js|cjs|mjs)$']
-      }
-    ],
-    'vue/first-attribute-linebreak': 'error',
-    'vue/multiline-html-element-content-newline': 'off',
-    'vue/singleline-html-element-content-newline': 'off',
-    'vue/no-mutating-props': 'off' // TODO: Remove this rule and fix resulting errors
-  },
-  overrides: [
-    {
-      files: LEGACY_FILES,
-      rules: {
-        'no-unused-vars': [
-          'error',
-          {
-            vars: 'all',
-            args: 'none',
-            varsIgnorePattern: 'controller'
-          }
-        ],
-        'no-nested-ternary': 'off',
-        'no-var': 'off',
-        'one-var': 'off'
-      }
-    }
-  ]
-};
-
-module.exports = config;

.git-blame-ignore-revs

@@ -1,16 +0,0 @@
-# git-blame ignored revisions
-# To configure, run:
-#   git config blame.ignoreRevsFile .git-blame-ignore-revs
-# Requires Git > 2.23
-# See https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt
-
-# vue-eslint update 2019
-14a0f84c1bcd56886d7c9e4e6afa8f7d292734e5
-# eslint changes 2022
-d80b6923541704ab925abf0047cbbc58735c27e2
-# Copyright year update 2022
-4a9744e916d24122a81092f6b7950054048ba860
-# Copyright year update 2023
-8040b275fcf2ba71b42cd72d4daa64bb25c19c2d
-# Apply `prettier` formatting
-caa7bc6faebc204f67aedae3e35fb0d0d3ce27a7

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,47 +0,0 @@
----
-name: Bug report
-about: File a Bug !
-title: ''
-labels: type:bug
-assignees: ''
-
----
-
-<!--- Focus on user impact in the title. Use the Summary Field to -->
-<!--- describe the problem technically. -->
-
-#### Summary
-<!--- A description of the issue encountered. When possible, a description -->
-<!--- of the impact of the issue. What use case does it impede?-->
-
-#### Expected vs Current Behavior
-<!--- Tell us what should have happened -->
-
-#### Steps to Reproduce
-<!--- Provide a link to a live example, or an unambiguous set of steps to -->
-<!--- reproduce this bug. Include code to reproduce, if relevant -->
-1.
-2.
-3.
-4.
-
-#### Environment
-<!--- If encountered on local machine, execute the following:
-<!--- npx envinfo --system --browsers --npmPackages --binaries --markdown -->
-* Open MCT Version: <!--- date of build, version, or SHA -->
-* Deployment Type: <!--- npm dev? VIPER Dev? openmct-yamcs? -->
-* OS:
-* Browser:
-
-#### Impact Check List
-<!--- Please select from the following options -->
-- [ ] Data loss or misrepresented data?
-- [ ] Regression? Did this used to work or has it always been broken?
-- [ ] Is there a workaround available?
-- [ ] Does this impact a critical component?
-- [ ] Is this just a visual bug with no functional impact?
-- [ ] Does this block the execution of e2e tests?
-- [ ] Does this have an impact on Performance?
-
-#### Additional Information
-<!--- Include any screenshots, gifs, or logs which will expedite triage -->

.github/ISSUE_TEMPLATE/config.yml

@@ -1,5 +0,0 @@
-blank_issues_enabled: true
-contact_links:
-  - name: Discussions
-    url: https://github.com/nasa/openmct/discussions
-    about: Have a question about the project?

.github/ISSUE_TEMPLATE/enhancement-request.md

@@ -1,20 +0,0 @@
----
-name: Enhancement request
-about: Suggest an enhancement or new improvement for this project
-title: ''
-labels: type:enhancement
-assignees: ''
-
----
-
-**Is your feature request related to a problem? Please describe.**
-A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
-
-**Describe the solution you'd like**
-A clear and concise description of what you want to happen.
-
-**Describe alternatives you've considered**
-A clear and concise description of any alternative solutions or features you've considered.
-
-**Additional context**
-Add any other context or screenshots about the feature request here.

.github/ISSUE_TEMPLATE/maintenance-type.md

@@ -1,11 +0,0 @@
----
-name: Maintenance
-about: Add, update or remove documentation, tests, or dependencies.
-title: ''
-labels: type:maintenance
-assignees: ''
-
----
-
-#### Summary
-<!--- Generally describe the purpose of the change. -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,28 +0,0 @@
-<!--- Note: Please open the PR in draft form until you are ready for active review. -->
-Closes <!--- Insert Issue Number(s) this PR addresses. Start by typing # will open a dropdown of recent issues. Note: this does not work on PRs which target release branches -->
-
-### Describe your changes:
-<!--- Describe your changes and add any comments about your approach either here or inline if code comments aren't added -->
-
-### All Submissions:
-
-* [ ] Have you followed the guidelines in our [Contributing document](https://github.com/nasa/openmct/blob/master/CONTRIBUTING.md)?
-* [ ] Have you checked to ensure there aren't other open [Pull Requests](https://github.com/nasa/openmct/pulls) for the same update/change?
-* [ ] Is this a [notable change](../docs/src/process/release.md) that will require a special callout in the release notes? For example, will this break compatibility with existing APIs or projects that consume these plugins?
-
-### Author Checklist
-
-* [ ] Changes address original issue?
-* [ ] Tests included and/or updated with changes?
-* [ ] Has this been smoke tested?
-* [ ] Have you associated this PR with a `type:` label? Note: this is not necessarily the same as the original issue.
-* [ ] Have you associated a milestone with this PR? Note: leave blank if unsure.
-* [ ] Testing instructions included in associated issue OR is this a dependency/testcase change?
-
-### Reviewer Checklist
-
-* [ ] Changes appear to address issue?
-* [ ] Reviewer has tested changes by following the provided instructions?
-* [ ] Changes appear not to be breaking changes?
-* [ ] Appropriate automated tests included?
-* [ ] Code style and in-line documentation are appropriate?

.github/codeql/codeql-config.yml

@@ -1,5 +0,0 @@
-name: 'Custom CodeQL config'
-
-paths-ignore:
-  # Ignore e2e tests and framework
-  - e2e

.github/dependabot.yml

@@ -1,42 +0,0 @@
-version: 2
-updates:
-  - package-ecosystem: 'npm'
-    directory: '/'
-    schedule:
-      interval: 'weekly'
-    open-pull-requests-limit: 10
-    rebase-strategy: 'disabled'
-    labels:
-      - 'pr:daveit'
-      - 'pr:e2e'
-      - 'type:maintenance'
-      - 'dependencies'
-      - 'pr:platform'
-    ignore:
-      #We have to source the playwright container which is not detected by Dependabot
-      - dependency-name: '@playwright/test'
-      - dependency-name: 'playwright-core'
-      #Lots of noise in these type patch releases.
-      - dependency-name: '@babel/eslint-parser'
-        update-types: ['version-update:semver-patch']
-      - dependency-name: 'eslint-plugin-vue'
-        update-types: ['version-update:semver-patch']
-      - dependency-name: 'babel-loader'
-        update-types: ['version-update:semver-patch']
-      - dependency-name: 'sinon'
-        update-types: ['version-update:semver-patch']
-      - dependency-name: 'moment-timezone'
-        update-types: ['version-update:semver-patch']
-      - dependency-name: '@types/lodash'
-        update-types: ['version-update:semver-patch']
-      - dependency-name: 'marked'
-        update-types: ['version-update:semver-patch']
-  - package-ecosystem: 'github-actions'
-    directory: '/'
-    schedule:
-      interval: 'daily'
-    rebase-strategy: 'disabled'
-    labels:
-      - 'pr:daveit'
-      - 'type:maintenance'
-      - 'dependencies'

.github/release.yml

@@ -1,26 +0,0 @@
-changelog:
-  categories:
-    - title: 💥 Notable Changes
-      labels:
-        - notable_change
-    - title: 🏕 Features
-      labels:
-        - type:feature
-    - title: 🎉 Enhancements
-      labels:
-        - type:enhancement
-      exclude:
-        labels:
-          - type:feature
-    - title: 🔧 Maintenance
-      labels:
-        - type:maintenance
-    - title: ⚡ Performance
-      labels:
-        - performance
-    - title: 👒 Dependencies
-      labels:
-        - dependencies
-    - title: 🐛 Bug Fixes
-      labels:
-        - "*"

.github/workflows/codeql-analysis.yml

@@ -1,44 +0,0 @@
-name: 'CodeQL'
-
-on:
-  push:
-    branches: [master, 'release/*']
-  pull_request:
-    branches: [master, 'release/*']
-    paths-ignore:
-      - '**/*Spec.js'
-      - '**/*.md'
-      - '**/*.txt'
-      - '**/*.yml'
-      - '**/*.yaml'
-      - '**/*.spec.js'
-      - '**/*.config.js'
-  schedule:
-    - cron: '28 21 * * 3'
-
-jobs:
-  analyze:
-    name: Analyze
-    runs-on: ubuntu-latest
-    permissions:
-      actions: read
-      contents: read
-      security-events: write
-
-    steps:
-      - name: Checkout repository
-        uses: actions/checkout@v4
-
-      # Initializes the CodeQL tools for scanning.
-      - name: Initialize CodeQL
-        uses: github/codeql-action/init@v3
-        with:
-          config-file: ./.github/codeql/codeql-config.yml
-          languages: javascript
-          queries: security-and-quality
-
-      - name: Autobuild
-        uses: github/codeql-action/autobuild@v3
-
-      - name: Perform CodeQL Analysis
-        uses: github/codeql-action/analyze@v3

.github/workflows/e2e-couchdb.yml

@@ -1,95 +0,0 @@
-name: 'e2e-couchdb'
-on:
-  push:
-    branches: master
-  workflow_dispatch:
-  pull_request:
-    types:
-      - labeled
-      - opened
-  schedule:
-    - cron: '0 0 * * *'
-jobs:
-  e2e-couchdb:
-    if: contains(github.event.pull_request.labels.*.name, 'pr:e2e:couchdb') || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch' || github.event.action == 'opened'
-    runs-on: ubuntu-latest
-    timeout-minutes: 60
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 'lts/hydrogen'
-
-      - name: Cache NPM dependencies
-        uses: actions/cache@v3
-        with:
-          path: ~/.npm
-          key: ${{ runner.os }}-node-${{ hashFiles('**/package.json') }}
-          restore-keys: |
-            ${{ runner.os }}-node-
-
-      - run: npm ci --no-audit --progress=false
-
-      - name: Login to DockerHub
-        uses: docker/login-action@v3
-        continue-on-error: true
-        with:
-          username: ${{ secrets.DOCKERHUB_USERNAME }}
-          password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-      - run: npx playwright@1.48.1 install
-
-      - name: Start CouchDB Docker Container and Init with Setup Scripts
-        run: |
-          export $(cat src/plugins/persistence/couch/.env.ci | xargs)
-          docker compose -f src/plugins/persistence/couch/couchdb-compose.yaml up --detach
-          sleep 3
-          bash src/plugins/persistence/couch/setup-couchdb.sh
-          bash src/plugins/persistence/couch/replace-localstorage-with-couchdb-indexhtml.sh
-
-      - name: Run CouchDB Tests
-        env:
-          COMMIT_INFO_SHA: ${{github.event.pull_request.head.sha }}
-        run: npm run test:e2e:couchdb
-      
-      - name: Generate Code Coverage Report
-        run: npm run cov:e2e:report
-
-      - name: Publish Results to Codecov.io
-        uses: codecov/codecov-action@v4
-        with:
-          token: ${{ secrets.CODECOV_TOKEN }}
-          files: ./coverage/e2e/lcov.info
-          flags: e2e-full
-          fail_ci_if_error: true
-          verbose: true
-
-      - name: Archive test results
-        if: success() || failure()
-        uses: actions/upload-artifact@v3
-        with:
-          path: test-results
-
-      - name: Archive html test results
-        if: success() || failure()
-        uses: actions/upload-artifact@v3
-        with:
-          path: html-test-results
-
-      - name: Remove pr:e2e:couchdb label (if present)
-        if: always()
-        uses: actions/github-script@v6
-        with:
-          script: |
-            const { owner, repo, number } = context.issue;
-            const labelToRemove = 'pr:e2e:couchdb';
-            try {
-              await github.rest.issues.removeLabel({
-                owner,
-                repo,
-                issue_number: number,
-                name: labelToRemove
-              });
-            } catch (error) {
-              core.warning(`Failed to remove ' + labelToRemove + ' label: ${error.message}`);
-            }

.github/workflows/e2e-flakefinder.yml

@@ -1,61 +0,0 @@
-name: 'pr:e2e:flakefinder'
-
-on:
-#  push:
-#    branches: master
-  workflow_dispatch:
-#  pull_request:
-#    types:
-#      - labeled
-#      - opened
-#  schedule:
-#    - cron: '0 0 * * *'
-
-jobs:
-  e2e-flakefinder:
-    if: contains(github.event.pull_request.labels.*.name, 'pr:e2e:flakefinder') || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch' || github.event.action == 'opened'
-    runs-on: ubuntu-latest
-    timeout-minutes: 120
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 'lts/hydrogen'
-
-      - name: Cache NPM dependencies
-        uses: actions/cache@v3
-        with:
-          path: ~/.npm
-          key: ${{ runner.os }}-node-${{ hashFiles('**/package.json') }}
-          restore-keys: |
-            ${{ runner.os }}-node-
-
-      - run: npx playwright@1.48.1 install
-      - run: npm ci --no-audit --progress=false
-
-      - name: Run E2E Tests (Repeated 10 Times)
-        run: npm run test:e2e:ci -- --retries=0 --repeat-each=10 --max-failures=50
-
-      - name: Archive test results
-        if: success() || failure()
-        uses: actions/upload-artifact@v3
-        with:
-          path: test-results
-
-      - name: Remove pr:e2e:flakefinder label (if present)
-        if: always()
-        uses: actions/github-script@v6
-        with:
-          script: |
-            const { owner, repo, number } = context.issue;
-            const labelToRemove = 'pr:e2e:flakefinder';
-            try {
-                await github.rest.issues.removeLabel({
-                owner,
-                repo,
-                issue_number: number,
-                name: labelToRemove
-                });
-            } catch (error) {
-                core.warning(`Failed to remove ' + labelToRemove + ' label: ${error.message}`);
-            }

.github/workflows/e2e-perf.yml

@@ -1,58 +0,0 @@
-name: 'e2e-perf'
-on:
-  push:
-    branches: master
-  workflow_dispatch:
-  pull_request:
-    types:
-      - labeled
-      - opened
-  schedule:
-    - cron: '0 0 * * *'
-jobs:
-  e2e-full:
-    if: contains(github.event.pull_request.labels.*.name, 'pr:e2e:perf') || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'
-    runs-on: ubuntu-latest
-    timeout-minutes: 60
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 'lts/hydrogen'
-
-      - name: Cache NPM dependencies
-        uses: actions/cache@v3
-        with:
-          path: ~/.npm
-          key: ${{ runner.os }}-node-${{ hashFiles('**/package.json') }}
-          restore-keys: |
-            ${{ runner.os }}-node-
-
-      - run: npx playwright@1.48.1 install
-      - run: npm ci --no-audit --progress=false
-      - run: npm run test:perf:localhost
-      - run: npm run test:perf:contract
-      - run: npm run test:perf:memory
-      - name: Archive test results
-        if: success() || failure()
-        uses: actions/upload-artifact@v3
-        with:
-          path: test-results
-
-      - name: Remove pr:e2e:perf label (if present)
-        if: always()
-        uses: actions/github-script@v6
-        with:
-          script: |
-            const { owner, repo, number } = context.issue;
-            const labelToRemove = 'pr:e2e:perf';
-            try {
-              await github.rest.issues.removeLabel({
-                owner,
-                repo,
-                issue_number: number,
-                name: labelToRemove
-              });
-            } catch (error) {
-              core.warning(`Failed to remove ' + labelToRemove + ' label: ${error.message}`);
-            }

.github/workflows/e2e-pr.yml

@@ -1,68 +0,0 @@
-name: 'e2e-pr'
-on:
-  push:
-    branches: master
-  workflow_dispatch:
-  pull_request:
-    types:
-      - labeled
-      - opened
-  schedule:
-    - cron: '0 0 * * *'
-jobs:
-  e2e-full:
-    if: contains(github.event.pull_request.labels.*.name, 'pr:e2e') || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'
-    runs-on: ${{ matrix.os }}
-    timeout-minutes: 60
-    strategy:
-      matrix:
-        os:
-          - ubuntu-latest
-          - windows-latest
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 'lts/hydrogen'
-
-      - name: Cache NPM dependencies
-        uses: actions/cache@v3
-        with:
-          path: ~/.npm
-          key: ${{ runner.os }}-node-${{ hashFiles('**/package.json') }}
-          restore-keys: |
-            ${{ runner.os }}-node-
-
-      - run: npx playwright@1.47.2 install
-      - run: npx playwright install chrome-beta
-      - run: npm ci --no-audit --progress=false
-      - run: npm run test:e2e:full -- --max-failures=40
-      - run: npm run cov:e2e:report || true
-      - shell: bash
-        env:
-          SUPER_SECRET: ${{ secrets.CODECOV_TOKEN }}
-        run: |
-          npm run cov:e2e:full:publish
-      - name: Archive test results
-        if: success() || failure()
-        uses: actions/upload-artifact@v3
-        with:
-          path: test-results
-
-      - name: Remove pr:e2e label (if present)
-        if: always()
-        uses: actions/github-script@v6
-        with:
-          script: |
-            const { owner, repo, number } = context.issue;
-            const labelToRemove = 'pr:e2e';
-            try {
-              await github.rest.issues.removeLabel({
-                owner,
-                repo,
-                issue_number: number,
-                name: labelToRemove
-              });
-            } catch (error) {
-              core.warning(`Failed to remove ' + labelToRemove + ' label: ${error.message}`);
-            }

.github/workflows/npm-prerelease.yml

@@ -1,37 +0,0 @@
-# This workflow will run tests using node and then publish a package to npmjs when a prerelease is created
-# For more information see: https://help.github.com/actions/language-and-framework-guides/publishing-nodejs-packages
-
-name: npm_prerelease
-
-on:
-  release:
-    types: [prereleased]
-
-jobs:
-  build:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: lts/hydrogen
-      - run: npm ci
-      - run: |
-          echo "//registry.npmjs.org/:_authToken=$NODE_AUTH_TOKEN" >> ~/.npmrc
-          npm whoami
-          npm publish --access=public --tag unstable openmct
-      # - run: npm test
-
-  publish-npm-prerelease:
-    needs: build
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: lts/hydrogen
-          registry-url: https://registry.npmjs.org/
-      - run: npm ci
-      - run: npm publish --access=public --tag unstable
-        env:
-          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

.github/workflows/pr-platform.yml

@@ -1,70 +0,0 @@
-name: 'pr-platform'
-on:
-  push:
-    branches: master
-  workflow_dispatch:
-  pull_request:
-    types:
-      - labeled
-      - opened
-  schedule:
-    - cron: '0 0 * * *'
-jobs:
-  pr-platform:
-    if: contains(github.event.pull_request.labels.*.name, 'pr:platform') || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'
-    runs-on: ${{ matrix.os }}
-    timeout-minutes: 60
-    strategy:
-      fail-fast: false
-      matrix:
-        os:
-          - ubuntu-latest
-          - macos-latest
-          - windows-latest
-        node_version:
-          - lts/iron
-          - lts/hydrogen
-        architecture:
-          - x64
-
-    name: Node ${{ matrix.node_version }} - ${{ matrix.architecture }} on ${{ matrix.os }}
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Setup node
-        uses: actions/setup-node@v4
-        with:
-          node-version: ${{ matrix.node_version }}
-          architecture: ${{ matrix.architecture }}
-
-      - name: Cache NPM dependencies
-        uses: actions/cache@v3
-        with:
-          path: ~/.npm
-          key: ${{ runner.os }}-${{ matrix.node_version }}-${{ hashFiles('**/package.json') }}
-          restore-keys: |
-            ${{ runner.os }}-${{ matrix.node_version }}-
-
-      - run: npm ci --no-audit --progress=false
-
-      - run: npm test
-
-      - run: npm run lint -- --quiet
-
-      - name: Remove pr:platform label (if present)
-        if: always()
-        uses: actions/github-script@v6
-        with:
-          script: |
-            const { owner, repo, number } = context.issue;
-            const labelToRemove = 'pr:platform';
-            try {
-              await github.rest.issues.removeLabel({
-                owner,
-                repo,
-                issue_number: number,
-                name: labelToRemove
-              });
-            } catch (error) {
-              core.warning(`Failed to remove ' + labelToRemove + ' label: ${error.message}`);
-            }

.github/workflows/prcop-config.json

@@ -1,19 +0,0 @@
-{
-  "linters": [
-    {
-      "name": "descriptionRegexp",
-      "config": {
-        "regexp": "[x|X]] Testing instructions",
-        "errorMessage": ":police_officer: PR Description does not confirm that associated issue(s) contain Testing instructions"
-      }
-    },
-    {
-      "name": "descriptionMinWords",
-      "config": {
-        "minWordsCount": 160,
-        "errorMessage": ":police_officer: Please, be sure to use existing PR template."
-      }
-    }
-  ],
-  "disableWord": "pr:daveit"
-}

.github/workflows/prcop.yml

@@ -1,40 +0,0 @@
-name: PRCop
-
-on:
-  pull_request:
-    types:
-      - labeled
-      - unlabeled
-      - milestoned
-      - demilestoned
-      - opened
-      - reopened
-      - synchronize
-      - edited
-  pull_request_review_comment:
-    types:
-      - created
-env:
-  LABELS: ${{ join( github.event.pull_request.labels.*.name, ' ' ) }}
-jobs:
-  prcop:
-    runs-on: ubuntu-latest
-    name: Template Check
-    steps:
-      - name: Linting Pull Request
-        uses: makaroni4/prcop@v1.0.35
-        with:
-          config-file: '.github/workflows/prcop-config.json'
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-  check-type-label:
-    name: Check type Label
-    runs-on: ubuntu-latest
-    steps:
-      - if: contains( env.LABELS, 'type:' ) == false
-        run: exit 1
-  check-milestone:
-    name: Check Milestone
-    runs-on: ubuntu-latest
-    steps:
-      - if: github.event.pull_request.milestone == null && contains( env.LABELS, 'no milestone' ) == false
-        run: exit 1

.gitignore

@@ -3,50 +3,30 @@
 *.gzip
 *.tgz
 *.DS_Store
-*.swp
 
-# Compiled CSS, unless directly added
 *.sass-cache
 *COMPILE.css
-*.css
-*.css.map
 
 # Intellij project configuration files
 *.idea
 *.iml
 
-# VSCode
-.vscode/settings.json
+# External dependencies
 
 # Build output
 target
-dist
 
 # Mac OS X Finder
 .DS_Store
 
-# Node, Bower dependencies
+# Closed source libraries
+closed-lib
+
+# Node dependencies
 node_modules
-bower_components
+
+# Protractor logs
+protractor/logs
 
 # npm-debug log
 npm-debug.log
-
-# karma reports
-report.*.json
-
-# e2e test artifacts
-test-results
-html-test-results
-
-# couchdb scripting artifacts
-src/plugins/persistence/couch/.env.local
-index.html.bak
-
-# codecov artifacts
-.nyc_output
-coverage
-codecov
-
-# Don't commit MacOS screenshots
-*-darwin.png

.npmignore

@@ -1,27 +0,0 @@
-# Ignore everything first (will not ignore special files like LICENSE.md,
-# README.md, and package.json)...
-/**/*
-
-# ...but include these folders...
-!/dist/**/*
-!/src/**/*
-
-# We might be able to remove this if it is not imported by any project directly.
-# https://github.com/nasa/openmct/issues/4992
-!/example/**/*
-
-# ...except for these files in the above folders.
-/src/**/*Spec.js
-/src/**/test/
-# TODO move test utils into test/ folders
-/src/utils/testing.js
-
-# Also include these special top-level files.
-!copyright-notice.js
-!copyright-notice.html
-!index.html
-!openmct.js
-!SECURITY.md
-
-# Dont include the example html
-dist/index.html

.npmrc

@@ -1,4 +0,0 @@
-loglevel=warn
-
-#Prevent folks from ignoring an important error when building from source
-engine-strict=true

.nvmrc

@@ -1 +0,0 @@
-lts/*

.prettierignore

@@ -1,27 +0,0 @@
-# Docs
-*.md
-
-# Build output
-target
-dist
-
-# Mac OS X Finder
-.DS_Store
-
-# Node dependencies
-node_modules
-
-# npm-debug log
-npm-debug.log
-
-# karma reports
-report.*.json
-
-# e2e test artifacts
-test-results
-html-test-results
-
-# codecov artifacts
-.nyc_output
-coverage
-codecov

.prettierrc

@@ -1,6 +0,0 @@
-{
-  "trailingComma": "none",
-  "singleQuote": true,
-  "printWidth": 100,
-  "endOfLine": "auto"
-}

.vscode/extensions.json

@@ -1,13 +0,0 @@
-{
-  // See https://go.microsoft.com/fwlink/?LinkId=827846 to learn about workspace recommendations.
-  // Extension identifier format: ${publisher}.${name}. Example: vscode.csharp
-
-  // List of extensions which should be recommended for users of this workspace.
-  "recommendations": [
-    "Vue.volar",
-    "dbaeumer.vscode-eslint",
-    "rvest.vs-code-prettier-eslint"
-  ],
-  // List of extensions recommended by VS Code that should not be recommended for users of this workspace.
-  "unwantedRecommendations": ["octref.vetur"]
-}

.webpack/webpack.common.mjs

@@ -1,188 +0,0 @@
-/*
-This is the OpenMCT common webpack file. It is imported by the other three webpack configurations:
- - webpack.prod.mjs - the production configuration for OpenMCT (default)
- - webpack.dev.mjs - the development configuration for OpenMCT
- - webpack.coverage.mjs - imports webpack.dev.js and adds code coverage
-There are separate npm scripts to use these configurations, though simply running `npm install`
-will use the default production configuration.
-*/
-import { execSync } from 'node:child_process';
-import fs from 'node:fs';
-import path from 'node:path';
-import { fileURLToPath } from 'node:url';
-
-import CopyWebpackPlugin from 'copy-webpack-plugin';
-import MiniCssExtractPlugin from 'mini-css-extract-plugin';
-import { VueLoaderPlugin } from 'vue-loader';
-import webpack from 'webpack';
-import { merge } from 'webpack-merge';
-let gitRevision = 'error-retrieving-revision';
-let gitBranch = 'error-retrieving-branch';
-
-const { version } = JSON.parse(fs.readFileSync(new URL('../package.json', import.meta.url)));
-
-try {
-  gitRevision = execSync('git rev-parse HEAD').toString().trim();
-  gitBranch = execSync('git rev-parse --abbrev-ref HEAD').toString().trim();
-} catch (err) {
-  console.warn(err);
-}
-
-const projectRootDir = fileURLToPath(new URL('../', import.meta.url));
-
-/** @type {import('webpack').Configuration} */
-const config = {
-  context: projectRootDir,
-  devServer: {
-    client: {
-      progress: true,
-      overlay: {
-        // Disable overlay for runtime errors.
-        // See: https://github.com/webpack/webpack-dev-server/issues/4771
-        runtimeErrors: false
-      }
-    }
-  },
-  entry: {
-    openmct: './openmct.js',
-    generatorWorker: './example/generator/generatorWorker.js',
-    couchDBChangesFeed: './src/plugins/persistence/couch/CouchChangesFeed.js',
-    inMemorySearchWorker: './src/api/objects/InMemorySearchWorker.js',
-    espressoTheme: './src/plugins/themes/espresso-theme.scss',
-    snowTheme: './src/plugins/themes/snow-theme.scss',
-    darkmatterTheme: './src/plugins/themes/darkmatter-theme.scss'
-  },
-  output: {
-    globalObject: 'this',
-    filename: '[name].js',
-    path: path.resolve(projectRootDir, 'dist'),
-    library: {
-      name: 'openmct',
-      type: 'umd',
-      export: 'default'
-    },
-    publicPath: '',
-    hashFunction: 'xxhash64',
-    clean: true
-  },
-  resolve: {
-    alias: {
-      '@': path.join(projectRootDir, 'src'),
-      legacyRegistry: path.join(projectRootDir, 'src/legacyRegistry'),
-      csv: 'comma-separated-values',
-      bourbon: 'bourbon.scss',
-      'plotly-basic': 'plotly.js-basic-dist-min',
-      'plotly-gl2d': 'plotly.js-gl2d-dist-min',
-      printj: 'printj/printj.mjs',
-      styles: path.join(projectRootDir, 'src/styles'),
-      MCT: path.join(projectRootDir, 'src/MCT'),
-      testUtils: path.join(projectRootDir, 'src/utils/testUtils.js'),
-      objectUtils: path.join(projectRootDir, 'src/api/objects/object-utils.js'),
-      utils: path.join(projectRootDir, 'src/utils'),
-      vue: 'vue/dist/vue.esm-bundler'
-    }
-  },
-  plugins: [
-    new webpack.DefinePlugin({
-      __OPENMCT_VERSION__: `'${version}'`,
-      __OPENMCT_BUILD_DATE__: `'${new Date()}'`,
-      __OPENMCT_REVISION__: `'${gitRevision}'`,
-      __OPENMCT_BUILD_BRANCH__: `'${gitBranch}'`,
-      __VUE_OPTIONS_API__: true, // enable/disable Options API support, default: true
-      __VUE_PROD_DEVTOOLS__: false // enable/disable devtools support in production, default: false
-    }),
-    new VueLoaderPlugin(),
-    new CopyWebpackPlugin({
-      patterns: [
-        {
-          from: 'src/images/favicons',
-          to: 'favicons'
-        },
-        {
-          from: './index.html',
-          transform: function (content) {
-            return content.toString().replace(/dist\//g, '');
-          }
-        },
-        {
-          from: 'src/plugins/imagery/layers',
-          to: 'imagery'
-        }
-      ]
-    }),
-    new MiniCssExtractPlugin({
-      filename: '[name].css',
-      chunkFilename: '[name].css'
-    }),
-    // Add a UTF-8 BOM to CSS output to avoid random mojibake
-    new webpack.BannerPlugin({
-      test: /.*Theme\.css$/,
-      raw: true,
-      banner: '@charset "UTF-8";'
-    })
-  ],
-  module: {
-    rules: [
-      {
-        test: /\.(sc|sa|c)ss$/,
-        use: [
-          MiniCssExtractPlugin.loader,
-          {
-            loader: 'css-loader'
-          },
-          {
-            loader: 'resolve-url-loader'
-          },
-          {
-            loader: 'sass-loader',
-            options: { sourceMap: true }
-          }
-        ]
-      },
-      {
-        test: /\.vue$/,
-        loader: 'vue-loader',
-        options: {
-          compilerOptions: {
-            hoistStatic: false,
-            whitespace: 'preserve'
-          }
-        }
-      },
-      {
-        test: /\.html$/,
-        type: 'asset/source'
-      },
-      {
-        test: /\.(jpg|jpeg|png|svg)$/,
-        type: 'asset/resource',
-        generator: {
-          filename: 'images/[name][ext]'
-        }
-      },
-      {
-        test: /\.ico$/,
-        type: 'asset/resource',
-        generator: {
-          filename: 'icons/[name][ext]'
-        }
-      },
-      {
-        test: /\.(woff|woff2?|eot|ttf)$/,
-        type: 'asset/resource',
-        generator: {
-          filename: 'fonts/[name][ext]'
-        }
-      }
-    ]
-  },
-  stats: 'errors-warnings',
-  performance: {
-    // We should eventually consider chunking to decrease
-    // these values
-    maxEntrypointSize: 27000000,
-    maxAssetSize: 27000000
-  }
-};
-
-export default config;

.webpack/webpack.coverage.mjs

@@ -1,31 +0,0 @@
-/*
-This file extends the webpack.dev.mjs config to add babel istanbul coverage.
-OpenMCT Continuous Integration servers use this configuration to add code coverage
-information to pull requests.
-*/
-
-import config from './webpack.dev.mjs';
-
-config.devtool = 'inline-source-map';
-config.devServer.hot = false;
-
-config.module.rules.push({
-  test: /\.js$/,
-  exclude: /(Spec\.js$)|(node_modules)/,
-  use: {
-    loader: 'babel-loader',
-    options: {
-      retainLines: true,
-      plugins: [
-        [
-          'babel-plugin-istanbul',
-          {
-            extension: ['.js', '.vue']
-          }
-        ]
-      ]
-    }
-  }
-});
-
-export default config;

.webpack/webpack.dev.mjs

@@ -1,49 +0,0 @@
-/*
-This configuration should be used for development purposes. It contains full source map, a
-devServer (which be invoked using by `npm start`), and a non-minified Vue.js distribution.
-If OpenMCT is to be used for a production server, use webpack.prod.mjs instead.
-*/
-import { fileURLToPath } from 'node:url';
-
-import path from 'path';
-import webpack from 'webpack';
-import { merge } from 'webpack-merge';
-
-import common from './webpack.common.mjs';
-
-export default merge(common, {
-  mode: 'development',
-  watchOptions: {
-    // Since we use require.context, webpack is watching the entire directory.
-    // We need to exclude any files we don't want webpack to watch.
-    // See: https://webpack.js.org/configuration/watch/#watchoptions-exclude
-    ignored: [
-      '**/{node_modules,dist,docs,e2e}', // All files in node_modules, dist, docs, e2e,
-      '**/{*.yml,Procfile,webpack*.js,babel*.js,package*.json,tsconfig.json}', // Config files
-      '**/*.{sh,md,png,ttf,woff,svg}', // Non source files
-      '**/.*' // dotfiles and dotfolders
-    ]
-  },
-  plugins: [
-    new webpack.DefinePlugin({
-      __OPENMCT_ROOT_RELATIVE__: '"dist/"'
-    })
-  ],
-  devtool: 'eval-source-map',
-  devServer: {
-    devMiddleware: {
-      writeToDisk: (filePathString) => {
-        const filePath = path.parse(filePathString);
-        const shouldWrite = !filePath.base.includes('hot-update');
-
-        return shouldWrite;
-      }
-    },
-    watchFiles: ['src/**/*.css', 'example/**/*.css'],
-    static: {
-      directory: fileURLToPath(new URL('../dist', import.meta.url)),
-      publicPath: '/dist',
-      watch: false
-    }
-  }
-});

.webpack/webpack.prod.mjs

@@ -1,19 +0,0 @@
-/*
-This configuration should be used for production installs.
-It is the default webpack configuration.
-*/
-
-import webpack from 'webpack';
-import { merge } from 'webpack-merge';
-
-import common from './webpack.common.mjs';
-
-export default merge(common, {
-  mode: 'production',
-  plugins: [
-    new webpack.DefinePlugin({
-      __OPENMCT_ROOT_RELATIVE__: '""'
-    })
-  ],
-  devtool: 'eval-source-map'
-});

CONTRIBUTING.md

@@ -1,6 +1,6 @@
-# Contributing to Open MCT
+# Contributing to Open MCT Web
 
-This document describes the process of contributing to Open MCT as well
+This document describes the process of contributing to Open MCT Web as well
 as the standards that will be applied when evaluating contributions.
 
 Please be aware that additional agreements will be necessary before we can
@@ -10,7 +10,7 @@ accept changes from external contributors.
 
 The short version:
 
-1. Write your contribution or describe your idea in the form of a [GitHub issue](https://github.com/nasa/openmct/issues/new/choose) or [start a GitHub discussion](https://github.com/nasa/openmct/discussions).
+1. Write your contribution.
 2. Make sure your contribution meets code, test, and commit message
    standards as described below.
 3. Submit a pull request from a topic branch back to `master`. Include a check
@@ -18,13 +18,12 @@ The short version:
    for review.)
 4. Respond to any discussion. When the reviewer decides it's ready, they
    will merge back `master` and fill out their own check list.
-5. If you are a first-time contributor, please see [this discussion](https://github.com/nasa/openmct/discussions/3821) for further information.
 
 ## Contribution Process
 
-Open MCT uses git for software version control, and for branching and
+Open MCT Web uses git for software version control, and for branching and
 merging. The central repository is at
-<https://github.com/nasa/openmct.git>.
+https://github.com/nasa/openmctweb.git.
 
 ### Roles
 
@@ -44,9 +43,9 @@ the check-in process. These roles are:
 
 Three basic types of branches may be included in the above repository:
 
-1. Master branch
-2. Topic branches
-3. Developer branches
+1. Master branch.
+2. Topic branches.
+3. Developer branches.
 
 Branches which do not fit into the above categories may be created and used
 during the course of development for various reasons, such as large-scale
@@ -104,138 +103,128 @@ the name chosen could not be mistaken for a topic or master branch.
 ### Merging
 
 When development is complete on an issue, the first step toward merging it
-back into the master branch is to file a Pull Request (PR). The contributions
+back into the master branch is to file a Pull Request. The contributions
 should meet code, test, and commit message standards as described below,
 and the pull request should include a completed author checklist, also
 as described below. Pull requests may be assigned to specific team
-members when appropriate (e.g. to draw to a specific person's attention).
+members when appropriate (e.g. to draw to a specific person's attention.)
 
 Code review should take place using discussion features within the pull
 request. When the reviewer is satisfied, they should add a comment to
 the pull request containing the reviewer checklist (from below) and complete
 the merge back to the master branch.
 
-Additionally:
-
-* Every pull request must link to the issue that it addresses. Eg. “Addresses #1234” or “Closes #1234”. This is the responsibility of the pull request’s __author__. If no issue exists, [create one](https://github.com/nasa/openmct/issues/new/choose).
-* Every __author__ must include testing instructions. These instructions should identify the areas of code affected, and some minimal test steps. If addressing a bug, reproduction steps should be included, if they were not included in the original issue. If reproduction steps were included on the original issue, and are sufficient, refer to them.
-* A pull request that closes an issue should say so in the description. Including the text “Closes #1234” will cause the linked issue to be automatically closed when the pull request is merged. This is the responsibility of the pull request’s __author__.
-* When a pull request is merged, and the corresponding issue closed, the __reviewer__ must add the tag “unverified” to the original issue. This will indicate that although the issue is closed, it has not been tested yet.
-* Every PR must have two reviewers assigned, though only one approval is necessary for merge.
-* Changes to API require approval by a senior developer.
-* When creating a PR, it is the author's responsibility to apply any priority label from the issue to the PR as well. This helps with prioritization.
-
 ## Standards
 
-Contributions to Open MCT are expected to meet the following standards.
+Contributions to Open MCT Web are expected to meet the following standards.
 In addition, reviewers should use general discretion before accepting
 changes.
 
 ### Code Standards
 
-JavaScript sources in Open MCT must satisfy the [ESLint](https://eslint.org/) rules defined in
-this repository. [Prettier](https://prettier.io/) is used in conjunction with ESLint to enforce code style
-via automated formatting. These are verified by the command line build.
+JavaScript sources in Open MCT Web must satisfy JSLint under its default
+settings. This is verified by the command line build.
 
 #### Code Guidelines
 
-The following guidelines are provided for anyone contributing source code to the Open MCT project:
+JavaScript sources in Open MCT Web should:
 
-1. Write clean code. Here’s a good summary - <https://github.com/ryanmcdermott/clean-code-javascript>.
-1. Include JSDoc for any exposed API (e.g. public methods, classes).
-1. Include non-JSDoc comments as-needed for explaining private variables,
-   methods, or algorithms when they are non-obvious. Otherwise code
-   should be self-documenting.
-1. Classes and Vue components should use camel case, first letter capitalized
-   (e.g. SomeClassName).
-1. Methods, variables, fields, events, and function names should use camelCase,
-   first letter lower-case (e.g. someVariableName).
-1. Source files that export functions should use camelCase, first letter lower-case (eg. testTools.js)
-1. Constants (variables or fields which are meant to be declared and
-   initialized statically, and never changed) should use only capital
-   letters, with underscores between words (e.g. SOME_CONSTANT). They should always be declared as `const`s
-1. File names should be the name of the exported class, plus a .js extension
-   (e.g. SomeClassName.js).
-1. Avoid anonymous functions, except when functions are short (one or two lines)
-   and their inclusion makes sense within the flow of the code
-   (e.g. as arguments to a forEach call). Anonymous functions should always be arrow functions.
-1. Named functions are preferred over functions assigned to variables.
-   eg.
+* Use four spaces for indentation. Tabs should not be used.
+* Include JSDoc for any exposed API (e.g. public methods, constructors.)
+* Include non-JSDoc comments as-needed for explaining private variables,
+  methods, or algorithms when they are non-obvious.
+* Define one public class per script, expressed as a constructor function
+  returned from an AMD-style module.
+* Follow “Java-like” naming conventions. These includes:
+  * Classes should use camel case, first letter capitalized
+    (e.g. SomeClassName.)
+  * Methods, variables, fields, and function names should use camel case,
+    first letter lower-case (e.g. someVariableName.) Constants
+    (variables or fields which are meant to be declared and initialized
+    statically, and never changed) should use only capital letters, with
+    underscores between words (e.g. SOME_CONSTANT.)
+  * File name should be the name of the exported class, plus a .js extension
+    (e.g. SomeClassName.js)
+* Avoid anonymous functions, except when functions are short (a few lines)
+  and/or their inclusion makes sense within the flow of the code
+  (e.g. as arguments to a forEach call.)
+* Avoid deep nesting (especially of functions), except where necessary
+  (e.g. due to closure scope.)
+* End with a single new-line character.
+* Expose public methods by declaring them on the class's prototype.
+* Within a given function's scope, do not mix declarations and imperative
+  code, and  present these in the following order:
+  * First, variable declarations and initialization.
+  * Second, function declarations.
+  * Third, imperative statements.
+  * Finally, the returned value.
 
-   ```JavaScript
-   function renameObject(object, newName) {
-       Object.name = newName;
-   }
-   ```
-
-   is preferable to
-
-   ```JavaScript
-   const rename = (object, newName) => {
-       Object.name = newName;
-   }
-   ```
-
-1. Avoid deep nesting (especially of functions), except where necessary
-   (e.g. due to closure scope).
-1. End with a single new-line character.
-1. Always use ES6 `Class`es and inheritance rather than the pre-ES6 prototypal
-   pattern.
-1. Within a given function's scope, do not mix declarations and imperative
-   code, and  present these in the following order:
-   * First, variable declarations and initialization.
-   * Secondly, imperative statements.
-   * Finally, the returned value. A single return statement at the end of the function should be used, except where an early return would improve code clarity.
-1. Avoid the use of "magic" values.
-   eg.
-
-   ```JavaScript
-   const UNAUTHORIZED = 401;
-   if (responseCode === UNAUTHORIZED)
-   ```
-
-   is preferable to
-
-   ```JavaScript
-   if (responseCode === 401)
-   ```
-
-1. Use the ternary operator only for simple cases such as variable assignment. Nested ternaries should be avoided in all cases.
-1. Unit Test specs should reside alongside the source code they test, not in a separate directory.
-1. Organize code by feature, not by type.
-   eg.
-
-   ```txt
-   - telemetryTable
-       - row
-           TableRow.js
-           TableRowCollection.js
-           TableRow.vue
-       - column
-           TableColumn.js
-           TableColumn.vue
-       plugin.js
-       pluginSpec.js
-   ```
-
-   is preferable to
-
-   ```txt
-   - telemetryTable
-       - components
-           TableRow.vue
-           TableColumn.vue
-       - collections
-           TableRowCollection.js
-       TableColumn.js
-       TableRow.js
-       plugin.js
-       pluginSpec.js
-   ```
-
-Deviations from Open MCT code style guidelines require two-party agreement,
+Deviations from Open MCT Web code style guidelines require two-party agreement,
 typically from the author of the change and its reviewer.
 
+#### Code Example
+
+```js
+/*global define*/
+
+/**
+ * Bundles should declare themselves as namespaces in whichever source
+ * file is most like the "main point of entry" to the bundle.
+ * @namespace some/bundle
+ */
+define(
+    ['./OtherClass'],
+    function (OtherClass) {
+        "use strict";
+
+        /**
+         * A summary of how to use this class goes here.
+         *
+         * @constructor
+         * @memberof some/bundle
+         */
+        function ExampleClass() {
+        }
+
+        // Methods which are not intended for external use should
+        // not have JSDoc (or should be marked @private)
+        ExampleClass.prototype.privateMethod = function () {
+        };
+
+        /**
+         * A summary of this method goes here.
+         * @param {number} n a parameter
+         * @returns {number} a return value
+         */
+        ExampleClass.prototype.publicMethod = function (n) {
+            return n * 2;
+        }
+
+        return ExampleClass;
+    }
+);
+```
+
+### Test Standards
+
+Automated testing shall occur whenever changes are merged into the main
+development branch and must be confirmed alongside any pull request.
+
+Automated tests are typically unit tests which exercise individual software
+components. Tests are subject to code review along with the actual
+implementation, to ensure that tests are applicable and useful.
+
+Examples of useful tests:
+* Tests which replicate bugs (or their root causes) to verify their
+  resolution.
+* Tests which reflect details from software specifications.
+* Tests which exercise edge or corner cases among inputs.
+* Tests which verify expected interactions with other components in the
+  system.
+
+During automated testing, code coverage metrics will be reported. Line
+coverage must remain at or above 80%.
+
 ### Commit Message Standards
 
 Commit messages should:
@@ -245,7 +234,7 @@ Commit messages should:
   line of white space.
 * Contain a short (usually one word) reference to the feature or subsystem
   the commit effects, in square brackets, at the start of the subject line
-  (e.g. `[Documentation] Draft of check-in process`).
+  (e.g. `[Documentation] Draft of check-in process`)
 * Contain a reference to a relevant issue number in the body of the commit.
   * This is important for traceability; while branch names also provide this,
     you cannot tell from looking at a commit what branch it was authored on.
@@ -261,9 +250,9 @@ Commit messages should:
 Commit messages should not:
 
 * Exceed 54 characters in length on the subject line.
-* Exceed 72 characters in length in the body of the commit,
+* Exceed 72 characters in length in the body of the commit.
   * Except where necessary to maintain the structure of machine-readable or
-    machine-generated text (e.g. error messages).
+    machine-generated text (e.g. error messages)
 
 See [Contributing to a Project](http://git-scm.com/book/ch5-2.html) from
 Pro Git by Shawn Chacon and Ben Straub for a bit of the rationale behind
@@ -271,19 +260,42 @@ these standards.
 
 ## Issue Reporting
 
-Issues are tracked at <https://github.com/nasa/openmct/issues>.
+Issues are tracked at https://github.com/nasa/openmctweb/issues
+
+Issues should include:
+
+* A short description of the issue encountered.
+* A longer-form description of the issue encountered. When possible, steps to
+  reproduce the issue.
+* When possible, a description of the impact of the issue. What use case does
+  it impede?
+* An assessment of the severity of the issue.
 
 Issue severity is categorized as follows (in ascending order):
 
-* _Trivial_: Minimal impact on the usefulness and functionality of the software; a "nice-to-have." Visual impact without functional impact,
-* _Medium_: Some impairment of use, but simple workarounds exist
-* _Critical_: Significant loss of functionality or impairment of use. Display of telemetry data is not affected though. Complex workarounds exist.
-* _Blocker_: Major functionality is impaired or lost, threatening mission success. Display of telemetry data is impaired or blocked by the bug, which could lead to loss of situational awareness.
+* _Trivial_: Minimal impact on the usefulness and functionality of the
+  software; a "nice-to-have."
+* _(Unspecified)_: Major loss of functionality or impairment of use.
+* _Critical_: Large-scale loss of functionality or impairment of use,
+  such that remaining utility becomes marginal.
+* _Blocker_: Harmful or otherwise unacceptable behavior. Must fix.
 
 ## Check Lists
 
 The following check lists should be completed and attached to pull requests
 when they are filed (author checklist) and when they are merged (reviewer
-checklist).
+checklist.)
 
-[Within PR Template](.github/PULL_REQUEST_TEMPLATE.md)
+### Author Checklist
+
+1. Changes address original issue?
+2. Unit tests included and/or updated with changes?
+3. Command line build passes?
+4. Expect to pass code review?
+
+### Reviewer Checklist
+
+1. Changes appear to address issue?
+2. Appropriate unit tests included?
+3. Code style and in-line documentation are appropriate?
+4. Commit messages meet standards?

LICENSE.md

@@ -1,7 +0,0 @@
-# Open MCT License
-
-Open MCT, Copyright (c) 2014-2024, United States Government as represented by the Administrator of the National Aeronautics and Space Administration. All rights reserved.
-
-Open MCT is licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.  You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0.
-
-Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

LICENSES.md

@@ -0,0 +1,452 @@
+# Open MCT Web Licenses
+
+Open MCT Web, Copyright (c) 2014-2015, United States Government as represented by the Administrator of the National Aeronautics and Space Administration. All rights reserved.
+
+Open MCT Web is licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.  You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0.
+
+Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+Open MCT Web includes source code licensed under additional open source licenses as follows.
+
+## Software Components Licenses
+
+This software includes components released under the following licenses:
+
+---
+
+### SuperSocket
+
+#### Info
+
+* Link: https://supersocket.codeplex.com/
+
+* Version: 0.9.0.2
+
+* Author: Kerry Jiang
+
+* Description: Supports SuperWebSocket
+
+#### License
+
+Copyright 2012 Kerry Jiang (kerry-jiang@hotmail.com)
+
+SuperSocket is licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.  You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0.
+
+Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+---
+
+### SuperWebSocket
+
+#### Info
+
+* Link: https://superswebocket.codeplex.com/
+
+* Version: 0.9.0.2
+
+* Author: Kerry Jiang
+
+* Description: WebSocket implementation for client-server communication
+
+#### License
+
+Copyright 2010-2013 Kerry Jiang (kerry-jiang@hotmail.com)
+
+SuperWebSocket is licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.  You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0.
+
+Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+
+---
+
+### log4net
+
+#### Info
+
+* Link: http://logging.apache.org/log4net/
+
+* Version: 1.2.13
+
+* Author: Apache Software Foundation
+
+* Description: Logging.
+
+#### License
+
+Copyright © 2004-2015 Apache Software Foundation.
+
+log4net is licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.  You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0.
+
+Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+---
+
+### Blanket.js
+
+#### Info
+
+* Link: http://blanketjs.org/
+
+* Version: 1.1.5
+
+* Author: Alex Seville
+
+* Description: Code coverage measurement and reporting
+
+#### License
+
+Copyright (c) 2013 Alex Seville
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+---
+
+### Jasmine
+
+#### Info
+
+* Link: http://jasmine.github.io/
+
+* Version: 1.3.1
+
+* Author: Pivotal Labs
+
+* Description: Unit testing
+
+#### License
+
+Copyright (c) 2008-2011 Pivotal Labs
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+---
+
+### RequireJS
+
+#### Info
+
+* Link: http://requirejs.org/
+
+* Version: 2.1.9
+
+* Author: The Dojo Foundation
+
+* Description: Script loader
+
+#### License
+
+Copyright (c) 2010-2015, The Dojo Foundation
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+---
+
+### AngularJS
+
+#### Info
+
+* Link: http://angularjs.org/
+
+* Version: 1.2.26
+
+* Author: Google
+
+* Description: Client-side web application framework
+
+#### License
+
+Copyright (c) 2010-2014 Google, Inc. http://angularjs.org
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+---
+
+### Angular-Route
+
+#### Info
+
+* Link: http://angularjs.org/
+
+* Version: 1.2.26
+
+* Author: Google
+
+* Description: Client-side view routing
+
+#### License
+
+Copyright (c) 2010-2014 Google, Inc. http://angularjs.org
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+---
+
+### ES6-Promise
+
+#### Info
+
+* Link: https://github.com/jakearchibald/es6-promise
+
+* Version: 2.0.0
+
+* Authors: Yehuda Katz, Tom Dale, Stefan Penner and contributors
+
+* Description: Promise polyfill for pre-ECMAScript 6 browsers
+
+#### License
+
+Copyright (c) 2014 Yehuda Katz, Tom Dale, Stefan Penner and contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+---
+
+### screenfull.js
+
+#### Info
+
+* Link: https://github.com/sindresorhus/screenfull.js/
+
+* Version: 1.2.0
+
+* Author: Sindre Sorhus
+
+* Description: Wrapper for cross-browser usage of fullscreen API
+
+#### License
+
+Copyright (c) Sindre Sorhus <sindresorhus@gmail.com> (sindresorhus.com)
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+---
+
+### Math.uuid.js
+
+#### Info
+
+* Link: https://github.com/broofa/node-uuid
+
+* Version: 1.4
+
+* Author: Robert Kieffer
+
+* Description: Unique identifer generation (code adapted.)
+
+#### License
+
+Copyright (c) 2010 Robert Kieffer
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+---
+
+### Modernizr
+
+#### Info
+
+* Link: http://modernizr.com
+
+* Version: 2.6.2
+
+* Author: Faruk Ateş
+
+* Description: Browser/device capability finding
+
+#### License
+
+Copyright (c) 2009–2015
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+---
+
+### Normalize.css
+
+#### Info
+
+* Link: https://github.com/necolas/normalize.css
+
+* Version: 1.1.2
+
+* Authors: Nicolas Gallagher, Jonathan Neal
+
+* Description: Browser style normalization
+
+#### License
+
+Copyright (c) Nicolas Gallagher and Jonathan Neal
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+---
+
+### Moment.js
+
+#### Info
+
+* Link: http://momentjs.com
+
+* Version: 2.7.0
+
+* Authors: Tim Wood, Iskren Chernev, Moment.js contributors
+
+* Description: Time/date parsing/formatting
+
+#### License
+
+Copyright (c) 2011-2014 Tim Wood, Iskren Chernev, Moment.js contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+---
+
+### moment-duration-format
+
+#### Info
+
+* Link: https://github.com/jsmreese/moment-duration-format
+
+* Version: 1.3.0
+
+* Authors: John Madhavan-Reese
+
+* Description: Duration parsing/formatting
+
+#### License
+
+Copyright 2014 John Madhavan-Reese
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of
+this software and associated documentation files (the "Software"), to deal in
+the Software without restriction, including without limitation the rights to
+use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
+the Software, and to permit persons to whom the Software is furnished to do so,
+subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
+FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
+COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
+IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+---
+
+### Json.NET
+
+#### Info
+
+* Link: http://www.newtonsoft.com/json
+
+* Version: 6.0.8
+
+* Author: Newtonsoft
+
+* Description: JSON serialization/deserialization
+
+#### License
+
+Copyright (c) 2007 James Newton-King
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+---
+
+### Nancy
+
+#### Info
+
+* Link: http://nancyfx.org
+
+* Version: 0.23.2
+
+* Author: Andreas Håkansson, Steven Robbins and contributors
+
+* Description: Embedded web server
+
+#### License
+
+Copyright © 2010 Andreas Håkansson, Steven Robbins and contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+---
+
+### Nancy.Hosting.Self
+
+#### Info
+
+* Link: http://nancyfx.org
+
+* Version: 0.23.2
+
+* Author: Andreas Håkansson, Steven Robbins and contributors
+
+* Description: Embedded web server
+
+#### License
+
+Copyright © 2010 Andreas Håkansson, Steven Robbins and contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+

Procfile

@@ -0,0 +1 @@
+web: node app.js --port $PORT

README.md

@@ -1,190 +1,169 @@
-# Open MCT [![license](https://img.shields.io/badge/license-Apache%202.0-blue.svg)](http://www.apache.org/licenses/LICENSE-2.0) [![codecov](https://codecov.io/gh/nasa/openmct/branch/master/graph/badge.svg?token=7DQIipp3ej)](https://codecov.io/gh/nasa/openmct) [![This project is using Percy.io for visual regression testing.](https://percy.io/static/images/percy-badge.svg)](https://percy.io/b2e34b17/openmct) [![npm version](https://img.shields.io/npm/v/openmct.svg)](https://www.npmjs.com/package/openmct) ![CodeQL](https://github.com/nasa/openmct/workflows/CodeQL/badge.svg)
+# Open MCT Web
 
-Open MCT (Open Mission Control Technologies) is a next-generation mission control framework for visualization of data on desktop and mobile devices. It is developed at NASA's Ames Research Center, and is being used by NASA for data analysis of spacecraft missions, as well as planning and operation of experimental rover systems. As a generalizable and open source framework, Open MCT could be used as the basis for building applications for planning, operation, and analysis of any systems producing telemetry data.
+Open MCT Web is a web-based platform for mission operations user interface
+software.
 
-> [!NOTE]
-> Please visit our [Official Site](https://nasa.github.io/openmct/) and [Getting Started Guide](https://nasa.github.io/openmct/getting-started/)
+## Bundles
 
-Once you've created something amazing with Open MCT, showcase your work in our GitHub Discussions [Show and Tell](https://github.com/nasa/openmct/discussions/categories/show-and-tell) section. We love seeing unique and wonderful implementations of Open MCT!
+A bundle is a group of software components (including source code, declared
+as AMD modules, as well as resources such as images and HTML templates)
+that are intended to be added or removed as a single unit. A plug-in for
+Open MCT Web will be expressed as a bundle; platform components are also
+expressed as bundles.
 
-![Screen Shot 2022-11-23 at 9 51 36 AM](https://user-images.githubusercontent.com/4215777/203617422-4d912bfc-766f-4074-8324-409d9bbe7c05.png)
+A bundle is also just a directory which contains a file `bundle.json`,
+which declares its contents.
 
-## Building and Running Open MCT Locally
+The file `bundles.json` (note the plural), at the top level of the
+repository, is a JSON file containing an array of all bundles (expressed as
+directory names) to include in a running instance of Open MCT Web. Adding or
+removing paths from this list will add or remove bundles from the running
+application.
 
-Building and running Open MCT in your local dev environment is very easy. Be sure you have [Git](https://git-scm.com/downloads) and [Node.js](https://nodejs.org/) installed, then follow the directions below. Need additional information? Check out the [Getting Started](https://nasa.github.io/openmct/getting-started/) page on our website.
-(These instructions assume you are installing as a non-root user; developers have [reported issues](https://github.com/nasa/openmct/issues/1151) running these steps with root privileges.)
+### Bundle Contents
 
-1. Clone the source code:
+A bundle directory will contain:
 
-```sh
-git clone https://github.com/nasa/openmct.git
-```
+* `bundle.json`, the declaration of the bundles contents.
+* A source code directory, named `src` by convention. This contains all
+  JavaScript sources exposed by the bundle. These are declared as
+  AMD modules.
+* A directory for other resources, named `res` by convention. This
+  contains all HTML templates, CSS files, images, and so forth to be
+  used within a given bundle.
+* A library directory, named `lib` by convention. This contains all
+  external libraries used and/or exposed by the bundle.
+* A test directory, named `test` by convention. This contains all unit
+  tests declared for the bundle, as well as a `suite.json` that acts
+  as a listing of these dependencies. See the section on unit testing
+  below.
 
-2. (Optional) Install the correct node version using [nvm](https://github.com/nvm-sh/nvm):
-
-```sh
-nvm install
-```
-
-3. Install development dependencies (Note: Check the `package.json` engine for our tested and supported node versions):
-
-```sh
-npm install
-```
-
-4. Run a local development server:
-
-```
-npm start
-```
-
-> [!IMPORTANT]
-> Open MCT is now running, and can be accessed by pointing a web browser at [http://localhost:8080/](http://localhost:8080/)
-
-Open MCT is built using [`npm`](http://npmjs.com/) and [`webpack`](https://webpack.js.org/).
-
-## Documentation
-
-Documentation is available on the [Open MCT website](https://nasa.github.io/openmct/documentation/).
-
-### Examples
-
-The clearest examples for developing Open MCT plugins are in the
-[tutorials](https://github.com/nasa/openmct-tutorial) provided in
-our documentation.
-
-> [!NOTE]
-> We want Open MCT to be as easy to use, install, run, and develop for as
-> possible, and your feedback will help us get there!
-> Feedback can be provided via [GitHub issues](https://github.com/nasa/openmct/issues/new/choose),
-> [Starting a GitHub Discussion](https://github.com/nasa/openmct/discussions),
-> or by emailing us at [arc-dl-openmct@mail.nasa.gov](mailto:arc-dl-openmct@mail.nasa.gov).
-
-## Developing Applications With Open MCT
-
-For more on developing with Open MCT, see our documentation for a guide on [Developing Applications with Open MCT](./API.md#starting-an-open-mct-application).
-
-## Compatibility
-
-This is a fast moving project and we do our best to test and support the widest possible range of browsers, operating systems, and NodeJS APIs. We have a published list of support available in our package.json's `browserslist` key.
-
-The project utilizes `nvm` to maintain consistent node and npm versions across all projects. For UNIX, MacOS, Windows WSL, and other POSIX-compliant shell environments, click [here](https://github.com/nvm-sh/nvm). For Windows, check out [nvm-windows](https://github.com/coreybutler/nvm-windows).
-
-If you encounter an issue with a particular browser, OS, or NodeJS API, please [file an issue](https://github.com/nasa/openmct/issues/new/choose).
-
-## Plugins
-
-Open MCT can be extended via plugins that make calls to the Open MCT API. A plugin is a group
-of software components (including source code and resources such as images and HTML templates)
-that is intended to be added or removed as a single unit.
-
-As well as providing an extension mechanism, most of the core Open MCT codebase is also
-written as plugins.
-
-For information on writing plugins, please see [our API documentation](./API.md#plugins).
+Following these bundle conventions is required, at present, to ensure
+that Open MCT Web (and its build and tests) execute correctly.
 
 ## Tests
 
-Our automated test coverage comes in the form of unit, e2e, visual, performance, and security tests.
+The repository for Open MCT Web includes a test suite that can be run
+directly from the web browser, `test.html`. This page will:
 
-### Unit Tests
+* Load `bundles.json` to determine which bundles are in the application.
+* Load `test/suite.json` to determine which source files are to be tested.
+  This should contain an array of strings, where each is the name of an
+  AMD module in the bundle's source directory. For each source file:
+  * Code coverage instrumentation will be added, via Blanket.
+  * The associated test file will be loaded, via RequireJS. These will
+    be located in the bundle's test folder; the test runner will presume
+    these follow a naming convention where each module to be tested has a
+    corresponding test module with the suffix `Spec` in that folder.
+* Jasmine will then be invoked to run all tests defined in the loaded
+  test modules. Code coverage reporting will be displayed at the bottom
+  of the test page.
 
-Unit Tests are written for [Jasmine](https://jasmine.github.io/api/edge/global)
-and run by [Karma](http://karma-runner.github.io). To run:
+At present, the test runner presumes that bundle conventions are followed
+as above; that is, sources are contained in `src`, and tests are contained
+in `test`. Additionally, individual test files must use the `Spec` suffix
+as described above.
 
-`npm test`
+An example of this is expressed in `platform/framework`, which follows
+bundle conventions.
 
-The test suite is configured to load any scripts ending with `Spec.js` found
-in the `src` hierarchy. Full configuration details are found in
-`karma.conf.js`. By convention, unit test scripts should be located
-alongside the units that they test; for example, `src/foo/Bar.js` would be
-tested by `src/foo/BarSpec.js`.
+### Functional Testing
 
-### e2e, Visual, and Performance Testing
+The tests described above are all at the unit-level; an additional
+test suite using [Protractor](https://angular.github.io/protractor/)
+us under development, in the `protractor` folder.
 
-Our e2e (end-to-end), Visual, and Performance tests leverage the Playwright framework and are executed using Playwright's test runner, [@playwright/test](https://playwright.dev/).
+To run:
 
-#### How to Run Tests
+* Install protractor following the instructions above.
+* `cd protractor`
+* `npm install`
+* `npm run all`
 
-- **e2e Tests**: These tests are run on every commit. To run the tests locally, use:
+## Build
 
-  ```sh
-  npm run test:e2e:ci
-  ```
+Open MCT Web includes a Maven command line build. Although Open MCT Web
+can be run as-is using the repository contents (that is, by viewing
+`index.html` in a web browser), and its tests can be run in-place
+similarly (that is, by viewing `test.html` in a browser), the command
+line build allows machine-driven verification and packaging.
 
-- **Visual Tests**: For running the visual test suite, use:
+This build will:
 
-  ```sh
-  npm run test:e2e:visual
-  ```
+* Check all sources (excluding those in directories named `lib`) with
+  JSLint for code style compliance. The build will fail if any sources
+  do not satisfy JSLint.
+* Run unit tests. This is done by running `test.html` in a PhantomJS
+  browser-like environment. The build will fail if any tests fail.
+* Package the application as a `war` (web archive) file. This is
+  convenient for deployment on Tomcat or similar. This archive will
+  include sources, resources, and libraries for bundles, as well
+  as the top-level files used to initiate running of the application
+  (`index.html` and `bundles.json`).
 
-- **Performance Tests**: To initiate the performance tests, enter:
+Run as `mvn clean install`.
 
-  ```sh
-  npm run test:perf
-  ```
+### Building Documentation
 
-All tests are located within the `e2e/tests/` directory and are identified by the `*.e2e.spec.js` filename pattern. For more information about the e2e test suite, refer to the [README](./e2e/README.md).
+Open MCT Web's documentation is generated by an
+[npm](https://www.npmjs.com/)-based build:
 
-### Security Tests
+* `npm install` _(only needs to run once)_
+* `npm run docs`
 
-Each commit is analyzed for known security vulnerabilities using [CodeQL](https://codeql.github.com/docs/codeql-language-guides/codeql-library-for-javascript/). The list of CWE coverage items is available in the [CodeQL docs](https://codeql.github.com/codeql-query-help/javascript-cwe/). The CodeQL workflow is specified in the [CodeQL analysis file](./.github/workflows/codeql-analysis.yml) and the custom [CodeQL config](./.github/codeql/codeql-config.yml).
+Documentation will be generated in `target/docs`. Note that diagram
+generation is dependent on having [Cairo](http://cairographics.org/download/)
+installed; see
+[node-canvas](https://github.com/Automattic/node-canvas#installation)'s
+documentation for help with installation.
 
-### Test Reporting and Code Coverage
 
-Each test suite generates a report in CircleCI. For a complete overview of testing functionality, please see our [Circle CI Test Insights Dashboard](https://app.circleci.com/insights/github/nasa/openmct/workflows/the-nightly/overview?branch=master&reporting-window=last-30-days)
+# Glossary
 
-Our code coverage is generated during the runtime of our unit, e2e, and visual tests. The combination of those reports is published to [codecov.io](https://app.codecov.io/gh/nasa/openmct/)
-
-For more on the specifics of our code coverage setup, [see](TESTING.md#code-coverage)
-
-## Glossary
-
-Certain terms are used throughout Open MCT with consistent meanings
+Certain terms are used throughout Open MCT Web with consistent meanings
 or conventions. Any deviations from the below are issues and should be
 addressed (either by updating this glossary or changing code to reflect
 correct usage.) Other developer documentation, particularly in-line
 documentation, may presume an understanding of these terms.
-| Term          | Definition                                                                                                                                                                                                                                                                                                                                                   |
-|---------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| _plugin_      | A removable, reusable grouping of software elements. The application is composed of plugins.                                                                                                                                                                                                                                                                  |
-| _composition_ | In the context of a domain object, this term refers to the set of other domain objects that compose or are contained by that object. A domain object's composition is the set of domain objects that should appear immediately beneath it in a tree hierarchy. It is described in its model as an array of ids, providing a means to asynchronously retrieve the actual domain object instances associated with these identifiers. |
-| _description_ | When used as an object property, this term refers to the human-readable description of a thing, usually a single sentence or short paragraph. It is most often used in the context of extensions, domain object models, or other similar application-specific objects.                                                                                           |
-| _domain object_ | A meaningful object to the user and a distinct thing in the work supported by Open MCT. Anything that appears in the left-hand tree is a domain object.                                                                                                                                                                                                       |
-| _identifier_  | A tuple consisting of a namespace and a key, which together uniquely identifies a domain object.                                                                                                                                                                                                                                                              |
-| _model_       | The persistent state associated with a domain object. A domain object's model is a JavaScript object that can be converted to JSON without losing information, meaning it contains no methods.                                                                                                                                                                 |
-| _name_        | When used as an object property, this term refers to the human-readable name for a thing. It is most often used in the context of extensions, domain object models, or other similar application-specific objects.                                                                                                                                             |
-| _navigation_  | This term refers to the current state of the application with respect to the user's expressed interest in a specific domain object. For example, when a user clicks on a domain object in the tree, they are navigating to it, and it is thereafter considered the navigated object until the user makes another such choice.                                    |
-| _namespace_   | A name used to identify a persistence store. A running Open MCT application could potentially use multiple persistence stores.                                                                                                                                                                                                                                 |
-
-## Open MCT v2.0.0
-
-Support for our legacy bundle-based API, and the libraries that it was built on (like Angular 1.x), have now been removed entirely from this repository.
-
-For now if you have an Open MCT application that makes use of the legacy API, [a plugin](https://github.com/nasa/openmct-legacy-plugin) is provided that bootstraps the legacy bundling mechanism and API. This plugin will not be maintained over the long term however, and the legacy support plugin will not be tested for compatibility with future versions of Open MCT. It is provided for convenience only.
-
-### How do I know if I am using legacy API?
-
-You might still be using legacy API if your source code
-
-- Contains files named bundle.js, or bundle.json,
-- Makes calls to `openmct.$injector()`, or `openmct.$angular`,
-- Makes calls to `openmct.legacyRegistry`, `openmct.legacyExtension`, or `openmct.legacyBundle`.
-
-### What should I do if I am using legacy API?
-
-Please refer to [the modern Open MCT API](https://nasa.github.io/openmct/documentation/). Post any questions to the [Discussions section](https://github.com/nasa/openmct/discussions) of the Open MCT GitHub repository.
-
-## Related Repos
-
-> [!NOTE]
-> Although Open MCT functions as a standalone project, it is primarily an extensible framework intended to be used as a dependency with users' own plugins and packaging. Furthermore, Open MCT is intended to be used with an HTTP server such as Apache or Nginx. A great example of hosting Open MCT with Apache is `openmct-quickstart` and can be found in the table below.
-
-| Repository | Description |
-| --- | --- |
-| [openmct-tutorial](https://github.com/nasa/openmct-tutorial) | A great place for beginners to learn how to use and extend Open MCT. |
-| [openmct-quickstart](https://github.com/scottbell/openmct-quickstart) | A working example of Open MCT integrated with Apache HTTP server, YAMCS telemetry, and Couch DB for persistence.
-| [Open MCT YAMCS Plugin](https://github.com/akhenry/openmct-yamcs) | Plugin for integrating YAMCS telemetry and command server with Open MCT. |
-| [openmct-performance](https://github.com/unlikelyzero/openmct-performance) | Resources for performance testing Open MCT. |
-| [openmct-as-a-dependency](https://github.com/unlikelyzero/openmct-as-a-dependency) | An advanced guide for users on how to build, develop, and test Open MCT when it's used as a dependency. |
 
+* _bundle_: A bundle is a removable, reusable grouping of software elements.
+  The application is composed of bundles. Plug-ins are bundles. For more
+  information, refer to framework documentation (under `platform/framework`.)
+* _capability_: An object which exposes dynamic behavior or non-persistent
+  state associated with a domain object.
+* _composition_: In the context of a domain object, this refers to the set of
+  other domain objects that compose or are contained by that object. A domain
+  object's composition is the set of domain objects that should appear
+  immediately beneath it in a tree hierarchy. A domain object's composition is
+  described in its model as an array of id's; its composition capability
+  provides a means to retrieve the actual domain object instances associated
+  with these identifiers asynchronously.
+* _description_: When used as an object property, this refers to the human-readable
+  description of a thing; usually a single sentence or short paragraph.
+  (Most often used in the context of extensions, domain
+  object models, or other similar application-specific objects.)
+* _domain object_: A meaningful object to the user; a distinct thing in
+  the work support by Open MCT Web. Anything that appears in the left-hand
+  tree is a domain object.
+* _extension_: An extension is a unit of functionality exposed to the
+  platform in a declarative fashion by a bundle. For more
+  information, refer to framework documentation (under `platform/framework`.)
+* _id_: A string which uniquely identifies a domain object.
+* _key_: When used as an object property, this refers to the machine-readable
+  identifier for a specific thing in a set of things. (Most often used in the
+  context of extensions or other similar application-specific object sets.)
+* _model_: The persistent state associated with a domain object. A domain
+  object's model is a JavaScript object which can be converted to JSON
+  without losing information (that is, it contains no methods.)
+* _name_: When used as an object property, this refers to the human-readable
+  name for a thing. (Most often used in the context of extensions, domain
+  object models, or other similar application-specific objects.)
+* _navigation_: Refers to the current state of the application with respect
+  to the user's expressed interest in a specific domain object; e.g. when
+  a user clicks on a domain object in the tree, they are _navigating_ to
+  it, and it is thereafter considered the _navigated_ object (until the
+  user makes another such choice.)
+* _space_: A name used to identify a persistence store. Interactions with
+  persistence with generally involve a `space` parameter in some form, to
+  distinguish multiple persistence stores from one another (for cases
+  where there are multiple valid persistence locations available.)

SECURITY.md

@@ -1,29 +0,0 @@
-# Security Policy
-
-The Open MCT team secures our code base using a combination of code review, dependency review, and periodic security reviews. Static analysis performed during automated verification additionally safeguards against common coding errors which may result in vulnerabilities.
-
-### Reporting a Vulnerability
-
-For general defects, please for a [Bug Report](https://github.com/nasa/openmct/issues/new/choose)
-
-To report a vulnerability for Open MCT please send a detailed report to [arc-dl-openmct](mailto:arc-dl-openmct@mail.nasa.gov). 
-
-See our [top-level security policy](https://github.com/nasa/openmct/security/policy) for additional information.
-
-### CodeQL and LGTM
-
-The [CodeQL GitHub Actions workflow](https://github.com/nasa/openmct/blob/master/.github/workflows/codeql-analysis.yml) is available to the public. To review the results, fork the repository and run the CodeQL workflow. 
-
-CodeQL is run for every pull-request in GitHub Actions.
-
-### ESLint
-
-Static analysis is run for every push on the master branch and every pull request on all branches in Github Actions. 
-
-For more information about ESLint, visit https://eslint.org/.
-
-### General Support
-
-For additional support, please open a [Github Discussion](https://github.com/nasa/openmct/discussions). 
-
-If you wish to report a cybersecurity incident or concern, please contact the NASA Security Operations Center either by phone at 1-877-627-2732 or via email address soc@nasa.gov.

TESTING.md

@@ -1,122 +0,0 @@
-# Testing
-Open MCT Testing is iterating and improving at a rapid pace. This document serves to capture and index existing testing documentation and house documentation which no other obvious location as our testing evolves.
-
-## General Testing Process
-Documentation located [here](./docs/src/process/testing/plan.md)
-
-## Unit Testing
-Unit testing is essential part of our test strategy and complements our e2e testing strategy.
-
-#### Unit Test Guidelines
-* Unit Test specs should reside alongside the source code they test, not in a separate directory.
-* Unit test specs for plugins should be defined at the plugin level. Start with one test spec per plugin named pluginSpec.js, and as this test spec grows too big, break it up into multiple test specs that logically group related tests.
-* Unit tests for API or for utility functions and classes may be defined at a per-source file level.
-* Wherever possible only use and mock public API, builtin functions, and UI in your test specs. Do not directly invoke any private functions. ie. only call or mock functions and objects exposed by openmct.* (eg. openmct.telemetry, openmct.objectView, etc.), and builtin browser functions (fetch, requestAnimationFrame, setTimeout, etc.).
-* Where builtin functions have been mocked, be sure to clear them between tests.
-* Test at an appropriate level of isolation. Eg. 
-    * If you’re testing a view, you do not need to test the whole application UI, you can just fetch the view provider using the public API and render the view into an element that you have created. 
-    * You do not need to test that the view switcher works, there should be separate tests for that. 
-    * You do not need to test that telemetry providers work, you can mock openmct.telemetry.request() to feed test data to the view.
-    * Use your best judgement when deciding on appropriate scope.
-* Automated tests for plugins should start by actually installing the plugin being tested, and then test that installing the plugin adds the desired features and behavior to Open MCT, observing the above rules.
-* All variables used in a test spec, including any instances of the Open MCT API should be declared inside of an appropriate block scope (not at the root level of the source file), and should be initialized in the relevant beforeEach block. `beforeEach` is preferable to `beforeAll` to avoid leaking of state between tests.
-* A `afterEach` or `afterAll` should be used to do any clean up necessary to prevent leakage of state between test specs. This can happen when functions on `window` are wrapped, or when the URL is changed. [A convenience function](https://github.com/nasa/openmct/blob/master/src/utils/testing.js#L59) is provided for resetting the URL and clearing builtin spies between tests.
-
-#### Unit Test Examples
-* [Example of an automated test spec for an object view plugin](https://github.com/nasa/openmct/blob/master/src/plugins/telemetryTable/pluginSpec.js)
-* [Example of an automated test spec for API](https://github.com/nasa/openmct/blob/master/src/api/time/TimeAPISpec.js)
-
-#### Unit Testing Execution
-
-The unit tests can be executed in one of two ways:
-`npm run test` which runs the entire suite against headless chrome
-`npm run test:debug` for debugging the tests in realtime in an active chrome session.
-
-## e2e, performance, and visual testing
-Documentation located [here](./e2e/README.md)
-
-## Code Coverage
-
-It's up to the individual developer as to whether they want to add line coverage in the form of a unit test or e2e test.
-
-Line Code Coverage is generated by our unit tests and e2e tests, then combined by ([Codecov.io Flags](https://docs.codecov.com/docs/flags)), and finally reported in GitHub PRs by Codecov.io's PR Bot. This workflow gives a comprehensive (if flawed) view of line coverage.
-
-### Karma-istanbul
-
-Line coverage is generated by our `karma-coverage-istanbul-reporter` package as defined in our `karma.conf.js` file:
-
-```js
-    coverageIstanbulReporter: {
-      fixWebpackSourcePaths: true,
-      skipFilesWithNoCoverage: true,
-      dir: 'coverage/unit', //Sets coverage file to be consumed by codecov.io
-      reports: ['lcovonly']
-    },
-```
-
-Once the file is generated, it can be published to codecov with
-
-```json
-    "cov:unit:publish": "codecov --disable=gcov -f ./coverage/unit/lcov.info -F unit",
-```
-
-### e2e
-The e2e line coverage is a bit more complex than the karma implementation. This is the general sequence of events:
-
-1. Each e2e suite will start webpack with the ```npm run start:coverage``` command with config `webpack.coverage.mjs` and the `babel-plugin-istanbul` plugin to generate code coverage during e2e test execution using our custom [baseFixture](./baseFixtures.js). 
-1. During testcase execution, each e2e shard will generate its piece of the larger coverage suite. **This coverage file is not merged**. The raw coverage file is stored in a `.nyc_report` directory.
-1. [nyc](https://github.com/istanbuljs/nyc) converts this directory into a `lcov` file with the following command `npm run cov:e2e:report`
-1. Most of the tests focus on chrome/ubuntu at a single resolution. This coverage is published to codecov with `npm run cov:e2e:ci:publish`.
-1. The rest of our coverage only appears when run against persistent datastore (couchdb), non-ubuntu machines, and non-chrome browsers with the `npm run cov:e2e:full:publish` flag. Since this happens about once a day, we have leveraged codecov.io's carryforward flag to report on lines covered outside of each commit on an individual PR.
-
-
-### Limitations in our code coverage reporting
-Our code coverage implementation has some known limitations:
-- [Variability](https://github.com/nasa/openmct/issues/5811)
-- [Accuracy](https://github.com/nasa/openmct/issues/7015)
-- [Vue instrumentation gaps](https://github.com/nasa/openmct/issues/4973)
-
-## Troubleshooting CI
-The following is an evolving guide to troubleshoot CI and PR issues.
-
-### Github Checks failing
-There are a few reasons that your GitHub PR could be failing beyond simple failed tests.
-* Required Checks. We're leveraging required checks in GitHub so that we can quickly and precisely control what becomes and informational failure vs a hard requirement. The only way to determine the difference between a required vs information check is check for the `(Required)` emblem next to the step details in GitHub Checks.
-* Not all required checks are run per commit. You may need to manually trigger addition GitHub checks with a `pr:<label>` label added to your PR.
-
-### Flaky tests
-
-(CircleCI's test insights feature)[https://circleci.com/blog/introducing-test-insights-with-flaky-test-detection/] collects historical data about the individual test results for both unit and e2e tests. Note: only a 14 day window of flake is available.
-
-### Local=Pass and CI=Fail
-Although rare, it is possible that your test can pass locally but fail in CI.
-
-### Reset your workspace
-It's possible that you're running with dependencies or a local environment which is out of sync with the branch you're working on. Make sure to execute the following:
-
-```sh
-nvm use
-npm run clean
-npm install
-```
-
-#### Run tests in the same container as CI
-
-In extreme cases, tests can fail due to the constraints of running within a container. To execute tests in exactly the same way as run in CircleCI. 
-
-```sh
-// Replace {X.X.X} with the current Playwright version 
-// from our package.json or circleCI configuration file
-docker run --rm --network host --cpus="2" -v $(pwd):/work/ -w /work/ -it mcr.microsoft.com/playwright:v{X.X.X}-focal /bin/bash
-npm install
-```
-
-At this point, you're running inside the same container and with 2 cpu cores. You can specify the unit tests:
-```sh
-npm run test
-```
-or e2e tests:
-
-```sh
-npx playwright test --config=e2e/playwright-ci.config.js --project=chrome --grep <the testcase name>
-```

app.js

@@ -0,0 +1,63 @@
+/*global require,process,console*/
+
+/**
+ * Usage:
+ *
+ * npm install minimist express
+ * node app.js [options]
+ */
+
+(function () {
+    "use strict";
+
+    var BUNDLE_FILE = 'bundles.json',
+        options = require('minimist')(process.argv.slice(2)),
+        express = require('express'),
+        app = express(),
+        fs = require('fs');
+
+    // Defaults
+    options.port = options.port || options.p || 8080;
+    ['include', 'exclude', 'i', 'x'].forEach(function (opt) {
+        options[opt] = options[opt] || [];
+        // Make sure includes/excludes always end up as arrays
+        options[opt] = Array.isArray(options[opt]) ?
+                options[opt] : [options[opt]];
+    });
+    options.include = options.include.concat(options.i);
+    options.exclude = options.exclude.concat(options.x);
+
+    // Show command line options
+    if (options.help || options.h) {
+        console.log("\nUsage: node app.js [options]\n");
+        console.log("Options:");
+        console.log("  --help, -h               Show this message.");
+        console.log("  --port, -p <number>      Specify port.");
+        console.log("  --include, -i <bundle>   Include the specified bundle.");
+        console.log("  --exclude, -x <bundle>   Exclude the specified bundle.");
+        console.log("");
+        process.exit(0);
+    }
+
+    // Override bundles.json for HTTP requests
+    app.use('/' + BUNDLE_FILE, function (req, res) {
+        var bundles = JSON.parse(fs.readFileSync(BUNDLE_FILE, 'utf8'));
+
+        // Handle command line inclusions/exclusions
+        bundles = bundles.concat(options.include);
+        bundles = bundles.filter(function (bundle) {
+            return options.exclude.indexOf(bundle) === -1;
+        });
+        bundles = bundles.filter(function (bundle, index) { // Uniquify
+            return bundles.indexOf(bundle) === index;
+        });
+
+        res.send(JSON.stringify(bundles));
+    });
+
+    // Expose everything else as static files
+    app.use(express['static']('.'));
+
+    // Finally, open the HTTP server
+    app.listen(options.port);
+}());

build-docs.sh

@@ -1,11 +1,11 @@
 #!/bin/bash
 
 #*****************************************************************************
-#* Open MCT, Copyright (c) 2014-2024, United States Government
+#* Open MCT Web, Copyright (c) 2014-2015, United States Government
 #* as represented by the Administrator of the National Aeronautics and Space
 #* Administration. All rights reserved.
 #*
-#* Open MCT is licensed under the Apache License, Version 2.0 (the
+#* Open MCT Web is licensed under the Apache License, Version 2.0 (the
 #* "License"); you may not use this file except in compliance with the License.
 #* You may obtain a copy of the License at
 #* http://www.apache.org/licenses/LICENSE-2.0.
@@ -16,25 +16,23 @@
 #* License for the specific language governing permissions and limitations
 #* under the License.
 #*
-#* Open MCT includes source code licensed under additional open source
+#* Open MCT Web includes source code licensed under additional open source
 #* licenses. See the Open Source Licenses file (LICENSES.md) included with
 #* this source code distribution or the Licensing information page available
 #* at runtime from the About dialog for additional information.
 #*****************************************************************************
 
-# Script to build and deploy docs.
+# Script to build and deploy docs to github pages.
 
-OUTPUT_DIRECTORY="dist/docs"
-# Docs, once built, are pushed to the private website repo
-REPOSITORY_URL="git@github.com:nasa/openmct-website.git"
-WEBSITE_DIRECTORY="website"
+OUTPUT_DIRECTORY="target/docs"
+REPOSITORY_URL="git@github.com:nasa/openmctweb.git"
 
-BUILD_SHA=`git rev-parse HEAD`
+BUILD_SHA=`git rev-parse head`
 
 # A remote will be created for the git repository we are pushing to.
-# Don't worry, as this entire directory will get trashed in between builds.
+# Don't worry, as this entire directory will get trashed inbetween builds.
 REMOTE_NAME="documentation"
-WEBSITE_BRANCH="master"
+WEBSITE_BRANCH="gh-pages"
 
 # Clean output directory, JSDOC will recreate
 if [ -d $OUTPUT_DIRECTORY ]; then
@@ -42,21 +40,23 @@ if [ -d $OUTPUT_DIRECTORY ]; then
 fi
 
 npm run docs
+cd $OUTPUT_DIRECTORY || exit 1
 
-echo "git clone $REPOSITORY_URL website"
-git clone $REPOSITORY_URL website || exit 1
-echo "cp -r $OUTPUT_DIRECTORY $WEBSITE_DIRECTORY"
-cp -r $OUTPUT_DIRECTORY $WEBSITE_DIRECTORY
-echo "cd $WEBSITE_DIRECTORY"
-cd $WEBSITE_DIRECTORY || exit 1
+echo "git init"
+git init
 
 # Configure github for CircleCI user.
 git config user.email "buildbot@circleci.com"
 git config user.name "BuildBot"
 
+echo "git remote add $REMOTE_NAME $REPOSITORY_URL"
+git remote add $REMOTE_NAME $REPOSITORY_URL
 echo "git add ."
 git add .
-echo "git commit -m \"Docs updated from build $BUILD_SHA\""
-git commit -m "Docs updated from build $BUILD_SHA"
-# Push to the website repo
-git push
+echo "git commit -m \"Generate docs from build $BUILD_SHA\""
+git commit -m "Generate docs from build $BUILD_SHA"
+
+echo "git push $REMOTE_NAME HEAD:$WEBSITE_BRANCH -f"
+git push $REMOTE_NAME HEAD:$WEBSITE_BRANCH -f
+
+echo "Documentation pushed to gh-pages branch."

bundles.json

@@ -0,0 +1,39 @@
+[
+    "platform/framework",
+    "platform/core",
+    "platform/representation",
+    "platform/commonUI/about",
+    "platform/commonUI/browse",
+    "platform/commonUI/edit",
+    "platform/commonUI/dialog",
+    "platform/commonUI/formats",
+    "platform/commonUI/general",
+    "platform/commonUI/inspect",
+    "platform/commonUI/mobile",
+    "platform/commonUI/themes/espresso",
+    "platform/commonUI/notification",
+    "platform/containment",
+    "platform/execution",
+    "platform/telemetry",
+    "platform/features/clock",
+    "platform/features/events",
+    "platform/features/imagery",
+    "platform/features/layout",
+    "platform/features/pages",
+    "platform/features/plot",
+    "platform/features/scrolling",
+    "platform/features/timeline",
+    "platform/forms",
+    "platform/identity",
+    "platform/persistence/aggregator",
+    "platform/persistence/local",
+    "platform/persistence/queue",
+    "platform/policy",
+    "platform/entanglement",
+    "platform/search",
+    "platform/status",
+
+    "example/imagery",
+    "example/eventGenerator",
+    "example/generator"
+]

circle.yml

@@ -0,0 +1,17 @@
+test:
+  override:
+    - exit 0
+deployment:
+  production:
+    branch: master
+    commands:
+      - ./build-docs.sh
+      - git push git@heroku.com:openmctweb-demo.git $CIRCLE_SHA1:refs/heads/master
+  openmctweb-staging-un:
+    branch: open199
+    heroku:
+      appname: openmctweb-staging-un
+  openmctweb-staging-deux:
+    branch: mobile
+    heroku:
+      appname: openmctweb-staging-deux

codecov.yml

@@ -1,28 +0,0 @@
-codecov:
-  require_ci_to_pass: false #This setting will update the bot regardless of whether or not tests pass
-
-coverage:
-  status:
-    project:
-      default:
-        informational: true
-    patch:
-      default:
-        informational: true
-  precision: 2
-  round: down
-  range: "66...100"
-
-flags:
-  unit:
-    carryforward: false
-  e2e-ci:
-    carryforward: false
-  e2e-full:
-    carryforward: true
-
-comment:
-  layout: "diff,flags,files,footer"
-  behavior: default
-  require_changes: false
-  show_carryforward_flags: true

copyright-notice.html

@@ -1,21 +0,0 @@
-<!--
- Open MCT, Copyright (c) 2014-2024, United States Government
- as represented by the Administrator of the National Aeronautics and Space
- Administration. All rights reserved.
-
- Open MCT is licensed under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
- http://www.apache.org/licenses/LICENSE-2.0.
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- License for the specific language governing permissions and limitations
- under the License.
-
- Open MCT includes source code licensed under additional open source
- licenses. See the Open Source Licenses file (LICENSES.md) included with
- this source code distribution or the Licensing information page available
- at runtime from the About dialog for additional information.
--->

copyright-notice.js

@@ -1,21 +0,0 @@
-/*****************************************************************************
- * Open MCT, Copyright (c) 2014-2024, United States Government
- * as represented by the Administrator of the National Aeronautics and Space
- * Administration. All rights reserved.
- *
- * Open MCT is licensed under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- * http://www.apache.org/licenses/LICENSE-2.0.
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- * License for the specific language governing permissions and limitations
- * under the License.
- *
- * Open MCT includes source code licensed under additional open source
- * licenses. See the Open Source Licenses file (LICENSES.md) included with
- * this source code distribution or the Licensing information page available
- * at runtime from the About dialog for additional information.
- *****************************************************************************/

docs/footer.html

@@ -0,0 +1,9 @@
+        <hr>
+        <cite>
+            This document is styled using
+            <a href="https://github.com/jasonm23/markdown-css-themes">
+                https://github.com/jasonm23/markdown-css-themes
+            </a>.
+        </cite>
+    </body>
+</html>

docs/gendocs.js

@@ -0,0 +1,204 @@
+/*****************************************************************************
+ * Open MCT Web, Copyright (c) 2014-2015, United States Government
+ * as represented by the Administrator of the National Aeronautics and Space
+ * Administration. All rights reserved.
+ *
+ * Open MCT Web is licensed under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ * http://www.apache.org/licenses/LICENSE-2.0.
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
+ * under the License.
+ *
+ * Open MCT Web includes source code licensed under additional open source
+ * licenses. See the Open Source Licenses file (LICENSES.md) included with
+ * this source code distribution or the Licensing information page available
+ * at runtime from the About dialog for additional information.
+ *****************************************************************************/
+
+/*global require,process,__dirname,GLOBAL*/
+/*jslint nomen: false */
+
+
+// Usage:
+//   node gendocs.js --in <source directory> --out <dest directory>
+
+var CONSTANTS = {
+        DIAGRAM_WIDTH: 800,
+        DIAGRAM_HEIGHT: 500
+    },
+    TOC_HEAD = "# Table of Contents";
+
+GLOBAL.window = GLOBAL.window ||  GLOBAL; // nomnoml expects window to be defined
+(function () {
+    "use strict";
+
+    var fs = require("fs"),
+        mkdirp = require("mkdirp"),
+        path = require("path"),
+        glob = require("glob"),
+        marked = require("marked"),
+        split = require("split"),
+        stream = require("stream"),
+        nomnoml = require('nomnoml'),
+        toc = require("markdown-toc"),
+        Canvas = require('canvas'),
+        header = fs.readFileSync(path.resolve(__dirname, 'header.html')),
+        footer = fs.readFileSync(path.resolve(__dirname, 'footer.html')),
+        options = require("minimist")(process.argv.slice(2));
+
+    // Convert from nomnoml source to a target PNG file.
+    function renderNomnoml(source, target) {
+        var canvas =
+            new Canvas(CONSTANTS.DIAGRAM_WIDTH, CONSTANTS.DIAGRAM_HEIGHT);
+        nomnoml.draw(canvas, source, 1.0);
+        canvas.pngStream().pipe(fs.createWriteStream(target));
+    }
+
+    // Stream transform.
+    // Pulls out nomnoml diagrams from fenced code blocks and renders them
+    // as PNG files in the output directory, prefixed with a provided name.
+    // The fenced code blocks will be replaced with Markdown in the
+    // output of this stream.
+    function nomnomlifier(outputDirectory, prefix) {
+        var transform = new stream.Transform({ objectMode: true }),
+            isBuilding = false,
+            counter = 1,
+            outputPath,
+            source = "";
+
+        transform._transform = function (chunk, encoding, done) {
+            if (!isBuilding) {
+                if (chunk.trim().indexOf("```nomnoml") === 0) {
+                    var outputFilename = prefix + '-' + counter + '.png';
+                    outputPath = path.join(outputDirectory, outputFilename);
+                    this.push([
+                        "\n![Diagram ",
+                        counter,
+                        "](",
+                        outputFilename,
+                        ")\n\n"
+                    ].join(""));
+                    isBuilding = true;
+                    source = "";
+                    counter += 1;
+                } else {
+                    // Otherwise, pass through
+                    this.push(chunk + '\n');
+                }
+            } else {
+                if (chunk.trim() === "```") {
+                    // End nomnoml
+                    renderNomnoml(source, outputPath);
+                    isBuilding = false;
+                } else {
+                    source += chunk + '\n';
+                }
+            }
+            done();
+        };
+
+        return transform;
+    }
+
+    // Convert from Github-flavored Markdown to HTML
+    function gfmifier() {
+        var transform = new stream.Transform({ objectMode: true }),
+            markdown = "";
+        transform._transform = function (chunk, encoding, done) {
+            markdown += chunk;
+            done();
+        };
+        transform._flush = function (done) {
+            // Prepend table of contents
+            markdown =
+                [ TOC_HEAD, toc(markdown).content, "", markdown ].join("\n");
+            this.push(header);
+            this.push(marked(markdown));
+            this.push(footer);
+            done();
+        };
+        return transform;
+    }
+
+    // Custom renderer for marked; converts relative links from md to html,
+    // and makes headings linkable.
+    function CustomRenderer() {
+        var renderer = new marked.Renderer(),
+            customRenderer = Object.create(renderer);
+        customRenderer.heading = function (text, level) {
+            var escapedText = (text || "").trim().toLowerCase().replace(/\W/g, "-"),
+                aOpen = "<a name=\"" + escapedText + "\" href=\"#" + escapedText + "\">",
+                aClose = "</a>";
+            return aOpen + renderer.heading.apply(renderer, arguments) + aClose;
+        };
+        // Change links to .md files to .html
+        customRenderer.link = function (href, title, text) {
+            // ...but only if they look like relative paths
+            return (href || "").indexOf(":") === -1 && href[0] !== "/" ?
+                    renderer.link(href.replace(/\.md/, ".html"), title, text) :
+                    renderer.link.apply(renderer, arguments);
+        };
+        return customRenderer;
+    }
+
+    options['in'] = options['in'] || options.i;
+    options.out = options.out || options.o;
+
+    marked.setOptions({
+        renderer: new CustomRenderer(),
+        gfm: true,
+        tables: true,
+        breaks: false,
+        pedantic: false,
+        sanitize: true,
+        smartLists: true,
+        smartypants: false
+    });
+
+    // Convert all markdown files.
+    // First, pull out nomnoml diagrams.
+    // Then, convert remaining Markdown to HTML.
+    glob(options['in'] + "/**/*.md", {}, function (err, files) {
+        files.forEach(function (file) {
+            var destination = file.replace(options['in'], options.out)
+                .replace(/md$/, "html"),
+                destPath = path.dirname(destination),
+                prefix = path.basename(destination).replace(/\.html$/, "");
+
+            mkdirp(destPath, function (err) {
+                fs.createReadStream(file, { encoding: 'utf8' })
+                    .pipe(split())
+                    .pipe(nomnomlifier(destPath, prefix))
+                    .pipe(gfmifier())
+                    .pipe(fs.createWriteStream(destination, {
+                        encoding: 'utf8'
+                    }));
+            });
+        });
+    });
+
+    // Also copy over all HTML, CSS, or PNG files
+    glob(options['in'] + "/**/*.@(html|css|png)", {}, function (err, files) {
+        files.forEach(function (file) {
+            var destination = file.replace(options['in'], options.out),
+                destPath = path.dirname(destination),
+                streamOptions = {};
+            if (file.match(/png$/)) {
+                streamOptions.encoding = null;
+            } else {
+                streamOptions.encoding = 'utf8';
+            }
+
+            mkdirp(destPath, function (err) {
+                fs.createReadStream(file, streamOptions)
+                    .pipe(fs.createWriteStream(destination, streamOptions));
+            });
+        });
+    });
+
+}());

docs/header.html

@@ -0,0 +1,7 @@
+<html>
+    <head>
+        <link rel="stylesheet"
+              href="http://jasonm23.github.io/markdown-css-themes/avenir-white.css">
+    </head>
+    <body>
+

docs/src/architecture/framework.md

@@ -0,0 +1,232 @@
+# Overview
+
+The framework layer's most basic responsibility is allowing individual
+software components to communicate. The software components it recognizes
+are:
+
+* _Extensions_: Individual units of functionality that can be added to
+  or removed from Open MCT Web. _Extension categories_ distinguish what
+  type of functionality is being added/removed.
+* _Bundles_: A grouping of related extensions
+  (named after an analogous concept from [OSGi](http://www.osgi.org/))
+  that may be added or removed as a group.
+
+The framework layer operates by taking a set of active bundles, and
+exposing extensions to one another as-needed, using
+[dependency injection](https://en.wikipedia.org/wiki/Dependency_injection).
+Extensions are responsible for declaring their dependencies in a
+manner which the framework layer can understand.
+
+```nomnoml
+#direction: down
+[Open MCT Web|
+  [Dependency injection framework]-->[Platform bundle #1]
+  [Dependency injection framework]-->[Platform bundle #2]
+  [Dependency injection framework]-->[Plugin bundle #1]
+  [Dependency injection framework]-->[Plugin bundle #2]
+  [Platform bundle #1|[Extensions]]
+  [Platform bundle #2|[Extensions]]
+  [Plugin bundle #1|[Extensions]]
+  [Plugin bundle #2|[Extensions]]
+  [Platform bundle #1]<->[Platform bundle #2]
+  [Plugin bundle #1]<->[Platform bundle #2]
+  [Plugin bundle #1]<->[Plugin bundle #2]
+]
+```
+
+The "dependency injection framework" in this case is
+[AngularJS](https://angularjs.org/). Open MCT Web's framework layer
+is really just a thin wrapper over Angular that recognizes the
+concepts of bundles and extensions (as declared in JSON files) and
+registering extensions with Angular. It additionally acts as a
+mediator between Angular and [RequireJS](http://requirejs.org/),
+which is used to load JavaScript sources which implement
+extensions.
+
+```nomnoml
+[Framework layer|
+  [AngularJS]<-[Framework Component]
+  [RequireJS]<-[Framework Component]
+  [Framework Component]1o-*[Bundles]
+]
+```
+
+It is worth noting that _no other components_ are "aware" of the
+framework component directly; Angular and Require are _used by_ the
+framework components, and extensions in various bundles will have
+their dependencies satisfied by Angular as a consequence of registration
+activities which were performed by the framework component.
+
+
+## Application Initialization
+
+The framework component initializes an Open MCT Web application following
+a simple sequence of steps.
+
+```nomnoml
+[<start> Start]->[<state> Load bundles.json]
+[Load bundles.json]->[<state> Load bundle.json files]
+[Load bundle.json files]->[<state> Resolve implementations]
+[Resolve implementations]->[<state> Register with Angular]
+[Register with Angular]->[<state> Bootstrap application]
+[Bootstrap application]->[<end> End]
+```
+
+1. __Loading bundles.json.__ A file named `bundles.json` is loaded to determine
+   which bundles to load. Bundles are given in this file as relative paths
+   which point to bundle directories.
+2. __Load bundle.json files.__ Individual bundle definitions are loaded; a
+   `bundle.json` file is expected in each bundle directory.
+2. __Resolving implementations.__ Any scripts which provide implementations for
+   extensions exposed by bundles are loaded, using RequireJS.
+3. __Register with Angular.__ Resolved extensions are registered with Angular,
+   such that they can be used by the application at run-time. This stage
+   includes both registration of Angular built-ins (directives, controllers,
+   routes, constants, and services) as well as registration of non-Angular
+   extensions.
+4. __Bootstrap application.__ Once all extensions have been registered,
+   the Angular application
+   [is bootstrapped](https://docs.angularjs.org/guide/bootstrap).
+
+## Architectural Paradigm
+
+```nomnoml
+[Extension]
+[Extension]o->[Dependency #1]
+[Extension]o->[Dependency #2]
+[Extension]o->[Dependency #3]
+```
+
+Open MCT Web's architecture relies on a simple premise: Individual units
+(extensions) only have access to the dependencies they declare that they
+need, and they acquire references to these dependencies via dependency
+injection. This has several desirable traits:
+
+* Programming to an interface is enforced. Any given dependency can be
+  swapped out for something which exposes an equivalent interface. This
+  improves flexibility against refactoring, simplifies testing, and
+  provides a common mechanism for extension and reconfiguration.
+* The dependencies of a unit must be explicitly defined. This means that
+  it can be easily determined what a given unit's role is within the
+  larger system, in terms of what other components it will interact with.
+  It also helps to enforce good separation of concerns: When a set of
+  declared dependencies becomes long it is obvious, and this is usually
+  a sign that a given unit is involved in too many concerns and should
+  be refactored into smaller pieces.
+* Individual units do not need to be aware of the framework; they need
+  only be aware of the interfaces to the components they specifically
+  use. This avoids introducing a ubiquitous dependency upon the framework
+  layer itself; it is plausible to modify or replace the framework
+  without making changes to individual software components which run upon
+  the framework.
+
+A drawback to this approach is that it makes it difficult to define
+"the architecture" of Open MCT Web, in terms of describing the specific
+units that interact at run-time. The run-time architecture is determined
+by the framework as the consequence of wiring together dependencies.
+As such, the specific architecture of any given application built on
+Open MCT Web can look very different.
+
+Keeping that in mind, there are a few useful patterns supported by the
+framework that are useful to keep in mind.
+
+The specific service infrastructure provided by the platform is described
+in the [Platform Architecture](Platform.md).
+
+## Extension Categories
+
+One of the capabilities that the framework component layers on top of
+AngularJS is support for many-to-one dependencies. That is, a specific
+extension may declare a dependency to _all extensions of a specific
+category_, instead of being limited to declaring specific dependencies.
+
+```nomnoml
+#direction: right
+[Specific Extension] 1 o-> * [Extension of Some Category]
+```
+
+This is useful for introducing specific extension points to an application.
+Some unit of software will depend upon all extensions of a given category
+and integrate their behavior into the system in some fashion; plugin authors
+can then add new extensions of that category to augment existing behaviors.
+
+Some developers may be familiar with the use of registries to achieve
+similar characteristics. This approach is similar, except that the registry
+is effectively implicit whenever a new extension category is used or
+depended-upon. This has some advantages over a more straightforward
+registry-based approach:
+
+* These many-to-one relationships are expressed as dependencies; an
+  extension category is registered as having dependencies on all individual
+  extensions of this category. This avoids ordering issues that may occur
+  with more conventional registries, which may be observed before all
+  dependencies are resolved.
+* The need for service registries of specific types is removed, reducing
+  the number of interfaces to manage within the system. Groups of
+  extensions are provided as arrays.
+
+## Composite Services
+
+Composite services (registered via extension category `components`) are
+a pattern supported by the framework. These allow service instances to
+be built from multiple components at run-time; support for this pattern
+allows additional bundles to introduce or modify behavior associated
+with these services without modifying or replacing original service
+instances.
+
+```nomnoml
+#direction: down
+[<abstract> FooService]
+[FooDecorator #1]--:>[FooService]
+[FooDecorator #n]--:>[FooService]
+[FooAggregator]--:>[FooService]
+[FooProvider #1]--:>[FooService]
+[FooProvider #n]--:>[FooService]
+
+[FooDecorator #1]o->[<state> ...decorators...]
+[...decorators...]o->[FooDecorator #n]
+[FooDecorator #n]o->[FooAggregator]
+[FooAggregator]o->[FooProvider #1]
+[FooAggregator]o->[<state> ...providers...]
+[FooAggregator]o->[FooProvider #n]
+
+[FooDecorator #1]--[<note> Exposed as fooService]
+```
+
+In this pattern, components all implement an interface which is
+standardized for that service. Components additionally declare
+that they belong to one of three types:
+
+* __Providers.__ A provider actually implements the behavior
+  (satisfies the contract) for that kind of service. For instance,
+  if a service is responsible for looking up documents by an identifier,
+  one provider may do so by querying a database, while another may
+  do so by reading a static JSON document. From the outside, either
+  provider would look the same (they expose the same interface) and
+  they could be swapped out easily.
+* __Aggregator.__ An aggregator takes many providers and makes them
+  behave as one. Again, this implements the same interface as an
+  individual provider, so users of the service do not need to be
+  concerned about the difference between consulting many providers
+  and consulting one. Continuing with the example of a service that
+  looks up documents by identifiers, an aggregator here might consult
+  all providers, and return any document is found (perhaps picking one
+  over the other or merging documents if there are multiple matches.)
+* __Decorators.__ A decorator exposes the same interface as other
+  components, but instead of fully implementing the behavior associated
+  with that kind of service, it only acts as an intermediary, delegating
+  the actual behavior to a different component. Decorators may transform
+  inputs or outputs, or initiate some side effects associated with a
+  service. This is useful if certain common behavior associated with a
+  service (caching, for instance) may be useful across many different
+  implementations of that same service.
+
+The framework will register extensions in this category such that an
+aggregator will depend on all of its providers, and decorators will
+depend upon on one another in a chain. The result of this compositing step
+(the last decorator, if any; otherwise the aggregator, if any;
+otherwise a single provider) will be exposed as a single service that
+other extensions can acquire through dependency injection. Because all
+components of the same type of service expose the same interface, users
+of that service do not need to be aware that they are talking to an
+aggregator or a provider, for instance.

docs/src/architecture/index.md

@@ -0,0 +1,78 @@
+# Introduction
+
+The purpose of this document is to familiarize developers with the
+overall architecture of Open MCT Web.
+
+The target audience includes:
+
+* _Platform maintainers_: Individuals involved in developing,
+  extending, and maintaing capabilities of the platform.
+* _Integration developers_: Individuals tasked with integrated
+  Open MCT Web into a larger system, who need to understand
+  its inner workings sufficiently to complete this integration.
+
+As the focus of this document is on architecture, whenever possible
+implementation details (such as relevant API or JSON syntax) have been
+omitted. These details may be found in the developer guide.
+
+# Overview
+
+Open MCT Web is client software: It runs in a web browser and
+provides a user interface, while communicating with various
+server-side resources through browser APIs.
+
+```nomnoml
+#direction: right
+[Client|[Browser|[Open MCT Web]->[Browser APIs]]]
+[Server|[Web services]]
+[Client]<->[Server]
+```
+
+While Open MCT Web can be configured to run as a standalone client,
+this is rarely very useful. Instead, it is intended to be used as a
+display and interaction layer for information obtained from a
+variety of back-end services. Doing so requires authoring or utilizing
+adapter plugins which allow Open MCT Web to interact with these services.
+
+Typically, the pattern here is to provide a known interface that
+Open MCT Web can utilize, and implement it such that it interacts with
+whatever back-end provides the relevant information.
+Examples of back-ends that can be utilized in this fashion include
+databases for the persistence of user-created objects, or sources of
+telemetry data.
+
+## Software Architecture
+
+The simplest overview of Open MCT Web is to look at it as a "layered"
+architecture, where each layer more clearly specifies the behavior
+of the software.
+
+```nomnoml
+#direction: down
+[Open MCT Web|
+  [Platform]<->[Application]
+  [Framework]->[Application]
+  [Framework]->[Platform]
+]
+```
+
+These layers are:
+
+* [_Framework_](framework.md): The framework layer is responsible for
+  managing the interactions between application components. It has no
+  application-specific knowledge; at this layer, we have only
+  established an abstraction by which different software components
+  may communicate and/or interact.
+* [_Platform_](platform.md): The platform layer defines the general look, 
+  feel, and behavior of Open MCT Web. This includes user-facing components like
+  Browse mode and Edit mode, as well as underlying elements of the
+  information model and the general service infrastructure.
+* _Application_: The application layer defines specific features of
+  an application built on Open MCT Web. This includes adapters to
+  specific back-ends, new types of things for users to create, and
+  new ways of visualizing objects within the system. This layer
+  typically consists of a mix of custom plug-ins to Open MCT Web,
+  as well as optional features (such as Plot view) included alongside
+  the platform.
+
+

docs/src/architecture/platform.md

@@ -0,0 +1,726 @@
+# Overview
+
+The Open MCT Web platform utilizes the [framework layer](Framework.md)
+to provide an extensible baseline for applications which includes:
+
+* A common user interface (and user interface paradigm) for dealing with
+  domain objects of various sorts.
+* A variety of extension points for introducing new functionality
+  of various kinds within the context of the common user interface.
+* A service infrastructure to support building additional components.
+
+## Platform Architecture
+
+While the framework provides a more general architectural paradigm for
+building application, the platform adds more specificity by defining
+additional extension types and allowing for integration with back end
+components.
+
+The run-time architecture of an Open MCT Web application can be categorized
+into certain high-level tiers:
+
+```nomnoml
+[DOM]->[<state> AngularJS]
+[AngularJS]->[Presentation Layer]
+[Presentation Layer]->[Information Model]
+[Presentation Layer]->[Service Infrastructure]
+[Information Model]->[Service Infrastructure]
+[Service Infrastructure]->[<state> Browser APIs]
+[Browser APIs]->[Back-end]
+```
+
+Applications built using Open MCT Web may add or configure functionality
+in __any of these tiers__.
+
+* _DOM_: The rendered HTML document, composed from HTML templates which
+  have been processed by AngularJS and will be updated by AngularJS
+  to reflect changes from the presentation layer. User interactions
+  are initiated from here and invoke behavior in the presentation layer. HTML 
+  templates are written in Angular’s template syntax; see the [Angular documentation on templates](https://docs.angularjs.org/guide/templates)​. 
+  These describe the page as actually seen by the user. Conceptually, 
+  stylesheets (controlling the look­and­feel of the rendered templates) belong 
+  in this grouping as well. 
+* [_Presentation layer_](#presentation-layer): The presentation layer
+  is responsible for updating (and providing information to update)
+  the displayed state of the application. The presentation layer consists
+  primarily of _controllers_ and _directives_. The presentation layer is
+  concerned with inspecting the information model and preparing it for
+  display.
+* [_Information model_](#information-model): ​Provides a common (within Open MCT 
+  Web) set of interfaces for dealing with “things” ­ domain objects ­ within the 
+  system. User­facing concerns in a Open MCT Web application are expressed as 
+  domain objects; examples include folders (used to organize other domain 
+  objects), layouts (used to build displays), or telemetry points (used as 
+  handles for streams of remote measurements.) These domain objects expose a 
+  common set of interfaces to allow reusable user interfaces to be built in the 
+  presentation and template tiers; the specifics of these behaviors are then 
+  mapped to interactions with underlying services. 
+* [_Service infrastructure_](#service-infrastructure): The service
+  infrastructure is responsible for providing the underlying general
+  functionality needed to support the information model. This includes
+  exposing underlying sets of extensions and mediating with the
+  back-end.
+* _Back-end_: The back-end is out of the scope of Open MCT Web, except
+  for the interfaces which are utilized by adapters participating in the
+  service infrastructure. Includes the underlying persistence stores, telemetry 
+  streams, and so forth which the Open MCT Web client is being used to interact 
+  with.
+
+## Application Start-up
+
+Once the
+[application has been initialized](Framework.md#application-initialization)
+Open MCT Web primarily operates in an event-driven paradigm; various
+events (mouse clicks, timers firing, receiving responses to XHRs) trigger
+the invocation of functions, typically in the presentation layer for
+user actions or in the service infrastructure for server responses.
+
+The "main point of entry" into an initialized Open MCT Web application
+is effectively the
+[route](https://docs.angularjs.org/api/ngRoute/service/$route#example)
+which is associated with the URL used to access Open MCT Web (or a
+default route.) This route will be associated with a template which
+will be displayed; this template will include references to directives
+and controllers which will be interpreted by Angular and used to
+initialize the state of the display in a manner which is backed by
+both the information model and the service infrastructure.
+
+```nomnoml
+[<start> Start]->[<state> page load]
+[page load]->[<state> route selection]
+[route selection]->[<state> compile, display template]
+[compile, display template]->[Template]
+[Template]->[<state> use Controllers]
+[Template]->[<state> use Directives]
+[use Controllers]->[Controllers]
+[use Directives]->[Directives]
+[Controllers]->[<state> consult information model]
+[consult information model]->[<state> expose data]
+[expose data]->[Angular]
+[Angular]->[<state> update display]
+[Directives]->[<state> add event listeners]
+[Directives]->[<state> update display]
+[add event listeners]->[<end> End]
+[update display]->[<end> End]
+```
+
+
+# Presentation Layer
+
+The presentation layer of Open MCT Web is responsible for providing
+information to display within templates, and for handling interactions
+which are initiated from templated DOM elements. AngularJS acts as
+an intermediary between the web page as the user sees it, and the
+presentation layer implemented as Open MCT Web extensions.
+
+```nomnoml
+[Presentation Layer|
+  [Angular built-ins|
+    [routes]
+    [controllers]
+    [directives]
+    [templates]
+  ]
+  [Domain object representation|
+    [views]
+    [representations]
+    [representers]
+    [gestures]
+  ]
+]
+```
+
+## Angular built-ins
+
+Several extension categories in the presentation layer map directly
+to primitives from AngularJS:
+
+* [_Controllers_](https://docs.angularjs.org/guide/controller) provide
+  data to templates, and expose functionality that can be called from
+  templates.
+* [_Directives_](https://docs.angularjs.org/guide/directive) effectively
+  extend HTML to provide custom behavior associated with specific
+  attributes and tags.
+* [_Routes_](https://docs.angularjs.org/api/ngRoute/service/$route#example)
+  are used to associate specific URLs (including the fragment identifier)
+  with specific application states. (In Open MCT Web, these are used to
+  describe the mode of usage - e.g. browse or edit - as well as to
+  identify the object being used.)
+* [_Templates_](https://docs.angularjs.org/guide/templates) are partial
+  HTML documents that will be rendered and kept up-to-date by AngularJS.
+  Open MCT Web introduces a custom `mct-include` directive which acts
+  as a wrapper around `ng-include` to allow templates to be referred
+  to by symbolic names.
+
+## Domain object representation
+
+The remaining extension categories in the presentation layer are specific
+to displaying domain objects.
+
+* _Representations_ are templates that will be used to display
+  domain objects in specific ways (e.g. "as a tree node.")
+* _Views_ are representations which are exposed to the user as options
+  for displaying domain objects.
+* _Representers_ are extensions which modify or augment the process
+  of representing domain objects generally (e.g. by attaching
+  gestures to them.)
+* _Gestures_ provide associations between specific user actions
+  (expressed as DOM events) and resulting behavior upon domain objects
+  (typically expressed as members of the `actions` extension category)
+  that can be reused across domain objects. For instance, `drag` and
+  `drop` are both gestures associated with using drag-and-drop to
+  modify the composition of domain objects by interacting with their
+  representations.
+
+# Information Model
+
+```nomnoml
+#direction: right
+[Information Model|
+  [DomainObject|
+    getId() : string
+    getModel() : object
+    getCapability(key : string) : Capability
+    hasCapability(key : string) : boolean
+    useCapability(key : string, args...) : *
+  ]
+  [DomainObject] 1 +- 1 [Model]
+  [DomainObject] 1 o- * [Capability]
+]
+```
+
+Domain objects are the most fundamental component of Open MCT Web's
+information model. A domain object is some distinct thing relevant to a
+user's work flow, such as a telemetry channel, display, or similar.
+Open MCT Web is a tool for viewing, browsing, manipulating, and otherwise
+interacting with a graph of domain objects.
+
+A domain object should be conceived of as the union of the following:
+
+* _Identifier_: A machine-readable string that uniquely identifies the
+  domain object within this application instance.
+* _Model_: The persistent state of the domain object. A domain object's
+  model is a JavaScript object that can be losslessly converted to JSON.
+* _Capabilities_: Dynamic behavior associated with the domain object.
+  Capabilities are JavaScript objects which provide additional methods
+  for interacting with the domain objects which expose those capabilities.
+  Not all domain objects expose all capabilities. The interface exposed
+  by any given capability will depend on its type (as identified
+  by the `key` argument.) For instance, a `persistence` capability
+  has a different interface from a `telemetry` capability. Using
+  capabilities requires some prior knowledge of their interface.
+
+## Capabilities and Services
+
+```nomnoml
+#direction: right
+[DomainObject]o-[FooCapability]
+[FooCapability]o-[FooService]
+[FooService]o-[foos]
+```
+
+At run-time, the user is primarily concerned with interacting with
+domain objects. These interactions are ultimately supported via back-end
+services, but to allow customization per-object, these are often mediated
+by capabilities.
+
+A common pattern that emerges in the Open MCT Platform is as follows:
+
+* A `DomainObject` has some particular behavior that will be supported
+  by a service.
+* A `Capability` of that domain object will define that behavior,
+  _for that domain object_, supported by a service.
+* A `Service` utilized by that capability will perform the actual behavior.
+* An extension category will be utilized by that capability to determine
+  the set of possible behaviors.
+
+Concrete examples of capabilities which follow this pattern
+(or a subset of this pattern) include:
+
+```nomnoml
+#direction: right
+[DomainObject]1 o- *[Capability]
+[Capability]<:--[TypeCapability]
+[Capability]<:--[ActionCapability]
+[Capability]<:--[PersistenceCapability]
+[Capability]<:--[TelemetryCapability]
+[TypeCapability]o-[TypeService]
+[TypeService]o-[types]
+[ActionCapability]o-[ActionService]
+[ActionService]o-[actions]
+[PersistenceCapability]o-[PersistenceService]
+[TelemetryCapability]o-[TelemetryService]
+```
+
+# Service Infrastructure
+
+Most services exposed by the Open MCT Web platform follow the
+[composite services](Framework.md#composite-services) to permit
+a higher degree of flexibility in how a service can be modified
+or customized for specific applications.
+
+To simplify usage for plugin developers, the platform also usually
+includes a provider implementation for these service type that consumes
+some extension category. For instance, an `ActionService` provider is
+included which depends upon extension category `actions`, and exposes
+all actions declared as such to the system. As such, plugin developers
+can simply implement the new actions they wish to be made available without
+worrying about the details of composite services or implementing a new
+`ActionService` provider; however, the ability to implement a new provider
+remains useful when the expressive power of individual extensions is
+insufficient.
+
+```nomnoml
+[ Service Infrastructure |
+  [ObjectService]->[ModelService]
+  [ModelService]->[PersistenceService]
+  [ObjectService]->[CapabilityService]
+  [CapabilityService]->[capabilities]
+  [capabilities]->[TelemetryService]
+  [capabilities]->[PersistenceService]
+  [capabilities]->[TypeService]
+  [capabilities]->[ActionService]
+  [capabilities]->[ViewService]
+  [PersistenceService]->[<database> Document store]
+  [TelemetryService]->[<database> Telemetry source]
+  [ActionService]->[actions]
+  [ActionService]->[PolicyService]
+  [ViewService]->[PolicyService]
+  [ViewService]->[views]
+  [PolicyService]->[policies]
+  [TypeService]->[types]
+]
+```
+
+A short summary of the roles of these services:
+
+* _[ObjectService](#object-service)_: Allows retrieval of domain objects by
+  their identifiers; in practice, often the main point of entry into the
+  [information model](#information-model).
+* _[ModelService](#model-service)_: Provides domain object models, retrieved
+  by their identifier.
+* _[CapabilityService](#capability-service)_: Provides capabilities, as they
+  apply to specific domain objects (as judged from their model.)
+* _[TelemetryService](#telemetry-service)_: Provides access to historical
+  and real-time telemetry data.
+* _[PersistenceService](#persistence-service)_: Provides the ability to
+  store and retrieve documents (such as domain object models.)
+* _[ActionService](#action-service)_: Provides distinct user actions that
+  can take place within the system (typically, upon or using domain objects.)
+* _[ViewService](#view-service)_: Provides views for domain objects. A view
+  is a user-selectable representation of a domain object (in practice, an
+  HTML template.)
+* _[PolicyService](#policy-service)_: Handles decisions about which
+  behavior are allowed within certain specific contexts.
+* _[TypeService](#type-service)_: Provides information to distinguish
+  different types of domain objects from one another within the system.
+
+## Object Service
+
+```nomnoml
+#direction: right
+[<abstract> ObjectService|
+  getObjects(ids : Array.<string>) : Promise.<object.<string, DomainObject>>
+]
+[DomainObjectProvider]--:>[ObjectService]
+[DomainObjectProvider]o-[ModelService]
+[DomainObjectProvider]o-[CapabilityService]
+```
+
+As domain objects are central to Open MCT Web's information model,
+acquiring domain objects is equally important.
+
+```nomnoml
+#direction: right
+[<start> Start]->[<state> Look up models]
+[<state> Look up models]->[<state> Look up capabilities]
+[<state> Look up capabilities]->[<state> Instantiate DomainObject]
+[<state> Instantiate DomainObject]->[<end> End]
+```
+
+Open MCT Web includes an implementation of an `ObjectService` which
+satisfies this capability by:
+
+* Consulting the [Model Service](#model-service) to acquire domain object
+  models by identifier.
+* Passing these models to a [Capability Service](#capability-service) to
+  determine which capabilities are applicable.
+* Combining these results together as [DomainObject](#information-model)
+  instances.
+
+## Model Service
+
+```nomnoml
+#direction: down
+[<abstract> ModelService|
+  getModels(ids : Array.<string>) : Promise.<object.<string, object>>
+]
+[StaticModelProvider]--:>[ModelService]
+[RootModelProvider]--:>[ModelService]
+[PersistedModelProvider]--:>[ModelService]
+[ModelAggregator]--:>[ModelService]
+[CachingModelDecorator]--:>[ModelService]
+[MissingModelDecorator]--:>[ModelService]
+
+[MissingModelDecorator]o-[CachingModelDecorator]
+[CachingModelDecorator]o-[ModelAggregator]
+[ModelAggregator]o-[StaticModelProvider]
+[ModelAggregator]o-[RootModelProvider]
+[ModelAggregator]o-[PersistedModelProvider]
+
+[PersistedModelProvider]o-[PersistenceService]
+[RootModelProvider]o-[roots]
+[StaticModelProvider]o-[models]
+```
+
+The platform's model service is responsible for providing domain object
+models (effectively, JSON documents describing the persistent state
+associated with domain objects.) These are retrieved by identifier.
+
+The platform includes multiple components of this variety:
+
+* `PersistedModelProvider` looks up domain object models from
+  a persistence store (the [`PersistenceService`](#persistence-service));
+  this is how user-created and user-modified
+  domain object models are retrieved.
+* `RootModelProvider` provides domain object models that have been
+  declared via the `roots` extension category. These will appear at the
+  top level of the tree hierarchy in the user interface.
+* `StaticModelProvider` provides domain object models that have been
+  declared via the `models` extension category. This is useful for
+  allowing plugins to expose new domain objects declaratively.
+* `ModelAggregator` merges together the results from multiple providers.
+  If multiple providers return models for the same domain object,
+  the most recently modified version (as determined by the `modified`
+  property of the model) is chosen.
+* `CachingModelDecorator` caches model instances in memory. This
+  ensures that only a single instance of a domain object model is
+  present at any given time within the application, and prevent
+  redundant retrievals.
+* `MissingModelDecorator` adds in placeholders when no providers
+  have returned domain object models for a specific identifier. This
+  allows the user to easily see that something was expected to be
+  present, but wasn't.
+
+## Capability Service
+
+```nomnoml
+#direction: down
+[<abstract> CapabilityService|
+  getCapabilities(model : object) : object.<string, Function>
+]
+[CoreCapabilityProvider]--:>[CapabilityService]
+[QueuingPersistenceCapabilityDecorator]--:>[CapabilityService]
+
+[CoreCapabilityProvider]o-[capabilities]
+[QueuingPersistenceCapabilityDecorator]o-[CoreCapabilityProvider]
+```
+
+The capability service is responsible for determining which capabilities
+are applicable for a given domain object, based on its model. Primarily,
+this is handled by the `CoreCapabilityProvider`, which examines
+capabilities exposed via the `capabilities` extension category.
+
+Additionally, `platform/persistence/queue` decorates the persistence
+capability specifically to batch persistence attempts among multiple
+objects (this allows failures to be recognized and handled in groups.)
+
+## Telemetry Service
+
+```nomnoml
+[<abstract> TelemetryService|
+  requestData(requests : Array.<TelemetryRequest>) : Promise.<object>
+  subscribe(requests : Array.<TelemetryRequest>) : Function
+]<--:[TelemetryAggregator]
+```
+
+The telemetry service is responsible for acquiring telemetry data.
+
+Notably, the platform does not include any providers for
+`TelemetryService`; applications built on Open MCT Web will need to
+implement a provider for this service if they wish to expose telemetry
+data. This is usually the most important step for integrating Open MCT Web
+into an existing telemetry system.
+
+Requests for telemetry data are usually initiated in the
+[presentation layer](#presentation-layer) by some `Controller` referenced
+from a view. The `telemetryHandler` service is most commonly used (although
+one could also use an object's `telemetry` capability directly) as this
+handles capability delegation, by which a domain object such as a Telemetry
+Panel can declare that its `telemetry` capability should be handled by the
+objects it contains. Ultimately, the request for historical data and the
+new subscriptions will reach the `TelemetryService`, and, by way of the
+provider(s) which are present for that `TelemetryService`, will pass the
+same requests to the back-end.
+
+```nomnoml
+[<start> Start]->[Controller]
+[Controller]->[<state> declares object of interest]
+[declares object of interest]->[TelemetryHandler]
+[TelemetryHandler]->[<state> requests telemetry from capabilities]
+[TelemetryHandler]->[<state> subscribes to telemetry using capabilities]
+[requests telemetry from capabilities]->[TelemetryCapability]
+[subscribes to telemetry using capabilities]->[TelemetryCapability]
+[TelemetryCapability]->[<state> requests telemetry]
+[TelemetryCapability]->[<state> subscribes to telemetry]
+[requests telemetry]->[TelemetryService]
+[subscribes to telemetry]->[TelemetryService]
+[TelemetryService]->[<state> issues request]
+[TelemetryService]->[<state> updates subscriptions]
+[TelemetryService]->[<state> listens for real-time data]
+[issues request]->[<database> Telemetry Back-end]
+[updates subscriptions]->[Telemetry Back-end]
+[listens for real-time data]->[Telemetry Back-end]
+[Telemetry Back-end]->[<end> End]
+```
+
+The back-end, in turn, is expected to provide whatever historical
+telemetry is available to satisfy the request that has been issue.
+
+```nomnoml
+[<start> Start]->[<database> Telemetry Back-end]
+[Telemetry Back-end]->[<state> transmits historical telemetry]
+[transmits historical telemetry]->[TelemetryService]
+[TelemetryService]->[<state> packages telemetry, fulfills requests]
+[packages telemetry, fulfills requests]->[TelemetryCapability]
+[TelemetryCapability]->[<state> unpacks telemetry per-object, fulfills request]
+[unpacks telemetry per-object, fulfills request]->[TelemetryHandler]
+[TelemetryHandler]->[<state> exposes data]
+[TelemetryHandler]->[<state> notifies controller]
+[exposes data]->[Controller]
+[notifies controller]->[Controller]
+[Controller]->[<state> prepares data for template]
+[prepares data for template]->[Template]
+[Template]->[<state> displays data]
+[displays data]->[<end> End]
+```
+
+One peculiarity of this approach is that we package many responses
+together at once in the `TelemetryService`, then unpack these in the
+`TelemetryCapability`, then repackage these in the `TelemetryHandler`.
+The rationale for this is as follows:
+
+* In the `TelemetryService`, we want to have the ability to combine
+  multiple requests into one call to the back-end, as many back-ends
+  will support this. It follows that we give the response as a single
+  object, packages in a manner that allows responses to individual
+  requests to be easily identified.
+* In the `TelemetryCapability`, we want to provide telemetry for a
+  _single object_, so the telemetry data gets unpacked. This allows
+  for the unpacking of data to be handled in a single place, and
+  also permits a flexible substitution method; domain objects may have
+  implementations of the `telemetry` capability that do not use the
+  `TelemetryService` at all, while still maintaining compatibility
+  with any presentation layer code written to utilize this capability.
+  (This is true of capabilities generally.)
+* In the `TelemetryHandler`, we want to group multiple responses back
+  together again to make it easy for the presentation layer to consume.
+  In this case, the grouping is different from what may have occurred
+  in the `TelemetryService`; this grouping is based on what is expected
+  to be useful _in a specific view_. The `TelemetryService`
+  may be receiving requests from multiple views.
+
+```nomnoml
+[<start> Start]->[<database> Telemetry Back-end]
+[Telemetry Back-end]->[<state> notifies client of new data]
+[notifies client of new data]->[TelemetryService]
+[TelemetryService]->[<choice> relevant subscribers?]
+[relevant subscribers?] yes ->[<state> notify subscribers]
+[relevant subscribers?] no ->[<state> ignore]
+[ignore]->[<end> Ignored]
+[notify subscribers]->[TelemetryCapability]
+[TelemetryCapability]->[<state> notify listener]
+[notify listener]->[TelemetryHandler]
+[TelemetryHandler]->[<state> exposes data]
+[TelemetryHandler]->[<state> notifies controller]
+[exposes data]->[Controller]
+[notifies controller]->[Controller]
+[Controller]->[<state> prepares data for template]
+[prepares data for template]->[Template]
+[Template]->[<state> displays data]
+[displays data]->[<end> End]
+```
+
+The flow of real-time data is similar, and is handled by a sequence
+of callbacks between the presentation layer component which is
+interested in data and the telemetry service. Providers in the
+telemetry service listen to the back-end for new data (via whatever
+mechanism their specific back-end supports), package this data in
+the same manner as historical data, and pass that to the callbacks
+which are associated with relevant requests.
+
+## Persistence Service
+
+```nomnoml
+#direction: right
+[<abstract> PersistenceService|
+  listSpaces() : Promise.<Array.<string>>
+  listObjects() : Promise.<Array.<string>>
+  createObject(space : string, key : string, document : object) : Promise.<boolean>
+  readObject(space : string, key : string, document : object) : Promise.<object>
+  updateObject(space : string, key : string, document : object) : Promise.<boolean>
+  deleteObject(space : string, key : string, document : object) : Promise.<boolean>
+]
+
+[ElasticPersistenceProvider]--:>[PersistenceService]
+[ElasticPersistenceProvider]->[<database> ElasticSearch]
+
+[CouchPersistenceProvider]--:>[PersistenceService]
+[CouchPersistenceProvider]->[<database> CouchDB]
+```
+
+Closely related to the notion of domain objects models is their
+persistence. The `PersistenceService` allows these to be saved
+and loaded. (Currently, this capability is only used for domain
+object models, but the interface has been designed without this idea
+in mind; other kinds of documents could be saved and loaded in the
+same manner.)
+
+There is no single definitive implementation of a `PersistenceService` in
+the platform. Optional adapters are provided to store and load documents
+from CouchDB and ElasticSearch, respectively; plugin authors may also
+write additional adapters to utilize different back end technologies.
+
+## Action Service
+
+```nomnoml
+[ActionService|
+  getActions(context : ActionContext) : Array.<Action>
+]
+[ActionProvider]--:>[ActionService]
+[CreateActionProvider]--:>[ActionService]
+[ActionAggregator]--:>[ActionService]
+[LoggingActionDecorator]--:>[ActionService]
+[PolicyActionDecorator]--:>[ActionService]
+
+[LoggingActionDecorator]o-[PolicyActionDecorator]
+[PolicyActionDecorator]o-[ActionAggregator]
+[ActionAggregator]o-[ActionProvider]
+[ActionAggregator]o-[CreateActionProvider]
+
+[ActionProvider]o-[actions]
+[CreateActionProvider]o-[TypeService]
+[PolicyActionDecorator]o-[PolicyService]
+```
+
+Actions are discrete tasks or behaviors that can be initiated by a user
+upon or using a domain object. Actions may appear as menu items or
+buttons in the user interface, or may be triggered by certain gestures.
+
+Responsibilities of platform components of the action service are as
+follows:
+
+* `ActionProvider` exposes actions registered via extension category
+  `actions`, supporting simple addition of new actions. Actions are
+  filtered down to match action contexts based on criteria defined as
+  part of an action's extension definition.
+* `CreateActionProvider` provides the various Create actions which
+  populate the Create menu. These are driven by the available types,
+  so do not map easily ot extension category `actions`; instead, these
+  are generated after looking up which actions are available from the
+  [`TypeService`](#type-service).
+* `ActionAggregator` merges together actions from multiple providers.
+* `PolicyActionDecorator` enforces the `action` policy category by
+  filtering out actions which violate this policy, as determined by
+  consulting the [`PolicyService`](#policy-service).
+* `LoggingActionDecorator` wraps exposed actions and writes to the
+  console when they are performed.
+
+## View Service
+
+```nomnoml
+[ViewService|
+  getViews(domainObject : DomainObject) : Array.<View>
+]
+[ViewProvider]--:>[ViewService]
+[PolicyViewDecorator]--:>[ViewService]
+
+[ViewProvider]o-[views]
+[PolicyViewDecorator]o-[ViewProvider]
+```
+
+The view service provides views that are relevant to a specified domain
+object. A "view" is a user-selectable visualization of a domain object.
+
+The responsibilities of components of the view service are as follows:
+
+* `ViewProvider` exposes views registered via extension category
+  `views`, supporting simple addition of new views. Views are
+  filtered down to match domain objects based on criteria defined as
+  part of a view's extension definition.
+* `PolicyViewDecorator` enforces the `view` policy category by
+  filtering out views which violate this policy, as determined by
+  consulting the [`PolicyService`](#policy-service).
+
+## Policy Service
+
+```nomnoml
+[PolicyService|
+  allow(category : string, candidate : object, context : object, callback? : Function) : boolean
+]
+[PolicyProvider]--:>[PolicyService]
+[PolicyProvider]o-[policies]
+```
+
+The policy service provides a general-purpose extensible decision-making
+mechanism; plugins can add new extensions of category `policies` to
+modify decisions of a known category.
+
+Often, the policy service is referenced from a decorator for another
+service, to filter down the results of using that service based on some
+appropriate policy category.
+
+The policy provider works by looking up all registered policy extensions
+which are relevant to a particular _category_, then consulting each in
+order to see if they allow a particular _candidate_ in a particular
+_context_; the types for the `candidate` and `context` arguments will
+vary depending on the `category`. Any one policy may disallow the
+decision as a whole.
+
+
+```nomnoml
+[<start> Start]->[<state> is something allowed?]
+[is something allowed?]->[PolicyService]
+[PolicyService]->[<state> look up relevant policies by category]
+[look up relevant policies by category]->[<state> consult policy #1]
+[consult policy #1]->[Policy #1]
+[Policy #1]->[<choice> policy #1 allows?]
+[policy #1 allows?] no ->[<state> decision disallowed]
+[policy #1 allows?] yes ->[<state> consult policy #2]
+[consult policy #2]->[Policy #2]
+[Policy #2]->[<choice> policy #2 allows?]
+[policy #2 allows?] no ->[<state> decision disallowed]
+[policy #2 allows?] yes ->[<state> consult policy #3]
+[consult policy #3]->[<state> ...]
+[...]->[<state> consult policy #n]
+[consult policy #n]->[Policy #n]
+[Policy #n]->[<choice> policy #n allows?]
+[policy #n allows?] no ->[<state> decision disallowed]
+[policy #n allows?] yes ->[<state> decision allowed]
+[decision disallowed]->[<end> Disallowed]
+[decision allowed]->[<end> Allowed]
+```
+
+The policy decision is effectively an "and" operation over the individual
+policy decisions: That is, all policies must agree to allow a particular
+policy decision, and the first policy to disallow a decision will cause
+the entire decision to be disallowed. As a consequence of this, policies
+should generally be written with a default behavior of "allow", and
+should only disallow the specific circumstances they are intended to
+disallow.
+
+## Type Service
+
+```nomnoml
+[TypeService|
+  listTypes() : Array.<Type>
+  getType(key : string) : Type
+]
+[TypeProvider]--:>[TypeService]
+[TypeProvider]o-[types]
+```
+
+The type service provides metadata about the different types of domain
+objects that exist within an Open MCT Web application. The platform
+implementation reads these types in from extension category `types`
+and wraps them in a JavaScript interface.

docs/src/guide/security.md

@@ -1,121 +0,0 @@
-# Security Guide
-
-Open MCT is a rich client with plugin support that executes as a single page
-web application in a browser environment. Security concerns and
-vulnerabilities associated with the web as a platform should be considered
-before deploying Open MCT (or any other web application) for mission or
-production usage.
-
-This document describes several important points to consider when developing
-for or deploying Open MCT securely. Other resources such as
-[Open Web Application Security Project (OWASP)](https://www.owasp.org)
-provide a deeper and more general overview of security for web applications.
-
-
-## Security Model
-
-Open MCT has been architected assuming the following deployment pattern:
-
-* A tagged, tested Open MCT version will be used.
-* Externally authored plugins will be installed.
-* A server will provide persistent storage, telemetry, and other shared data.
-* Authorization, authentication, and auditing will be handled by a server.
-
-
-## Security Procedures
-
-The Open MCT team secures our code base using a combination of code review,
-dependency review, and periodic security reviews. Static analysis performed 
-during automated verification additionally safeguards against common 
-coding errors which may result in vulnerabilities.
-
-
-### Code Review
-
-All contributions are reviewed by internal team members. External
-contributors receive increased scrutiny for security and quality,
-and must sign a licensing agreement.
-
-### Dependency Review
-
-Before integrating third-party dependencies, they are reviewed for security
-and quality, with consideration given to authors and users of these
-dependencies, as well as review of open source code.
-
-### Periodic Security Reviews
-
-Open MCT's code, design, and architecture are periodically reviewed
-(approximately annually) for common security issues, such as the
-[OWASP Top Ten](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project).
-
-
-## Security Concerns
-
-Certain security concerns deserve special attention when deploying Open MCT,
-or when authoring plugins.
-
-### Identity Spoofing
-
-Open MCT issues calls to web services with the privileges of a logged in user.
-Compromised sources (either for Open MCT itself or a plugin) could
-therefore allow malicious code to execute with those privileges.
-
-To avoid this:
-
-* Serve Open MCT and other scripts over SSL (https rather than http)
-  to prevent man-in-the-middle attacks.
-* Exercise precautions such as security reviews for any plugins or
-  applications built for or with Open MCT to reject malicious changes.
-
-### Information Disclosure
-
-If Open MCT is used to handle or display sensitive data, any components
-(such as adapter plugins) must take care to avoid leaking or disclosing
-this information. For example, avoid sending sensitive data to third-party
-servers or insecure APIs.
-
-### Data Tampering
-
-The web application architecture leaves open the possibility that direct
-calls will be made to back-end services, circumventing Open MCT entirely.
-As such, Open MCT assumes that server components will perform any necessary
-data validation during calls issues to the server.
-
-Additionally, plugins which serialize and write data to the server must
-escape that data to avoid database injection attacks, and similar.
-
-### Repudiation
-
-Open MCT assumes that servers log any relevant interactions and associates
-these with a user identity; the specific user actions taken within the
-application are assumed not to be of concern for auditing.
-
-In the absence of server-side logging, users may disclaim (maliciously,
-mistakenly, or otherwise) actions taken within the system without any
-way to prove otherwise.
-
-If keeping client-level interactions is important, this will need to be
-implemented via a plugin.
-
-### Denial-of-service
-
-Open MCT assumes that server-side components will be insulated against
-denial-of-service attacks. Services should only permit resource-intensive
-tasks to be initiated by known or trusted users.
-
-### Elevation of Privilege
-
-Corollary to the assumption that servers guide against identity spoofing,
-Open MCT assumes that services do not allow a user to act with
-inappropriately escalated privileges. Open MCT cannot protect against
-such escalation; in the clearest case, a malicious actor could interact
-with web services directly to exploit such a vulnerability.
-
-## Additional Reading
-
-The following resources have been used as a basis for identifying potential
-security threats to Open MCT deployments in preparation of this document:
-
-* [STRIDE model](https://www.owasp.org/index.php/Threat_Risk_Modeling#STRIDE)
-* [Attack Surface Analysis Cheat Sheet](https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet)
-* [XSS Prevention Cheat Sheet](https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet)

docs/src/index.html

@@ -0,0 +1,38 @@
+<!--
+ Open MCT Web, Copyright (c) 2014-2015, United States Government
+ as represented by the Administrator of the National Aeronautics and Space
+ Administration. All rights reserved.
+
+ Open MCT Web is licensed under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+ http://www.apache.org/licenses/LICENSE-2.0.
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+ WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ License for the specific language governing permissions and limitations
+ under the License.
+
+ Open MCT Web includes source code licensed under additional open source
+ licenses. See the Open Source Licenses file (LICENSES.md) included with
+ this source code distribution or the Licensing information page available
+ at runtime from the About dialog for additional information.
+-->
+<!DOCTYPE html>
+<html>
+<head lang="en">
+    <meta charset="UTF-8">
+    <title>Open MCT Web Documentation</title>
+</head>
+<body class="user-environ" ng-view>
+    Sections:
+    <ul>
+        <li><a href="api/">API</a></li>
+        <li><a href="architecture/">Architecture Overview</a></li>
+        <li><a href="guide/">Developer Guide</a></li>
+        <li><a href="tutorials/">Tutorials</a></li>
+        <li><a href="process/">Development Process</a></li>
+    </ul>
+</body>
+</html>

docs/src/index.md

@@ -1,26 +0,0 @@
-# Open MCT Documentation
-
-## Overview
-
- Documentation is provided to support the use and development of
- Open MCT. It's recommended that before doing
- any development with Open MCT you take some time to familiarize yourself
- with the documentation below.
-
- Open MCT provides functionality out of the box, but it's also a platform for
- building rich mission operations applications based on modern web technology. 
- The platform is configured by plugins which extend the platform at a variety
- of extension points. The details of how to
- extend the platform are provided in the following documentation.
-
-## Sections
-
-* The [API](api/) uses inline documentation.
- using [TypeScript](https://www.typescriptlang.org) and some legacy [JSDoc](https://jsdoc.app/). It describes the JavaScript objects and
- functions that make up the software platform.
-
-* The [Development Process](process/) document describes the
- Open MCT software development cycle.
-
-* The [tutorial](https://github.com/nasa/openmct-tutorial) and [plugin template](https://github.com/nasa/openmct-hello) give examples of extending the platform to add
- functionality and integrate with data sources.

docs/src/process/cycle.md

@@ -1,165 +0,0 @@
-# Development Cycle
-
-Development of Open MCT occurs on an iterative cycle of
-sprints and releases.
-
-* A _sprint_ is three weeks in duration, and represents a
-  set of improvements that can be completed and tested by the
-  development team. Software at the end of the sprint is
-  "semi-stable"; it will have undergone reduced testing and may carry
-  defects or usability issues of lower severity, particularly if
-  there are workarounds.
-* A _release_ occurs every four sprints. Releases are stable, and
-  will have undergone full acceptance testing to ensure that the
-  software behaves correctly and usably.
-
-## Roles
-
-The sprint process assumes the presence of a __project manager.__
-The project manager is responsible for
-making tactical decisions about what development work will be
-performed, and for coordinating with stakeholders to arrive at
-higher-level strategic decisions about desired functionality
-and characteristics of the software, major external milestones,
-and so forth.
-
-In the absence of a dedicated project manager, this role may be rotated
-among members of the development team on a per-sprint basis.
-
-Responsibilities of the project manager including:
-
-* Maintaining (with agreement of stakeholders) a "road map" of work
-  planned for future releases/sprints; this should be higher-level,
-  usually expressed as "themes",
-  with just enough specificity to gauge feasibility of plans,
-  relate work back to milestones, and identify longer-term
-  dependencies.
-* Determining (with assistance from the rest of the team) which
-  issues to work on in a given sprint and how they shall be
-  assigned.
-* Pre-planning subsequent sprints to ensure that all members of the
-  team always have a clear direction.
-* Scheduling and/or ensuring adherence to
-  [process points](#process-points).
-* Responding to changes within the sprint (shifting priorities,
-  new issues) and re-allocating work for the sprint as needed.
-
-## Sprint Calendar
-
-Certain [process points](#process-points) are regularly scheduled in
-the sprint cycle.
-
-### Sprints by Release
-
-Allocation of work among sprints should be planned relative to release
-goals and milestones. As a general guideline, higher-risk work (large
-new features which may carry new defects, major refactoring, design
-changes with uncertain effects on usability) should be allocated to
-earlier sprints, allowing for time in later sprints to ensure stability.
-
-| Sprint | Focus                                                   |
-|:------:|:--------------------------------------------------------|
-| __1__  | Prototyping, design, experimentation.                   |
-| __2__  | New features, refinements, enhancements.                |
-| __3__  | Feature completion, low-risk enhancements, bug fixing.  |
-| __4__  | Stability & quality assurance.                          |
-
-### Sprints 1-3
-
-The first three sprints of a release are primarily centered around
-development work, with regular acceptance testing in the third
-week. During this third week, the top priority should be passing
-acceptance testing (e.g. by resolving any blockers found); any
-resources not needed for this effort should be used to begin work
-for the subsequent sprint.
-
-| Week  | Mon                       | Tue    | Wed | Thu                          | Fri                                   |
-|:-----:|:-------------------------:|:------:|:---:|:----------------------------:|:-------------------------------------:|
-| __1__ | Sprint plan               | Tag-up |     |                              |                                       |
-| __2__ |                           | Tag-up |     |                              | Code freeze  and sprint branch        |
-| __3__ | Per-sprint testing        | Triage |     | _Per-sprint testing*_        | Ship and merge sprint branch to master|
-
-* If necessary.
-
-### Sprint 4
-
-The software must be stable at the end of the fourth sprint; because of
-this, the fourth sprint is scheduled differently, with a heightened
-emphasis on testing.
-
-| Week   | Mon                       | Tue    | Wed | Thu                          | Fri         |
-|-------:|:-------------------------:|:------:|:---:|:----------------------------:|:-----------:|
-| __1__  | Sprint plan               | Tag-up |     |                              | Code freeze |
-| __2__  | Per-release testing       | Triage |     |                              |             |
-| __3__  | _Per-release testing*_    | Triage |     | _Per-release testing*_       | Ship        |
-
-* If necessary.
-
-## Process Points
-
-* __Sprint plan.__ Project manager allocates issues based on
-  theme(s) for sprint, then reviews with team. Each team member
-  should have roughly two weeks of work allocated (to allow time
-  in the third week for testing of work completed.)
-  * Project manager should also sketch out subsequent sprint so
-    that team may begin work for that sprint during the
-    third week, since testing and blocker resolution is unlikely
-    to require all available resources.
-  * Testing success criteria identified per issue (where necessary). This could be in the form of acceptance tests on the issue or detailing performance tests, for example.
-* __Tag-up.__ Check in and status update among development team.
-  May amend plan for sprint as-needed.
-* __Code freeze.__ Any new work from this sprint
-  (features, bug fixes, enhancements) must be integrated by the
-  end of the second week of the sprint. After code freeze, a sprint
-  branch will be created (and until the end of the sprint) the only 
-  changes that should be merged into the sprint branch should 
-  directly address issues needed to pass acceptance testing.
-  During this time, any other feature development will continue to
-  be merged into the master branch for the next sprint.
-* __Sprint branch merge to master.__ After acceptance testing, the sprint branch
-  will be merged back to the master branch. Any code conflicts that 
-  arise will be resolved by the team.
-* [__Per-release Testing.__](testing/plan.md#per-release-testing)
-  Structured testing with predefined
-  success criteria. No release should ship without passing
-  acceptance tests. Time is allocated in each sprint for subsequent
-  rounds of acceptance testing if issues are identified during a
-  prior round. Specific details of acceptance testing need to be
-  agreed-upon with relevant stakeholders and delivery recipients,
-  and should be flexible enough to allow changes to plans
-  (e.g. deferring delivery of some feature in order to ensure
-  stability of other features.) Baseline testing includes:
-  * [__Testathon.__](testing/plan.md#user-testing)
-    Multi-user testing, involving as many users as
-    is feasible, plus development team. Open-ended; should verify
-    completed work from this sprint using the sprint branch, test 
-    exploratory for regressions, et cetera.
-  * [__Long-Duration Test.__](testing/plan.md#long-duration-testing) A
-    test to verify that the software remains
-    stable after running for longer durations. May include some
-    combination of automated testing and user verification (e.g.
-    checking to verify that software remains subjectively
-    responsive at conclusion of test.)
-  * [__Unit Testing.__](testing/plan.md#unit-testing)
-    Automated testing integrated into the
-    build. (These tests are verified to pass more often than once
-    per sprint, as they run before any merge to master, but still
-    play an important role in per-release testing.)
-* [__Per-sprint Testing.__](testing/plan.md#per-sprint-testing)
-  Subset of Pre-release Testing
-  which should be performed before shipping at the end of any
-  sprint. Time is allocated for a second round of
-  Pre-release Testing if the first round is not passed. Smoke tests collected from issues/PRs
-* __Triage.__ Team reviews issues from acceptance testing and uses
-  success criteria to determine whether or not they should block
-  release, then formulates a plan to address these issues before
-  the next round of acceptance testing. Focus here should be on
-  ensuring software passes that testing in order to ship on time;
-  may prefer to disable malfunctioning components and fix them
-  in a subsequent sprint, for example.
-* [__Ship.__](version.md) Tag a code snapshot that has passed release/sprint
-  testing and deploy that version. (Only true if relevant
-  testing has passed by this point; if testing has not
-  been passed, will need to make ad hoc decisions with stakeholders,
-  e.g. "extend the sprint" or "defer shipment until end of next
-  sprint.")

docs/src/process/index.md

@@ -1,11 +1,156 @@
-# Development Process
+# Development Cycle
+
+Development of Open MCT Web occurs on an iterative cycle of
+sprints and releases.
+
+* A _sprint_ is three weeks in duration, and represents a
+  set of improvements that can be completed and tested by the
+  development team. Software at the end of the sprint is
+  "semi-stable"; it will have undergone reduced testing and may carry
+  defects or usability issues of lower severity, particularly if
+  there are workarounds.
+* A _release_ occurs every four sprints. Releases are stable, and
+  will have undergone full acceptance testing to ensure that the
+  software behaves correctly and usably.
+
+## Roles
+
+The sprint process assumes the presence of a __project manager.__
+The project manager is responsible for
+making tactical decisions about what development work will be
+performed, and for coordinating with stakeholders to arrive at
+higher-level strategic decisions about desired functionality
+and characteristics of the software, major external milestones,
+and so forth.
+
+In the absence of a dedicated project manager, this role may be rotated
+among members of the development team on a per-sprint basis.
+
+Responsibilities of the project manager including:
+
+* Maintaining (with agreement of stakeholders) a "road map" of work
+  planned for future releases/sprints; this should be higher-level,
+  usually expressed as "themes",
+  with just enough specificity to gauge feasibility of plans,
+  relate work back to milestones, and identify longer-term
+  dependencies.
+* Determining (with assistance from the rest of the team) which
+  issues to work on in a given sprint and how they shall be
+  assigned.
+* Pre-planning subsequent sprints to ensure that all members of the
+  team always have a clear direction.
+* Scheduling and/or ensuring adherence to
+  [process points](#process-points).
+* Responding to changes within the sprint (shifting priorities,
+  new issues) and re-allocating work for the sprint as needed.
+
+## Sprint Calendar
+
+Certain [process points](#process-points) are regularly scheduled in
+the sprint cycle.
+
+### Sprints by Release
+
+Allocation of work among sprints should be planned relative to release
+goals and milestones. As a general guideline, higher-risk work (large
+new features which may carry new defects, major refactoring, design
+changes with uncertain effects on usability) should be allocated to
+earlier sprints, allowing for time in later sprints to ensure stability.
+
+| Sprint | Focus                                                   |
+|:------:|:--------------------------------------------------------|
+| __1__  | Prototyping, design, experimentation.                   |
+| __2__  | New features, refinements, enhancements.                |
+| __3__  | Feature completion, low-risk enhancements, bug fixing.  |
+| __4__  | Stability & quality assurance.                          |
+
+### Sprints 1-3
+
+The first three sprints of a release are primarily centered around
+development work, with regular acceptance testing in the third
+week. During this third week, the top priority should be passing
+acceptance testing (e.g. by resolving any blockers found); any
+resources not needed for this effort should be used to begin work
+for the subsequent sprint.
+
+| Week  | Mon                       | Tue    | Wed | Thu                          | Fri         |
+|:-----:|:-------------------------:|:------:|:---:|:----------------------------:|:-----------:|
+| __1__ | Sprint plan               | Tag-up |     |                              |             |
+| __2__ |                           | Tag-up |     |                              | Code freeze |
+| __3__ | Sprint acceptance testing | Triage |     | _Sprint acceptance testing*_ | Ship        |
+
+* If necessary.
+
+### Sprint 4
+
+The software must be stable at the end of the fourth sprint; because of
+this, the fourth sprint is scheduled differently, with a heightened
+emphasis on testing.
+
+| Week   | Mon                       | Tue    | Wed | Thu                          | Fri         |
+|-------:|:-------------------------:|:------:|:---:|:----------------------------:|:-----------:|
+| __1__  | Sprint plan               | Tag-up |     |                              | Code freeze |
+| __2__  | Acceptance testing        | Triage |     |                              |             |
+| __3__  | _Acceptance testing*_     | Triage |     | _Acceptance testing*_        | Ship        |
+
+* If necessary.
+
+## Process Points
+
+* __Sprint plan.__ Project manager allocates issues based on
+  theme(s) for sprint, then reviews with team. Each team member
+  should have roughly two weeks of work allocated (to allow time
+  in the third week for testing of work completed.)
+  * Project manager should also sketch out subsequent sprint so
+    that team may begin work for that sprint during the
+    third week, since testing and blocker resolution is unlikely
+    to require all available resources.
+* __Tag-up.__ Check in and status update among development team.
+  May amend plan for sprint as-needed.
+* __Code freeze.__ Any new work from this sprint
+  (features, bug fixes, enhancements) must be integrated by the
+  end of the second week of the sprint. After code freeze
+  (and until the end of the sprint) the only changes that should be
+  merged into the master branch should directly address issues
+  needed to pass acceptance testing.
+* __Acceptance Testing.__ Structured testing with predefined
+  success criteria. No release should ship without passing
+  acceptance tests. Time is allocated in each sprint for subsequent
+  rounds of acceptance testing if issues are identified during a
+  prior round. Specific details of acceptance testing need to be
+  agreed-upon with relevant stakeholders and delivery recipients,
+  and should be flexible enough to allow changes to plans
+  (e.g. deferring delivery of some feature in order to ensure
+  stability of other features.) Baseline testing includes:
+  * __Testathon.__ Multi-user testing, involving as many users as
+    is feasible, plus development team. Open-ended; should verify
+    completed work from this sprint, test exploratorily for
+    regressions, et cetera.
+  * __24-Hour Test.__ A test to verify that the software remains
+    stable after running for longer durations. May include some
+    combination of automated testing and user verification (e.g.
+    checking to verify that software remains subjectively
+    responsive at conclusion of test.)
+  * __Automated Testing.__ Automated testing integrated into the
+    build. (These tests are verified to pass more often than once
+    per sprint, as they run before any merge to master, but still
+    play an important role in acceptance testing.)
+* __Sprint Acceptance Testing.__ Subset of Acceptance Testing
+  which should be performed before shipping at the end of any
+  sprint. Time is allocated for a second round of
+  Sprint Acceptance Testing if the first round is not passed.
+* __Triage.__ Team reviews issues from acceptance testing and uses
+  success criteria to determine whether or not they should block
+  release, then formulates a plan to address these issues before
+  the next round of acceptance testing. Focus here should be on
+  ensuring software passes that testing in order to ship on time;
+  may prefer to disable malfunctioning components and fix them
+  in a subsequent sprint, for example.
+* __Ship.__ Tag a code snapshot that has passed acceptance
+  testing and deploy that version. (Only true if acceptance
+  testing has passed by this point; if acceptance testing has not
+  been passed, will need to make ad hoc decisions with stakeholders,
+  e.g. "extend the sprint" or "defer shipment until end of next
+  sprint.")
 
-The process used to develop Open MCT is described in the following
-documents:
 
-* The [Development Cycle](cycle.md) describes how and when specific
-  process points are repeated during development.
-* The [Version Guide](version.md) describes version numbering for
-  Open MCT (both semantics and process.)
-* The [Test Plan](testing/plan.md) summarizes the approaches used
-  to test Open MCT.

docs/src/process/release.md

@@ -1,30 +0,0 @@
-
-# Release of NASA Open MCT NPM Package
-
-This document outlines the process and key considerations for releasing a new version of the NASA Open MCT project as an NPM (Node Package Manager) package.
-
-## 1. Pre-requisites
-
-Before releasing a new version of the NASA Open MCT NPM package, ensure all dependencies are updated, and comprehensive tests are performed. This ensures compatibility and performance of the Open MCT within the Node.js ecosystem.
-
-## 2. Versioning
-
-Versioning is a critical step for package release. The Open MCT team follows [Semantic Versioning (SemVer)](https://semver.org) that consists of three major components: MAJOR.MINOR.PATCH. These ensure a structured process for updating, bug fixes, backward compatibility, and software progress.
-
-## 3. Changelog Maintenance
-
-A comprehensive changelog file, `CHANGELOG.md`, documents any changes, adding a high level of transparencies for anyone desiring to look into the status of new and past progress. It includes the summation of any major new enhancements, changes, bug fixes, and the credits to the users responsible for each unique progress.
-
-## 4. Notable Changes Labels on GitHub PRs
-
-For the Open MCT package, we leverage GitHub's Pull Request (PR) mechanisms extensively, with three important PR labels dedicated to signifying 'notable_changes':
-
-- **Breaking Change** Highlights the integration of changes that are suspected to break, or without a doubt will break, backward compatibility. These should signal to users the upgrade might be seamless only if dependency and integration factors are properly managed, if not, one should expect to manage atypical technical snags.
-- **API change** Signifies when a contribution makes any complete or under layer changes to the communication or its supporting access processes. This label flags required see-through insight on how the web-based control panel sees and manipulates any value and or network logs.
-- **Default Behavior Change:** In the incident an update either adjusts a form to or integrates a not previously kept setting or plugin. i.e. autoscale is enabled by default when working with plots.
-
-## 6. Community & Contributions
-
-A flat community and the rounded center are kept in continuous celebration, with the given station open for two open-specifying dialogues, research, and all-for development probing. State the ownership for a handed looped, a welcome for even structure-core and architectural draft and impend.
-
-Thank you for your collaboration and commitment to moving the project onto a text big club. 

docs/src/process/testing/plan.md

@@ -1,146 +0,0 @@
-# Test Plan
-
-## Test Levels
-
-Testing for Open MCT includes:
-
-* _Smoke testing_: Brief, informal testing to verify that no major issues
-  or regressions are present in the software, or in specific features of
-  the software.
-* _Unit testing_: Automated verification of the performance of individual
-  software components.
-* _User testing_: Testing with a representative user base to verify
-  that application behaves usably and as specified.
-* _Long-duration testing_: Testing which takes place over a long period
-  of time to detect issues which are not readily noticeable during
-  shorter test periods.
-
-### Smoke Testing
-
-Manual, non-rigorous testing of the software and/or specific features
-of interest. Verifies that the software runs and that basic functionality
-is present. The outcome of Smoke Testing should be a simplified list of Acceptance Tests which could be executed by another team member with sufficient context.
-
-### Unit Testing
-
-Unit tests are automated tests which exercise individual software
-components. Tests are subject to code review along with the actual
-implementation, to ensure that tests are applicable and useful.
-
-Unit tests should meet
-[test standards](https://github.com/nasa/openmctweb/blob/master/CONTRIBUTING.md#test-standards)
-as described in the contributing guide.
-
-### User Testing
-
-User testing is performed at scheduled times involving target users
-of the software or reasonable representatives, along with members of
-the development team exercising known use cases. Users test the
-software directly; the software should be configured as similarly to
-its planned production configuration as is feasible without introducing
-other risks (e.g. damage to data in a production instance.)
-
-User testing will focus on the following activities:
-
-* Verifying issues resolved since the last test session.
-* Checking for regressions in areas related to recent changes.
-* Using major or important features of the software,
-  as determined by the user.
-* General "trying to break things."
-
-During user testing, users will
-[report issues](https://github.com/nasa/openmct/issues/new/choose)
-as they are encountered.
-
-Desired outcomes of user testing are:
-
-* Identified software defects.
-* Areas for usability improvement.
-* Feature requests (particularly missed requirements.)
-* Recorded issue verification.
-
-### Long-duration Testing
-
-Long-duration testing occurs over a twenty-four hour period. The
-software is run in one or more stressing cases representative of expected
-usage. After twenty-four hours, the software is evaluated for:
-
-* Performance metrics: Have memory usage or CPU utilization increased
-  during this time period in unexpected or undesirable ways?
-* Subjective usability: Does the software behave in the same way it did
-  at the start of the test? Is it as responsive?
-
-Any defects or unexpected behavior identified during testing should be
-[reported as issues](https://github.com/nasa/openmct/issues/new/choose)
-and reviewed for severity.
-
-## Test Performance
-
-Tests are performed at various levels of frequency.
-
-* _Per-merge_: Performed before any new changes are integrated into
-  the software.
-* _Per-sprint_: Performed at the end of every [sprint](../cycle.md).
-* _Per-release_: Performed at the end of every [release](../cycle.md).
-
-### Per-merge Testing
-
-Before changes are merged, the author of the changes must perform:
-
-* _Smoke testing_ (both generally, and for areas which interact with
-  the new changes.)
-* _Unit testing_ (as part of the automated build step.)
-
-Changes are not merged until the author has affirmed that both
-forms of testing have been performed successfully; this is documented
-by the [Author Checklist](https://github.com/nasa/openmctweb/blob/master/CONTRIBUTING.md#author-checklist).
-
-### Per-sprint Testing
-
-Before a sprint is closed, the development team must additionally
-perform:
-
-* A relevant subset of [_user testing_](procedures.md#user-test-procedures)
-  identified by the acting [project manager](../cycle.md#roles).
-* [_Long-duration testing_](procedures.md#long-duration-testing)
-  (specifically, for 24 hours.)
-
-Issues are reported as a product of both forms of testing.
-
-A sprint is not closed until both categories have been performed on
-the latest snapshot of the software, _and_ no issues labelled as
-["blocker"](https://github.com/nasa/openmctweb/blob/master/CONTRIBUTING.md#issue-reporting)
-remain open.
-
-### Per-release Testing
-
-As [per-sprint testing](#per-sprint-testing), except that _user testing_
-should cover all test cases, with less focus on changes from the specific
-sprint or release.
-
-Per-release testing should also include any acceptance testing steps
-agreed upon with recipients of the software.
-
-A release is not closed until both categories have been performed on
-the latest snapshot of the software, _and_ no issues labelled as
-["blocker" or "critical"](https://github.com/nasa/openmctweb/blob/master/CONTRIBUTING.md#issue-reporting)
-remain open.
-
-### Testathons
-Testathons can be used as a means of performing per-sprint and per-release testing. 
-
-#### Timing
-For per-sprint testing, a testathon is typically performed at the beginning of the third week of a sprint, and again later that week to verify any fixes. For per-release testing, a testathon is typically performed prior to any formal testing processes that are applicable to that release.
-
-#### Process
-
-1. Prior to the scheduled testathon, a list will be compiled of all issues that are closed and unverified.
-2. For each issue, testers should review the associated PR for testing instructions. See the contributing guide for instructions on [pull requests](https://github.com/nasa/openmct/blob/master/CONTRIBUTING.md#merging).
-3. As each issue is verified via testing, any team members testing it should leave a comment on that issue indicating that it has been verified fixed.
-4. If a bug is found that relates to an issue being tested, notes should be included on the associated issue, and the issue should be reopened. Bug notes should include reproduction steps.
-5. For any bugs that are not obviously related to any of the issues under test, a new issue should be created with details about the bug, including reproduction steps. If unsure about whether a bug relates to an issue being tested, just create a new issue.
-6. At the end of the testathon, triage will take place, where all tested issues will be reviewed.
-7. If verified fixed, an issue will remain closed, and will have the “unverified” label removed.
-8. For any bugs found, a severity will be assigned.
-9. A second testathon will be scheduled for later in the week that will aim to address all issues identified as blockers, as well as any other issues scoped by the team during triage.
-10. Any issues that were not tested will remain "unverified" and will be picked up in the next testathon.

docs/src/process/version.md

@@ -1,155 +0,0 @@
-# Version Guide
-
-This document describes semantics and processes for providing version
-numbers for Open MCT, and additionally provides guidelines for dependent
-projects developed by the same team.
-
-Versions are incremented at specific points in Open MCT's
-[Development Cycle](cycle.md); see that document for a description of
-sprints and releases.
-
-## Audience
-
-Individuals interested in consuming version numbers can be categorized as
-follows:
-
-* _Users_: Generally disinterested, occasionally wish to identify version
-  to cross-reference against documentation, or to report issues.
-* _Testers_: Want to identify which version of the software they are
-  testing, e.g. to file issues for defects.
-* _Internal developers_: Often, inverse of testers; want to identify which
-  version of software was/is in use when certain behavior is observed. Want
-  to be able to correlate versions in use with “streams” of development
-  (e.g. dev vs. prod), when possible.
-* _External developers_: Need to understand which version of software is
-  in use when developing/maintaining plug-ins, in order to ensure
-  compatibility of their software.
-
-## Version Reporting
-
-Software versions should be reflected in the user interface of the
-application in three ways:
-
-* _Version number_: A semantic version (see below) which serves both to
-  uniquely identify releases, as well as to inform plug-in developers
-  about compatibility with previous releases.
-* _Revision identifier_: While using git, the commit hash. Supports
-  internal developers and testers by uniquely identifying client
-  software snapshots.
-* _Branding_: Identifies which variant is in use. (Typically, Open MCT
-  is re-branded when deployed for a specific mission or center.)
-
-## Version Numbering
-
-Open MCT shall provide version numbers consistent with
-[Semantic Versioning 2.0.0](http://semver.org/). In summary, versions
-are expressed in a "major.minor.patch" form, and incremented based on
-nature of changes to external API. Breaking changes require a "major"
-version increment; backwards-compatible changes require a "minor"
-version increment; neutral changes (such as bug fixes) require a "patch"
-version increment. A hyphen-separated suffix indicates a pre-release
-version, which may be unstable or may not fully meet compatibility
-requirements.
-
-Additionally, the following project-specific standards will be used:
-
-* During development, a "-next" suffix shall be appended to the
-  version number. The version number before the suffix shall reflect
-  the next expected version number for release.
-* Prior to a 1.0.0 release, the _minor_ version will be incremented
-  on a per-release basis; the _patch_ version will be incremented on a
-  per-sprint basis.
-* Starting at version 1.0.0, version numbers will be updated with each
-  completed sprint. The version number for the sprint shall be
-  determined relative to the previous released version; the decision
-  to increment the _major_, _minor_, or _patch_ version should be
-  made based on the nature of changes during that release. (It is
-  recommended that these numbers are incremented as changes are
-  introduced, such that at end of release the version number may
-  be chosen by simply removing the suffix.)
-* The first three sprints in a release may be unstable; in these cases, a
-  unique version identifier should still be generated, but a suffix
-  should be included to indicate that the version is not necessarily
-  production-ready. Recommended suffixes are:
-
- Sprint |  Suffix
-:------:|:--------:
-   1    | `-alpha`
-   2    | `-beta`
-   3    | `-rc`
-
-### Scope of External API
-
-"External API" refers to the API exposed to, documented for, and used by
-plug-in developers. Changes to interfaces used internally by Open MCT
-(or otherwise not documented for use externally) require only a _patch_
-version bump.
-
-## Incrementing Versions
-
-At the end of a sprint, the [project manager](cycle.md#roles)
-should update (or delegate the task of updating) Open MCT version
-numbers by the following process:
-
-1. Update version number in `package.json`
-  1. Checkout branch created for the last sprint that has been successfully tested.
-  2. Remove a `-next` suffix from the version in `package.json`.
-  3. Verify that resulting version number meets semantic versioning
-     requirements relative to previous stable version. Increment the 
-     version number if necessary.
-  4. If version is considered unstable (which may be the case during
-     the first three sprints of a release), apply a new suffix per
-     [Version Numbering](#version-numbering) guidance above.
-2. Tag the release.
-  1. Commit changes to `package.json` on the new branch created in 
-     the previous step.
-     The commit message should reference the sprint being closed,
-     preferably by a URL reference to the associated Milestone in
-     GitHub.
-  2. Verify that build still completes, that application passes
-     smoke-testing, and that only differences from tested versions
-     are the changes to version number above.
-  3. Push the new branch.
-  4. Tag this commit with the version number, prepending the letter "v".
-     (e.g. `git tag v0.9.3-alpha`)
-  5. Push the tag to GitHub. (e.g. `git push origin v0.9.3-alpha`).
-3. Upload a release archive.
-  1. Use the [GitHub release interface](https://github.com/nasa/openmct/releases)
-     to draft a new release.
-  2. Choose the existing tag for the new version (created and pushed above.)
-     Enter the tag name as the release name as well; see existing releases
-     for examples. (e.g. `Open MCT v0.9.3-alpha`)
-  3. Designate the release as a "pre-release" as appropriate (for instance,
-     when the version number has been suffixed as unstable, or when
-     the version number is below 1.0.0.)
-  4. Add release notes including any breaking changes, enhancements, 
-     bug fixes with solutions in brief.
-  5. Publish the release.
-4. Publish the release to npm
-  1. Login to npm
-  2. Checkout the tag created in the previous step.
-  3. In `package.json` change package to be public (private: false)
-  4. Test the package before publishing by doing `npm publish --dry-run` 
-     if necessary.
-  5. Publish the package to the npmjs registry (e.g. `npm publish --access public`) 
-     NOTE: Use the `--tag unstable` flag to the npm publish if this is a prerelease.
-  6. Confirm the package has been published (e.g. `https://www.npmjs.com/package/openmct`)
-5. Update snapshot status in `package.json`
-  1. Create a new branch off the `master` branch.
-  2. Remove any suffix from the version number, 
-     or increment the _patch_ version if there is no suffix.
-  3. Append a `-next` suffix.
-  4. Commit changes to `package.json` on the `master` branch.
-     The commit message should reference the sprint being opened,
-     preferably by a URL reference to the associated Milestone in
-     GitHub.
-  5. Verify that build still completes, that application passes
-     smoke-testing.
-  6. Create a PR to be merged into the `master` branch.
-
-Projects dependent on Open MCT being co-developed by the Open MCT
-team should follow a similar process, except that they should
-additionally update their dependency on Open MCT to point to the
-latest archive when removing their `-next` status, and
-that they should be pointed back to the `master` branch after
-this has completed.

e2e/.eslintrc.cjs

@@ -1,38 +0,0 @@
-/* eslint-disable no-undef */
-module.exports = {
-  extends: ['plugin:playwright/recommended'],
-  rules: {
-    'playwright/max-nested-describe': ['error', { max: 1 }],
-    'playwright/expect-expect': 'off'
-  },
-  overrides: [
-    {
-      //Apply Best Practices to externalFixtures and exampleTemplate.e2e.spec.js
-      files: [
-        'appActions.js',
-        'baseFixtures.js',
-        'pluginFixtures.js',
-        '**/exampleTemplate.e2e.spec.js'
-      ],
-      rules: {
-        'playwright/no-raw-locators': 'error',
-        'playwright/no-nth-methods': 'error',
-        'playwright/no-get-by-title': 'error',
-        'playwright/prefer-comparison-matcher': 'error'
-      }
-    },
-    {
-      // Disable no-raw-locators for .contract.perf.spec.js files until https://github.com/grafana/xk6-browser/issues/1226
-      files: ['**/*.contract.perf.spec.js'],
-      rules: {
-        'playwright/no-raw-locators': 'off'
-      }
-    },
-    {
-      files: ['**/*.visual.spec.js'],
-      rules: {
-        'playwright/no-networkidle': 'off' //https://github.com/nasa/openmct/issues/7549
-      }
-    }
-  ]
-};

e2e/.npmignore

@@ -1,7 +0,0 @@
-*
-!appActions.js
-!baseFixtures.js
-!pluginFixtures.js
-!avpFixtures.js
-!index.js
-!*.md

e2e/.percy.ci.yml

@@ -1,44 +0,0 @@
-version: 2
-snapshot:
-  widths: [1024]
-  min-height: 1440 # px
-  percyCSS: |
-    /* Clock indicator... your days are numbered  */
-    .t-indicator-clock > .label {
-      opacity: 0 !important;
-    }
-    .c-input--datetime {
-      opacity: 0 !important;
-    }
-    /* Timer object text */
-    .c-ne__time-and-creator {
-      opacity: 0 !important;
-    }
-    /* Time Conductor ticks */
-    div.c-conductor-axis.c-conductor__ticks > svg {
-      opacity: 0 !important;
-    }
-    /* Embedded timestamp in notebooks */
-    .c-ne__embed__time{
-      opacity: 0 !important;
-    }
-    /* Time Conductor Start Time */
-    .c-compact-tc__setting-value{
-      opacity: 0 !important;
-    }
-    /* Chart Area for Plots */
-    .gl-plot-chart-area{
-      opacity: 0 !important;
-    }
-    /* SWG Time values on plot */
-    .gl-plot-x{
-      opacity: 0 !important;
-    }
-    /* Notification Time in modal */
-    .c-ne__time{
-      opacity: 0 !important;
-    }
-    /* Snapshot name with embedded time */
-    .l-browse-bar__snapshot-datetime{
-      opacity: 0 !important;
-    }

e2e/.percy.nightly.yml

@@ -1,44 +0,0 @@
-version: 2
-snapshot:
-  widths: [1024, 2000]
-  min-height: 1440 # px
-  percyCSS: |
-    /* Clock indicator... your days are numbered  */
-    .t-indicator-clock > .label {
-      opacity: 0 !important;
-    }
-    .c-input--datetime {
-      opacity: 0 !important;
-    }
-    /* Timer object text */
-    .c-ne__time-and-creator {
-      opacity: 0 !important;
-    }
-    /* Time Conductor ticks */
-    div.c-conductor-axis.c-conductor__ticks > svg {
-      opacity: 0 !important;
-    }
-    /* Embedded timestamp in notebooks */
-    .c-ne__embed__time{
-      opacity: 0 !important;
-    }
-    /* Time Conductor Start Time */
-    .c-compact-tc__setting-value{
-      opacity: 0 !important;
-    }
-    /* Chart Area for Plots */
-    .gl-plot-chart-area{
-      opacity: 0 !important;
-    }
-    /* SWG Time values on plot */
-    .gl-plot-x{
-      opacity: 0 !important;
-    }
-    /* Notification Time in modal */
-    .c-ne__time{
-      opacity: 0 !important;
-    }
-    /* Snapshot name with embedded time */
-    .l-browse-bar__snapshot-datetime{
-      opacity: 0 !important;
-    }

e2e/README.md

@@ -1,647 +0,0 @@
-# e2e testing
-
-This document captures information specific to the e2e testing of Open MCT. For general information about testing, please see [the Open MCT README](https://github.com/nasa/openmct/blob/master/README.md#tests).
-
-## Table of Contents
-
-This document is designed to capture on the What, Why, and How's of writing and running e2e tests in Open MCT. Please use the built-in Github Table of Contents functionality at the top left of this page or the markup.
-
-1. [Getting Started](#getting-started)
-2. [Types of Testing](#types-of-e2e-testing)
-3. [Architecture](#test-architecture-and-ci)
-
-## Getting Started
-
-While our team does our best to lower the barrier to entry to working with our e2e framework and Open MCT, there is a bit of work required to get from 0 to 1 test contributed.
-
-### Getting started with Playwright
-
-If this is your first time ever using the Playwright framework, we recommend going through the [Getting Started Guide](https://playwright.dev/docs/next/intro) which can be completed in about 15 minutes. This will give you a concise tour of Playwright's functionality and an understanding of the official Playwright documentation which we leverage in Open MCT.
-
-### Getting started with Open MCT's implementation of Playwright
-
-Once you've got an understanding of Playwright, you'll need a baseline understanding of Open MCT:
-
-1. Follow the steps [Building and Running Open MCT Locally](../README.md#building-and-running-open-mct-locally)
-2. Once you're serving Open MCT locally, create a 'Display Layout' object. Save it.
-3. Create a 'Plot' Object (e.g.: 'Stacked Plot')
-4. Create an Example Telemetry Object (e.g.: 'Sine Wave Generator')
-5. Expand the Tree and note the hierarchy of objects which were created.
-6. Navigate to the Demo Display Layout Object to edit and modify the embedded plot.
-7. Modify the embedded plot with Telemetry Data.
-
-What you've created is a display which mimics the display that a mission control operator might use to understand and model telemetry data.
-
-Recreate the steps above with Playwright's codegen tool:
-
-1. `npm run start` in a terminal window to serve Open MCT locally
-2. `npx @playwright/test install` to install playwright and dependencies
-3. Open another terminal window and start the Playwright codegen application `npx playwright codegen`
-4. Navigate the browser to `http://localhost:8080`
-5. Click the Create button and notice how your actions in the browser are being recorded in the Playwright Inspector
-6. Continue through the steps 2-6 above
-
-What you've created is an automated test which mimics the creation of a mission control display.
-
-Next, you should walk through our implementation of Playwright in Open MCT:
-
-1. Close any terminals which are serving up a local instance of Open MCT
-2. Run our 'Getting Started' test in debug mode with `npm run test:e2e:local -- exampleTemplate --debug`
-3. Step through each test step in the Playwright Inspector to see how we leverage Playwright's capabilities to test Open MCT
-
-## Types of e2e Testing
-
-e2e testing describes the layer at which a test is performed without prescribing the assertions which are made. Generally, when writing an e2e test, we have five choices to make on an assertion strategy:
-
-1. Functional - Verifies the functional correctness of the application. Sometimes interchanged with e2e or regression testing.
-2. Visual - Verifies the "look and feel" of the application and can only detect _undesirable changes when compared to a previous baseline_.
-3. Snapshot - Similar to Visual in that it captures the "look" of the application and can only detect _undesirable changes when compared to a previous baseline_. **Generally not preferred due to advanced setup necessary.**
-4. Accessibility - Verifies that the application meets the accessibility standards defined by the [WCAG organization](https://www.w3.org/WAI/standards-guidelines/wcag/).
-5. Performance - Verifies that application provides a performant experience. Like Snapshot testing, these tests are generally not recommended due to their difficulty in providing a consistent result.
-
-When choosing between the different testing strategies, think only about the assertion that is made at the end of the series of test steps. "I want to verify that the Timer plugin functions correctly" vs "I want to verify that the Timer plugin does not look different than originally designed".
-
-We do not want to interleave visual and functional testing inside the same suite because visual test verification of correctness must happen with a 3rd party service. This service is not available when executing these tests in other contexts (i.e. VIPER).
-
-### Functional Testing
-
-The bulk of our e2e coverage lies in "functional" test coverage which verifies that Open MCT is functionally correct as well as defining _how we expect it to behave_. This enables us to test the application exactly as a user would, while prescribing exactly how a user can interact with the application via a web browser.
-
-### Visual Testing
-
-Visual Testing is an essential part of our e2e strategy as it ensures that the application _appears_ correctly to a user while it compliments the functional e2e suite. It would be impractical to make thousands of assertions functional assertions on the look and feel of the application. Visual testing is interested in getting the DOM into a specified state and then comparing that it has not changed against a baseline.
-
-For a better understanding of the visual issues which affect Open MCT, please see our bug tracker with the `label:visual` filter applied [here](https://github.com/nasa/openmct/issues?q=label%3Abug%3Avisual+)
-To read about how to write a good visual test, please see [How to write a great Visual Test](#how-to-write-a-great-visual-test).
-
-`npm run test:e2e:visual` commands will run all of the visual tests against a local instance of Open MCT. If no `PERCY_TOKEN` API key is found in the terminal or command line environment variables, no visual comparisons will be made.
-
-- `npm run test:e2e:visual:ci` will run against every commit and PR.
-- `npm run test:e2e:visual:full` will run every night with additional comparisons made for Larger Displays and with the `snow` theme.
-
-#### Percy.io
-
-To make this possible, we're leveraging a 3rd party service, [Percy](https://percy.io/). This service maintains a copy of all changes, users, scm-metadata, and baselines to verify that the application looks and feels the same _unless approved by a Open MCT developer_. To request a Percy API token, please reach out to the Open MCT Dev team on GitHub. For more information, please see the official [Percy documentation](https://docs.percy.io/docs/visual-testing-basics).
-
-At present, we are using percy with two configuration files: `./e2e/.percy.nightly.yml` and `./e2e/.percy.ci.yml`. This is mainly to reduce the number of snapshots.
-
-### Advanced: Snapshot Testing (Not Recommended)
-
-While snapshot testing offers a precise way to detect changes in your application without relying on third-party services like Percy.io, we've found that it doesn't offer any advantages over visual testing in our use-cases. Therefore, snapshot testing is **not recommended** for further implementation.
-
-#### CI vs Manual Checks
-
-Snapshot tests can be reliably executed in Continuous Integration (CI) environments but lack the manual oversight provided by visual testing platforms like Percy.io. This means they may miss issues that a human reviewer could catch during manual checks.
-
-#### Example
-
-A single visual test assertion in Percy.io can be executed across 10 different browser and resolution combinations without additional setup, providing comprehensive testing with minimal configuration. In contrast, a snapshot test is restricted to a single OS and browser resolution, requiring more effort to achieve the same level of coverage.
-
-#### Further Reading
-
-For those interested in the mechanics of snapshot testing with Playwright, you can refer to the [Playwright Snapshots Documentation](https://playwright.dev/docs/test-snapshots). However, keep in mind that we do not recommend using this approach.
-
-#### Open MCT's implementation
-
-- Our Snapshot tests receive a `@snapshot` tag.
-- Snapshots need to be executed within the official Playwright container to ensure we're using the exact rendering platform in CI and locally. To do a valid comparison locally:
-
-```sh
-// Replace {X.X.X} with the current Playwright version 
-// from our package.json or circleCI configuration file
-docker run --rm --network host -v $(pwd):/work/ -w /work/ -it mcr.microsoft.com/playwright:v{X.X.X}-focal /bin/bash
-npm install
-npm run test:e2e:checksnapshots
-```
-
-### Updating Snapshots
-
-When the `@snapshot` tests fail, they will need to be evaluated to determine if the failure is an acceptable and desireable or an unintended regression.
-
-To compare a snapshot, run a test and open the html report with the 'Expected' vs 'Actual' screenshot. If the actual screenshot is preferred, then the source-controlled 'Expected' snapshots will need to be updated with the following scripts.
-
-```sh
-// Replace {X.X.X} with the current Playwright version 
-// from our package.json or circleCI configuration file
-docker run --rm --network host -v $(pwd):/work/ -w /work/ -it mcr.microsoft.com/playwright:v{X.X.X}-focal /bin/bash
-npm install
-npm run test:e2e:updatesnapshots
-```
-
-Once that's done, you'll need to run the following to verify that the changes do not cause more problems:
-
-```sh
-npm run test:e2e:checksnapshots
-```
-
-## Automated Accessibility (a11y) Testing
-
-Open MCT incorporates accessibility testing through two primary methods to ensure its compliance with accessibility standards:
-
-1. **Usage of Playwright's Locator Strategy**: Open MCT utilizes Playwright's locator strategy, specifically the [page.getByRole('') function](https://playwright.dev/docs/api/class-framelocator#frame-locator-get-by-role), to ensure that web elements are accessible via assistive technologies. This approach focuses on the accessibility of elements rather than full adherence to a11y guidelines, which is covered in the second method.
-
-2. **Enforcing a11y Guidelines with Playwright Axe Plugin**: To rigorously enforce a11y guideline compliance, Open MCT employs the [playwright axe plugin](https://playwright.dev/docs/accessibility-testing). This is achieved through the `scanForA11yViolations` function within the visual testing suite. This method not only benefits from the existing coverage of the visual tests but also targets specific a11y issues, such as `color-contrast` violations, which are particularly pertinent in the context of visual testing.
-
-### a11y Standards (WCAG and Section 508)
-
-Playwright axe supports a wide range of [WCAG Standards](https://playwright.dev/docs/accessibility-testing#scanning-for-wcag-violations) to test against. Open MCT is testing against the [Section 508](https://www.section508.gov/test/testing-overview/) accessibility guidelines with the intent to support higher standards over time. As of 2024, Section508 requirements now map completely to WCAG 2.0 AA. In the future, Section 508 requirements may map to WCAG 2.1 AA.
-
-### Reading an a11y test failure
-
-When an a11y test fails, the result must be interpreted in the html test report or the a11y report json artifact stored in the `/test-results/` folder. The json structure should be parsed for `"violations"` by `"id"` and identified `"target"`. Example provided for the 'color-contrast-enhanced' violation.
-
-```json
-  "violations": 
-    {
-      "id": "color-contrast-enhanced",
-      "impact": "serious",
-      "html": "<span class=\"label c-indicator__label\">0 Snapshots <button aria-label=\"Show Snapshots\">Show</button></span>",
-        "target": [
-          ".s-status-off > .label.c-indicator__label"
-        ],
-        "failureSummary": "Fix any of the following:\n  Element has insufficient color contrast of 6.51 (foreground color: #aaaaaa, background color: #262626, font size: 8.1pt (10.8px), font weight: normal). Expected contrast ratio of 7:1"
-      }
-```
-
-## Performance Testing
-
-The open source performance tests function in three ways which match their naming and folder structure:
-
-`tests/performance` - The tests at the root of this folder path detect functional changes which are mostly apparent with large performance regressions like [this](https://github.com/nasa/openmct/issues/6879). These tests run against openmct webpack in `production-mode` with the `npm run test:perf:localhost` script.
-`tests/performance/contract/` -  These tests serve as [contracts](https://martinfowler.com/bliki/ContractTest.html) for the locator logic, functionality, and assumptions will work in our downstream, closed source test suites. These tests run against openmct webpack in `dev-mode` with the `npm run test:perf:contract` script.
-`tests/performance/memory/` -  These tests execute memory leak detection checks in various ways. This is expected to evolve as we move to the `memlab` project. These tests run against openmct webpack in `production-mode` with the `npm run test:perf:memory` script.
-
-These tests are expected to become blocking and gating with assertions as we extend the capabilities of Playwright.
-
-In addition to the explicit definition of performance tests, we also ensure that our test timeout timing is "tight" to catch performance regressions detectable by action timeouts. i.e. [Notebooks load much slower than they used to #6459](https://github.com/nasa/openmct/issues/6459)
-
-## Test Architecture and CI
-
-### Architecture
-
-### File Structure
-
-Our file structure follows the type of type of testing being exercised at the e2e layer and files containing test suites which matcher application behavior or our `src` and `example` layout. This area is not well refined as we figure out what works best for closed source and downstream projects. This may change altogether if we move `e2e` to it's own npm package.
-
-|File Path|Description|
-|:-:|-|
-|`./helper`                    | Contains helper functions or scripts which are leveraged directly within the test suites (e.g.: non-default plugin scripts injected into the DOM)|
-|`./test-data`                 | Contains test data which is leveraged or generated in the functional, performance, or visual test suites (e.g.: localStorage data).|
-|`./tests/functional`          | The bulk of the tests are contained within this folder to verify the functionality of Open MCT.|
-|`./tests/functional/example/` | Tests which specifically verify the example plugins (e.g.: Sine Wave Generator).|
-|`./tests/functional/plugins/` | Tests which loosely test each plugin. This folder is the most likely to change. Note: some `@snapshot` tests are still contained within this structure.|
-|`./tests/framework/`          | Tests which verify that our testing framework's functionality and assumptions will continue to work based on further refactoring or Playwright version changes (e.g.: verifying custom fixtures and appActions).|
-|`./tests/performance/`        | Performance tests which should be run on every commit.|
-|`./tests/performance/contract/` | A subset of performance tests which are designed to provide a contract between the open source tests which are run on every commit and the downstream tests which are run post merge and with other frameworks.|
-|`./tests/performance/memory`  | A subset of performance tests which are designed to test for memory leaks.|
-|`./tests/visual-a11y/`             | Visual tests and accessibility tests.|
-|`./tests/visual-a11y/component/`             | Visual and accessibility tests which are only run against a single component.|
-|`./appActions.js`             | Contains common methods which can be leveraged by test case authors to quickly move through the application when writing new tests.|
-|`./baseFixture.js`            | Contains base fixtures which only extend default `@playwright/test` functionality. The expectation is that these fixtures will be removed as the native Playwright API improves|
-
-Our functional tests end in `*.e2e.spec.js`, visual tests in `*.visual.spec.js` and performance tests in `*.perf.spec.js`.
-
-### Configuration
-
-Where possible, we try to run Open MCT without modification or configuration change so that the Open MCT doesn't fail exclusively in "test mode" or in "production mode".
-
-Open MCT is leveraging the [config file](https://playwright.dev/docs/test-configuration) pattern to describe the capabilities of Open MCT e2e _where_ it's run
-
-|Config File|Description|
-|:-:|-|
-|`./playwright-ci.config.js` | Used when running in CI or to debug CI issues locally|
-|`./playwright-local.config.js` | Used when running locally|
-|`./playwright-performance.config.js` | Used when running performance tests in CI or locally|
-|`./playwright-performance-devmode.config.js` | Used when running performance tests in CI or locally|
-|`./playwright-visual-a11y.config.js` | Used to run the visual and a11y tests in CI or locally|
-
-#### Test Tags
-
-Test tags are a great way of organizing tests outside of a file structure. To learn more see the official documentation [here](https://playwright.dev/docs/test-annotations#tag-tests).
-
-Current list of test tags:
-
-|Test Tag|Description|
-|:-:|-|
-|`@mobile` | Test case or test suite is compatible with Playwright's iPad support and Open MCT's read-only mobile view (i.e. no create button).|
-|`@a11y` | Test case or test suite to execute playwright-axe accessibility checks and generate a11y reports.|
-|`@addInit` | Initializes the browser with an injected and artificial state. Useful for loading non-default plugins. Likely will not work outside of `npm start`.|
-|`@localStorage` | Captures or generates session storage to manipulate browser state. Useful for excluding in tests which require a persistent backend (i.e. CouchDB). See [note](#utilizing-localstorage)|
-|`@snapshot` | Uses Playwright's snapshot functionality to record a copy of the DOM for direct comparison. Must be run inside of the playwright container.|
-|`@2p` | Indicates that multiple users are involved, or multiple tabs/pages are used. Useful for testing multi-user interactivity.|
-|`@generatedata` | Indicates that a test is used to generate testdata or test the generated test data. Usually to be associated with localstorage, but this may grow over time.|
-|`@clock` | A test which modifies the clock. These have expanded out of the visual tests and into the functional tests.
-|`@framework` | A test for open mct e2e capabilities. This is primarily to ensure we don't break projects which depend on sourcing this project's fixtures like appActions.js.
-
-### Continuous Integration
-
-The cheapest time to catch a bug is pre-merge. Unfortunately, this is the most expensive time to run all of the tests since each merge event can consist of hundreds of commits. For this reason, we're selective in _what we run_ as much as _when we run it_.
-
-We leverage CircleCI to run tests against each commit and inject the Test Reports which are generated by Playwright so that they team can keep track of flaky and [historical test trends](https://app.circleci.com/insights/github/nasa/openmct/workflows/overall-circleci-commit-status/tests?branch=master&reporting-window=last-30-days)
-
-We leverage Github Actions / Workflows to execute tests as it gives us the ability to run against multiple operating systems with greater control over git event triggers (i.e. Run on a PR Comment event).
-
-Our CI environment consists of 3 main modes of operation:
-
-#### 1. Per-Commit Testing
-
-CircleCI
-
-- e2e tests against ubuntu and chrome
-- Performance tests against ubuntu and chrome
-- e2e tests are linted
-- Visual and a11y tests are run in a single resolution on the default `espresso` theme
-
-#### 2. Per-Merge Testing
-
-Github Actions / Workflow
-
-- Full suite against all browsers/projects. Triggered with Github Label Event 'pr:e2e'
-- CouchDB Tests. Triggered on PR Create and again with Github Label Event 'pr:e2e:couchdb'
-
-#### 3. Scheduled / Batch Testing
-
-Nightly Testing in Circle CI
-
-- Full e2e suite against ubuntu and chrome, firefox, and an MMOC resolution profile
-- Performance tests against ubuntu and chrome
-- CouchDB suite
-- Visual and a11y Tests are run in the full profile
-
-Github Actions / Workflow
-
-- None at the moment
-
-#### Parallelism and Fast Feedback
-
-In order to provide fast feedback in the Per-Commit context, we try to keep total test feedback at 5 minutes or less. That is to say, A developer should have a pass/fail result in under 5 minutes.
-
-Playwright has native support for semi-intelligent sharding. Read about it [here](https://playwright.dev/docs/test-parallel#shard-tests-between-multiple-machines).
-
-We will be adjusting the parallelization of the Per-Commit tests to keep below the 5 minute total runtime threshold.
-
-In addition to the Parallelization of Test Runners (Sharding), we're also running two concurrent threads on every Shard. This is the functional limit of what CircleCI Agents can support from a memory and CPU resource constraint.
-
-So for every commit, Playwright is effectively running 4 x 2 concurrent browsercontexts to keep the overall runtime to a miminum.
-
-At the same time, we don't want to waste CI resources on parallel runs, so we've configured each shard to fail after 5 test failures. Test failure logs are recorded and stored to allow fast triage.
-
-### Cross-browser and Cross-operating system
-
-#### **What's supported:**
-
-We are leveraging the `browserslist` project to declare our supported list of browsers. We support macOS, Windows, and ubuntu 20+.
-
-#### **Where it's tested:**
-
-We lint on `browserslist` to ensure that we're not implementing deprecated browser APIs and are aware of browser API improvements over time.
-
-We also have the need to execute our e2e tests across this published list of browsers. Our browsers and browser version matrix is found inside of our `./playwright-*.config.js`, but mostly follows in order of bleeding edge to stable:
-
-- `playwright-chromium channel:beta`
-  - A beta version of Chromium from official chromium channels. As close to the bleeding edge as we can get.
-- `playwright-chromium`
-  - A stable version of Chromium from the official chromium channels. This is always at least 1 version ahead of desktop chrome.
-- `playwright-chrome`
-  - The stable channel of Chrome from the official chrome channels. This is always 2 versions behind chromium.
-- `playwright-firefox`
-  - Firefox Latest Stable. Modified slightly by the playwright team to support a CDP Shim.
-
-In terms of operating system testing, we're only limited by what the CI providers are able to support. The bulk of our testing is performed on the official playwright container which is based on ubuntu. Github Actions allows us to use `windows-latest` and `mac-latest` and is run as needed.
-
-#### **Mobile**
-
-We have a Mission-need to support iPad and mobile devices. To run our test suites with mobile devices, please see our `playwright-mobile.config.js` projects.
-
-In general, our test suite is not designed to run against mobile devices as the mobile experience is a focused version of the application. Core functionality is missing (chiefly the 'Create' button). To bypass the object creation, we leverage the `storageState` properties for starting the mobile tests with localstorage.
-
-For now, the mobile tests will exist in the /tests/mobile/ suites and be executed with the
-
-```sh
-npm run test:e2e:mobile
-```
-
-command.
-
-#### **Skipping or executing tests based on browser, os, and/os browser version:**
-
-Conditionally skipping tests based on browser (**RECOMMENDED**):
-
-```js
-test('Can adjust image brightness/contrast by dragging the sliders', async ({ page, browserName }) => {
-  // eslint-disable-next-line playwright/no-skipped-test
-  test.skip(browserName === 'firefox', 'This test needs to be updated to work with firefox');
-
-  // ...
-```
-
-Conditionally skipping tests based on OS:
-
-```js
-test('Can adjust image brightness/contrast by dragging the sliders', async ({ page }) => {
-  // eslint-disable-next-line playwright/no-skipped-test
-  test.skip(process.platform === 'darwin', 'This test needs to be updated to work with MacOS');
-
-  // ...
-```
-
-Skipping based on browser version (Rarely used): <https://github.com/microsoft/playwright/discussions/17318>
-
-## Test Design, Best Practices, and Tips & Tricks
-
-### Test Design
-
-#### Test as the User
-
-In general, strive to test only through the UI as a user would. As stated in the [Playwright Best Practices](https://playwright.dev/docs/best-practices#test-user-visible-behavior):
-
-> "Automated tests should verify that the application code works for the end users, and avoid relying on implementation details such as things which users will not typically use, see, or even know about such as the name of a function, whether something is an array, or the CSS class of some element. The end user will see or interact with what is rendered on the page, so your test should typically only see/interact with the same rendered output."
-
-By adhering to this principle, we can create tests that are both robust and reflective of actual user experiences.
-
-#### How to make tests robust to function in other contexts (VISTA, COUCHDB, YAMCS, VIPER, etc.)
-
-  1. Leverage the use of `appActions.js` methods such as `createDomainObjectWithDefaults()`. This ensures that your tests will create unique instances of objects for your test to interact with.
-  1. Do not assert on the order or structure of objects available unless you created them yourself. These tests may be used against a persistent datastore like couchdb with many objects in the tree.
-  1. Do not search for your created objects. Open MCT does not performance uniqueness checks so it's possible that your tests will break when run twice.
-  1. Avoid creating locator aliases. This likely means that you're compensating for a bad locator. Improve the application instead.
-  1. Leverage `await page.goto('./', { waitUntil: 'domcontentloaded' });` instead of `{ waitUntil: 'networkidle' }`. Tests run against deployments with websockets often have issues with the networkidle detection.
-  
-#### How to make tests faster and more resilient to application changes
-  1. Avoid app interaction when possible. The best way of doing this is to navigate directly by URL:
-
-  ```js
-    // You can capture the CreatedObjectInfo returned from this appAction:
-    const clock = await createDomainObjectWithDefaults(page, { type: 'Clock' });
-
-    // ...and use its `url` property to navigate directly to it later in the test:
-    await page.goto(clock.url);
-  ```
-
-  1. Leverage `await page.goto('./', { waitUntil: 'domcontentloaded' });`
-    - Initial navigation should _almost_ always use the `{ waitUntil: 'domcontentloaded' }` option.
-  1. Avoid repeated setup to test a single assertion. Write longer tests with multiple soft assertions.
-  This ensures that your changes will be picked up with large refactors.
-  1. Use [user-facing locators](https://playwright.dev/docs/best-practices#use-locators) (Now a eslint rule!)
-  
-  ```js
-  page.getByRole('button', { name: 'Create' } )
-  ```
-  Instead of 
-  ```js
-  page.locator('.c-create-button')
-  ```
-  Note: `page.locator()` can be used in performance tests as xk6-browser does not yet support the new `page.getBy` pattern and css lookups can be [1.5x faster](https://serpapi.com/blog/css-selectors-faster-than-getbyrole-playwright/)
-
-##### Utilizing LocalStorage
-
-  1. In order to save test runtime in the case of tests that require a decent amount of initial setup (such as in the case of testing complex displays), you may use [Playwright's `storageState` feature](https://playwright.dev/docs/api/class-browsercontext#browser-context-storage-state) to generate and load localStorage states.
-  1. To generate a localStorage state to be used in a test:
-    - Add an e2e test to our generateLocalStorageData suite which sets the initial state (creating/configuring objects, etc.), saving it in the `test-data` folder:
-    ```js
-    // Save localStorage for future test execution
-    await context.storageState({
-      path: path.join(__dirname, '../../../e2e/test-data/display_layout_with_child_layouts.json')
-    });
-    ```
-    - Load the state from file at the beginning of the desired test suite (within the `test.describe()`). (NOTE: the storage state will be used for each test in the suite, so you may need to create a new suite):
-    ```js
-      const LOCALSTORAGE_PATH = path.resolve(
-        __dirname,
-        '../../../../test-data/display_layout_with_child_layouts.json'
-      );
-      test.use({
-        storageState: path.resolve(__dirname, LOCALSTORAGE_PATH)
-      }); 
-    ```
-
-### How to write a great test
-
-- Avoid using css locators to find elements to the page. Use modern web accessible locators like `getByRole`
-- Use our [App Actions](./appActions.js) for performing common actions whenever applicable.
-  - Use `waitForPlotsToRender()` before asserting against anything that is dependent upon plot series data being loaded and drawn.
-- If you create an object outside of using the `createDomainObjectWithDefaults` App Action, make sure to fill in the 'Notes' section of your object with `page.testNotes`:
-
-  ```js
-  // Fill the "Notes" section with information about the
-  // currently running test and its project.
-  const { testNotes } = page;
-  const notesInput = page.locator('form[name="mctForm"] #notes-textarea');
-  await notesInput.fill(testNotes);
-  ```
-
-#### How to Write a Great Visual Test
-
-1. **Look for the Unknown Unknowns**: Avoid asserting on specific differences in the visual diff. Visual tests are most effective for identifying unknown unknowns.
-
-2. **Get the App into Interesting States**: Prioritize getting Open MCT into unusual layouts or behaviors before capturing a visual snapshot. For instance, you could open a dropdown menu.
-
-3. **Expect the Unexpected**: Use functional expect statements only to verify assumptions about the state between steps. A great visual test doesn't fail during the test itself, but rather when changes are reviewed in Percy.io.
-
-4. **Control Variability**: Account for variations inherent in working with time-based telemetry and clocks.
-
-- Utilize `percyCSS` to ignore time-based elements. For more details, consult our [percyCSS file](./.percy.ci.yml).
-- Use Open MCT's fixed-time mode unless explicitly testing realtime clock
-- Employ the `createExampleTelemetryObject` appAction to source telemetry and specify a `name` to avoid autogenerated names.
-- Avoid creating objects with a time component like timers and clocks.
-- Utilize the playwright clock() API. See @clock Annotations for examples.
-
-5. **Hide the Tree and Inspector**: Generally, your test will not require comparisons involving the tree and inspector. These aspects are covered in component-specific tests (explained below). To exclude them from the comparison by default, navigate to the root of the main view with the tree and inspector hidden:
-    - `await page.goto('./#/browse/mine?hideTree=true&hideInspector=true')`
-
-6. **Component-Specific Tests**: If you wish to focus on a particular component, use the `/visual-a11y/component/` folder and limit the scope of the comparison to that component. For instance:
-
-    ```js
-    await percySnapshot(page, `Tree Pane w/ single level expanded (theme: ${theme})`, {
-        scope: treePane
-    });
-    ```
-
-    - Note: The `scope` variable can be any valid CSS selector.
-
-7. **Write many `percySnapshot` commands in a single test**: In line with our approach to longer functional tests, we recommend that many test percySnapshots are taken in a single test. For instance:
-
-    ```js
-    //<Some interesting state>
-    await percySnapshot(page, `Before object expanded (theme: ${theme})`);
-    //<Click on object>
-    await percySnapshot(page, `object expanded (theme: ${theme})`);
-    //Select from object
-    await percySnapshot(page, `object selected (theme: ${theme})`)
-    ```
-8. **Use `networkidle` to wait for network requests to complete**: This is necessary to ensure that all network requests have completed before taking a snapshot. This ensures that icons are loaded and other assets are available. https://github.com/nasa/openmct/issues/7549
-
-#### How to write a great network test
-
-- Where possible, it is best to mock out third-party network activity to ensure we are testing application behavior of Open MCT.
-- It is best to be as specific as possible about the expected network request/response structures in creating your mocks.
-- Make sure to only mock requests which are relevant to the specific behavior being tested.
-- Where possible, network requests and responses should be treated in an order-agnostic manner, as the order in which certain requests/responses happen is dynamic and subject to change.
-
-Some examples of mocking network responses in regards to CouchDB can be found in our [couchdb.e2e.spec.js](./tests/functional/couchdb.e2e.spec.js) test file.
-
-### Best Practices
-
-For now, our best practices exist as self-tested, living documentation in our [exampleTemplate.e2e.spec.js](./tests/framework/exampleTemplate.e2e.spec.js) file.
-
-For best practices with regards to mocking network responses, see our [couchdb.e2e.spec.js](./tests/functional/couchdb.e2e.spec.js) file.
-
-### Tips & Tricks
-
-The following contains a list of tips and tricks which don't exactly fit into a FAQ or Best Practices doc.
-
-- (Advanced) Overriding the Browser's Clock
-It is possible to override the browser's clock in order to control time-based elements. Since this can cause unwanted behavior -- i.e. Tree not rendering -- only use this sparingly. Use the `page.clock()` API as such:
-
-```js
-import { test, expect } from '../../pluginFixtures.js';
-
-test.describe('foo test suite @clock', () => {
-  test.beforeEach(async ({ page }) => {
-    //Set clock time
-    await page.clock.install({ time: MISSION_TIME });
-    await page.clock.resume();
-    //Navigate to page with new clock
-    await page.goto('./', { waitUntil: 'domcontentloaded' });
-  });
-
-  test('bar here', async ({ page }) => {
-    /// ...
-  });
-  ```
-
-- Working with multiple pages
-There are instances where multiple browser pages will needed to verify multi-page or multi-tab application behavior. Make sure to use the `@2p` annotation as well as name each page appropriately: i.e. `page1` and `page2` or `tab1` and `tab2` depending on the intended use case. Generally pages should be used unless testing `sharedWorker` code, specifically.
-
-- Working with file downloads and JSON data
-Open MCT has the capability of exporting certain objects in the form of a JSON file handled by the chrome browser. The best example of this type of test can be found in the exportAsJson test.
-
-```js
-const [download] = await Promise.all([
-  page.waitForEvent('download'), // Waits for the download event
-  page.getByLabel('Export as JSON').click() // Triggers the download
-]);
-
-// Wait for the download process to complete
-const path = await download.path();
-
-// Read the contents of the downloaded file using readFile from fs/promises
-const fileContents = await fs.readFile(path, 'utf8');
-const jsonData = JSON.parse(fileContents);
-
-// Use the function to retrieve the key
-const key = getFirstKeyFromOpenMctJson(jsonData);
-
-// Verify the contents of the JSON file
-expect(jsonData.openmct[key]).toHaveProperty('name', 'e2e folder');
-```
-
-### Reporting
-
-Test Reporting is done through official Playwright reporters and the CI Systems which execute them.
-
-We leverage the following official Playwright reporters:
-
-- HTML
-- junit
-- github annotations
-- Tracefile
-- Screenshots
-
-When running the tests locally with the `npm run test:e2e:local` command, the html report will open automatically on failure. Inside this HTML report will be a complete summary of the finished tests. If the tests failed, you'll see embedded links to screenshot failure, execution logs, and the Tracefile.
-
-When looking at the reports run in CI, you'll leverage this same HTML Report which is hosted either in CircleCI or Github Actions as a build artifact.
-
-### e2e Code Coverage
-
-Our e2e code coverage is captured and combined with our unit test coverage. For more information, please see our [code coverage documentation](../TESTING.md)
-
-#### Generating e2e code coverage
-
-Please read more about our code coverage [here](../TESTING.md#code-coverage)
-
-## Other
-
-### About e2e testing
-
-e2e testing is an industry-standard approach to automating the testing of web-based UIs such as Open MCT. Broadly speaking, e2e tests differentiate themselves from unit tests by preferring replication of real user interactions over execution of raw JavaScript functions.
-
-Historically, the abstraction necessary to replicate real user behavior meant that:
-
-- e2e tests were "expensive" due to how much code each test executed. The closer a test replicates the user, the more code is needed run during test execution. Unit tests could run smaller units of code more efficiently.
-- e2e tests were flaky due to network conditions or the underlying protocols associated with testing a browser.
-- e2e frameworks relied on a browser communication standard which lacked the observability and controls necessary needed to reach the code paths possible with unit and integration tests.
-- e2e frameworks provided insufficient debug information on test failure
-
-However, as the web ecosystem has matured to the point where mission-critical UIs can be written for the web (Open MCT), the e2e testing tools have matured as well. There are now fewer "trade-offs" when choosing to write an e2e test over any other type of test.
-
-Modern e2e frameworks:
-
-- Bypass the surface layer of the web-application-under-test and use a raw debugging protocol to observe and control application and browser state.
-- These new browser-internal protocols enable near-instant, bi-directional communication between test code and the browser, speeding up test execution and making the tests as reliable as the application itself.
-- Provide test debug tooling which enables developers to pinpoint failure
-
-Furthermore, the abstraction necessary to run e2e tests as a user enables them to be extended to run within a variety of contexts. This matches the extensible design of Open MCT.
-
-A single e2e test in Open MCT is extended to run:
-
-- Against a matrix of browser versions.
-- Against a matrix of OS platforms.
-- Against a local development version of Open MCT.
-- A version of Open MCT loaded as a dependency (VIPER, VISTA, etc)
-- Against a variety of data sources or telemetry endpoints.
-
-### Why Playwright?
-
-[Playwright](https://playwright.dev/) was chosen as our e2e framework because it solves a few VIPER Mission needs:
-
-1. First-class support for Automated Performance Testing
-2. Official Chrome, Chrome Canary, and iPad Capabilities
-3. Support for Browserless.io to run tests in a "hermetically sealed" environment
-4. Ability to generate code coverage reports
-
-### FAQ
-
-- How does this help NASA missions?
-- When should I write an e2e test instead of a unit test?
-- When should I write a functional vs visual test?
-- How is Open MCT extending default Playwright functionality?
-- What about Component Testing?
-
-### Writing Tests
-
-Playwright provides 3 supported methods of debugging and authoring tests:
-
-- A 'watch mode' for running tests locally and debugging on the fly
-- A 'debug mode' for debugging tests and writing assertions against tests
-- A 'VSCode plugin' for debugging tests within the VSCode IDE.
-
-Generally, we encourage folks to use the watch mode and provide a script `npm run test:e2e:watch` which launches the launch mode ui and enables hot reloading on the dev server.
-
-### e2e Troubleshooting
-
-Please follow the general guide troubleshooting in [the general troubleshooting doc](../TESTING.md#troubleshooting-ci)
-
-- Tests won't start because 'Error: <http://localhost:8080/># is already used...'
-This error will appear when running the tests locally. Sometimes, the webserver is left in an orphaned state and needs to be cleaned up. To clear up the orphaned webserver, execute the following from your Terminal:
-```lsof -n -i4TCP:8080 | awk '{print$2}' | tail -1 | xargs kill -9```
-
-### Upgrading Playwright
-
-In order to upgrade from one version of Playwright to another, the version should be updated in several places in both `openmct` and `openmct-yamcs` repos. An easy way to identify these locations is to search for the current version in all files and find/replace.
-
-For reference, all of the locations where the version should be updated are listed below:
-
-#### **In `openmct`:**
-
-- `package.json`
-  - Both packages `@playwright/test` and `playwright-core` should be updated to the same target version.
-- `.circleci/config.yml`
-- `.github/workflows/e2e-couchdb.yml`
-- `.github/workflows/e2e-pr.yml`
-
-#### **In `openmct-yamcs`:**
-
-- `package.json`
-  - `@playwright/test` should be updated to the target version.
-- `.github/workflows/yamcs-quickstart-e2e.yml`

e2e/appActions.js

@@ -1,703 +0,0 @@
-/*****************************************************************************
- * Open MCT, Copyright (c) 2014-2024, United States Government
- * as represented by the Administrator of the National Aeronautics and Space
- * Administration. All rights reserved.
- *
- * Open MCT is licensed under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- * http://www.apache.org/licenses/LICENSE-2.0.
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- * License for the specific language governing permissions and limitations
- * under the License.
- *
- * Open MCT includes source code licensed under additional open source
- * licenses. See the Open Source Licenses file (LICENSES.md) included with
- * this source code distribution or the Licensing information page available
- * at runtime from the About dialog for additional information.
- *****************************************************************************/
-
-/**
- * The fixtures in this file are to be used to consolidate common actions performed by the
- * various test suites. The goal is only to avoid duplication of code across test suites and not to abstract
- * away the underlying functionality of the application. For more about the App Action pattern, see /e2e/README.md)
- *
- * For example, if two functions are nearly identical in
- * timer.e2e.spec.js and notebook.e2e.spec.js, that function should be generalized and moved into this file.
- */
-
-/**
- * Defines parameters to be used in the creation of a domain object.
- * @typedef {Object} CreateObjectOptions
- * @property {string} type the type of domain object to create (e.g.: "Sine Wave Generator").
- * @property {string} [name] the desired name of the created domain object.
- * @property {string | import('../src/api/objects/ObjectAPI').Identifier} [parent] the Identifier or uuid of the parent object.
- */
-
-/**
- * Contains information about the newly created domain object.
- * @typedef {Object} CreatedObjectInfo
- * @property {string} name the name of the created object
- * @property {string} uuid the uuid of the created object
- * @property {string} url the relative url to the object (for use with `page.goto()`)
- */
-
-/**
- * Defines parameters to be used in the creation of a notification.
- * @typedef {Object} CreateNotificationOptions
- * @property {string} message the message
- * @property {'info' | 'alert' | 'error'} severity the severity
- * @property {import('../src/api/notifications/NotificationAPI').NotificationOptions} [notificationOptions] additional options
- */
-
-import { expect } from '@playwright/test';
-import { Buffer } from 'buffer';
-import { v4 as genUuid } from 'uuid';
-
-/**
- * This common function creates a domain object with the default options. It is the preferred way of creating objects
- * in the e2e suite when uninterested in properties of the objects themselves.
- *
- * @param {import('@playwright/test').Page} page - The Playwright page object.
- * @param {Object} options - Options for creating the domain object.
- * @param {string} options.type - The type of domain object to create (e.g., "Sine Wave Generator").
- * @param {string} [options.name] - The desired name of the created domain object.
- * @param {string | import('../src/api/objects/ObjectAPI').Identifier} [options.parent='mine'] - The Identifier or uuid of the parent object. Defaults to 'mine' folder
- * @returns {Promise<CreatedObjectInfo>} An object containing information about the newly created domain object.
- */
-async function createDomainObjectWithDefaults(page, { type, name, parent = 'mine' }) {
-  if (!name) {
-    name = `${type}:${genUuid()}`;
-  }
-
-  const parentUrl = await getHashUrlToDomainObject(page, parent);
-
-  // Navigate to the parent object. This is necessary to create the object
-  // in the correct location, such as a folder, layout, or plot.
-  await page.goto(parentUrl);
-
-  // Click the Create button
-  await page.getByRole('button', { name: 'Create', exact: true }).click();
-
-  // Click the object specified by 'type'-- case insensitive
-  await page.getByRole('menuitem', { name: new RegExp(`^${type}$`, 'i') }).click();
-
-  // Fill in the name of the object
-  await page.getByLabel('Title', { exact: true }).fill('');
-  await page.getByLabel('Title', { exact: true }).fill(name);
-
-  if (page.testNotes) {
-    // Fill the "Notes" section with information about the
-    // currently running test and its project.
-    // eslint-disable-next-line playwright/no-raw-locators
-    await page.locator('#notes-textarea').fill(page.testNotes);
-  }
-
-  await page.getByRole('button', { name: 'Save' }).click();
-
-  // Wait until the URL is updated
-  await page.waitForURL(`**/${parent}/*`);
-  const uuid = await getFocusedObjectUuid(page);
-  const objectUrl = await getHashUrlToDomainObject(page, uuid);
-
-  if (await _isInEditMode(page, uuid)) {
-    // Save (exit edit mode)
-    await page.getByRole('button', { name: 'Save' }).click();
-    await page.getByRole('listitem', { name: 'Save and Finish Editing' }).click();
-  }
-
-  return {
-    name,
-    uuid,
-    url: objectUrl
-  };
-}
-
-/**
- * Generate a notification with the given options.
- * @param {import('@playwright/test').Page} page
- * @param {CreateNotificationOptions} createNotificationOptions
- */
-async function createNotification(page, createNotificationOptions) {
-  await page.evaluate((_createNotificationOptions) => {
-    const { message, severity, options } = _createNotificationOptions;
-    const notificationApi = window.openmct.notifications;
-    if (severity === 'info') {
-      notificationApi.info(message, options);
-    } else if (severity === 'alert') {
-      notificationApi.alert(message, options);
-    } else {
-      notificationApi.error(message, options);
-    }
-  }, createNotificationOptions);
-}
-
-/**
- * Create a Plan object from JSON with the provided options. Must be used with a json based plan.
- * Please check appActions.e2e.spec.js for an example of how to use this function.
- *
- * @param {import('@playwright/test').Page} page
- * @param {string} name
- * @param {Object} json
- * @param {string | import('../src/api/objects/ObjectAPI').Identifier} [parent] the uuid or identifier of the parent object. Defaults to 'mine'
- * @returns {Promise<CreatedObjectInfo>} An object containing information about the newly created domain object.
- */
-async function createPlanFromJSON(page, { name, json, parent = 'mine' }) {
-  const parentUrl = await getHashUrlToDomainObject(page, parent);
-
-  // Navigate to the parent object. This is necessary to create the object
-  // in the correct location, such as a folder, layout, or plot.
-  await page.goto(`${parentUrl}`);
-
-  await page.getByRole('button', { name: 'Create' }).click();
-
-  await page.getByRole('menuitem', { name: 'Plan' }).click();
-
-  // Fill in the name of the object or generate a random one
-  if (!name) {
-    name = `Plan:${genUuid()}`;
-  }
-  await page.getByLabel('Title', { exact: true }).fill('');
-  await page.getByLabel('Title', { exact: true }).fill(name);
-
-  // Upload buffer from memory
-  await page.getByLabel('Select File...').setInputFiles({
-    name: 'plan.txt',
-    mimeType: 'text/plain',
-    buffer: Buffer.from(JSON.stringify(json))
-  });
-
-  await page.getByLabel('Save').click();
-
-  // Wait until the URL is updated
-  await page.waitForURL(`**/${parent}/*`);
-  const uuid = await getFocusedObjectUuid(page);
-  const objectUrl = await getHashUrlToDomainObject(page, uuid);
-
-  return {
-    uuid,
-    name,
-    url: objectUrl
-  };
-}
-
-/**
- * Create a standardized Telemetry Object (Sine Wave Generator) for use in visual tests
- * and tests against plotting telemetry (e.g. logPlot tests).
- * @param {import('@playwright/test').Page} page
- * @param {string | import('../src/api/objects/ObjectAPI').Identifier} [parent] the uuid or identifier of the parent object. Defaults to 'mine'
- * @returns {Promise<CreatedObjectInfo>} An object containing information about the telemetry object.
- */
-async function createExampleTelemetryObject(page, parent = 'mine') {
-  const parentUrl = await getHashUrlToDomainObject(page, parent);
-
-  await page.goto(`${parentUrl}`);
-
-  await page.getByRole('button', { name: 'Create' }).click();
-
-  await page.getByRole('menuitem', { name: 'Sine Wave Generator' }).click();
-
-  const name = 'VIPER Rover Heading';
-  await page.getByLabel('Title', { exact: true }).fill(name);
-
-  // Fill out the fields with default values
-  await page.getByRole('spinbutton', { name: 'Period' }).fill('10');
-  await page.getByRole('spinbutton', { name: 'Amplitude' }).fill('1');
-  await page.getByRole('spinbutton', { name: 'Offset' }).fill('0');
-  await page.getByRole('spinbutton', { name: 'Data Rate (hz)' }).fill('1');
-  await page.getByRole('spinbutton', { name: 'Phase (radians)' }).fill('0');
-  await page.getByRole('spinbutton', { name: 'Randomness' }).fill('0');
-  await page.getByRole('spinbutton', { name: 'Loading Delay (ms)' }).fill('0');
-
-  await page.getByRole('button', { name: 'Save' }).click();
-
-  // Wait until the URL is updated
-  await page.waitForURL(`**/${parent}/*`);
-
-  const uuid = await getFocusedObjectUuid(page);
-  const url = await getHashUrlToDomainObject(page, uuid);
-
-  return {
-    name,
-    uuid,
-    url
-  };
-}
-
-/**
- * Create a Stable State Telemetry Object (State Generator) for use in visual tests
- * and tests against plotting telemetry (e.g. logPlot tests). This will change state every 2 seconds.
- * @param {import('@playwright/test').Page} page
- * @param {string | import('../src/api/objects/ObjectAPI').Identifier} [parent] the uuid or identifier of the parent object. Defaults to 'mine'
- * @returns {Promise<CreatedObjectInfo>} An object containing information about the telemetry object.
- */
-async function createStableStateTelemetry(page, parent = 'mine') {
-  const parentUrl = await getHashUrlToDomainObject(page, parent);
-
-  await page.goto(`${parentUrl}`);
-  const createdObject = await createDomainObjectWithDefaults(page, {
-    type: 'State Generator',
-    name: 'Stable State Generator'
-  });
-  // edit the state generator to have a 1 second update rate
-  await page.getByLabel('More actions').click();
-  await page.getByRole('menuitem', { name: 'Edit Properties...' }).click();
-  await page.getByLabel('State Duration (seconds)', { exact: true }).fill('2');
-  await page.getByLabel('Save').click();
-  // Wait until the URL is updated
-  const uuid = await getFocusedObjectUuid(page);
-  const url = await getHashUrlToDomainObject(page, uuid);
-
-  return {
-    name: createdObject.name,
-    uuid,
-    url
-  };
-}
-
-/**
- * Navigates directly to a given object url, in fixed time mode, with the given start and end bounds. Note: does not set
- * default view type.
- *
- * @param {import('@playwright/test').Page} page
- * @param {string} url The url to the domainObject
- * @param {string | number} start The starting time bound in milliseconds since epoch
- * @param {string | number} end The ending time bound in milliseconds since epoch
- */
-async function navigateToObjectWithFixedTimeBounds(page, url, start, end) {
-  await page.goto(
-    `${url}?tc.mode=fixed&tc.timeSystem=utc&tc.startBound=${start}&tc.endBound=${end}`
-  );
-}
-
-/**
- * Navigates directly to a given object url, in real-time mode. Note: does not set
- * default view type.
- *
- * @param {import('@playwright/test').Page} page
- * @param {string} url The url to the domainObject
- * @param {string | number} start The start offset in milliseconds
- * @param {string | number} end The end offset in milliseconds
- */
-async function navigateToObjectWithRealTime(page, url, start = '1800000', end = '30000') {
-  await page.goto(
-    `${url}?tc.mode=local&tc.startDelta=${start}&tc.endDelta=${end}&tc.timeSystem=utc`
-  );
-}
-
-/**
- * Expands the entire object tree (every expandable tree item). Can be used to
- * ensure that the tree is fully expanded before performing actions on objects.
- * Can be applied to either the main tree or the create modal tree.
- *
- * @param {import('@playwright/test').Page} page
- * @param {"Main Tree" | "Create Modal Tree"} [treeName="Main Tree"]
- */
-async function expandEntireTree(page, treeName = 'Main Tree') {
-  const treeLocator = page.getByRole('tree', {
-    name: treeName
-  });
-  const collapsedTreeItems = treeLocator
-    .getByRole('treeitem', {
-      expanded: false
-    })
-    .getByLabel(/Expand/);
-
-  while ((await collapsedTreeItems.count()) > 0) {
-    //eslint-disable-next-line playwright/no-nth-methods
-    await collapsedTreeItems.nth(0).click();
-
-    // FIXME: Replace hard wait with something event-driven.
-    // Without the wait, this fails periodically due to a race condition
-    // with Vue rendering (loop exits prematurely).
-    // eslint-disable-next-line playwright/no-wait-for-timeout
-    await page.waitForTimeout(200);
-  }
-}
-
-/**
- * Gets the UUID of the currently focused object by parsing the current URL
- * and returning the last UUID in the path.
- * @param {import('@playwright/test').Page} page
- * @returns {Promise<string>} the uuid of the focused object
- */
-async function getFocusedObjectUuid(page) {
-  const UUIDv4Regexp = /[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}/gi;
-  const focusedObjectUuid = await page.evaluate((regexp) => {
-    return window.location.href.split('?')[0].match(regexp).at(-1);
-  }, UUIDv4Regexp);
-
-  return focusedObjectUuid;
-}
-
-/**
- * Returns the hashUrl to the domainObject given its uuid.
- * Useful for directly navigating to the given domainObject.
- *
- * URLs returned will be of the form `'./browse/#/mine/<uuid0>/<uuid1>/...'`
- *
- * @param {import('@playwright/test').Page} page
- * @param {string | import('../src/api/objects/ObjectAPI').Identifier} identifier the uuid or identifier of the object to get the url for
- * @returns {Promise<string>} the url of the object
- */
-async function getHashUrlToDomainObject(page, identifier) {
-  await page.waitForLoadState('domcontentloaded');
-  const hashUrl = await page.evaluate(async (objectIdentifier) => {
-    const path = await window.openmct.objects.getOriginalPath(objectIdentifier);
-    let url =
-      './#/browse/' +
-      [...path]
-        .reverse()
-        .map((object) => window.openmct.objects.makeKeyString(object.identifier))
-        .join('/');
-
-    // Drop the vestigial '/ROOT' if it exists
-    if (url.includes('/ROOT')) {
-      url = url.split('/ROOT').join('');
-    }
-
-    return url;
-  }, identifier);
-
-  return hashUrl;
-}
-
-/**
- * Utilizes the OpenMCT API to detect if the UI is in Edit mode.
- * @private
- * @param {import('@playwright/test').Page} page
- * @param {string | import('../src/api/objects/ObjectAPI').Identifier} identifier
- * @return {Promise<boolean>} true if the Open MCT is in Edit Mode
- */
-async function _isInEditMode(page, identifier) {
-  // eslint-disable-next-line no-return-await
-  return await page.evaluate(() => window.openmct.editor.isEditing());
-}
-
-/**
- * Set the time conductor mode to either fixed timespan or realtime mode.
- * @private
- * @param {import('@playwright/test').Page} page
- * @param {boolean} [isFixedTimespan=true] true for fixed timespan mode, false for realtime mode; default is true
- */
-async function _setTimeConductorMode(page, isFixedTimespan = true) {
-  // Click 'mode' button
-  await page.getByRole('button', { name: 'Time Conductor Mode', exact: true }).click();
-  await page.getByRole('button', { name: 'Time Conductor Mode Menu' }).click();
-  // Switch time conductor mode. Note, need to wait here for URL to update as the router is debounced.
-  if (isFixedTimespan) {
-    await page.getByRole('menuitem', { name: /Fixed Timespan/ }).click();
-    await page.waitForURL(/tc\.mode=fixed/);
-  } else {
-    await page.getByRole('menuitem', { name: /Real-Time/ }).click();
-    await page.waitForURL(/tc\.mode=local/);
-  }
-  //dismiss the time conductor popup
-  await page.getByLabel('Discard changes and close time popup').click();
-}
-
-/**
- * Set the time conductor to fixed timespan mode
- * @param {import('@playwright/test').Page} page
- */
-async function setFixedTimeMode(page) {
-  await _setTimeConductorMode(page, true);
-}
-
-/**
- * Set the time conductor to realtime mode
- * @param {import('@playwright/test').Page} page
- */
-async function setRealTimeMode(page) {
-  await _setTimeConductorMode(page, false);
-}
-
-/**
- * @typedef {Object} OffsetValues
- * @property {string | undefined} startHours
- * @property {string | undefined} startMins
- * @property {string | undefined} startSecs
- * @property {string | undefined} endHours
- * @property {string | undefined} endMins
- * @property {string | undefined} endSecs
- */
-
-/**
- * Set the values (hours, mins, secs) for the TimeConductor offsets when in realtime mode
- * @param {import('@playwright/test').Page} page
- * @param {OffsetValues} offset - Object containing offset values
- * @param {boolean} [offset.submitChanges=true] - If true, submit the offset changes; otherwise, discard them
- */
-async function setTimeConductorOffset(
-  page,
-  { startHours, startMins, startSecs, endHours, endMins, endSecs, submitChanges = true }
-) {
-  if (startHours) {
-    await page.getByLabel('Start offset hours').fill(startHours);
-  }
-
-  if (startMins) {
-    await page.getByLabel('Start offset minutes').fill(startMins);
-  }
-
-  if (startSecs) {
-    await page.getByLabel('Start offset seconds').fill(startSecs);
-  }
-
-  if (endHours) {
-    await page.getByLabel('End offset hours').fill(endHours);
-  }
-
-  if (endMins) {
-    await page.getByLabel('End offset minutes').fill(endMins);
-  }
-
-  if (endSecs) {
-    await page.getByLabel('End offset seconds').fill(endSecs);
-  }
-
-  // Click the check button
-  if (submitChanges) {
-    await page.getByLabel('Submit time offsets').click();
-  } else {
-    await page.getByLabel('Discard changes and close time popup').click();
-  }
-}
-
-/**
- * Set the values (hours, mins, secs) for the start time offset when in realtime mode
- * @param {import('@playwright/test').Page} page
- * @param {OffsetValues} offset
- * @param {boolean} [submit=true] If true, submit the offset changes; otherwise, discard them
- */
-async function setStartOffset(page, { submitChanges = true, ...offset }) {
-  // Click 'mode' button
-  await page.getByRole('button', { name: 'Time Conductor Mode', exact: true }).click();
-  await setTimeConductorOffset(page, { submitChanges, ...offset });
-}
-
-/**
- * Set the values (hours, mins, secs) for the end time offset when in realtime mode
- * @param {import('@playwright/test').Page} page
- * @param {OffsetValues} offset
- * @param {boolean} [submit=true] If true, submit the offset changes; otherwise, discard them
- */
-async function setEndOffset(page, { submitChanges = true, ...offset }) {
-  // Click 'mode' button
-  await page.getByRole('button', { name: 'Time Conductor Mode', exact: true }).click();
-  await setTimeConductorOffset(page, { submitChanges, ...offset });
-}
-
-/**
- * Set the time conductor bounds in fixed time mode
- *
- * NOTE: Unless explicitly testing the Time Conductor itself, it is advised to instead
- * navigate directly to the object with the desired time bounds using `navigateToObjectWithFixedTimeBounds()`.
- * @param {import('@playwright/test').Page} page
- * @param {Object} bounds - The time conductor bounds
- * @param {string} [bounds.startDate] - The start date in YYYY-MM-DD format
- * @param {string} [bounds.startTime] - The start time in HH:mm:ss format
- * @param {string} [bounds.endDate] - The end date in YYYY-MM-DD format
- * @param {string} [bounds.endTime] - The end time in HH:mm:ss format
- * @param {boolean} [bounds.submitChanges=true] - If true, submit the changes; otherwise, discard them.
- */
-async function setTimeConductorBounds(page, { submitChanges = true, ...bounds }) {
-  const { startDate, endDate, startTime, endTime } = bounds;
-
-  // Open the time conductor popup
-  await page.getByRole('button', { name: 'Time Conductor Mode', exact: true }).click();
-
-  // FIXME: https://github.com/nasa/openmct/pull/7818
-  // eslint-disable-next-line playwright/no-wait-for-timeout
-  await page.waitForTimeout(500);
-
-  if (startDate) {
-    await page.getByLabel('Start date').fill(startDate);
-  }
-
-  if (startTime) {
-    await page.getByLabel('Start time').fill(startTime);
-  }
-
-  if (endDate) {
-    await page.getByLabel('End date').fill(endDate);
-  }
-
-  if (endTime) {
-    await page.getByLabel('End time').fill(endTime);
-  }
-
-  if (submitChanges) {
-    await page.getByLabel('Submit time bounds').click();
-  } else {
-    await page.getByLabel('Discard changes and close time popup').click();
-  }
-}
-
-/**
- * Set the bounds of the visible conductor in fixed time mode.
- * Requires that page already has an independent time conductor in view.
- * @param {import('@playwright/test').Page} page
- * @param {string} start - The start date in 'YYYY-MM-DD HH:mm:ss.SSSZ' format
- * @param {string} end - The end date in 'YYYY-MM-DD HH:mm:ss.SSSZ' format
- */
-async function setFixedIndependentTimeConductorBounds(page, { start, end }) {
-  // Activate Independent Time Conductor
-  await page.getByLabel('Enable Independent Time Conductor').click();
-
-  // Bring up the time conductor popup
-  await page.getByLabel('Independent Time Conductor Settings').click();
-  await expect(page.getByLabel('Time Conductor Options')).toBeInViewport();
-  await _setTimeBounds(page, start, end);
-
-  await page.keyboard.press('Enter');
-}
-
-/**
- * Set the bounds of the visible conductor in fixed time mode
- * @private
- * @param {import('@playwright/test').Page} page
- * @param {string} start - The start date in 'YYYY-MM-DD HH:mm:ss.SSSZ' format
- * @param {string} end - The end date in 'YYYY-MM-DD HH:mm:ss.SSSZ' format
- */
-async function _setTimeBounds(page, startDate, endDate) {
-  if (startDate) {
-    // Fill start time
-    await page
-      .getByRole('textbox', { name: 'Start date' })
-      .fill(startDate.toString().substring(0, 10));
-    await page
-      .getByRole('textbox', { name: 'Start time' })
-      .fill(startDate.toString().substring(11, 19));
-  }
-
-  if (endDate) {
-    // Fill end time
-    await page.getByRole('textbox', { name: 'End date' }).fill(endDate.toString().substring(0, 10));
-    await page
-      .getByRole('textbox', { name: 'End time' })
-      .fill(endDate.toString().substring(11, 19));
-  }
-}
-
-/**
- * Waits and asserts that all plot series data on the page
- * is loaded and drawn.
- *
- * In lieu of a better way to detect when a plot is done rendering,
- * we [attach a class to the '.gl-plot' element](https://github.com/nasa/openmct/blob/5924d7ea95a0c2d4141c602a3c7d0665cb91095f/src/plugins/plot/MctPlot.vue#L27)
- * once all pending series data has been loaded. The following appAction retrieves
- * all plots on the page and waits up to the default timeout for the class to be
- * attached to each plot.
- * @param {import('@playwright/test').Page} page
- * @param {number} [timeout] Provide a custom timeout in milliseconds to override the default timeout
- */
-async function waitForPlotsToRender(page, { timeout } = {}) {
-  //eslint-disable-next-line playwright/no-raw-locators
-  const plotLocator = page.locator('.gl-plot');
-  for (const plot of await plotLocator.all()) {
-    await expect(plot).toHaveClass(/js-series-data-loaded/, { timeout });
-  }
-}
-
-/**
- * @typedef {Object} PlotPixel
- * @property {number} r The value of the red channel (0-255)
- * @property {number} g The value of the green channel (0-255)
- * @property {number} b The value of the blue channel (0-255)
- * @property {number} a The value of the alpha channel (0-255)
- * @property {string} strValue The rgba string value of the pixel
- */
-
-/**
- * Wait for all plots to render and then retrieve and return an array
- * of canvas plot pixel data (RGBA values).
- * @param {import('@playwright/test').Page} page
- * @param {string} canvasSelector The selector for the canvas element
- * @return {Promise<PlotPixel[]>}
- */
-async function getCanvasPixels(page, canvasSelector) {
-  const canvasHandle = await page.evaluateHandle(
-    (canvas) => document.querySelector(canvas),
-    canvasSelector
-  );
-  const canvasContextHandle = await page.evaluateHandle(
-    (canvas) => canvas.getContext('2d'),
-    canvasHandle
-  );
-
-  await waitForPlotsToRender(page);
-  return page.evaluate(
-    ([canvas, ctx]) => {
-      // The document canvas is where the plot points and lines are drawn.
-      // The only way to access the canvas is using document (using page.evaluate)
-      /** @type {ImageData} */
-      const data = ctx.getImageData(0, 0, canvas.width, canvas.height).data;
-      /** @type {number[]} */
-      const imageDataValues = Object.values(data);
-      /** @type {PlotPixel[]} */
-      const plotPixels = [];
-      // Each pixel consists of four values within the ImageData.data array. The for loop iterates by multiples of four.
-      // The values associated with each pixel are R (red), G (green), B (blue), and A (alpha), in that order.
-      for (let i = 0; i < imageDataValues.length; ) {
-        if (imageDataValues[i] > 0) {
-          plotPixels.push({
-            r: imageDataValues[i],
-            g: imageDataValues[i + 1],
-            b: imageDataValues[i + 2],
-            a: imageDataValues[i + 3],
-            strValue: `rgb(${imageDataValues[i]}, ${imageDataValues[i + 1]}, ${
-              imageDataValues[i + 2]
-            }, ${imageDataValues[i + 3]})`
-          });
-        }
-
-        i = i + 4;
-      }
-
-      return plotPixels;
-    },
-    [canvasHandle, canvasContextHandle]
-  );
-}
-
-/**
- * Search for telemetry and link it to an object. objectName should come from the domainObject.name function.
- * @param {import('@playwright/test').Page} page
- * @param {string} parameterName
- * @param {string} objectName
- */
-async function linkParameterToObject(page, parameterName, objectName) {
-  await page.getByRole('searchbox', { name: 'Search Input' }).click();
-  await page.getByRole('searchbox', { name: 'Search Input' }).fill(parameterName);
-  await page.getByLabel('Object Results').getByText(parameterName).click();
-  await page.getByLabel('More actions').click();
-  await page.getByLabel('Create Link').click();
-  await page.getByLabel('Modal Overlay').getByLabel('Search Input').click();
-  await page.getByLabel('Modal Overlay').getByLabel('Search Input').fill(objectName);
-  await page.getByLabel('Modal Overlay').getByLabel(`Navigate to ${objectName}`).click();
-  await page.getByLabel('Save').click();
-}
-
-export {
-  createDomainObjectWithDefaults,
-  createExampleTelemetryObject,
-  createNotification,
-  createPlanFromJSON,
-  createStableStateTelemetry,
-  expandEntireTree,
-  getCanvasPixels,
-  linkParameterToObject,
-  navigateToObjectWithFixedTimeBounds,
-  navigateToObjectWithRealTime,
-  setEndOffset,
-  setFixedIndependentTimeConductorBounds,
-  setFixedTimeMode,
-  setRealTimeMode,
-  setStartOffset,
-  setTimeConductorBounds,
-  waitForPlotsToRender
-};

e2e/avpFixtures.js

@@ -1,161 +0,0 @@
-/*****************************************************************************
- * Open MCT, Copyright (c) 2014-2024, United States Government
- * as represented by the Administrator of the National Aeronautics and Space
- * Administration. All rights reserved.
- *
- * Open MCT is licensed under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- * http://www.apache.org/licenses/LICENSE-2.0.
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- * License for the specific language governing permissions and limitations
- * under the License.
- *
- * Open MCT includes source code licensed under additional open source
- * licenses. See the Open Source Licenses file (LICENSES.md) included with
- * this source code distribution or the Licensing information page available
- * at runtime from the About dialog for additional information.
- *****************************************************************************/
-
-/**
- * avpFixtures.js
- *
- * @file This module provides custom fixtures specifically tailored for Accessibility, Visual, and Performance (AVP) tests.
- * These fixtures extend the base functionality of the Playwright fixtures and appActions, and are designed to be
- * generalized across all plugins. They offer functionalities like scanning for accessibility violations, integrating
- * with axe-core, and more.
- *
- * IMPORTANT NOTE: This fixture file is not intended to be extended further by other fixtures. If you find yourself
- * needing to do so, please consult the documentation and consider creating a specialized fixture or modifying the
- * existing ones.
- */
-
-import AxeBuilder from '@axe-core/playwright';
-import fs from 'fs/promises';
-import path from 'path';
-import { fileURLToPath } from 'url';
-
-import { expect, test } from './pluginFixtures.js';
-// Constants for repeated values
-const __dirname = path.dirname(fileURLToPath(import.meta.url));
-const TEST_RESULTS_DIR = path.join(__dirname, './test-results');
-
-const extendedTest = test.extend({
-  /**
-   * Overrides the default screenshot function to apply default options that should apply to all
-   * screenshots taken in the AVP tests.
-   *
-   * @param {import('@playwright/test').PlaywrightTestArgs} args - The Playwright test arguments.
-   * @param {Function} use - The function to use the page object.
-   * Defaults:
-   * - Disables animations
-   * - Masks the clock indicator
-   * - Masks the time conductor last update time in realtime mode
-   * - Masks the time conductor start bounds in fixed mode
-   * - Masks the time conductor end bounds in fixed mode
-   */
-  page: async ({ page }, use) => {
-    const playwrightScreenshot = page.screenshot;
-
-    /**
-     * Override the screenshot function to always mask a given set of locators which will always
-     * show variance across screenshots. Defaults may be overridden by passing in options to the
-     * screenshot function.
-     * @param {import('@playwright/test').PageScreenshotOptions} options - The options for the screenshot.
-     * @returns {Promise<Buffer>} Returns the screenshot as a buffer.
-     */
-    page.screenshot = async function (options = {}) {
-      const mask = [
-        this.getByLabel('Clock Indicator'), // Mask the clock indicator
-        this.getByLabel('Last update'), // Mask the time conductor last update time in realtime mode
-        this.getByLabel('Start bounds'), // Mask the time conductor start bounds in fixed mode
-        this.getByLabel('End bounds') // Mask the time conductor end bounds in fixed mode
-      ];
-
-      const result = await playwrightScreenshot.call(this, {
-        animations: 'disabled',
-        mask,
-        ...options // Pass through or override any options
-      });
-      return result;
-    };
-
-    await use(page);
-  }
-});
-
-/**
- * Writes the accessibility report to the specified path.
- *
- * @param {string} reportPath - The path to write the report to.
- * @param {Object} accessibilityScanResults - The results of the accessibility scan.
- * @returns {Promise<Object>} The accessibility scan results.
- * @throws Will throw an error if writing the report fails.
- */
-async function writeAccessibilityReport(reportPath, accessibilityScanResults) {
-  try {
-    await fs.mkdir(path.dirname(reportPath), { recursive: true });
-    const data = JSON.stringify(accessibilityScanResults, null, 2);
-    await fs.writeFile(reportPath, data);
-    console.log(`Accessibility report with violations saved successfully as ${reportPath}`);
-    return accessibilityScanResults;
-  } catch (err) {
-    console.error(`Error writing the accessibility report to file ${reportPath}:`, err);
-    throw err;
-  }
-}
-
-/**
- * Scans for accessibility violations on a page and writes a report to disk if violations are found.
- * Automatically asserts that no violations should be present.
- *
- * @param {import('playwright').Page} page - The page object from Playwright.
- * @param {string} testCaseName - The name of the test case.
- * @param {{ reportName?: string }} [options={}] - The options for the report generation.
- * @returns {Promise<Object|null>} Returns the accessibility scan results if violations are found, otherwise returns null.
- */
-
-export async function scanForA11yViolations(page, testCaseName, options = {}) {
-  const builder = new AxeBuilder({ page });
-  builder.withTags(['wcag2aa']);
-  // https://github.com/dequelabs/axe-core/blob/develop/doc/rule-descriptions.md
-  const accessibilityScanResults = await builder.analyze();
-
-  // Assert that no violations should be present
-  expect
-    .soft(
-      accessibilityScanResults.violations,
-      `Accessibility violations found in test case: ${testCaseName}`
-    )
-    .toEqual([]);
-
-  // Check if there are any violations
-  if (accessibilityScanResults.violations.length > 0) {
-    const reportName = options.reportName || testCaseName;
-    const sanitizedReportName = reportName.replace(/\//g, '_');
-    const reportPath = path.join(
-      TEST_RESULTS_DIR,
-      'a11y-json-reports',
-      `${sanitizedReportName}.json`
-    );
-
-    try {
-      await page.screenshot({
-        path: path.join(TEST_RESULTS_DIR, 'a11y-screenshots', `${sanitizedReportName}.png`)
-      });
-
-      return await writeAccessibilityReport(reportPath, accessibilityScanResults);
-    } catch (err) {
-      console.error(`Error writing the accessibility report to file ${reportPath}:`, err);
-      throw err;
-    }
-  } else {
-    console.log('No accessibility violations found, no report generated.');
-    return null;
-  }
-}
-
-export { expect, extendedTest as test };

e2e/baseFixtures.js

@@ -1,129 +0,0 @@
-/*****************************************************************************
- * Open MCT, Copyright (c) 2014-2024, United States Government
- * as represented by the Administrator of the National Aeronautics and Space
- * Administration. All rights reserved.
- *
- * Open MCT is licensed under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- * http://www.apache.org/licenses/LICENSE-2.0.
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- * License for the specific language governing permissions and limitations
- * under the License.
- *
- * Open MCT includes source code licensed under additional open source
- * licenses. See the Open Source Licenses file (LICENSES.md) included with
- * this source code distribution or the Licensing information page available
- * at runtime from the About dialog for additional information.
- *****************************************************************************/
-
-/**
- * This file is dedicated to extending the base functionality of the `@playwright/test` framework.
- * The functions in this file should be viewed as temporary or a shim to be removed as the RFEs in
- * the Playwright GitHub repo are implemented. Functions which serve those RFEs are marked with corresponding
- * GitHub issues.
- */
-
-import { expect, request, test } from '@playwright/test';
-import fs from 'fs';
-import path from 'path';
-import { fileURLToPath } from 'url';
-import { v4 as uuid } from 'uuid';
-
-/**
- * Takes a `ConsoleMessage` and returns a formatted string. Used to enable console log error detection.
- * @see {@link https://github.com/microsoft/playwright/discussions/11690 Github Discussion}
- * @private
- * @param {import('@playwright/test').ConsoleMessage} msg
- * @returns {string} formatted string with message type, text, url, and line and column numbers
- */
-function _consoleMessageToString(msg) {
-  const { url, lineNumber, columnNumber } = msg.location();
-
-  return `[${msg.type()}] ${msg.text()} at (${url} ${lineNumber}:${columnNumber})`;
-}
-
-/**
- * Wait for all animations within the given element and subtrees to finish. Useful when
- * verifying that css transitions have completed.
- * @see {@link https://github.com/microsoft/playwright/issues/15660 Github RFE}
- * @param {import('@playwright/test').Locator} locator
- * @return {Promise<Animation[]>}
- */
-function waitForAnimations(locator) {
-  return locator.evaluate((element) =>
-    Promise.all(element.getAnimations({ subtree: true }).map((animation) => animation.finished))
-  );
-}
-
-const istanbulCLIOutput = fileURLToPath(new URL('.nyc_output', import.meta.url));
-
-const extendedTest = test.extend({
-  /**
-   * Path to output raw coverage files. Can be overridden in Playwright config file.
-   * @see {@link https://github.com/mxschmitt/playwright-test-coverage Github Example Project}
-   * @constant {string}
-   */
-
-  coveragePath: [istanbulCLIOutput, { option: true }],
-  /**
-   * Extends the base context class to add codecoverage shim.
-   * @see {@link https://github.com/mxschmitt/playwright-test-coverage Github Project}
-   */
-  context: async ({ context, coveragePath }, use) => {
-    await context.addInitScript(() =>
-      window.addEventListener('beforeunload', () =>
-        window.collectIstanbulCoverage(JSON.stringify(window.__coverage__))
-      )
-    );
-    await fs.promises.mkdir(coveragePath, { recursive: true });
-    await context.exposeFunction('collectIstanbulCoverage', (coverageJSON) => {
-      if (coverageJSON) {
-        fs.writeFileSync(
-          path.join(coveragePath, `playwright_coverage_${uuid()}.json`),
-          coverageJSON
-        );
-      }
-    });
-
-    await use(context);
-    for (const page of context.pages()) {
-      await page.evaluate(() => {
-        window.collectIstanbulCoverage(JSON.stringify(window.__coverage__));
-      });
-    }
-  },
-  /**
-   * If true, will assert against any console.error calls that occur during the test. Assertions occur
-   * during test teardown (after the test has completed).
-   *
-   * Default: `true`
-   */
-  failOnConsoleError: [true, { option: true }],
-  /**
-   * Extends the base page class to enable console log error detection.
-   * @see {@link https://github.com/microsoft/playwright/discussions/11690 Github Discussion}
-   */
-  page: async ({ page, failOnConsoleError }, use) => {
-    // Capture any console errors during test execution
-    const messages = [];
-    page.on('console', (msg) => messages.push(msg));
-
-    await use(page);
-
-    // Assert against console errors during teardown
-    if (failOnConsoleError) {
-      messages.forEach((msg) =>
-        // eslint-disable-next-line playwright/no-standalone-expect
-        expect
-          .soft(msg.type(), `Console error detected: ${_consoleMessageToString(msg)}`)
-          .not.toEqual('error')
-      );
-    }
-  }
-});
-
-export { expect, request, extendedTest as test, waitForAnimations };

e2e/constants.js

@@ -1,36 +0,0 @@
-/**
- * Constants which may be used across all e2e tests.
- */
-
-/**
- * Time Constants
- * - Used for overriding the browser clock in tests.
- */
-export const MISSION_TIME = 1732413600000; // Saturday, November 23, 2024 6:00:00 PM GMT-08:00 (Thanksgiving Dinner Time)
-// Subtracting 30 minutes from MISSION_TIME
-export const MISSION_TIME_FIXED_START = 1732413600000 - 1800000; // 1732411800000
-
-// Adding 1 minute to MISSION_TIME
-export const MISSION_TIME_FIXED_END = 1732413600000 + 60000; // 1732413660000
-/**
- * URL Constants
- * These constants are used for initial navigation in visual tests, in either fixed or realtime mode.
- * They navigate to the 'My Items' folder at MISSION_TIME.
- * They set the following url parameters:
- *  - tc.mode - The time conductor mode ('fixed' or 'local')
- *  - tc.startBound - The time conductor start bound (when in fixed mode)
- *  - tc.endBound - The time conductor end bound (when in fixed mode)
- *  - tc.startDelta - The time conductor start delta (when in realtime mode)
- *  - tc.endDelta - The time conductor end delta (when in realtime mode)
- *  - tc.timeSystem - The time conductor time system ('utc')
- *  - view - The view to display ('grid')
- *  - hideInspector - Whether to hide the inspector (true)
- *  - hideTree - Whether to hide the tree (true)
- * @typedef {string} VisualUrl
- */
-
-/** @type {VisualUrl} */
-export const VISUAL_FIXED_URL = `./#/browse/mine?tc.mode=fixed&tc.startBound=${MISSION_TIME_FIXED_START}&tc.endBound=${MISSION_TIME_FIXED_END}&tc.timeSystem=utc&view=grid&hideInspector=true&hideTree=true`;
-/** @type {VisualUrl} */
-export const VISUAL_REALTIME_URL =
-  './#/browse/mine?tc.mode=local&tc.timeSystem=utc&view=grid&tc.startDelta=1800000&tc.endDelta=30000&hideTree=true&hideInspector=true';

e2e/helper/addInitDataVisualization.js

@@ -1,30 +0,0 @@
-/*****************************************************************************
- * Open MCT, Copyright (c) 2014-2024, United States Government
- * as represented by the Administrator of the National Aeronautics and Space
- * Administration. All rights reserved.
- *
- * Open MCT is licensed under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- * http://www.apache.org/licenses/LICENSE-2.0.
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- * License for the specific language governing permissions and limitations
- * under the License.
- *
- * Open MCT includes source code licensed under additional open source
- * licenses. See the Open Source Licenses file (LICENSES.md) included with
- * this source code distribution or the Licensing information page available
- * at runtime from the About dialog for additional information.
- *****************************************************************************/
-
-// This should be used to install the Example User
-document.addEventListener('DOMContentLoaded', () => {
-  const openmct = window.openmct;
-  openmct.install(openmct.plugins.example.ExampleDataVisualizationSourcePlugin());
-  openmct.install(
-    openmct.plugins.InspectorDataVisualization({ type: 'exampleDataVisualizationSource' })
-  );
-});

e2e/helper/addInitExampleFaultProvider.js

@@ -1,28 +0,0 @@
-/*****************************************************************************
- * Open MCT, Copyright (c) 2014-2024, United States Government
- * as represented by the Administrator of the National Aeronautics and Space
- * Administration. All rights reserved.
- *
- * Open MCT is licensed under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- * http://www.apache.org/licenses/LICENSE-2.0.
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- * License for the specific language governing permissions and limitations
- * under the License.
- *
- * Open MCT includes source code licensed under additional open source
- * licenses. See the Open Source Licenses file (LICENSES.md) included with
- * this source code distribution or the Licensing information page available
- * at runtime from the About dialog for additional information.
- *****************************************************************************/
-
-// This should be used to install the Example Fault Provider, this will also install the FaultManagementPlugin (neither of which are installed by default).
-
-document.addEventListener('DOMContentLoaded', () => {
-  const openmct = window.openmct;
-  openmct.install(openmct.plugins.example.ExampleFaultSource());
-});

e2e/helper/addInitExampleFaultProviderStatic.js

@@ -1,30 +0,0 @@
-/*****************************************************************************
- * Open MCT, Copyright (c) 2014-2024, United States Government
- * as represented by the Administrator of the National Aeronautics and Space
- * Administration. All rights reserved.
- *
- * Open MCT is licensed under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- * http://www.apache.org/licenses/LICENSE-2.0.
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- * License for the specific language governing permissions and limitations
- * under the License.
- *
- * Open MCT includes source code licensed under additional open source
- * licenses. See the Open Source Licenses file (LICENSES.md) included with
- * this source code distribution or the Licensing information page available
- * at runtime from the About dialog for additional information.
- *****************************************************************************/
-
-// This should be used to install the Example Fault Provider, this will also install the FaultManagementPlugin (neither of which are installed by default).
-
-document.addEventListener('DOMContentLoaded', () => {
-  const openmct = window.openmct;
-  const staticFaults = true;
-
-  openmct.install(openmct.plugins.example.ExampleFaultSource(staticFaults));
-});

e2e/helper/addInitExampleUser.js

@@ -1,27 +0,0 @@
-/*****************************************************************************
- * Open MCT, Copyright (c) 2014-2024, United States Government
- * as represented by the Administrator of the National Aeronautics and Space
- * Administration. All rights reserved.
- *
- * Open MCT is licensed under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- * http://www.apache.org/licenses/LICENSE-2.0.
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- * License for the specific language governing permissions and limitations
- * under the License.
- *
- * Open MCT includes source code licensed under additional open source
- * licenses. See the Open Source Licenses file (LICENSES.md) included with
- * this source code distribution or the Licensing information page available
- * at runtime from the About dialog for additional information.
- *****************************************************************************/
-
-// This should be used to install the Example User
-document.addEventListener('DOMContentLoaded', () => {
-  const openmct = window.openmct;
-  openmct.install(openmct.plugins.example.ExampleUser());
-});

e2e/helper/addInitFaultManagementPlugin.js

@@ -1,28 +0,0 @@
-/*****************************************************************************
- * Open MCT, Copyright (c) 2014-2024, United States Government
- * as represented by the Administrator of the National Aeronautics and Space
- * Administration. All rights reserved.
- *
- * Open MCT is licensed under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- * http://www.apache.org/licenses/LICENSE-2.0.
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- * License for the specific language governing permissions and limitations
- * under the License.
- *
- * Open MCT includes source code licensed under additional open source
- * licenses. See the Open Source Licenses file (LICENSES.md) included with
- * this source code distribution or the Licensing information page available
- * at runtime from the About dialog for additional information.
- *****************************************************************************/
-
-// This should be used to install the Example Fault Provider, this will also install the FaultManagementPlugin (neither of which are installed by default).
-
-document.addEventListener('DOMContentLoaded', () => {
-  const openmct = window.openmct;
-  openmct.install(openmct.plugins.FaultManagement());
-});

e2e/helper/addInitFileInputObject.js

@@ -1,71 +0,0 @@
-class DomainObjectViewProvider {
-  constructor(openmct) {
-    this.key = 'doViewProvider';
-    this.name = 'Domain Object View Provider';
-    this.openmct = openmct;
-  }
-
-  canView(domainObject) {
-    return domainObject.type === 'imageFileInput' || domainObject.type === 'jsonFileInput';
-  }
-
-  view(domainObject, objectPath) {
-    let content;
-
-    return {
-      show: function (element) {
-        const body = domainObject.selectFile.body;
-        const type = typeof body;
-
-        content = document.createElement('div');
-        content.id = 'file-input-type';
-        content.textContent = JSON.stringify(type);
-        element.appendChild(content);
-      },
-      destroy: function (element) {
-        element.removeChild(content);
-        content = undefined;
-      }
-    };
-  }
-}
-
-document.addEventListener('DOMContentLoaded', () => {
-  const openmct = window.openmct;
-
-  openmct.types.addType('jsonFileInput', {
-    key: 'jsonFileInput',
-    name: 'JSON File Input Object',
-    creatable: true,
-    form: [
-      {
-        name: 'Upload File',
-        key: 'selectFile',
-        control: 'file-input',
-        required: true,
-        text: 'Select File...',
-        type: 'application/json',
-        property: ['selectFile']
-      }
-    ]
-  });
-
-  openmct.types.addType('imageFileInput', {
-    key: 'imageFileInput',
-    name: 'Image File Input Object',
-    creatable: true,
-    form: [
-      {
-        name: 'Upload File',
-        key: 'selectFile',
-        control: 'file-input',
-        required: true,
-        text: 'Select File...',
-        type: 'image/*',
-        property: ['selectFile']
-      }
-    ]
-  });
-
-  openmct.objectViews.addProvider(new DomainObjectViewProvider(openmct));
-});

e2e/helper/addInitNotebookWithUrls.js

@@ -1,32 +0,0 @@
-/*****************************************************************************
- * Open MCT, Copyright (c) 2014-2024, United States Government
- * as represented by the Administrator of the National Aeronautics and Space
- * Administration. All rights reserved.
- *
- * Open MCT is licensed under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- * http://www.apache.org/licenses/LICENSE-2.0.
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- * License for the specific language governing permissions and limitations
- * under the License.
- *
- * Open MCT includes source code licensed under additional open source
- * licenses. See the Open Source Licenses file (LICENSES.md) included with
- * this source code distribution or the Licensing information page available
- * at runtime from the About dialog for additional information.
- *****************************************************************************/
-
-// This should be used to install the re-instal default Notebook plugin with a simple url whitelist.
-// e.g.
-// await page.addInitScript({ path: path.join(__dirname, 'addInitNotebookWithUrls.js') });
-const NOTEBOOK_NAME = 'Notebook';
-const URL_WHITELIST = ['google.com'];
-
-document.addEventListener('DOMContentLoaded', () => {
-  const openmct = window.openmct;
-  openmct.install(openmct.plugins.Notebook(NOTEBOOK_NAME, URL_WHITELIST));
-});

e2e/helper/addInitOperatorStatus.js

@@ -1,27 +0,0 @@
-/*****************************************************************************
- * Open MCT, Copyright (c) 2014-2024, United States Government
- * as represented by the Administrator of the National Aeronautics and Space
- * Administration. All rights reserved.
- *
- * Open MCT is licensed under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- * http://www.apache.org/licenses/LICENSE-2.0.
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- * License for the specific language governing permissions and limitations
- * under the License.
- *
- * Open MCT includes source code licensed under additional open source
- * licenses. See the Open Source Licenses file (LICENSES.md) included with
- * this source code distribution or the Licensing information page available
- * at runtime from the About dialog for additional information.
- *****************************************************************************/
-
-// This should be used to install the Operator Status
-document.addEventListener('DOMContentLoaded', () => {
-  const openmct = window.openmct;
-  openmct.install(openmct.plugins.OperatorStatus());
-});

e2e/helper/addInitRestrictedNotebook.js

@@ -1,30 +0,0 @@
-/*****************************************************************************
- * Open MCT, Copyright (c) 2014-2024, United States Government
- * as represented by the Administrator of the National Aeronautics and Space
- * Administration. All rights reserved.
- *
- * Open MCT is licensed under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- * http://www.apache.org/licenses/LICENSE-2.0.
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- * License for the specific language governing permissions and limitations
- * under the License.
- *
- * Open MCT includes source code licensed under additional open source
- * licenses. See the Open Source Licenses file (LICENSES.md) included with
- * this source code distribution or the Licensing information page available
- * at runtime from the About dialog for additional information.
- *****************************************************************************/
-
-// This should be used to install the non-default Restricted Notebook plugin since it is not installed by default.
-// e.g.
-// await page.addInitScript({ path: path.join(__dirname, 'addInitRestrictedNotebook.js') });
-
-document.addEventListener('DOMContentLoaded', () => {
-  const openmct = window.openmct;
-  openmct.install(openmct.plugins.RestrictedNotebook('CUSTOM_NAME'));
-});

e2e/helper/addNoneditableObject.js

@@ -1,27 +0,0 @@
-(function () {
-  document.addEventListener('DOMContentLoaded', () => {
-    const PERSISTENCE_KEY = 'persistence-tests';
-    const openmct = window.openmct;
-
-    openmct.objects.addRoot({
-      namespace: PERSISTENCE_KEY,
-      key: PERSISTENCE_KEY
-    });
-
-    openmct.objects.addProvider(PERSISTENCE_KEY, {
-      get(identifier) {
-        if (identifier.key !== PERSISTENCE_KEY) {
-          return undefined;
-        } else {
-          return Promise.resolve({
-            identifier,
-            type: 'folder',
-            name: 'Persistence Testing',
-            location: 'ROOT',
-            composition: []
-          });
-        }
-      }
-    });
-  });
-})();

e2e/helper/faultUtils.js

@@ -1,247 +0,0 @@
-/*****************************************************************************
- * Open MCT, Copyright (c) 2014-2024, United States Government
- * as represented by the Administrator of the National Aeronautics and Space
- * Administration. All rights reserved.
- *
- * Open MCT is licensed under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- * http://www.apache.org/licenses/LICENSE-2.0.
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- * License for the specific language governing permissions and limitations
- * under the License.
- *
- * Open MCT includes source code licensed under additional open source
- * licenses. See the Open Source Licenses file (LICENSES.md) included with
- * this source code distribution or the Licensing information page available
- * at runtime from the About dialog for additional information.
- *****************************************************************************/
-import { fileURLToPath } from 'url';
-
-import { expect } from '../pluginFixtures.js';
-
-/**
- * @param {import('@playwright/test').Page} page
- * @returns {Promise<void>}
- */
-export async function navigateToFaultManagementWithExample(page) {
-  await page.addInitScript({
-    path: fileURLToPath(new URL('./addInitExampleFaultProvider.js', import.meta.url))
-  });
-
-  await navigateToFaultItemInTree(page);
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- * @returns {Promise<void>}
- */
-export async function navigateToFaultManagementWithStaticExample(page) {
-  await page.addInitScript({
-    path: fileURLToPath(new URL('./addInitExampleFaultProviderStatic.js', import.meta.url))
-  });
-
-  await navigateToFaultItemInTree(page);
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- * @returns {Promise<void>}
- */
-export async function navigateToFaultManagementWithoutExample(page) {
-  await page.addInitScript({
-    path: fileURLToPath(new URL('./addInitFaultManagementPlugin.js', import.meta.url))
-  });
-
-  await navigateToFaultItemInTree(page);
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- * @returns {Promise<void>}
- */
-async function navigateToFaultItemInTree(page) {
-  await page.goto('./', { waitUntil: 'domcontentloaded' });
-  await page.waitForURL('**/#/browse/mine?**');
-
-  const faultManagementTreeItem = page
-    .getByRole('tree', {
-      name: 'Main Tree'
-    })
-    .getByRole('treeitem', {
-      name: 'Fault Management'
-    });
-
-  // Navigate to "Fault Management" from the tree
-  await faultManagementTreeItem.click();
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- * @param {number} rowNumber
- * @returns {Promise<void>}
- */
-export async function acknowledgeFault(page, rowNumber) {
-  await openFaultRowMenu(page, rowNumber);
-  await page.getByLabel('Acknowledge', { exact: true }).click();
-  await page.getByLabel('Save').click();
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- * @param {...number} nums
- * @returns {Promise<void>}
- */
-export async function shelveMultipleFaults(page, ...nums) {
-  const selectRows = nums.map((num) => {
-    return selectFaultItem(page, num);
-  });
-  await Promise.all(selectRows);
-
-  await page.getByLabel('Shelve selected faults').click();
-  await page.getByLabel('Save').click();
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- * @param {...number} nums
- * @returns {Promise<void>}
- */
-export async function acknowledgeMultipleFaults(page, ...nums) {
-  const selectRows = nums.map((num) => {
-    return selectFaultItem(page, num);
-  });
-  await Promise.all(selectRows);
-
-  await page.getByLabel('Acknowledge selected faults').click();
-  await page.getByLabel('Save').click();
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- * @param {number} rowNumber
- * @returns {Promise<void>}
- */
-export async function shelveFault(page, rowNumber) {
-  await openFaultRowMenu(page, rowNumber);
-  await page.getByLabel('Shelve', { exact: true }).click();
-  await page.getByLabel('Save').click();
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- * @param {'severity' | 'newest-first' | 'oldest-first'} sort
- * @returns {Promise<void>}
- */
-export async function sortFaultsBy(page, sort) {
-  await page.getByTitle('Sort By').getByRole('combobox').selectOption(sort);
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- * @param {'acknowledged' | 'shelved' | 'standard view'} view
- * @returns {Promise<void>}
- */
-export async function changeViewTo(page, view) {
-  await page.getByTitle('View Filter').getByRole('combobox').selectOption(view);
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- * @param {number} rowNumber
- * @returns {Promise<void>}
- */
-export async function selectFaultItem(page, rowNumber) {
-  await page
-    .getByLabel('Select fault')
-    .nth(rowNumber - 1)
-    .check({
-      // Need force here because checkbox state is changed by an event emitted by the checkbox
-      // eslint-disable-next-line playwright/no-force-option
-      force: true
-    });
-  await expect(page.getByLabel('Select fault').nth(rowNumber - 1)).toBeChecked();
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- * @param {number} rowNumber
- * @returns {import('@playwright/test').Locator}
- */
-export function getFault(page, rowNumber) {
-  const fault = page.getByLabel('Fault triggered at').nth(rowNumber - 1);
-
-  return fault;
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- * @param {string} name
- * @returns {import('@playwright/test').Locator}
- */
-export function getFaultByName(page, name) {
-  const fault = page.getByLabel('Fault triggered at').filter({
-    hasText: name
-  });
-
-  return fault;
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- * @param {number} rowNumber
- * @returns {Promise<string>}
- */
-export async function getFaultName(page, rowNumber) {
-  const faultName = await page
-    .getByLabel('Fault name', { exact: true })
-    .nth(rowNumber - 1)
-    .textContent();
-
-  return faultName;
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- * @param {number} rowNumber
- * @returns {Promise<string>}
- */
-export async function getFaultNamespace(page, rowNumber) {
-  const faultNamespace = await page
-    .getByLabel('Fault namespace')
-    .nth(rowNumber - 1)
-    .textContent();
-
-  return faultNamespace;
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- * @param {number} rowNumber
- * @returns {Promise<string>}
- */
-export async function getFaultTriggerTime(page, rowNumber) {
-  const faultTriggerTime = await page
-    .getByLabel('Last Trigger Time')
-    .nth(rowNumber - 1)
-    .textContent();
-
-  return faultTriggerTime.toString().trim();
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- * @param {number} rowNumber
- * @returns {Promise<void>}
- */
-export async function openFaultRowMenu(page, rowNumber) {
-  // select
-  await page
-    .getByLabel('Fault triggered at')
-    .nth(rowNumber - 1)
-    .getByLabel('Disposition Actions')
-    .click();
-}

e2e/helper/hotkeys/clipboard.js

@@ -1,47 +0,0 @@
-/*****************************************************************************
- * Open MCT, Copyright (c) 2014-2024, United States Government
- * as represented by the Administrator of the National Aeronautics and Space
- * Administration. All rights reserved.
- *
- * Open MCT is licensed under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- * http://www.apache.org/licenses/LICENSE-2.0.
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- * License for the specific language governing permissions and limitations
- * under the License.
- *
- * Open MCT includes source code licensed under additional open source
- * licenses. See the Open Source Licenses file (LICENSES.md) included with
- * this source code distribution or the Licensing information page available
- * at runtime from the About dialog for additional information.
- *****************************************************************************/
-
-const isMac = process.platform === 'darwin';
-const modifier = isMac ? 'Meta' : 'Control';
-
-/**
- * @param {import('@playwright/test').Page} page
- */
-async function selectAll(page) {
-  await page.keyboard.press(`${modifier}+KeyA`);
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- */
-async function copy(page) {
-  await page.keyboard.press(`${modifier}+KeyC`);
-}
-
-/**
- * @param {import('@playwright/test').Page} page
- */
-async function paste(page) {
-  await page.keyboard.press(`${modifier}+KeyV`);
-}
-
-export { copy, paste, selectAll };

e2e/helper/hotkeys/hotkeys.js

@@ -1,23 +0,0 @@
-/*****************************************************************************
- * Open MCT, Copyright (c) 2014-2024, United States Government
- * as represented by the Administrator of the National Aeronautics and Space
- * Administration. All rights reserved.
- *
- * Open MCT is licensed under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- * http://www.apache.org/licenses/LICENSE-2.0.
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- * License for the specific language governing permissions and limitations
- * under the License.
- *
- * Open MCT includes source code licensed under additional open source
- * licenses. See the Open Source Licenses file (LICENSES.md) included with
- * this source code distribution or the Licensing information page available
- * at runtime from the About dialog for additional information.
- *****************************************************************************/
-
-export * from './clipboard.js';