Change: clarify architecture overview section

1 files changed, 15 insertions, 13 deletions

diff --git a/architecture.mdwn b/architecture.mdwn
index da0e3dd..e648237 100644
--- a/architecture.mdwn
+++ b/architecture.mdwn
@@ -111,30 +111,32 @@ The architecture of ick is a collection of mutually recursive
 self-modifying microservices. (That's intended to scare you off.)
 
 * A project consists of one or more pipelines to be executed when
-  triggered to do so, and some parameters given to the pipelines. The
-  user (or some other entity) triggers a project, and ick will execute
-  all the pipelines (FIXME: this is not yet implemented, currently
-  each pipeline needs to be triggered individually). Each pipeline
-  acts in the same workspace. The entire pipeline is executed on the
-  same worker. All workers are considered equal (for now).
-
-* There is currently no separate workspace description. Each pipeline
-  needs to construct the workspace itself, if it needs to.
+  triggered to do so. A project defines some parameters given to the
+  pipelines. The user (or some other entity, such as a version control
+  server) triggers a project, and ick will execute all the pipelines.
+  Each pipeline acts in the same workspace. The entire pipeline is
+  executed on the same worker. All workers are considered equal.
+
+* There is no separate workspace description. Each project needs to
+  construct the workspace itself, if it needs to. Each build starts
+  with an empty directory as the workspace. The project needs to
+  populate it by, say, `git clone` or by telling ick to fetch the
+  contents of the prevoius build's workspace from the artifact store.
 
 * The project's pipelines do things like: prepare workspace, run
   actual build, publish build artifacts from worker to a suitable
   server. The controller keeps track of where in each pipeline a
   build is.
 
-* Each worker is represented by a worker-manager, which requests work from
-  the controller and perform the work by running commands locally
+* Each worker is represented by a worker-manager, which requests work
+  from the controller and perform the work by running commands locally
   (later also over ssh on the actual worker host).
 
 * Worker-builders register themselves with the controller.
 
 * A pipeline is a sequence of actions (such as shell or python
-  snippets to run), plus some parameters that the shell (or whatever)
-  can reference.
+  snippets to run), plus some parameters that the actions can
+  reference.
 
 * If a pipeline action fails, the controller will mark the pipeline
   execution as having failed and won't schedule more steps to execute.