Remove non plutus apps components

.gitattributes

@@ -2,7 +2,6 @@
 nix/pkgs/haskell/materialized*/**/*.nix linguist-generated=true
 # linguist gets confused by PIR files, and thinks they make up a lot of our source!
 *.pir linguist-detectable=false
-stubs/plutus-ghc-stub/** linguist-vendored=true
 # Large HTML files inside 'notes' are dominating our repoistory language
 # estimate.
 notes/**/*.html linguist-documentation

.github/ISSUE_TEMPLATE/bug_report.md

@@ -6,14 +6,6 @@ labels: bug
 assignees: ''
 
 ---
-
-## Area
-
-[] *Plutus Foundation* Related to the GHC plugin, Haskell-to-Plutus compiler, on-chain code
-[] *Plutus Application Framework* Related to the Plutus application backend (PAB), emulator, Plutus libraries
-[] *Marlowe* Related to Marlowe
-[] *Other* Any other topic (Playgrounds, etc.)
-
 ## Summary
 
 A clear and specific description of what the bug is.

.github/workflows/deploy.yml

@@ -2,9 +2,9 @@ name: "Deploy"
 on:
   push:
     branches:
-      - marlowe-dist-demo # production, TODO this should be from the marlowe-production branch
-      - master # staging
-      # TODO need branches for wyohack and plutus-production
+      # Commented out until plutus-ops is updated for the repo split
+      # - main # staging
+      - fake-branch-which-will-not-exist-prior-to-ops-update
 jobs:
   deploy:
     runs-on: ubuntu-latest

.gitignore

@@ -47,9 +47,6 @@ stack.yaml.lock
 *.prof
 .liquid/
 
-# Agda
-*.agdai
-
 # Python
 __pycache__
 

ARCHITECTURE.adoc

@@ -1,32 +1,13 @@
-= Architecture of the Plutus project
+= Architecture of the Plutus apps project
 :email: plutus@iohk.io
 :author: Input Output HK Limited
 :toc: left
 :reproducible:
 
-This document is an overview of how the software in the Plutus project is
+This document is an overview of how the software in the Plutus apps project is
 structured. Most things are in direct subdirectories of the root, so we will
 work through those in conceptual order.
 
-== Plutus Core
-
-Plutus Core is the language that actually goes on the blockchain. Consequently
-this is the absolute core of the codebase, and everything depends on it.
-It also includes the Plutus IR intermediary language.
-
-include::plutus-core/ARCHITECTURE.adoc[]
-
-== Plutus Tx
-
-Plutus Tx is how we refer to the subset of Haskell which we compile into Plutus
-Core. This is how users actually write Plutus contracts: they write Haskell
-programs, part of which is compiled into Plutus Core. The rest of the program
-can then use this compiled code when submitting transactions.
-
-include::plutus-tx/ARCHITECTURE.adoc[]
-
-include::plutus-tx-plugin/ARCHITECTURE.adoc[]
-
 == Ledger
 
 To write actual Plutus contracts we need a model of the ledger that we're
@@ -56,70 +37,26 @@ include::plutus-contract/ARCHITECTURE.adoc[]
 
 include::plutus-use-cases/ARCHITECTURE.adoc[]
 
-== Marlowe
+== Playground
 
-Although conceptually separate from Plutus, a fair amount of Marlowe-related
-code is in the Plutus repository. This is for two different reasons:
-
-. We have an implementation of Marlowe on top of Plutus, which depends on the
-other code in the repository.
-. The Marlowe Playground shares code and deployment infrastructure with the
-Plutus Playground.
-
-include::marlowe/ARCHITECTURE.adoc[]
-
-include::marlowe-symbolic/ARCHITECTURE.adoc[]
-
-include::marlowe-actus/ARCHITECTURE.adoc[]
-
-== Playgrounds
-
-The Plutus/Marlowe Playgrounds are our web-based environment for developing and
-testing basic Plutus and Marlowe contracts. That means they're the main way that
+The Plutus Playground is our web-based environment for developing and
+testing basic Plutus contracts. That means it's the main way that
 anyone outside the team has interacted with out product!
 
 include::playground-common/ARCHITECTURE.adoc[]
 
 include::plutus-playground-server/ARCHITECTURE.adoc[]
 
-include::marlowe-playground-server/ARCHITECTURE.adoc[]
-
 include::plutus-playground-client/ARCHITECTURE.adoc[]
 
-include::marlowe-playground-client/ARCHITECTURE.adoc[]
-
-include::playground-common/ARCHITECTURE.adoc[]
-
 include::web-common/ARCHITECTURE.adoc[]
 
-include::deployment/ARCHITECTURE.adoc[]
-
 == Smart Contract Backend
 
 The smart contract backend provides the runtime environment for compiled Plutus contracts. It manages the state of contract instances and brokers messages between them and the nodes, users, and wallets that they interact with.
 
 include::plutus-pab/ARCHITECTURE.adoc[]
 
-== Documentation
-
-include::marlowe/ARCHITECTURE.adoc[]
-
-include::notes/ARCHITECTURE.adoc[]
-
-== Specification and design
-
-We have done a fair amount of work in specifying and formalizing parts of our
-system. At the moment all of this work also lives in the Plutus repository, and
-we even have some basic testing of the Haskell implementation against the Agda formalization.
-
-include::plutus-metatheory/ARCHITECTURE.adoc[]
-
-include::papers/ARCHITECTURE.adoc[]
-
-include::plutus-core-spec/ARCHITECTURE.adoc[]
-
-include::extended-utxo-spec/ARCHITECTURE.adoc[]
-
 == Build tooling
 
 include::nix/ARCHITECTURE.adoc[]

CONTRIBUTING.adoc

@@ -13,7 +13,6 @@ This includes a variety of useful tools:
 
 * The right version of GHC with all the external Haskell dependencies in its package database.
 * `cabal-install`
-* Agda with the right libraries set up to build our Agda code
 * `stylish-haskell`
 * `haskell-language-server`
 * `purescript-language-server`
@@ -305,7 +304,7 @@ Use the Github "draft" feature for this.
 
 Until a PR is merged, the branch is yours to do with as you will.
 In particular, rebasing and force-pushing is fine.
-Indeed, if you need to update your branch with changes from master, rebasing is typically better than merging.
+Indeed, if you need to update your branch with changes from main, rebasing is typically better than merging.
 
 So please do use this ability where it helps, for example:
 
@@ -371,9 +370,9 @@ Pull requests cannot be merged without at least the Hydra CI check being green.
 NOTE: This isn't strictly true: repository admins (notably Michael) can force-merge PRs without the checks being green
 If you really need this, ask.
 
-CI checks are run on the tip of the PR branch, not on the merge commit that is created with master.
+CI checks are run on the tip of the PR branch, not on the merge commit that is created with main.
 As a result, it's possible to create a "semantic" merge commit where the CI passes on commits C1 and C2, but not on the merge of C1 and C2.
-In this circumstance we can end up with the CI checks being broken on master.
+In this circumstance we can end up with the CI checks being broken on main.
 However, this is sufficiently infrequent that we just live with the possibility, since eliminating it is quite awkward.
 
 ==== Hydra
@@ -404,55 +403,3 @@ These perform some of the same checks as Hydra, but Github Actions is often more
 ==== Buildkite
 
 Buildkite currently only performs the continuous deployment steps.
-
-=== Continuous deployment
-
-Several packages are continuously deployed to a staging environment. See link:./deployment/README.md[deployment/README.md] for detailed information on the deployment setup.
-
-== Integrating with other Cardano projects
-
-=== The Cardano ledger (`cardano-ledger-specs`)
-
-We have a cyclic dependency with `cardano-ledger-specs`:
-1. `cardano-ledger-alonzo` depends on `plutus-ledger-api`.
-2. `plutus-ledger`/`plutus-contract` etc. depend on `cardano-api`, which depends on `cardano-node`, which depends on `cardo-ledger-alonzo`.
-
-This is possible because the cycle is not between *packages*, merely between the respositories.
-Still, it causes some problems: if we make a change to `plutus-ledger-api` or below that causes `cardano-ledger-alonzo` to not compile, we cannot immediately merge that change!
-To do that, we would need to change our `source-repository-package` pin to point to a version of `cardano-ledger-specs` that works with that change.
-But we can't easily make such a PR to `cardano-ledger-specs` either: that would require them to pin a version of `plutus` where everything worked.
-
-To make this less painful, we have a (slightly complicated) workflow for such changes.
-
-==== Staging branch
-
-Firstly, there is a branch `plutus-staging` in `cardano-ledger-specs`.
-The rules for `plutus-staging` are:
-1. It should pass the `cardano-ledger-specs` CI, so it is always mergeable. 
-This means that you *will* need to update the `plutus` pin when you make changes to `plutus-staging`.
-2. It is allowed for the `plutus` pin in `plutus-staging` to point to a _non-master_ commit, such as a commit in an unmerged PR.
-3. The commit pointed to by the `plutus` pin in `plutus-staging` must continue to exist: we should not squash or rebase it away.
-3. When merging `plutus-staging` into `master`, the `plutus` pin should be updated to point to a _master_ commit.
-
-==== PR workflow
-
-1. Create a `plutus` PR (#1) with your changes.
-2. Create a `cardano-ledger-specs` PR (#2) targeting `plutus-staging` with the necessary changes in `cardano-ledger-specs`. 
-The `plutus` pin should point to a commit on the PR #1 branch.
-While you are working, you can point the `cardano-ledger-specs` pin in your PR #1 branch to the tip of PR #2, so that everything compiles.
-3. Once the changes to `cardano-ledger-specs` have settled down, we can merge PR #2.
-After this be careful not to remove the commit from PR #1 which you used in `plutus-staging`!
-4. Update the `cardano-ledger-specs` pin in PR #1 to point to `plutus-staging`.
-5. Once the changes overall settle down, we can merge PR #1.
-
-==== Merging the staging branches
-
-We can do several PRs that touch `cardano-ledger-specs` before we merge `plutus-staging` into master, but it's best not to let it diverge too much.
-The process is:
-
-1. Open a PR in `cardano-ledger-specs` merging `plutus-staging` into master, and updating the `plutus` pin to point to master.
-2. You may need to rerun the `plutus-preprocessor` in `cardano-ledger-specs` before doing this.
-It generates some test scripts, and isn't done automatically.
-3. Open a PR in `plutus` updating the `cardano-ledger-specs` pin to point to master.
-This can happen later.
-