[docs] Replace docs with pointers to the new repository.

Do not replace any given doc with a pointer to the same doc in the new
repository.  Rationale:

If we point to the same doc at HEAD, it may have been moved, renamed, or
deleted.  This could leave us with dangling links.

If we point to the same doc at a particular revision, the link will
become stale, and potentially confusing to users looking for
documentation.

Test: Big flaming ball of obsolescence.
Change-Id: I1677bde60f291033b420264a869e91faad5ada36
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
index 4644fc2..225b97b 100644
--- a/CODE_OF_CONDUCT.md
+++ b/CODE_OF_CONDUCT.md
@@ -1,83 +1,7 @@
-# Fuchsia Code of Conduct
+# Obsolete
 
-Google and the Fuchsia team are committed to preserving and fostering a diverse,
-welcoming community. Below is our community code of conduct, which applies to
-our repos and organizations, mailing lists, blog content, IRC channel and any
-other Fuchsia-supported communication group, as well as any private
-communication initiated in the context of these spaces.
-Simply put, community discussions should be
- * respectful and kind;
- * about Fuchsia;
- * about features and code, not the individuals involved.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-## Be respectful and constructive.
-
-Treat everyone with respect. Build on each other's ideas. Each of us has the
-right to enjoy our experience and participate without fear of harassment,
-discrimination, or condescension, whether blatant or subtle. Remember that
-Fuchsia is a geographically distributed team and that you may not be
-communicating with someone in their primary language. We all get frustrated
-when working on hard problems, but we cannot allow that frustration to turn
-into personal attacks.
-
-## Speak up if you see or hear something.
-You are empowered to politely engage when you feel that you or others are
-disrespected. The person making you feel uncomfortable may not be aware of what
-they are doing - politely bringing their behavior to their attention is
-encouraged.
-
-If you are uncomfortable speaking up, or feel that your concerns are not being
-duly considered, you can email fuchsia-community-managers@google.com to request
-involvement from a community manager. All concerns shared with community
-managers will be kept confidential, but you may also submit an anonymous report
-[here](https://goo.gl/forms/xgisUdowrEWrYgui2).  Please note that without a way
-to contact you, an anonymous report may be difficult to act on. You may also
-create a throwaway account to report. In cases where a public response is deemed
-necessary, the identities of victims and reporters will remain confidential
-unless those individuals instruct us otherwise.
-
-While all reports will be taken seriously, the Fuchsia community managers may
-not act on complaints that they feel are not violations of this code of
-conduct.
-
-## We will not tolerate harassment of any kind, including but not limited to:
-
- * Harassing comments
- * Intimidation
- * Encouraging a person to engage in self-harm.
- * Sustained disruption or derailing of threads, channels, lists, etc.
- * Offensive or violent comments, jokes or otherwise
- * Inappropriate sexual content
- * Unwelcome sexual or otherwise aggressive attention
- * Continued one-on-one communication after requests to cease
- * Distribution or threat of distribution of people's personally identifying
-   information, AKA “doxing”
-
-## Consequences for failing to comply with this policy
-
-Consequences for failing to comply with this policy may include, at the sole
-discretion of the Fuchsia community managers:
- * a request for an apology;
- * a private or public warning or reprimand;
- * a temporary ban from the mailing list, blog, Fuchsia repository or
-   organization, or other Fuchsia-supported communication group, including
-   loss of committer status;
- * a permanent ban from any of the above, or from all current and future
-   Fuchsia-supported or Google-supported communities, including loss of
-   committer status.
-
-Participants warned to stop any harassing behavior are expected to comply
-immediately; failure to do so will result in an escalation of consequences.
-The decisions of the Fuchsia community managers may be appealed via
-fuchsia-community-appeals@google.com.
-
-## Acknowledgements
-
-This Code of Conduct is adapted from the Chromium Code of Conduct, based on the
-Geek Feminism Code of Conduct, the Django Code of Conduct and the Geek Feminism
-Wiki "Effective codes of conduct" guide.
-
-## License
-
-This Code of Conduct is available for reuse under the Creative Commons Zero
-(CC0) license.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 160ac8c..225b97b 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,283 +1,7 @@
-Contributing Changes
-====================
+# Obsolete
 
-Fuchsia manages commits through Gerrit at
-https://fuchsia-review.googlesource.com. Not all projects accept patches;
-please see the CONTRIBUTING.md document in individual projects for
-details.
-
-## Submitting changes
-
-To submit a patch to Fuchsia, you may first need to generate a cookie to
-authenticate you to Gerrit. To generate a cookie, log into Gerrit and click
-the "Generate Password" link at the top of https://fuchsia.googlesource.com.
-Then, copy the generated text and execute it in a terminal.
-
-Once authenticated, follow these steps to submit a patch to a repo in Fuchsia:
-
-```
-# create a new branch
-git checkout -b branch_name
-
-# write some awesome stuff, commit to branch_name
-# edit some_file ...
-git add some_file
-# if specified in the repo, follow the commit message format
-git commit ...
-
-# upload the patch to Gerrit
-# `jiri help upload` lists flags for various features, e.g. adding reviewers
-jiri upload # Adds default topic - ${USER}-branch_name
-# or
-jiri upload -topic="custom_topic"
-# or
-git push origin HEAD:refs/for/master
-
-# at any time, if you'd like to make changes to your patch, use --amend
-git commit --amend
-
-# once the change is landed, clean up the branch
-git branch -d branch_name
-```
-
-See the Gerrit documentation for more detail:
-[https://gerrit-documentation.storage.googleapis.com/Documentation/2.12.3/intro-user.html#upload-change](https://gerrit-documentation.storage.googleapis.com/Documentation/2.12.3/intro-user.html#upload-change)
-
-### Commit message tags
-
-If submitting a change to Zircon, Garnet, Peridot or Topaz, include [tags] in
-the commit subject flagging which module, library, app, etc, is affected by the
-change. The style here is somewhat informal. Look at these example changes to
-get a feel for how these are used.
-
-* https://fuchsia-review.googlesource.com/c/zircon/+/112976
-* https://fuchsia-review.googlesource.com/c/garnet/+/110795
-* https://fuchsia-review.googlesource.com/c/peridot/+/113955
-* https://fuchsia-review.googlesource.com/c/topaz/+/114013
-
-Gerrit will flag your change with
-`Needs Label: Commit-Message-has-tags` if these are missing.
-
-Example:
-```
-# Ready to submit
-[parent][component] Update component in Topaz.
-Test: Added test X
-
-# Needs Label: Commit-Message-has-tags
-Update component in Topaz.
-Test: Added test X
-```
-
-### Commit message "Test:" labels
-
-Changes to Zircon, Garnet, Peridot, and Topaz require a "Test:" line in the
-commit message.
-
-We normally expect all changes that modify behavior to include a test that
-demonstrates (some aspect of) the behavior change. The test label should name
-the test that was added or modified by the change:
-
-```
-Test: SandboxMetadata.ParseRapidJson
-```
-
-Some behavior changes are not appropriate to test in an automated fashion. In
-those cases, the test label should describe the manual testing performed by the
-author:
-
-```
-Test: Manually tested that the keyboard still worked after unplugging and
-      replugging the USB connector.
-```
-
-In some cases, we are not able to test certain behavior changes because we lack
-some particular piece of infrastructure. In that case, we should have an issue
-in the tracker about creating that infrastructure and the test label should
-mention the bug number in addition to describing how the change was manually
-tested:
-
-```
-Test: Manually tested that [...]. Automated testing needs US-XXXX
-```
-
-If the change does not change behavior, the test line should indicate that you
-did not intend to change any behavior:
-
-```
-Test: No behavior change
-```
-
-If there's a test suite that validates that your change did not change behavior,
-you can mention that test suite as well:
-
-```
-Test: blobfs-test
-```
-
-Alternatively, if the change involves updating a dependency for which the commit
-queue should provide appropriate acceptance testing, the test label should defer
-to the commit queue:
-
-```
-Test: CQ
-```
-
-Syntactically, commit messages must contain one of {test, tests, tested, testing}
-followed by ':' or '='. Any case (e.g., "TEST" or "Test") works.
-
-All of these are valid:
-
-```
-TEST=msg
-
-Test:msg
-
-Testing : msg
-
-  Tested = msg
-
-Tests:
-- test a
-- test b
-```
-
-(See https://fuchsia.googlesource.com/All-Projects/+/refs/meta/config/rules.pl
-for the exact regex.)
-
-Gerrit will flag your change with `Needs Label: Commit-Message-has-TEST-line` if
-these are missing.
-
-Example:
-
-```
-# Ready to submit
-[parent][component] Update component in Topaz.
-Test: Added test X
-
-# Needs Label: Commit-Message-has-TEST-line
-[parent][component] Update component in Topaz.
-```
-
-## [Non-Googlers only] Sign the Google CLA
-
-In order to land your change, you need to sign the [Google CLA](https://cla.developers.google.com/).
-
-## [Googlers only] Issue actions
-
-Commit messages may reference issue IDs in Fuchsia's
-[issue tracker](https://fuchsia.atlassian.net/); such references will become
-links in the Gerrit UI. Issue actions may also be specified, for example to
-automatically close an issue when a commit is landed:
-
-BUG-123 #done
-
-`done` is the most common issue action, though any workflow action can be
-indicated in this way.
-
-Issue actions take place when the relevant commit becomes visible in a Gerrit
-branch, with the exception that commits under refs/changes/ are ignored.
-Usually, this means the action will happen when the commit is merged to
-master, but note that it will also happen if a change is uploaded to a private
-branch.
-
-*Note*: Fuchsia's issue tracker is not open to external contributors at this
-time.
-
-## Cross-repo changes
-
-Changes in two or more separate repos will be automatically tracked for you by
-Gerrit if you use the same topic.
-
-### Using jiri upload
-Create branch with same name on all repos and upload the changes
-```
-# make and commit the first change
-cd fuchsia/bin/fortune
-git checkout -b add_feature_foo
-* edit foo_related_files ... *
-git add foo_related_files ...
-git commit ...
-
-# make and commit the second change in another repository
-cd fuchsia/build
-git checkout -b add_feature_foo
-* edit more_foo_related_files ... *
-git add more_foo_related_files ...
-git commit ...
-
-# Upload all changes with the same branch name across repos
-jiri upload -multipart # Adds default topic - ${USER}-branch_name
-# or
-jiri upload -multipart -topic="custom_topic"
-
-# after the changes are reviewed, approved and submitted, clean up the local branch
-cd fuchsia/bin/fortune
-git branch -d add_feature_foo
-
-cd fuchsia/build
-git branch -d add_feature_foo
-```
-
-### Using Gerrit commands
-
-```
-# make and commit the first change, upload it with topic 'add_feature_foo'
-cd fuchsia/bin/fortune
-git checkout -b add_feature_foo
-* edit foo_related_files ... *
-git add foo_related_files ...
-git commit ...
-git push origin HEAD:refs/for/master%topic=add_feature_foo
-
-# make and commit the second change in another repository
-cd fuchsia/build
-git checkout -b add_feature_foo
-* edit more_foo_related_files ... *
-git add more_foo_related_files ...
-git commit ...
-git push origin HEAD:refs/for/master%topic=add_feature_foo
-
-# after the changes are reviewed, approved and submitted, clean up the local branch
-cd fuchsia/bin/fortune
-git branch -d add_feature_foo
-
-cd fuchsia/build
-git branch -d add_feature_foo
-```
-
-Multipart changes are tracked in Gerrit via topics, will be tested together,
-and can be landed in Gerrit at the same time with `Submit Whole Topic`. Topics
-can be edited via the web UI.
-
-## Changes that span repositories
-
-See [Changes that span repositories](development/workflows/multilayer_changes.md).
-
-## Resolving merge conflicts
-
-```
-# rebase from origin/master, revealing the merge conflict
-git rebase origin/master
-
-# resolve the conflicts and complete the rebase
-* edit files_with_conflicts ... *
-git add files_with_resolved_conflicts ...
-git rebase --continue
-jiri upload
-
-# continue as usual
-git commit --amend
-jiri upload
-```
-
-## Github integration
-
-While Fuchsia's code is hosted at https://fuchsia.googlesource.com, it is also
-mirrored to https://github.com/fuchsia-mirror. To ensure Fuchsia contributions
-are associated with your Github account:
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-1. [Set your email in Git](https://help.github.com/articles/setting-your-email-in-git/).
-2. [Adding your email address to your GitHub account](https://help.github.com/articles/adding-an-email-address-to-your-github-account/).
-3. Star the project for your contributions to show up in your profile's
-Contribution Activity.
diff --git a/README.md b/README.md
index afe73ff..225b97b 100644
--- a/README.md
+++ b/README.md
@@ -1,17 +1,7 @@
-# Fuchsia Documentation
+# Obsolete
 
-This `README.md` document is a top-level entry point to the Fuchsia
-documentation.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
- - [Code of conduct](CODE_OF_CONDUCT.md)
- - [Glossary](glossary.md) - definitions of commonly used terms
- - [Development](development/README.md) - instructions for building, running and
-   testing Fuchsia and software that runs on Fuchsia
- - [System](the-book/README.md) - documentation for how Fuchsia works
- - [Repository map](map.md)
- - [Contributing changes](CONTRIBUTING.md)
-
-Other files in this repository are **system-wide** documentation articles for
-Fuchsia. **Individual subprojects** have their own documentation within each
-project repository. The articles above link to Individual documents both within
-the system-wide repository and within Individual project repositories.
diff --git a/best-practices/documentation_standards.md b/best-practices/documentation_standards.md
index 22780ed..225b97b 100644
--- a/best-practices/documentation_standards.md
+++ b/best-practices/documentation_standards.md
@@ -1,114 +1,7 @@
-# Documentation Standards
+# Obsolete
 
-A document about what to document and how to document it for people who create
-things that need documentation.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-## Why document?
-
-Fuchsia is a new operating system.  As it grows and new people join the project
-so grows the need to provide effective documentation resources.
-
-## Who is the audience?
-
-The documentation described here is intended to address a technical audience,
-i.e. those who expect to implement or exercise APIs or understand the internal
-dynamics of the operating system.  These standards are not intended for
-end-user product documentation.
-
-## What should I document?
-
-In brief, document your interfaces, introduce essential concepts, explain how
-everything fits together.
-
-- Conventions: e.g. this document about documentation, code style
-- System Design: e.g. network stack, compositor, kernel, assumptions
-- APIs: e.g. FIDL interfaces, library functions, syscalls
-- Protocols: e.g. schemas, encodings, wire formats, configuration files
-- Tools: e.g. `bootserver`, `netcp`, `fx`
-- Workflows: e.g. environment set up, test methodologies, where to find various
-  parts, how to get work done
-
-## Where should I put documents?  What goes where?
-
-Keep your documentation assets in the source tree near the things they
-describe.  Where this should go depends on the type of document and its topic.
-(See following sections for details.)
-
-### Prose Documentation
-
-Prose documentation is especially effective at explaining big ideas and
-demonstrating how to perform particular tasks.  It's great for documenting
-system design, protocols, tools, conventions, workflows, and tutorials.
-
-Prose documentation should be written in Markdown format and published as a
-file with the extension `.md` in the source repository.
-
-Preferred locations:
-
-- Documents about a specific project should go into the `docs` folder at the
-  root of that project's repository and be arranged by topic.
-  e.g. `//apps/my-project/docs/my-feature.md`
-- Documents about Fuchsia as a whole should go into the top-level `docs`
-  repository itself.  e.g. `//docs/build_packages.md`
-
-Alternate locations:
-
-- Adding a `README.md` to the root of a project's repository may serve as a
-  brief orientation to the project for first time visitors but this is not
-  required.
-
-Tips for writing effective prose documentation:
-
-- Write plain English text.
-- Optimize the experience of first time readers.
-- Give each document a clear title.
-- Briefly describe the purpose and underlying assumptions of each part.
-- Be sure to define your jargon; refrain from excess abbreviations.
-- Include links to other relevant documentation.
-- Stay on topic.
-- Use section headers to organize ideas.
-- Keep the tone informal.
-- Don't restate API documentation which is already published elsewhere (e.g. as
-  documentation comments)
-
-### Documentation Comments
-
-Documentation comments are especially effective at describing the purpose of
-interfaces, structures, methods, data types, and other elements of program
-code.
-
-Documentation comments should be applied consistently to all public APIs since
-they are a valuable asset for SDK consumers.
-
-Tips for writing effective documentation comments:
-
-- Write plain English text.
-- Write complete sentences and paragraphs.
-- Keep comments clear and brief, no more than a few sentences.
-- Follow the approved style guide for your programming language.
-- Always add value; don't restate what is already indicated by the type
-  signature.
-- Describe units of measure and integrity constraints of variables.
-- Link to prose documentation for more elaborate descriptions of how APIs fit
-  together as a whole.
-
-### Breadcrumbs
-
-Documentation is only useful when your audience can find it.  Adding links to
-or from existing documentation artifacts greatly improves the chances that
-someone will read it.
-
-Tips for leaving breadcrumbs:
-
-- Top-down linkage: Add links from more broadly scoped documents to more
-  detailed documents to help readers learn more about particular topics.  The
-  [Fuchsia book](../the-book/README.md) is a good starting point for top-down
-  linkage.
-- Bottom-up linkage: Add links from more detailed documents to more broadly
-  scoped documents to help readers develop more awareness of the overall
-  context of the topics being discussed.  Adding links from module, class, or
-  interface level documentation comments to higher level prose documentation
-  overviews can be particularly effective.
-- Sideways linkage: Add links to documents in related subject domains with
-  which a reader should familiarize themselves in order to better understand
-  the content of your document.
diff --git a/development/README.md b/development/README.md
index ce84554..225b97b 100644
--- a/development/README.md
+++ b/development/README.md
@@ -1,86 +1,7 @@
-# Development
+# Obsolete
 
-This document is a top-level entry point to all of Fuchsia documentation related
-to **developing** Fuchsia and software running on Fuchsia.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-## Developer workflow
-
-This sections describes the workflows and tools for building, running, testing
-and debugging Fuchsia and programs running on Fuchsia.
-
- - [Getting started](../getting_started.md) - **start here**. This document
-   covers getting the source, building and running Fuchsia.
- - [Source code](source_code/README.md)
- - [Multiple device setup](workflows/multi_device.md)
- - [Pushing a package](workflows/package_update.md)
- - [Changes that span layers](workflows/multilayer_changes.md)
- - [Debugging](workflows/debugging.md)
- - [Tracing][tracing]
- - [Trace-based Benchmarking][trace_based_benchmarking]
- - [LibFuzzer-based fuzzing](workflows/libfuzzer.md)
- - [Build system](build/README.md)
- - [Workflow FAQ](workflows/workflow_faq.md)
- - [Testing FAQ](workflows/testing_faq.md)
-
-## Languages
-
- - [C/C++](languages/c-cpp/README.md)
- - [Dart](languages/dart/README.md)
- - [FIDL](languages/fidl/README.md)
- - [Go](languages/go/README.md)
- - [Rust](languages/rust/README.md)
- - [Python](languages/python/README.md)
- - [Flutter modules](languages/dart/mods.md) - how to write a graphical module
-   using Flutter
-
-## API
-
- - [Council](api/council.md) - Definition of the API council
- - [System](api/system.md) - Rubric for designing the Zircon System Interface
- - [FIDL](api/fidl.md) - Rubric for designing FIDL protocols
- - [C](api/c.md) - Rubric for designing C library interfaces
- - [Tools](api/tools.md) - Rubrics for designing developer tools
- - [Devices](api/device_interfaces.md) - Rubric for designing device interfaces
-
-## ABI
-
- - [System](abi/system.md) - Describes scope of the binary-stable Fuchsia System Interface
-
-## SDK
-
- - [SDK](sdk/README.md) - information about developing the Fuchsia SDK
-
-## Hardware
-
-This section covers Fuchsia development hardware targets.
-
- - [Acer Switch Alpha 12][acer_12]
- - [Intel NUC][intel_nuc] (also [this](hardware/developing_on_nuc.md))
- - [Pixelbook](hardware/pixelbook.md)
-
-## Testing
-
- - [Testing components](tests/test_component.md)
-
-## Conventions
-
-This section covers Fuchsia-wide conventions and best practices.
-
- - [Layers](source_code/layers.md) - the Fuchsia layer cake, ie. how Fuchsia
-   subsystems are split into a stack of layers
- - [Repository structure](source_code/layer_repository_structure.md) - standard way
-   of organizing code within a Fuchsia layer repository
- - [Documentation standards](/best-practices/documentation_standards.md)
-
-## Miscellaneous
-
- - [CTU analysis in Zircon](workflows/ctu_analysis.md)
- - [Persistent disks in QEMU](workflows/qemu_persistent_disk.md)
- - [Tracing tutorial](tracing/tracing-tutorial.md)
-
-
-[acer_12]: https://fuchsia.googlesource.com/zircon/+/master/docs/targets/acer12.md "Acer 12"
-[intel_nuc]: https://fuchsia.googlesource.com/zircon/+/master/docs/targets/nuc.md "Intel NUC"
-[pixelbook]: hardware/pixelbook.md "Pixelbook"
-[tracing]: https://fuchsia.googlesource.com/garnet/+/master/docs/tracing_usage_guide.md
-[trace_based_benchmarking]: benchmarking/trace_based_benchmarking.md
diff --git a/development/abi/drivers.md b/development/abi/drivers.md
index cc315e3..225b97b 100644
--- a/development/abi/drivers.md
+++ b/development/abi/drivers.md
@@ -1,3 +1,7 @@
-# Drivers ABI
+# Obsolete
 
-TODO...
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
+
diff --git a/development/abi/system.md b/development/abi/system.md
index 8649535..225b97b 100644
--- a/development/abi/system.md
+++ b/development/abi/system.md
@@ -1,243 +1,7 @@
-# Fuchsia System Interface
+# Obsolete
 
-## Overview
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-The *Fuchsia System Interface* is the binary interface that the Fuchsia
-operating system presents to software it runs. The foundation of the interface
-is the vDSO, which provides access to the system calls. Programs are not allowed
-to issue system calls directly (e.g., by trapping into the kernel). Instead,
-programs use the vDSO to interface with the kernel.
-
-The bulk of the system interface is provided through inter-process
-communication protocols, typically defined using FIDL. These protocols are
-spoken over various kernel primitives, including channels and sockets.
-
-The `fuchsia.io` FIDL library provides protocols for file and directory
-operations. Fuchsia uses the `fuchsia.io` protocols to provide a namespace to
-components through which components can access system services and resources.
-The names in these namespaces follow certain conventions, which are part of the
-system ABI. See [namespaces](../../the-book/namespaces.md) for more details.
-
-Packages themselves also provide an interface to the system in terms of
-directory structure and file formats. The system uses this information to
-initialize processes in which components stored in these packages execute.
-
-## Terminology
-
-The *Application Programming Interface* (API) for a system is the source-level
-interface to the system. Developers typically write software that uses this
-interface directly. Changes to the system API might require developers to update
-their source code to account for the changes to the API.
-
-The *Application Binary Interface* (ABI) for a system is the binary-level
-interface to the system. Developers do not typically write software that uses
-this interface directly. Instead, they write software against the system API.
-Instead, when that software is compiled, the binary artifact created by the
-compiler interfaces with the system through the system ABI. Changes to the
-system ABI might require the developer to recompile their source code to account
-for the changes to the ABI.
-
-## ABI Surfaces
-
-This section describes the various ABI surfaces for Fuchsia components. The ABI
-for drivers is described in [drivers.md](drivers.md).
-
-### vDSO
-
-The vDSO is a virtual shared library that provides access to the kernel.
-Concretely, the vDSO is an ELF shared library, called `libzircon.so`, that
-exports a number of symbols with a C calling convention. The source of truth for
-these symbols is
-[syscalls.abigen](https://fuchsia.googlesource.com/zircon/+/master/system/public/zircon/syscalls.abigen).
-Their semantics are described in
-[the documentation](https://fuchsia.googlesource.com/zircon/+/master/docs/syscalls/).
-
-Of particular importance are the semantics of the clocks defined by
-`libzircon.so`. The semantics of these clocks are described by
-[clock_get.md](https://fuchsia.googlesource.com/zircon/+/master/docs/syscalls/clock_get.md#supported-clock-ids)
-
-### FIDL protocols
-
-The bulk of the system interfaces are defined in the Fuchsia Interface
-Definition Language (FIDL). The FIDL compiler produce language specific APIs and
-runtime libraries, referred to as FIDL bindings, for a variety of target
-languages. These bindings provide an idiomatic interface for sending and
-receiving interprocess communication messages over Zircon channels (and other
-primitives).
-
-#### Wire format
-
-The FIDL interface definitions themselves and the language-specific bindings
-generated by the compiler are part of the system *API* but not part of the
-system *ABI*. Instead, the format of the serialized messages, called the *wire
-format*, comprises the ABI. The FIDL wire format is defined by the
-[specification](../languages/fidl/reference/wire-format/index.md).
-
-#### User signals
-
-In addition to the messages sent, some FIDL protocols make use of user signals
-on the underlying kernel objects. Currently, these signals are not declared in
-FIDL. Typically, the semantics of any associated user signals are documented
-in prose in comments in the FIDL definitions.
-
-### Namespace conventions
-
-When run, components are given an *incoming namespace* and serve an
-*outgoing namespace*. The names in these namespaces follow certain
-conventions, which are are part of the system ABI.
-
-#### Incoming namespace
-
-A component's incoming namespace is provided to a component during startup and
-lets the component interact with the rest of the system. The names in the
-namespace follow certain conventions. Many of the namespace entries provide
-access to well-known protocols, most of which are defined by FIDL. For example,
-the component can access services through the `svc` entry in this namespace,
-which conventionally contains services listed by their fully qualified discovery
-name. Similarly, by convention, the `pkg` entry in this namespace is mapped to
-the package from which the component was run.
-
-#### Outgoing namespace
-
-A component can serve an outgoing namespace that lets the system and other
-components interact with the component. For example, the component exposes
-services for other components using the `public` entry in this namespace.
-Similarly, the component exposes debugging interfaces through the `debug` entry
-in this namespace.
-
-#### Data formats
-
-In addition to services, some namespaces include files with data. The data
-format used by these files is also part of the system ABI. For example,
-components access the root certificates through a namespace entry that contains
-a `certs.pem` file. The `pem` data format is therefore part of the system ABI.
-
-### Package conventions
-
-Fuchsia packages have a directory structure that follows certain naming
-conventions. These conventions are also part of the system ABI. This section
-gives two examples of important packaging conventions.
-
-#### meta
-
-By convention, the `meta` directory in a package contains metadata files that
-describe the package. The structure of this metadata, include the data formats
-used by these files, are part of the system ABI.
-
-#### lib
-
-By convention, the `lib` directory in a package contains the shared libraries
-used by components in the package. When the system runs an executable from the
-package, requests for shared libraries are resolved relative to this `lib`
-directory.
-
-One important difference between Fuchsia and other operating systems is that the
-shared libraries themselves are provided by the package creator rather than the
-system itself. For that reason, the shared libraries themselves (including
-`libc`) are not part of the system ABI.
-
-The system does provide two shared libraries: the [vDSO](#vdso) and the
-[Vulkan ICD](#vulkan-icd). See those sections for details.
-
-### Process structure
-
-Processes on Fuchsia are fairly flexible and largely under the control of the
-executable running in the process, but some of the initial structure of the
-process is controlled by the system and part of the system ABI.
-
-For additional details, see
-[Program Loading](https://fuchsia.googlesource.com/zircon/+/master/docs/program_loading.md).
-
-#### ELF loader
-
-Fuchsia uses the ELF data format for executables. When loading an executable
-into a process, the loader parses contents of the executable as ELF. The loader
-reads the `INTERP` directive from the executable and resolves that name as a
-file in the `lib` directory of the package that contained the executable. The
-loader then parses the contents of the `INTERP` file as an ELF shared library,
-relocates the library, and maps the library into the newly created process.
-
-#### Startup message
-
-As part of starting a process, the creator of the process supplies the process
-with a message that contains, for example, the command line arguments, the
-`environ`, the initial handles, and the incoming namespace for the process.
-(The outgoing namespace is included in the set of initial handles for the
-process.)
-
-The format of this message, including length limitations on fields such as the
-command line arguments and the `environ`, are part of the system ABI, as are
-the conventions around the contents of the message. For example, by convention,
-the `PWD` environment variable is the name the creator suggests the process use
-as its current working directory.
-
-The initial handles are associated with numerical identifiers. The conventions
-around these identifiers are part of the system ABI. For example, by convention,
-the `PA_PROC_SELF` handle is a handle to the process object for the newly
-created process. In addition to the types of these handles, the rights
-associated with these handles are also part of the system ABI.
-
-#### VMAR structure
-
-Before starting a process, the creator modifies the root VMAR for the process.
-For example, the creator maps the vDSO and allocates a stack for the initial
-thread. The structure of the VMAR when the process is started is part of the
-system ABI.
-
-#### Job policy
-
-Processes are run in jobs, which can apply policy to the processes and jobs they
-contain. The job policy applied to processes is part of the system ABI. For
-example, components run in processes with `ZX_POL_NEW_PROCESS` set to
-`ZX_POL_ACTION_DENY`, which forces components to use the
-`fuchsia.process.Launcher` service to create processes rather than issuing the
-`zx_process_create` system call directly.
-
-### Vulkan ICD
-
-Components that use the Vulkan API for hardware accelerated graphics link
-against `libvulkan.so` and specify the `vulkan` feature in their manifests. This
-library is provided by the package that contains the component and therefore is
-not part of the system ABI. However, `libvulkan.so` loads another shared
-library, called the *Installable Client Driver* (ICD). The Vulkan ICD is loaded
-using `fuchsia.vulkan.loader.Loader`, which means the library is provided by the
-system itself rather than the package that contains the component. For this
-reason, the Vulkan ICD is part of the system ABI.
-
-The Vulkan ICD is an ELF shared library that exports exactly two symbols:
-
- * `vk_icdGetInstanceProcAddr`
- * `vk_icdNegotiateLoaderICDInterfaceVersion`
-
-These symbols are reserved for use by the Vulkan ICD and should not be used
-directly. In addition, the Vulkan ICD has a `NEEDED` section that lists several
-shared libraries upon which the Vulkan ICD depends. The package containing the
-component is required to provide these shared libraries.
-
-The Vulkan ICD also imports a number of symbols. The conventions around these
-imported symbols, for example their parameters and semantics, are part of the
-system ABI.
-
-Currently, the `NEEDED` section and the list of imported symbols for the Vulkan
-ICD are both larger than we desire. Hopefully we will be able to minimize these
-aspects of the system ABI.
-
-### Sockets
-
-#### Control channel
-
-Some socket objects have an associated control plane. The protocol used by that
-control plane is also part of the system ABI.
-
-#### Datagram framing
-
-Datagram sockets used for networking include a frame that specifies the network
-address associated with the datagram. This frame is also part of the system ABI.
-
-### Terminal protocol
-
-Programs that run in the terminal communicate with the terminal using the
-Fuchsia Terminal Protocol, which is a text-based protocol similar to `vt100`.
-This protocol is also exposed over the network through `ssh`, both by clients
-that expect incoming `ssh` connections to support this protocol and by servers
-that expect outgoing `ssh` connections to support this protocol.
diff --git a/development/api/README.md b/development/api/README.md
index a835e87..225b97b 100644
--- a/development/api/README.md
+++ b/development/api/README.md
@@ -1,27 +1,7 @@
-# API Development
+# Obsolete
 
-This document is a top-level entry point to documentation related to developing
-APIs for Fuchsia.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-## What this covers
-
-Although the documentation in this directory applies to all Fuchsia APIs, it
-will be enforced for the _public facing surface area_ of Fuchsia: the Fuchsia
-APIs that are surfaced to developers via SDK releases.  All public facing API
-changes will be reviewed by the [API Council][council.md] for consistency with
-these guidelines.
-
-## Rubrics
-
-The documentation in this directory comes in the form of _rubrics_, which are
-established protocols for how to design and build APIs.  Note that the list
-below is not complete: as Fuchsia evolves, more rubrics will be added.
-
- * [API Documentation](documentation.md)
- * [CLI and GUI tools](tools.md)
- * Languages
-   * [C API Readability](c.md)
-   * [FIDL API Readability](fidl.md)
- * Domain-specific areas
-   * [Zircon System Interface](system.md)
-   * [Fuchsia Device Interface](device_interfaces.md)
diff --git a/development/api/c.md b/development/api/c.md
index 6783cf6..225b97b 100644
--- a/development/api/c.md
+++ b/development/api/c.md
@@ -1,474 +1,7 @@
-# C Library Readability Rubric
+# Obsolete
 
-This document describes heuristics and rules for writing C libraries
-that are published in the Fuchsia SDK.
-
-A different document will be written for C++ libraries. While C++ is
-almost an extension of C, and has some influence in this document, the
-patterns for writing C++ libraries will be quite different than for C.
-
-Most of this document is concerned with the description of an
-interface in a C header. This is not a full C style guide, and has
-little to say about the contents of C source files. Nor is this a
-documentation rubric (though public interfaces should be well
-documented).
-
-Some C libraries have external constraints that contradict these
-rules. For instance, the C standard library itself does not follow
-these rules. This document should still be followed where applicable.
-
-[TOC]
-
-## Goals
-
-### ABI Stability
-
-Some Fuchsia interfaces with a stable ABI will be published as C
-libraries. One goal of this document is to make it easy for Fuchsia
-developers to write and to maintain a stable ABI. Accordingly, we
-suggest not using certain features of the C language that have
-potentially surprising or complicated implications on the ABI of an
-interface. We also disallow nonstandard compiler extensions, since we
-cannot assume that third parties are using any particular compiler,
-with a handful of exceptions for the DDK described below.
-
-### Resource Management
-
-Parts of this document describe best practices for resource management
-in C. This includes resources, Zircon handles, and any other type of
-resource.
-
-### Standardization
-
-We would also like to adopt reasonably uniform standards for Fuchsia C
-libraries. This is especially true of naming schemes. Out parameter
-ordering is another example of standardization.
-
-### FFI Friendliness
-
-Some amount of attention is paid to Foreign Function Interface (FFI)
-friendliness. Many non-C languages support C interfaces. The
-sophistication of these FFI systems varies wildly, from essentially
-sed to sophisticated libclang-based tooling. Some amount of
-consideration of FFI friendliness went into these decisions.
-
-## Language versions
-
-### C
-
-Fuchsia C libraries are written against the C11 standard (with a small
-set of exceptions, such as unix signal support, that are not
-particularly relevant to our C library ABI). C99 compliance is not a
-goal.
-
-In particular, Fuchsia C code can use the `<threads.h>` and
-`<stdatomic.h>` headers from the C11 standard library, as well as the
-`_Thread_local` and alignment language features.
-
-The thread locals should use the `thread_local` spelling from
-`<threads.h>`, rather than the built in `_Thread_local`. Similarly,
-prefer `alignas` and `alignof` from `<stdalign.h>`, rather than
-`_Alignas` and `_Alignof`.
-
-Note that compilers support flags which may alter the ABI of the
-code. For instance, GCC has a `-m96bit-long-double` flag which alters
-the size of a long double. We assume that such flags are not used.
-
-Finally, some libraries (such as Fuchsia's C standard library) in our
-SDK are a mix of externally defined interfaces and Fuchsia specific
-extensions. In these cases, we allow some pragmatism. For instance,
-libc defines functions like `thrd_get_zx_handle` and
-`dlopen_vmo`. These names are not strictly in accordance with the
-rules below: the name of the library is not a prefix. Doing so would
-make the names fit less well next to other functions like
-`thrd_current` and `dlopen`, and so we allow the exceptions.
-
-### C++
-
-While C++ is not an exact superset of C, we still design C libraries
-to be usable from C++. Fuchsia C headers should be compatible with the
-C++11, C++14, and C++17 standards. In particular, function
-declarations must be `extern "C"`, as described below.
-
-C and C++ interfaces should not be mixed in one header. Instead,
-create a separate `cpp` subdirectory and place C++ interfaces in their
-own headers there.
-
-## Library Layout and Naming
-
-A Fuchsia C library has a name. This name determines its include path
-(as described in the [library naming document]) as well as identifiers
-within the library.
-
-In this document, the library is always named `tag`, and is variously
-referred to as `tag` or `TAG` or `Tag` or `kTag` to reflect a
-particular lexical convention. The `tag` should be a single identifier
-without underscores. The all-lowercase form of a tag is given by the
-regular expression `[a-z][a-z0-9]*`.  A tag can be replaced by a shorter
-version of the library name, for example `zx` instead of `zircon`.
-
-The include path for a header `foo.h`, as described by the [library
-naming document], should be `lib/tag/foo.h`.
-
-## Header Layout
-
-A single header in a C library contains a few kinds of things.
-
-- A copyright banner
-- A header guard
-- A list of file inclusions
-- Extern C guards
-- Constant declarations
-- Extern symbol declarations
-  - Including extern function declarations
-- Static inline functions
-- Macro definitions
-
-### Header Guards
-
-Use #ifndef guards in headers. These look like:
-
-```C
-#ifndef SOMETHING_MUMBLE_H_
-#define SOMETHING_MUMBLE_H_
-
-// code
-// code
-// code
-
-#endif // SOMETHING_MUMBLE_H_
-```
-
-The exact form of the define is as follows:
-- Take the canonical include path to the header
-- Replace all ., /, and - with _
-- Convert all letters to UPPERCASE
-- Add a trailing _
-
-For example, the header located in the SDK at `lib/tag/object_bits.h`
-should have a header guard `LIB_TAG_OBJECT_BITS_H_`.
-
-### Inclusions
-
-Headers should include what they use. In particular, any public header
-in a library should be safe to include first in a source file.
-
-Libraries can depend on the C standard library headers.
-
-Some libraries may also depend on a subset of POSIX headers. Exactly
-which are appropriate is pending a forthcoming libc API review.
-
-### Constant Definitions
-
-Most constants in a library will be compile-time constants, created
-via a `#define`. There are also read-only variables, declared via
-`extern const TYPE NAME;`, as it sometimes is useful to have storage
-for a constant (particularly for some forms of FFI). This section
-describes how to provide compile time constants in a header.
-
-There are several types of compile time constants.
-
-- Single integer constants
-- Enumerated integer constants
-- Floating point constants
-
-#### Single integer constants
-
-A single integer constants has some `NAME` in a library `TAG`, and its
-definition looks like the following.
-
-```C
-#define TAG_NAME EXPR
-```
-
-where `EXPR` has one of the following forms (for a `uint32_t`)
-
-- `((uint32_t)23)`
-- `((uint32_t)0x23)`
-- `((uint32_t)(EXPR | EXPR | ...))`
-
-#### Enumerated integer constants
-
-Given an enumerated set of integer constants named `NAME` in a library
-`TAG`, a related set of compile-time constants has the following parts.
-
-First, a typedef to give the type a name, a size, and a
-signedness. The typedef should be of an explicitly sized integer
-type. For example, if `uint32_t` is used:
-
-```C
-typedef uint32_t tag_name_t;
-```
-
-Each constant then has the form
-
-```C
-#define TAG_NAME_... EXPR
-```
-
-where `EXPR` is one of a handful of types of compile-time integer
-constants (always wrapped in parentheses):
-
-- `((tag_name_t)23)`
-- `((tag_name_t)0x23)`
-- `((tag_name_t)(TAG_NAME_FOO | TAG_NAME_BAR | ...))`
-
-Do not include a count of values, which is difficult to maintain as
-the set of constants grows.
-
-#### Floating point constants
-
-Floating point constants are similar to single integer constants,
-except that a different mechanism is used to describe the type. Float
-constants must end in `f` or `F`; double constants have no suffix;
-long double constants must end in `l` or `L`. Hexadecimal versions of
-floating point constants are allowed.
-
-```C
-// A float constant
-#define TAG_FREQUENCY_LOW 1.0f
-
-// A double constant
-#define TAG_FREQUENCY_MEDIUM 2.0
-
-// A long double constant
-#define TAG_FREQUENCY_HIGH 4.0L
-```
-
-### Function Declarations
-
-Function declarations should all have names beginning with `tag_...`.
-
-Function declarations should be placed in `extern "C"` guards. These
-are canonically provided by using the `__BEGIN_CDECLS` and
-`__END_CDECLS` macros from [compiler.h].
-
-#### Function parameters
-
-Function parameters must be named. For example,
-
-```C
-// Disallowed: missing parameter name
-zx_status_t tag_frob_vmo(zx_handle_t, size_t num_bytes);
-
-// Allowed: all parameters named
-zx_status_t tag_frob_vmo(zx_handle_t vmo, size_t num_bytes);
-```
-
-It should be clear which parameters are consumed and which are
-borrowed. Avoid interfaces in which clients may or may not own a
-resource after a function call. If this is infeasible, consider noting
-the ownership hazard in the name of the function, or one of its
-parameters. For example:
-
-```C
-zx_status_t tag_frobinate_subtle(zx_handle_t foo);
-zx_status_t tag_frobinate_if_frobable(zx_handle_t foo);
-zx_status_t tag_try_frobinate(zx_handle_t foo);
-zx_status_t tag_frobinate(zx_handle_t maybe_consumed_foo);
-```
-
-By convention, out parameters go last in a function's signature, and
-should be named `out_*`.
-
-#### Variadic functions
-
-Variadic functions should be avoided for everything except printf-like
-functions. Those functions should document their format string
-contract with the `__PRINTFLIKE` attribute from [compiler.h].
-
-#### Static inline functions
-
-Static inline functions are allowed, and are preferable to
-function-like macros. Inline-only (that is, not also `static`) C
-functions have complicated linkage rules and few use cases.
-
-### Types
-
-Prefer explicitly sized integer types (e.g. `int32_t`) to
-non-explicitly sized types (e.g. `int` or `unsigned long int`). An
-exemption is made for `int` when referring to POSIX file descriptors,
-and for typedefs like `size_t` from the C or POSIX headers.
-
-When possible, pointer types mentioned in interfaces should refer to
-specific types. This includes pointers to opaque structs. `void*` is
-acceptable for referring to raw memory, and to interfaces that pass
-around opaque user cookies or contexts.
-
-#### Opaque/Explicit types
-
-Defining an opaque struct is preferable to using `void*`. Opaque
-structs should be declared like:
-
-```C
-typedef struct tag_thing tag_thing_t;
-```
-
-Exposed structs should be declared like:
-
-```C
-typedef struct tag_thing {
-} tag_thing_t;
-```
-
-#### Reserved fields
-
-Any reserved fields in a struct should be documented as to the purpose
-of the reservation.
-
-A future version of this document will give guidance as to how to
-describe string parameters in C interfaces.
-
-#### Anonymous types
-
-Top-level anonymous types are not allowed. Anonymous structures and
-unions are allowed inside other structures, and inside function
-bodies, as they are then not part of the top level namespace. For
-instance, the following contains an allowed anonymous union.
-
-```C
-typedef struct tag_message {
-    tag_message_type_t type;
-    union {
-        message_foo_t foo;
-        message_bar_t bar;
-    };
-} tag_message_t;
-```
-
-#### Function typedefs
-
-Typedefs for function types are permitted.
-
-Functions should not overload return values with a `zx_status_t` on
-failure and a positive success value. Functions should not overload
-return values with a `zx_status_t` that contains additional values not
-described in [zircon/errors.h].
-
-#### Status return
-
-Prefer `zx_status_t` as a return value to describe errors relating to
-Zircon primitives and to I/O.
-
-## Resource Management
-
-Libraries can traffic in several kinds of resources. Memory and Zircon
-handles are examples of resources common across many
-libraries. Libraries may also define their own resources with
-lifetimes to manage.
-
-Ownership of all resources should be unambiguous. Transfer of
-resources should be explicit in the name of a function. For example,
-`create` and `take` connote a function transferring ownership.
-
-Libraries should be memory tight. Memory allocated by a function like
-`tag_thing_create` should released via `tag_thing_destroy` or some
-such, not via `free`.
-
-Libraries should not expose global variables. Instead, provide
-functions to manipulate that state. Libraries with process-global
-state must be dynamically linked, not statically. A common pattern is
-to split a library into a stateless static part, containing almost all
-of the code, and a small dynamic library holding global state.
-
-In particular, the `errno` interface (which is a global thread-local
-global) should be avoided in new code.
-
-## Linkage
-
-The default symbol visibility in a library should be hidden. Use
-either a whitelist of exported symbols, or explicit visibility
-annotations, on symbols to exported.
-
-C libraries must not export C++ symbols.
-
-## Evolution
-
-### Deprecation
-
-Deprecated functions should be marked with the __DEPRECATED attribute
-from [compiler.h]. They should also be commented with a description
-about what to do instead, and a bug tracking the deprecation.
-
-## Disallowed or Discouraged Language Features
-
-This section describes language features that cannot or should not be
-used in the interfaces to Fuchsia's C libraries, and the rationales
-behind the decisions to disallow them.
-
-### Enums
-
-C enums are banned. They are brittle from an ABI standpoint.
-
-- The size of integer used to represent a constant of enum type is
-  compiler (and compiler flag) dependent.
-- The signedness of an enum is brittle, as adding a negative value to
-  an enumeration can change the underlying type.
-
-### Bitfields
-
-C's bitfields are banned. They are brittle from an ABI standpoint, and
-have a lot of nonintuitive sharp edges.
-
-Note that this applies to the C language feature, not to an API which
-exposes bit flags. The C bitfield feature looks like:
-
-```C
-typedef struct tag_some_flags {
-    // Four bits for the frob state.
-    uint8_t frob : 4;
-    // Two bits for the grob state.
-    uint8_t grob : 2;
-} tag_some_flags_t;
-```
-
-We instead prefer exposing bit flags as compile-time integer
-constants.
-
-### Empty Parameter Lists
-
-C allows for function `with_empty_parameter_lists()`, which are
-distinct from `functions_that_take(void)`. The first means "take any
-number and type of parameters", while the second means "take zero
-parameters". We ban the empty parameter list for being too dangerous.
-
-### Flexible Array Members
-
-This is the C99 feature which allows declaring an incomplete array as
-the last member of a struct with more than one parameter. For example:
-
-```C
-typedef struct foo_buffer {
-    size_t length;
-    void* elements[];
-} foo_buffer_t;
-```
-
-As an exception, DDK structures are allowed to use this pattern when
-referring to an external layout that fits this header-plus-payload
-pattern.
-
-The similar GCC extension of declaring a 0-sized array member is
-similarly disallowed.
-
-### Module Maps
-
-These are a Clang extension to C-like languages which attempt to solve
-many of the issues with header-driven compilation. While the Fuchsia
-toolchain team is very likely to invest in these in the future, we
-currently do not support them.
-
-### Compiler Extensions
-
-These are, by definition, not portable across toolchains.
-
-This in particular includes packed attributes or pragmas, with one
-exception for the DDK.
-
-DDK structures often reflect an external layout that does not match
-the system ABI. For instance, it may refer to an integer field that is
-less aligned than required by the language. This can be expressed via
-compiler extensions such as pragma pack.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-[compiler.h]: https://fuchsia.googlesource.com/zircon/+/master/system/public/zircon/compiler.h
-[library naming document]: ../languages/c-cpp/naming.md
diff --git a/development/api/cli.md b/development/api/cli.md
index 111ce3f..225b97b 100644
--- a/development/api/cli.md
+++ b/development/api/cli.md
@@ -1,673 +1,7 @@
-# Command-line Tools Rubric
+# Obsolete
 
-
-## Overview
-
-This document is for command line interface (CLI) tools. Graphical User
-Interfaces (GUI) are out of scope.
-
-When developing tools for Fuchsia there are specific features and styles that
-will be used to create consistency. This document walks through those
-requirements.
-
-The goal is to maintain a uniform fit and finish for Fuchsia developer tools so
-that developers can know what to expect. They can most easily see how to
-accomplish common tasks and there is a well lit path to discover rarer used
-tools.
-
-
-## Guide
-
-The experience developers have writing software for Fuchsia will impact their
-general feelings toward writing for the platform and our tools are a significant
-part of that experience. Providing tools that are inconsistent (with one
-another) creates a poor developer experience.
-
-This guide provides a rubric that Fuchsia tools must follow.
-
-> **SDK**
->
-> Some sections have an "SDK" call-out, like this one. These detail specific
-> rules that apply to tools included with the SDK distribution.
-
-## Considerations
-
-Before embarking on the creation of a new tool, consider these factors to
-determine if the tool is a good fit for Fuchsia or the Fuchsia SDK.
-
-> **SDK**
->
-> SDK tools are specific to Fuchsia in some way. Generic tools or tools that are
-> widely available should not be part of Fuchsia and will not be included in the
-> Fuchsia SDK. For example, a tool that verifies generic JSON files would not be
-> a good addition. However a tool that verifies Fuchsia `.cmx` files, which
-> happen to use the JSON format, would be okay.
-
-### Audience
-
-Tools may be used for different development tasks. On a large team these roles
-may be separate people. Some categories are:
-- Component development (mods/agents)
-- Driver development (DDK)
-- Fuchsia development (SDK)
-- Build integration (Blaze, Bazel, etc.)
-- Quality assurance (QA)
-- System integrators (e.g., on-device network tools)
-- Publishing (from dev host to server)
-- Deployment (from server to customers)
-
-Consider which users may use a tool and cater the tool to the audience.
-
-Tools may have different integration expectations. For example, a developer
-doing mod development may expect tools to integrate with their Integrated
-Development Environment (IDE), while a build integration tool may be called from
-a script.
-
-### Grouping Related Tools
-
-Prefer to put related commands under a common tool, i.e. like `git` and `fx` do.
-This helps encourage the team toward a shared workflow and provides a point of
-discovery.
-
-Prefer subcommands to multiple tools. E.g. don't create tools with hyphenated
-names like `package-create` and `package-publish`, instead create a `package`
-command that accepts create and publish subcommands.
-
-Keep the number of commands under a tool organized and reasonable. I.e. avoid
-adding unrelated commands to a tool and provide sensible organization of the
-commands in the help and documentation.
-
-### Scope of Work
-
-Command line tools can be divided into two groups: simple single purpose tools
-and larger more featureful tools. Create tools that are ergonomic for their
-purpose. Simple tools should be quick to start up, while more complex tools will
-lean toward the more featureful.
-
-Larger tools will encompass an entire task at the user (developer) level. Avoid
-making a tool that accomplishes one small step of a task; instead make a tool
-that will perform a complete task.
-
-For example, when:
-- developing a C++ application: run the preprocessor, run the compiler, run the
-linker, start the built executable.
-- working on a unit test: build the tests and run the tests being worked on
-- developing a mod: compile the code, move the code and resources to the device,
-start the mod (or hot-reload)
-
-Lean toward a tool that will accomplish all the steps needed by default, but
-allow for an advanced user to do a partial step (for example, passing an
-argument to ask the C++ compiler to only run the preprocessor).
-
-> **SDK**
->
-> For SDK build integrators, separate tools. The build integrators will learn
-> each and piece them together to make a working system.
-
-#### Sharing common functionality
-
-If a small step of a task will be needed by several tools, it doesn't make sense
-to duplicate that code. Consider making a small support tool or create a library
-to share the code.
-
-Making a small tool that performs one step of the task can make sense to promote
-code reuse. If the user is not expected to run this small tool individually,
-place the support tool in a directory that is not added to the `$PATH`. I.e.
-avoid polluting the environment path unnecessarily.
-
-Providing a library to share code may be preferable, so that a subprocess isn't
-needed.
-
-
-## Implementation
-
-Here is some guidance for the nuts and bolts of creating a tool. We'll cover
-which language to write the tool in, what style to use in that language, and so
-on.
-
-### Programming Languages
-
-Tools may be written in C++, Rust, and Go. For clarity, here are some languages
-not approved: Bash, Python, Perl, JavaScript, and Dart (see exceptions below).
-
-No language is preferred between C++, Rust, and Go. The choice between these
-languages is up to the author of the tool.
-
-> **SDK**
->
-> If a given flavor of SDK includes a specific language (e.g. Dart), that
-> language may be used for tools that are distributed with that SDK. I.e. do not
-> include a Dart tool in an SDK that wouldn't otherwise include the Dart
-> runtime, but if it's already there, that's okay.
-
-### Style Guides
-
-Follow the corresponding [style guide](../README.md#languages) for the language
-and area of Fuchsia being developed.
-E.g. if the tool is included with Zircon and written
-in C++, use the style guide for C++ in Zircon. Specifically, avoid creating a
-separate style guide for tools.
-
-### Runtime Link Dependencies
-
-Try to minimize runtime link dependencies (statically link dependencies
-instead). On Linux it is acceptable to runtime link against the glibc suite of
-libraries (libm, etc.); other runtime link dependencies are not allowed.
-
-### Building from Source
-
-Keep in mind that some developers will want to build the tools from source. Use
-the same build and dependency structure as the code in the Fuchsia source tree.
-Do not make a separate system to build tools.
-
-
-## Host Platforms
-
-Keep an eye on how resource heavy a tool becomes and what OSes it will be
-expected to operate on.
-
-### Run on a Variety of Hardware
-
-Developer machines may range from a few CPU cores and moderate amount of RAM to
-dozens of CPU cores and huge amounts of RAM. Don't assume that host machines are
-very powerful or that a server cluster is available to offload work to.
-
-### Supported OSes
-
-This section is for the convenience of the reader. This document is not
-authoritative on which platforms are supported.
-
-We currently support
-- Linux
-- macOS
-
-Tools written for developers must run on those platforms. There are other
-platforms to consider, and while these are not required at this time, it's good
-to keep the platforms listed below in mind.
-
-Tools should be built in a way that makes them easy to port to the following
-platforms:
-- Fuchsia (self-hosted)
-- Windows
-
-This is not an exhaustive list, we may support others.
-
-### Case Insensitive File Systems
-
-Don't rely on case sensitivity in file paths. E.g. don't expect that `src/BUILD`
-and `src/build` are different files. Conversely, don't rely on case
-insensitivity since some platforms are case sensitive.
-
-### Development Hosts Using a Non-English Locale
-
-There are several aspects to consider for non-English developers:
-- Whether the tool itself can be localized
-- Whether the documentation for the tool can be localized
-- Whether the tool can work with path names and data that include non-ASCII
-- Whether the tool works correctly on non-English OSes
-
-Tools are provided in US English. It's not required that a tool be localized.
-(This may change in the future.)
-
-The documentation for a tool will support non-ASCII characters. Both HTML and
-Markdown can support Unicode (UTF-8) characters, so these are both good choices
-for documentation. Doing the translation is not required, merely allow for the
-possibility.
-
-Tools will function properly with file paths that contain binary sequences and
-white space. Use a library to work with file paths rather than manipulating
-paths as strings. (e.g. path.Join in Go.)
-
-Tools will operate correctly on non-English platforms (e.g. Japanese or French).
-This means handling binary (e.g. UTF-8) data without corrupting it. E.g. don't
-assume a text file is just ASCII characters.
-
-
-## Execution
-
-At runtime (or execution time) consider how the tool should behave.
-
-### Optimize for No Work Needed
-
-When appropriate, such as with a build tool, have the tool exit quickly if there
-is no work to do. If possible, go one step better by providing information to
-the caller about the dependencies so that the caller can accurately determine
-whether the tool needs to be called at all.
-
-### Command Line Arguments
-
-There are three types of command line arguments:
-- exact text
-- arguments
-- options (i.e. switches and keys)
-
-#### Exact text
-
-Exact text is placed as-is on the command line. A piece of exact text may be
-required or optional. Parsing exact text arguments should be restricted to cases
-where they are needed for disambiguation (i.e. for correctly parsing other
-arguments). For example if a `copy` command accepted multiple source and
-destination arguments, an exact text argument may be used to clarify which is
-which: `copy a b c` may be ambiguous; while `copy a to b c` may indicate that
-'`a`' is copied to two destinations.
-
-#### Arguments
-
-Arguments are like function parameters or slots for data to fit into. Often,
-their order matters. In the example `copy <from> <destination>`, both `<from>`
-and `<destination>` are ordered arguments. In cases where a single logical
-argument is repeated the order may not matter, such as remove `<files>...` where
-the tool might process the `<files>` in an arbitrary order.
-
-#### Options
-
-Some arguments are known as options. Both switches and keyed (key/value pairs)
-are options. Options tend to modify the behavior of the tool or how the tool
-processes parameter arguments. Options consist of a dash prefixed letter or
-word.
-
-Options must start with either one ('`-`') or two ('`--`') dashes followed by an
-alphanumeric label. In the case of a single dash, the length of the label must
-be 1. If the length of the label is two or more then two dashes must be used.
-For example: `-v` or `--help` are correct; `-help` is not valid.
-
-All choices are required to have a (`--`) option. Providing single character
-shorthand (`-`) is optional. E.g. it's okay to provide just `--output`, or both
-`-o` and `--output`, but it's not ok to only provide an `-o` option without a
-long option as well.
-
-Do not create numeric options, such as `-1` or `-2`. E.g. rather than having
-`-1` mean to do something once, add a `--once` option. If a numeric value is
-needed, make a keyed option, like `--repeat <number>`.
-
-One (`-`) or two (`--`) dashes on their own are special cases and are not
-allowed as a key or switch.
-
-#### Switches
-
-The presence of a switch means the feature it represents is 'on' while its
-absence means that it is 'off'. Switches default to 'off'. Unlike keyed options,
-a switch does not accept a value. E.g. `-v` is a common switch meaning verbose;
-it doesn't take a value, making it switch rather than a keyed value.
-
-All switches must be documented (hidden switches are not allowed).
-
-Running switches together is not allowed. E.g. `-xzf` or `-vv`, each must be
-separate: "`-x -z -f`" or "`-v -v`".
-
-#### Keyed Options
-
-Keyed options consist of a key and a value. Keys are similar in syntax to
-switches except that a keyed option expects a value for the key.
-E.g. `-o <my_output_file>` has a key '`-o`' and a value of '`my_output_file`'.
-
-Do not use an equals punctuation (or similar) to separate the key and value.
-E.g. do not do `-o=<my_output_file>`.
-
-Note about a rare case: Avoid making optional keys (where the value appears
-without its key) or optional values (where the key appears without its
-value). It's clearer to consider the key/value pair optional, but inseparable.
-I.e. if the key is present a value is required and vice versa. Consider making
-an argument instead of a keyed option with an optional key. E.g. rather than
-"`do_something [--config [<config_file>]]`" where not passing `[<config_file>]`
-means don't use a config file; instead do
-"`do_something [--config <config_file>|--no-config]`" where passing
-`--no-config` means don't load a config file.
-
-##### Mutually Exclusive Options
-
-Some options don't make sense with other options. We call the options mutually
-exclusive.
-
-Passing mutually exclusive options is considered a user error. When this occurs
-the tool will do one of the following:
-- Write an error message explaining the issue and exit with a non-zero result
-  code; doing no work (i.e. there was no data changed as a result of the call).
-  This is the expected handling, so no further documentation or notes are
-  required.
-- Prioritize one option over another. E.g. "`passing -z will override -y`". In
-  this case the handling will be documented in the `--help` output.
-- Other handling is possible (first takes precedence or last takes precedence or
-  something else) though this is discouraged. In this case the handling will
-  be documented in the Description, Options, ***and*** Notes; though
-  "`See Notes`" may be used in Description and Options with the full write-up in
-  `Notes`.
-
-##### Grouping Options
-
-There is no specific syntax to indicate when enabling one option will also
-affect another option. When an option implies that another option is enabled or
-disabled, specify that in the Options. E.g. "`passing -e implies -f`" means that
-if `-e` is enabled, `-f` will be enabled as if it were passed on the command
-line (regardless of whether `-f` was explicitly passed). The redundant passing
-of the implied value is harmless (not an error).
-
-##### Option Delimiter
-
-Two dashes ('`--`') on their own indicates the end of argument options. All
-subsequent values are given to the tool as-is. For example, with
-"`Usage: foo [-a] <file>`", the command line "`foo -- -a`" may interpret `-a` as
-a file name rather than a switch. Further, "`foo -a -- -a`" enables the switch
-`-a` (the first `-a`, before the `--`) and passes the literal text `-a` (the
-second `-a`).
-
-##### Repeating Options
-
-Repeating switches may be used to apply more emphasis (what more emphasis means
-is up to the tool, the description here is intentionally vague). A common
-example is increasing verbosity by passing more `-v` switches.
-
-Repeating keyed options may be used to pass multiple values to the same command.
-Often this is done to avoid calling the same command multiple times. Common
-commands that accept repeating options are `cp`, `rm`, `cat`. Care must be taken
-to ensure that repeating commands are unambiguous and clear. E.g. `cp` always
-interprets the last argument as the destination; if `cp` accepted multiple
-source and destination arguments the parsing would become ambiguous or unclear.
-
-#### Standard Input Alias
-
-In Fuchsia tools a single dash (`-`) is not interpreted as an alias to stdin. Use
-pipes to direct data into stdin or use `/dev/stdin` as an alias for stdin.
-(Note: `/dev/stdin` is not available on Fuchsia or Windows).
-
-#### Single Dash
-
-A single dash ('-') on its own is reserved for future use.
-
-#### Subcommands
-
-Tools may contain sub-command that accept independent command line arguments.
-(Similar to the `git` tool). Subcommands do not begin with any dashes. E.g. in
-`fx build` the `build` argument is a subcommand.
-
-When a tool has many subcommands, it should also have a help subcommand that
-display help about other subcommands. E.g. "`fx help build`" will provide help
-on the build subcommand.
-
-Subcommands may have their own arguments that are not handled by the main tool.
-Arguments between the tool name and the subcommand are handled by the tool and
-arguments that follow the subcommand are handled by the subcommand. E.g. in
-`fx -a build -b` the `-a` is an argument for the `fx` tool, while the `-b`
-argument is handled by the `build` subcommand.
-
-### Common Features
-
-Command line tools are expected to support some common switches:
-- `--help`
-- `--quiet`
-- `--verbose`
-- `--version`
-
-#### Interactive Help (--help)
-
-A tool must accept a `--help` switch and provide usage information to the
-command line in that case. The layout and syntax of the help text is described
-in a future document.
-
-The tool must not do other work (i.e. have side effects) when displaying help.
-
-Use a library that can parse the arguments as well as present help information
-from the same source. Doing so keeps the two in sync. I.e. avoid writing command
-line help as an independent paragraph of text.
-
-Keep the interactive help reasonably concise. Plan for a skilled reader, i.e.
-someone looking for a reminder on how to use the tool or a developer experienced
-in reading interactive help. For the novice, provide a note referring them to
-the Markdown documentation.
-
-Provide an option to generate machine parsable output.
-
-#### Verbosity (--quiet and --verbose)
-
-The `--quiet` and `--verbose` switches decrease or increase informational output
-to the user. Their implementation is optional, but all tools will accept them as
-arguments and must not use those terms for other purposes, e.g. don't use
-`--quiet` to turn off the audio output (use `--silence` or `--volume 0` or some
-other synonym).
-
-#### Interactive Version (--version)
-
-A tool must accept a `--version` switch and provide an indication of the code
-used to build the tool in that case. The layout and syntax is not specified, but
-the version will include a version number of some kind.
-
-The tool must not do other work (have side effects) when reporting its version.
-
-### Logging
-
-Logging is distinct from normal output. The audience for logging is normally the
-tool developer or a power user trying to debug an issue. Logging may go to
-stdout in special cases, such as when `--verbose` output is requested.
-
-Logging from multiple threads will not interlace words within a line, i.e. the
-minimum unit of output is a full text line. Each line will be prefixed with an
-indication of the severity of the line. The severity will be one of: detail,
-info, warning, error, fatal.
-
-## Metrics
-
-Every tool must file a Privacy Design Document (PDD) in order to collect usage
-metrics.
-
-Metrics are important to drive quality and business decisions. Questions we want
-to answer with metrics include:
-
-- Which OS are our users using? - so we know how to prioritize work for various
-  platforms
-- Which tools are they using? - so we know how to prioritize investments, and to
-  learn which workflows are currently being used so we can prioritize
-  investments or identify weak spots
-- How often do they use a tool? - so we know how to prioritize investments, and
-  to learn which workflows are currently being used so we can prioritize
-  investments or identify weak spots
-- Do our tools crash in the wild? How often? - so we know how to prioritize
-  maintenance of tools
-- How do they use a tool? - assuming that a tool can do one or more things, we'd
-  like to learn how to prioritize investments in particular workflows of a tool
-
-The type and content of the metrics collected must be carefully chosen. We will
-go through the Google-standard PDD review process to ensure we are compliant
-with Google's practices and policies. Tools must get approval on which metrics
-are collected before collection.
-
-## Configuration and Environment
-
-Tools often need to know something about the context they are running. Let's
-look at how that context should be gathered or stored.
-
-#### Reading Information
-
-Tools should not attempt to gather or intuit settings or other state directly
-from the environment. Information such as an attached target's IP address, the
-out directory for build products, or a directory for writing temporary files
-will be gathered from a platform agnostic source. Separating out the code that
-performs platform-specific work will allow tools to remain portable between
-disparate platforms.
-
-Where practical, configuration information should be stored in a way familiar to
-the user of the host machine (e.g. on Windows, use the registry). Tools should
-gather information from SDK files or platform-specific tools that encapsulate
-the work of reading from the Windows registry, Linux environment, or Mac
-settings.
-
-Tools will be build-system agnostic as well. Accessing a common file such as
-build input dependency file is okay.
-
-#### Writing Information
-
-Tools will not modify configuration or environment settings, except when the
-tool is clearly for the purpose of modifying an expected portion of the
-environment.
-
-If modifying the environment outside of the tool's normal scope may help the
-user, the tool may do so with the express permission of the user.
-
-
-## Execution Success and Failure
-
-Command line tools return an integer value in the range [0..127] when they exit.
-A zero represents success (no error) and 1-127 are various forms of error. The
-value 1 is used as a general error. Any values other than 0 and 1 that may be
-returned must be documented for the user.
-
-### Succeed with Grace
-
-If there were no errors encountered, return a result code of zero.
-
-Avoid producing unnecessary output on success. Don't print "succeeded" (unless
-the user is asking for verbose output).
-
-### If Something is Unclear, Stop
-
-If the tool encounters an ambiguous situation or is in danger of corrupting
-data, do not continue. E.g. if the path to the directory you're being asked to
-delete comes back as just "`/`", there was likely an error trying to get that
-configuration information, avoid 'soldiering on' and removing everything under
-"`/`".
-
-### Do Not Fail Silently
-
-Tools must clearly indicate failure by returning a non-zero error code. If
-appropriate (if it makes sense for the tool or if the user explicitly asked for
-verbose output) print an error message explaining what went wrong.
-
-### Provide Direction on Failure
-
-When a tool execution fails, be clear about whether the error came from bad
-inputs, missing dependencies, or bugs within the tool. Make error reports
-comprehensible and actionable.
-
-If the error came from bad inputs
-1. If the user gave the tool bad data, give context about the error and guide
-   the user toward fixing the input, e.g. print which input file (and line
-   number if that's appropriate for the input) where the input error occurred.
-   - Prefer output that follows this format (for easy regex use):
-     `file_name:line:column:description`. This is a common format used by many
-     tools. Other formats are acceptable, but try to use something that is easy
-     for both humans and tools to parse.
-2. Provide a reference to further information. E.g. if documentation is
-   available, provide a link to documentation about the tool in general or to
-   documentation regarding the specific error. If the tool has the capacity to
-   provide more details, describe that (like how `gn` can explain how to run the
-   tool to get more help).
-
-If the error came from missing dependencies
-1. Be clear that the error is from missing dependencies, i.e. don't leave the
-   user trying to debug their input data if that is not the issue.
-2. Provide instruction on how to satisfy the dependencies. This can be an
-   example command to run (e.g. `apt-get install foo`) or a link to further
-   instructions (e.g. "`see: http:example.com/how-to-install-foo`").
-
-If the error came from an unexpected state (i.e. a bug) in the tool
-1. Apologize. Explain that the tool got into an unexpected state. Don't leave
-   the user trying to guess whether their input data was bad or they were
-   missing dependencies.
-2. Suggest a mailing list or forum to get help. Help the user find out if the
-   bug is fixed in the next tool version; or someone has found a workaround.
-3. Invite the user to enter a bug report and make that as easy as possible. E.g.
-   provide a link that goes to the bug database with the tool and platform
-   information prepopulated.
-
-
-## Include Tests
-
-Tools must include tests that guarantee its correct behavior. Include both unit
-tests and integration tests with each tool. Tests will run in Fuchsia continuous
-integration.
-
-> **SDK**
->
-> It's especially important that SDK tools imported from the Fuchsia build (pm,
-> etc.) have tests that run in Fuchsia continuous integration because the SDK
-> bot does not currently prevent breaking changes.
-
-## Documentation
-
-The Markdown documentation is the right place to put more verbose usage examples
-nd explanations.
-
-> **SDK**
->
-> All tools included in the SDK and intended to be executed directly by an end
-> user must have a corresponding Markdown documentation file.
-
-## User vs. Programmatic Interaction
-
-A tool may be run interactively by a human user or programmatically via a script
-(or other tool).
-
-While each tool will default to interactive or non-interactive mode if they can
-glean which is sensible, they must also accept explicit instruction to run in a
-given mode (e.g. allow the user to execute the programmatic interface even if
-they are running in an interactive shell).
-
-### Stdin
-
-For tools that are not normally interactive, avoid requesting user input
-e.g. readline or linenoise). I.e. Don't suddenly put up an unexpected prompt to
-ask the user a question.
-
-For interactive tools (e.g. `zxdb`) prompting the user for input is expected.
-
-### Stdout
-
-When sending output to the user on stdout use proper spelling, grammar, and
-avoid unusual abbreviations. If an unusual abbreviation is used, be sure it has
-an entry in the [glossary.md](../../glossary.md).
-
-Try to check for output to terminal, i.e. see if a user is there or whether the
-receiver is a program.
-
-#### ANSI Color
-
-Use of color is allowed with the following caveats
-- Enabling/disabling color output based on terminal information (i.e. whether it
-  supports color) is encouraged, but that's not always possible (so it's not
-  required)
-  - Always allow the user to override color use (they can disable it)
-- When using color, be sure to use colors that are distinct for readers who may
-  not be able to see a full range of color (e.g. color-blindness).
-- Never rely on color to convey information. Only use color as an enhancement.
-  Seeing the color must not be needed for correct interpretation of the output.
-
-### Stderr
-
-Use stderr for reporting invalid operation (diagnostic output) i.e. when the
-tool is misbehaving. If the tool's purpose is to report issues (like a linter,
-where the tool is not failing) output those results to stdout instead of stderr.
-
-See Success and Failure for more information on reporting errors.
-
-### Full-Screen
-
-Avoid creating full-screen terminal applications. Use a GUI application for such
-a tool.
-
-### Non-interactive (Programmatic)
-
-Include a programmatic interface where reasonable to allow for automation.
-
-If there is an existing protocol for that domain, try to follow suit (or have a
-good reason not to). Otherwise consider using manifest or JSON files for
-machine input.
-
-### IDE (Semi-Programmatic)
-
-Allow for tools to be used by an Integrated Development Environment. This
-generally involves accepting a manifest for input and generating a manifest.
-
-### Interactive (User)
-
-Interacting with the user while the tool is running is an uncommon case for many
-tools. Some tools may run interactively as an option, e.g. `rm -i` will prompt
-the user before each removal.
-
-## State Files
-
-State files encode information for data sharing between tools. PID file and lock
-files are examples of state files.
-
-Avoid using a PID file to contain the process ID of a running executable.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-Avoid using a lock file to manage mutual exclusion of resource access (i.e. a
-mutex).
diff --git a/development/api/cli_help.md b/development/api/cli_help.md
index b8b5dea..225b97b 100644
--- a/development/api/cli_help.md
+++ b/development/api/cli_help.md
@@ -1,459 +1,7 @@
-# CLI Tool Help Requirements
+# Obsolete
 
-
-## Overview
-
-Command line help, as often provided via `--help` is an important means of
-communication with the user. It provides a shorthand for more detailed
-documentation and feature discovery.
-
-
-## Guide
-
-Help documentation must include a usage section written in
-[Usage](#bookmark=id.yv0npmd9oldw) format, followed by brief written prose
-describing the command, and the following sections (as needed): Options,
-Commands, Examples, Notes, and Error codes.
-
-Let's start with a full example before digging into the specifics.
-
-### Example
-
-Each section of this example is described in detail later in this document.
-(Note that `blast` is not a real tool).
-```
-Usage: blast [-f] [-s <scribble>] <command> [<args>]
-
-Destroy the contents of <file>.
-
-Options:
-  -f                force, ignore minor errors. This description
-                    is so long that it wraps to the next line.
-  -s <scribble>     write <scribble> repeatedly
-  -v, --verbose     say more. Defaults to $BLAST_VERBOSE.
-
-Commands:
-  blow-up         explosively separate
-  grind           make smaller by many small cuts
-  help            get help on other commands e.g. `blast help grind`
-
-Examples:
-  Scribble 'abc' and then run |grind|.
-  $ blast -s 'abc' grind old.txt taxes.cp
-
-Notes:
-  Use `blast help <command>` for details on [<args>] for a subcommand.
-
-Error codes:
-  2 The blade is too dull.
-  3 Out of fuel.
-```
-
-#### General layout and style
-
-See above for an example that follows these requirements.
-
-Several sections call for **English prose**. This means writing in proper
-sentences using English grammar with US English spelling (as opposed to British
-English or others). Use one space between sentences, and adhere to the "Oxford
-comma" style. E.g. the Description and Notes sections are written in English
-prose.
-
-**Layout**
-
-- Each section is separated by one blank line.
-- Section contents are indented two spaces.
-- Single line contents will be written on the same line as the label with one
-  space separating the colon and the command name. E.g. "`Usage: blast <file>`".
-- Multi-line sections will be written immediately following the label (without a
-  blank line). Each line after the label will be indented two spaces.
-- All output is a single column of text with the exception of Options, Commands,
-  and Error codes which are two column tables.
-- Use spaces for indentation or alignment. Do not output tab characters.
-- Wrap text at 80 columns. When wrapping Option or Command descriptions, align
-  the subsequent lines with the start of the description (e.g. about 20
-  characters in).
-
-**Style**
-
-- Section titles appear in title-case: capitalize the first and last words. All
-  words in between are also capitalized except for articles (a, an, the),
-  conjunctions (e.g., and, but, or), and prepositions (e.g., on, in, with).
-- Short description fragments (the second column in Options or Commands) begin
-  with a lowercase letter and are not expected to be full sentences. Any text
-  beyond the short description should be complete sentences, with a period after
-  the fragment.
-- Try to keep each section concise. If there is more to say, direct the user to
-  use `--verbose` when running `--help` or direct them to the full
-  documentation.
-- Unicode (UTF-8) characters are allowed in descriptive text (prose). The
-  command name and usage text will only contain portable ASCII characters
-  (without Unicode).
-
-### Usage
-
-Usage is required and includes the "`Usage:`" header.
-```
-Usage: blast [-f] [-s <scribble>] <command> [<args>]
-```
-
-Usage will commonly be a single line, though multiple lines can be used to
-clarify when options are mutually exclusive. If the number of lines needed to
-present all the mutually exclusive scenarios becomes excessive, limit the lines
-to some common cases and give more details in the full docs. If there are many
-mutually exclusive options, consider making subcommands or separate tools to
-reduce the complexity.
-
-#### Usage syntax
-
-The command name is listed first. The command name is not hardcoded: it will be
-dynamically pulled from the command name, i.e. the last element on the argv[0]
-path. This allows a single binary to operate as multiple different tools.
-
-The name and usage text will contain portable ASCII characters only. All long
-form commands are entirely lowercase, i.e. never all-caps or mixed-case. Single
-letter switches should prefer lowercase, but uppercase is allowed.
-
-Use meaningful words for options and placeholders. Avoid abbreviations. Prefer
-single words. When more than one word is used, separate words with a hyphen
-(`-`), i.e. do not use underscores, camel-case, or run words together.
-
-Aside from the command name there are several kinds of arguments (as described
-in [Fuchsia Tool Requirements](http://go/fuchsia-tool-requirements)).
-- Exact text
-- Arguments
-- Options (Switches and Keys)
-- Keyed options
-- Option delimiter
-
-##### Exact Text Syntax
-
-Exact text is written as-is in the usage line. In the example "`Usage: copy
-<from> to <destination>`", the word `to` is required exact text. If exact text
-is optional, it will be enclosed in brackets (`[]`) in the usage line: "`Usage:
-copy <from> [to] <destination>`".
-
-##### Argument Syntax
-
-Arguments are enclosed in angle brackets (<>) to differentiate them from
-explicit text. In the example `Usage: copy <from> <destination>`, both `<from>`
-and `<destination>` are arguments. If an argument is optional, it will be
-enclosed in brackets (`[]`) such as: `Usage: copy <from> [<destination>]`. See
-also [Option Delimiter](#bookmark=id.j2ckxvlhnf2f).
-
-##### Mutually Exclusive Option Syntax
-
-There are a couple choices when illustrating mutually exclusive options.
-
-If more than one usage line is provided, each will show a mutually exclusive set
-of commands. For example:
-```
-Usage:
-  swizzle [-z] <file>
-  swizzle --reset
-```
-
-Indicates that `--reset` and usage with a `<file>` are mutually exclusive
-options.
-
-Another way to specify mutually exclusive options is using a vertical bar ('|')
-between the options. Note that when a vertical bar is used to indicate data flow
-between processes it is called a "Pipe." When used to separate options it is
-read as "Or".
-
-For example:
-```
-Usage: froth [-y|-z] <file>
-```
-
-Indicates that `-y` **_or_** `-z` switches can be used (or neither, since they
-are optional), but it's senseless to use both together (they are mutually
-exclusive options). To indicate that either value must be used, but not both,
-wrap the choices in parentheses, e.g. "`Usage: froth (-a|-b) <file>`" means that
-`-a` **_or_** `-b` must be passed.
-
-Note that it's common that `--version` or `--help` causes other arguments to be
-ignored and is seldom listed as such. Listing them as separate usage lines is
-considered unnecessary.
-
-##### Grouping (implied) options
-
-There is no specific syntax to indicate when enabling one option will also
-affect another option. When an option implies that another option is enabled or
-disabled, specify that in the Options. E.g. "`passing -e implies -f`" means that
-if `-e` is enabled, `-f` will be enabled as if it were passed on the command
-line (regardless of whether `-f` was explicitly passed). The redundant passing
-of the implied value is harmless (not an error).
-
-Document the implication in the primary switch. E.g. if `-x implies -c and -p`
-place that note in the description of `-x` but not in `-c` and `-p`. This is to
-keep the `--help` output concise (this rule can be relaxed in the full
-documentation).
-
-##### Optional Keys
-
-To create the appearance of a keyed option with an optional Key, create optional
-exact text followed by an argument. For example "`Usage: copy [from] <from> [to]
-<destination>`". In the example, all of these are valid: "`copy a b`", "`copy
-from a b`", "`copy from a to b`", "`copy a to b`".
-
-##### Repeating Options
-
-If the same positional argument may be repeated, indicate that with an ellipsis
-('...'). Rather than a Unicode ellipsis, use three consecutive periods. For
-example: "`Usage: copy <from> [<from>...] <to>`" means the last argument is
-always interpreted as the `<to>`, while the preceding values are multiple
-`<from>` entries. Note that "`<from> [<from>...]`" means there is one or more
-`<from>` entries, while "`Usage: copy [<from>...] <to>`" means zero or more
-`<from>` entries are accepted.
-
-For Key/Value pairs which may be repeated, group them with brackets (if the pair
-is optional) or parentheses (if the pair is not optional) and add an ellipsis to
-the group, e.g. `[--input <file>]...` or `(--input <file>)...` respectively.
-
-##### Brackets
-
-Angle brackets (`<>`), brackets (`[]`), and parentheses (`()`) will not have
-spaces immediately inside.
-```
-[from] # correct
-<to> # correct
-(-a|-b) # correct
-
-[ from ] # incorrect
-< to > # incorrect
-( -a|-b ) # incorrect
-```
-
-Angle brackets (<>) wrap Arguments or Key values.
-
-Brackets (`[]`) wrap optional elements. With nested angle brackets, such as
-`[<file>]`, interpret the `<file>` as an Argument that is optional. The nested
-"`[<`" is not a separate bracket style, it is a "`[`" with a "`<`" within it.
-When nesting, the brackets (`[`) will be outermost (do not use `<[file]>`).
-
-Parentheses (`()`) are used to group elements. Use parentheses when they improve
-clarity, such as with required mutually exclusive options.
-
-Braces (`{}`) are reserved for future use. This guide intentionally leaves open
-the possibility for braces to have special meaning in a future revision of this
-document.
-
-### Description
-
-The description is required and does not include a header. I.e. the description
-area is not labeled "description". E.g.
-```
-Destroy the contents of <file>.
-```
-
-The description is written in US English prose (complete sentences using US
-English grammar, spelling, and punctuation).
-
-Every tool should tell you what it does and this is the section to do that.
-
-The Description section should describe
-- what the tool does (required)
-- the platform configuration used
-- schemes, data formats, or protocols used
-- golden workflows (critical developer journeys)
-- a broad URL to documentation (e.g. fuchsia.com/docs or similar, avoid deep
-  links that go stale to easily)
-
-The Description section can also contain a "see also" referring to another tool
-by name (avoid using a URL).
-
-What not to put in the Description section
-- environment variables used, other than those already listed in Options
-  (provide this in Options or Notes)
-- security hazards (explain these in the Notes section)
-- error codes (put those in an Error codes section)
-- copyright (don't include this in the --help)
-- author (don't include this in the --help)
-- how to get help on subcommands (put this in the short description for the
-  `help` subcommand)
-- how to update the tool (that should be in the documentation for the tool
-  package, if applicable)
-- release notes (use a separate file)
-
-### Options
-
-An Options section is required if the program accepts arguments. E.g.
-```
-Options:
-  -f              force, ignore minor errors
-  -s <scribble>   write <scribble> repeatedly. Defaults to $BLAST_SCRIBBLE.
-```
-
-The listed options apply to the tool itself and not to a subcommand. Options for
-individual subcommands are listed when requesting help for that subcommand, e.g.
-when using `blast help grind` or `blast grind --help`.
-
-Try to keep options to a single, complete word. If two words are needed,
-separate the words with a hyphen (`-`). Avoid uncommon abbreviations.
-
-Present the list of options in alphabetical order.
-
-Options will list each argument, switch, and keyed option on separate lines with
-the exception of arguments that have both a short and long form. If an argument
-has both a short and long form they are listed on the same line, short form
-first, and separated by ", " (comma space), e.g. `-f, --force`.
-
-Exact text arguments will not be listed in the Options section. They are shown
-in the Usage section.
-
-Text that will be typed as-is is not wrapped in brackets, while variable entries
-appear in angle brackets (`<>`) and optional entries appear in square brackets
-(`[]`). When listing options, the Key is never optional. For example:
-```
-  -a                   a good example
-  [-b]                 a bad example, to use -b it must be typed as-is
-```
-
-A short description will follow each option. There's no limit on the length of
-this description, but be concise. Try to put more details in the overall tool
-description, the Examples, or the Notes instead of creating a lengthy option
-description.
-
-What to describe
-- a brief reminder of what the option implies, e.g. `ignore minor errors`
-- if the option overrides another option, e.g. `-x implies -c and -p`
-- default value, e.g. `defaults to $BLAST_SCRIBBLE`
-
-The column on which the description sentence fragment begins may vary depending
-on the needs of the tool. Use 20 characters from the left edge if it looks okay,
-but adjust if a bit more or less reads better.
-
-If there is a large number of options, consider showing a useful subset and
-explaining how to get further help to see all of them, e.g. by passing
-`--verbose` along with `--help`.
-
-### Commands
-
-A commands section is required if the program has subcommands. If present it
-will be labeled, "Commands:". E.g.
-```
-Commands:
-  blow-up         explosively separate
-  grind           make smaller by many small cuts
-  help            get help on other commands e.g. `blast help grind`
-```
-
-If the program does not have subcommands, the commands section will not be
-present.
-
-When a tool has subcommands, it will also have a `help` command to get further
-help on the subcommands, i.e.` blast help grind`.
-
-Try to keep subcommands to a single, complete word. If two words are needed,
-separate the words with a hyphen (`-`). Avoid uncommon abbreviations. Present
-the list of commands in alphabetical order.
-
-Each command name appears with a short description on a separate line. For a
-more lengthy command description, the user will specifically ask for help on
-that command. This description serves as a short reminder of the command and to
-assist in discovery of commands.
-
-If there is a large number of commands, consider showing a useful subset and
-explaining how to get further help to see all of them, e.g. by passing
-`--verbose` along with `--help`.
-
-### Examples
-
-An examples section is optional. If present it will be labeled, "Examples:".
-E.g.
-```
-Examples:
-  Scribble 'abc' and then run |grind|.
-  $ blast -s 'abc' grind old.txt taxes.cp
-```
-
-Each example will have US English prose (i.e. complete sentences using US
-English grammar, spelling, and punctuation) describing the example, followed by
-an example command line. Each line that would be entered on the command line
-literally will be prefixed with a "`$ `" to mimic a command prompt.
-
-To wrap an example that is overly long, end the previous line with "`\ `" and
-begin subsequent lines with "`  `" (spaces) to indicate line continuation.
-```
-  This example wraps onto multiple lines.
-  $ blast -s 2332 some/long/path/cats.o \
-    more/long/path/dogs.o more/long/path/bears.o \
-    more/long/path/deer.o
-```
-
-If it is helpful to show some of the output from the example command, write the
-output immediately following the example.
-
-Separate examples with one blank line.
-
-If the Examples section is getting overly long, move examples to a help doc.
-Interactive help examples are for quick reference and discoverability rather
-than exhaustive documentation.
-
-### Notes
-
-Notes are optional and begin with a "Notes:" header. E.g.
-```
-Notes:
-  Use `blast help <command>` for details on [<args>] for a subcommand.
-```
-
-The notes are written in US English prose (i.e. complete sentences using US
-English grammar, spelling, and punctuation).
-
-What to put in the Notes
-- environment variables used, other than those already listed in Options (for
-  default values)
-- security hazards
-- reminders to help the user
-
-What not to put in the Notes
-- error codes (put those in an Error codes section)
-- copyright (don't include this in the --help)
-- author (don't include this in the --help)
-- how to get help on subcommands (put this in the short description for the
-  `help` subcommand)
-- how to update the tool (that should be in the documentation for the tool
-  package, if applicable)
-- release notes (use a separate file)
-
-### Error codes
-
-The Error codes section is required if codes other than `0` or `1` are
-generated. E.g.
-```
-Error codes:
-  2  The blade is too dull.
-  3  Out of fuel.
-```
-
-This section is omitted if only `0` or `1` results are generated by the program.
-
-Error code `0` is always treated as "no error" and error code `1` is always a
-"general error". Neither are documented in the `--help` output. Every error code
-other than `0` or `1` that may be generated by the tool must be documented.
-
-### Platform specifics
-
-Some platforms (e.g. DOS) use a different option prefix (e.g. `/`) or may allow
-case insensitive switches. Tools will use a dash prefix (`-`) and case sensitive
-options regardless of the platform. This means that the documentation for a tool
-generally doesn't need to consider the platform being used.
-
-### What not to include in --help output
-
-Do not show Key/Value pairs with an equals sign (`=`), e.g. `--scribble=abc`.
-The Key and Value are parsed using whitespace as a delimiter (`--scribble abc`).
-Showing the equals in the help is potentially confusing.
-
-Do not implement a pager (something like the `more` program that pauses output
-on each screenful of text).
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-Do not include
-- a copyright in the help output (put that where legal specifies)
-- release notes (put that in release notes)
-- full documentation (put that in the markdown documentation)
-- version information (output that from `--version`)
-- documentation on result codes `0` or `1` (put in .md docs)
-- shell-specific help (such as how to redirect output or pipe to a pager)
diff --git a/development/api/council.md b/development/api/council.md
index 98ec6fa..225b97b 100644
--- a/development/api/council.md
+++ b/development/api/council.md
@@ -1,307 +1,7 @@
-# Fuchsia API Council Charter
+# Obsolete
 
-## Overview
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-This document describes the *Fuchsia API Council*, which is a group of people
-who are accountable for the quality and long-term health of the Fuchsia API
-Surface. The council will collaborate constructively with the people who create
-and modify Fuchsia’s APIs to help guide the evolution of those APIs. The council
-will communicate its decisions clearly, including the underlying rationale, and
-will document best practices by contributing to Fuchsia’s API readability
-rubrics.
-
-## Definitions
-
-The *Fuchsia System Interface* is the binary interface that the Fuchsia
-operating system presents to software running on the system. For example, the
-entry points into the vDSO as well as all the FIDL protocols used by the system
-are part of the Fuchsia System Interface.
-
-A *client library* is a library that people writing software for Fuchsia might
-choose to use rather than interfacing directly with the Fuchsia System
-Interface. For example, FDIO is a client library that provides a POSIX-like
-abstraction over the underlying fuchsia.io protocol in the Fuchsia System
-Interface.
-
-The *Fuchsia SDK* is a collection of libraries and tools that the Fuchsia
-project provides to people writing software for Fuchsia. Among other things, the
-Fuchsia SDK contains a definition of the Fuchsia System Interface as well as a
-number of client libraries.
-
-The *Fuchsia API Surface* is the combination of the Fuchsia System Interface and
-the client libraries included in the Fuchsia SDK.
-
-*Fuchsia contributors* are people who are involved in creating the Fuchsia
-operating system, including people who work for Google and people who do not.
-
-*Fuchsia API* designers are people who create or modify the Fuchsia API Surface,
-including people who work for Google and people who do not.
-
-*End-developers* are people who write software that consumes the Fuchsia API
-Surface.
-
-*Users* are people who use devices that run the Fuchsia operating system.
-
-## Goals
-
-Ultimately, the end-goal of the Fuchsia API Council is to foster a healthy
-software ecosystem around the Fuchsia operating system. Fostering a healthy
-ecosystem requires balancing many concerns, including growing the ecosystem and
-guiding the ecosystem towards particular outcomes.
-
-### Values
-
-The ecosystem has many participants who play many different roles. Ideally, we
-would be able to design APIs that meet the needs of everyone in the ecosystem
-simultaneously, but API designers are often called upon to make decisions that
-involve trade-offs. The council should help API designers make these decisions
-in a way that respects the following *priority of constituencies*:
-
-1.  Users
-1.  End-developers
-1.  Contributors
-1.  API designers
-1.  Council members
-
-For example, we should design APIs that protect user privacy, even at the
-expense of not fulfilling all the desires of end-developers. Similarly, we
-should design APIs that are better for end-developers even if those designs
-place a higher burden on the people implementing the APIs.
-
-These values help guide the ecosystem towards meeting the needs of users, which
-promotes the health and growth of the ecosystem in the long run because users
-are more likely to join, and remain in, an ecosystem that meets their needs.
-
-### Strategy
-
-To achieve these goals, the council focus on the following metrics:
-
-*   *Functionality*. The council is accountable for the functionality of the
-    Fuchsia API Surface. Specifically, functionality refers to whether the APIs
-    meet the needs of the ecosystem participants. For example, the council is
-    accountable for how well our APIs protect the privacy of users, how well our
-    APIs help end-developers accomplish a given task, and how well our APIs let
-    Fuchsia contributors improve their implementations over time.
-
-*   *Usability*. The council is accountable for the usability of the Fuchsia API
-    Surface. For example, the council should strive for consistency in how
-    similar concepts are expressed in our APIs, which makes our APIs easier for
-    end-developers to learn. Similarly, the council should ensure that our APIs
-    are well-documented and that the semantics of interfaces are intuitive from
-    their declaration.
-
-*   *System impact*. The council is accountable for the burden on the system as
-    a whole incurred through the use of the Fuchsia API Surface, including both
-    intended and unintended usage. For example, APIs that use polling impose a
-    large burden on the system because they require their clients to run
-    continuously to monitor changes in conditions. Assessing system impact
-    requires a significant amount of judgement and experience, especially to
-    predict unintended uses of APIs.
-
-*   *Communication clarity*. The council is responsible for clearly
-    communicating decisions and the rationale behind those decisions to Fuchsia
-    contributors. This communication should provide transparency about the
-    decision-making process and should help educate API designers about how to
-    create high-quality APIs. For example, the council should document best
-    practices by contributing to Fuchsia’s API readability rubrics.
-
-*   *Customer satisfaction*. The council is responsible for collaborating
-    constructively with API designers. The council should foster an environment
-    in which council members and API designers work in partnership to improve
-    the Fuchsia API Surface. API designers should see the council as providing
-    positive value, helping them make better APIs, rather than as bureaucratic
-    burden. For example, council members should respond promptly and
-    respectfully to requests for API reviews.
-
-## Membership
-
-The council is comprised of Fuchsia contributors who have demonstrated:
-
-*   Good judgement about the quality and long-term health of APIs, either within
-    Fuchsia or in their past work with other platforms.
-
-*   Strong communication and collaboration skills, as viewed by API designers
-    (i.e., their collaborators).
-
-Members are appointed by each functional area of the project:
-
-*   Auth
-*   Architecture
-*   Component
-*   Connectivity
-*   DDK
-*   Developer
-*   Drivers
-*   Experiences
-*   FIDL
-*   Graphics
-*   Kernel
-*   Ledger
-*   Media
-*   Metrics
-*   Modular
-*   Security
-*   Software Delivery
-*   Storage
-*   System
-*   Toolchain
-*   Virtualization
-*   Web
-
-As the project evolves, the list of functional areas (and therefore the makeup
-of the council) will evolve as well. The list of functional areas is maintained
-by Fuchsia leadership.
-
-The council also has a *chair*, whose job is to facilitate the operations of the
-council. For example, the chair (a) schedules meetings, (b) sets the agenda for
-those meetings, and (c) assesses whether the council has reached
-[rough consensus](https://en.wikipedia.org/wiki/Rough_consensus). The chair is
-appointed by Fuchsia leadership.
-
-## Decision process
-
-If the council is called upon to make a decision, the decision process is as
-follows. The council member for the area in question is the *primary decision
-maker*, but the council as a whole is the *final decision maker*. The council as
-a whole makes decisions by *rough consensus*, as assessed by the chair.
-
-*   The primary decision maker can *defer* a decision, in which case the council
-    will make the decision. If the council fails to reach rough consensus, the
-    chair will make the final decision.
-
-*   A council member can ask the council to *overrule* the primary decision
-    maker. If the council fails to reach rough consensus, the decision made by
-    the primary decision maker stands.
-
-## Operations
-
-The council has two major functions: API review and API calibration.
-
-### API review
-
-Every change to the Fuchsia API Surface requires approval from a council member.
-A change in a particular functional area should typically be approved by the
-council member responsible for that area, but any council member can approve the
-change if the responsible council member is unavailable.
-
-Before being merged, every CL that modifies the Fuchsia API Surface must receive
-an API-Review+1 from a member of
-[api-council@fuchsia.com](https://groups.google.com/a/fuchsia.com/forum/#!forum/api-council)
-in addition to the usual Code-Review+2. The same person can provide both
-API-Review+1 and Code-Review+2 for a given change, but someone cannot give their
-own CLs API-Review+1. See
-[Review Labels](https://gerrit-review.googlesource.com/Documentation/config-labels.html)
-for documentation about this Gerrit feature.
-
-For small API changes, especially incremental refinements to existing APIs, a
-code review is usually sufficient for an API reviewer to give the change
-API-Review+1. However, for larger changes, especially those that expand the API
-surface significantly, the API designer should write an *API Design Document*
-(see [Fuchsia API Design Template](http://go/fuchsia-api-design-template)),
-which explains the design of the API, including use cases and examples, as well
-as security and privacy considerations. An API reviewer can always request the
-API designer to write an API Design Document, even for small changes if the API
-reviewer does not feel comfortable approving the change purely through code
-review.
-
-API designers are also encouraged to seek early feedback from council members.
-For example, API designers should consider sharing work-in-progress API Design
-Documents with council members to get input early in the design process. Council
-members should engage in these discussions with the goal of partnering with API
-designers to help design the best API. API designers can also seek feedback
-early in the design process from the full council by asking the chair for a slot
-in the agenda for an upcoming API calibration session (see the next section).
-
-The API reviewer should work with the API designer to improve the API Design
-Document to the point where the API reviewer feels comfortable approving the
-document. An approved document serves as the plan of record for the API in
-question. However, individual CLs that modify the API surface still need to
-review API-Review+1 before being merged. API designers should expect that CLs
-that follow the plan laid out in an approved API Design Document should review
-API-Review+1 quite easily, even from other council members.
-
-API designers or reviewers can refer a API Design Document to the full council
-by asking the chair for a slot in the agenda for an upcoming API calibration
-session (see the next section). For example, an API reviewer might refer a
-document to the full council if the API reviewer does not feel sufficiently
-calibrated, if the API is particularly complex or important, or if the reviewer
-feels pressured by looming deadlines or other teams.
-
-### API calibration
-
-Periodically, the API council will meet for *API calibration*. The purpose of
-API calibration is to promote consistency of API reviews across the project and
-to improve the quality of API reviews by cross-pollinating best practices across
-the council. These meetings often have a *facilitator*, who keeps the meeting on
-topic and helps ensure each participant has a chance to provide their feedback.
-
-Fuchsia contributors can observe API calibration meetings. Observing these
-meetings can be a good way to learn best practices about evolving our API
-surface.
-
-#### Review API Design Documents
-
-The first priority in API calibration is to review any API Design Documents that
-have been referred to the full council. If there are multiple pending documents,
-the chair will select the order in which the council works through the
-documents.
-
-The API designer who wrote the document should present the document, providing
-the council with the necessary context to understand the issues at stake.
-Afterwards, the person who referred the document should lead a discussion of the
-areas of the API design for which they are seeking feedback. Council members are
-encouraged to focus their feedback on those areas but are free to provide
-feedback about the document as a whole.
-
-#### Review backlog
-
-The Fuchsia API Surface contains a large number of APIs that were designed
-before the council was formed. The council will work through that backlog of API
-reviews, eventually reaching the point where every API in the Fuchsia API
-Surface has been reviewed. Ideally, the council will have a chance to review the
-entire Fuchsia API Surface before Fuchsia commits to the backwards compatibility
-of its APIs.
-
-The chair selects the order in which the council works through the backlog,
-attempting to balance reviewing APIs from diverse areas of the project with the
-urgency to review APIs that are acreeting a large number of clients.
-
-When reviewing an API, the council member who is responsible for the area that
-contains the API (hereafter the *responsible member*) will present the API,
-providing the council with the necessary context to understand the use cases and
-motivation for the API. The responsible member can invite one or more subject
-matter experts to help provide additional context and technical details.
-Ideally, the responsible member will have pre-reviewed the API and will have a
-list of proposed modifications.
-
-#### Secondary review
-
-The council will also cycle through the functional areas of the project,
-performing a secondary review of changes to the API surface for each area since
-the last cycle. This activity lets the council provide feedback to members on
-their recent API reviews.
-
-The chair will select the order in which the areas are reviewed, attempting to
-balance reviewing APIs from diverse areas of the project with the urgency to
-review APIs that have a large volume of changes.
-
-During secondary review, the council member who was the primary reviewer for the
-API change will present the change as well as any associated API Design
-Documents, providing the council with the necessary context to understand the
-use cases and motivation for the changes. The API designer who made the change
-in question is also encouraged (but not required) to attend.
-
-Generally, the council should respect the decisions made during the primary API
-review, but council members are encouraged to provide feedback about how the API
-could have been improved, which benefits future reviews. Depending on the
-maturity of the API, the primary reviewer might decide to incorporate these
-improvements into the API. In rare cases, the council can overrule the primary
-reviewer, per the council’s decision process.
-
-## Acknowledgements
-
-This document draws heavily from the governance structure used by the Android
-API Council, the Web API OWNERS, the W3C, and the IETF. Special thanks to Jeff
-Brown, Dimitri Glazkov, Jeremy Manson, Rebecca Silberstein, and Greg Simon for
-sharing their experience with API governance and for their thoughtful feedback
-on early drafts of this document.
diff --git a/development/api/device_interfaces.md b/development/api/device_interfaces.md
index c991651..225b97b 100644
--- a/development/api/device_interfaces.md
+++ b/development/api/device_interfaces.md
@@ -1,66 +1,7 @@
-# Fuchsia Device Interface Rubric
+# Obsolete
 
-The Fuchsia device interfaces are expressed as FIDL interfaces.  These FIDL
-definitions should conform to the [FIDL Readability Rubric].
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-## Identifiers
-
-Prefer descriptive identifiers.  If you are using domain-specific abbreviations,
-document the expansion or provide a reference for further information.
-
-Every identifier that is defined as part of an interface must be documented with
-a comment explaining its interpretation (in the case of fields, types, and
-parameters) or behavior (in the case of methods).
-
-## Interfaces
-
-All device interfaces must use the `[Layout = "Simple"]` attribute.  This
-restriction exists to allow ease of implementing interfaces in any of our
-supported languages for driver development.
-
-## Method Statuses
-
-Use a `zx.status` return to represent success and failure.  If a method should not be
-able to fail, do not provide a `zx.status` return.  If the method returns multiple
-values, the `zx.status` should come first.
-
-## Arrays, Strings, and Vectors
-
-All arrays, strings, and vectors must be of bounded length.  For arbitrarily
-selected bounds, prefer to use a `const` identifier as the length so that
-interface consumers can programmatically inspect the length.
-
-## Enums
-
-Prefer enums with explicit sizes (e.g. `enum Foo : uint32 { ... }`) to plain
-integer types when a field has a constrained set of non-arithmetic values.
-
-## Bitfields
-
-If your interface has a bitfield, represent its values using `const` values.
-They should be grouped together in the FIDL file and have a common prefix.  For
-example:
-
-```
-// Bit definitions for Info.features field
-
-// If present, this device represents WLAN hardware.
-const uint32 INFO_FEATURE_WLAN = 0x00000001;
-// If present, this device is synthetic (i.e. not backed by hardware).
-const uint32 INFO_FEATURE_SYNTH = 0x00000002;
-// If present, this device will receive all messages it sends.
-const uint32 INFO_FEATURE_LOOPBACK = 0x00000004;
-```
-
-If FIDL gains bitfield support, this guidance will be updated.
-
-## Non-channel based protocols
-
-Some interfaces may negotiate a non-channel protocol as a performance
-optimization (e.g. the zircon.ethernet.Device's GetFifos/SetIOBuffer methods).
-FIDL does not currently support expressing these protocols.  For now, represent
-any shared data structures with `struct` definitions and provide detailed
-documentation about participation in the protocol.  Packed structures are not
-currently supported.
-
-[FIDL Readability Rubric]: fidl.md
diff --git a/development/api/documentation.md b/development/api/documentation.md
index e1740c2..225b97b 100644
--- a/development/api/documentation.md
+++ b/development/api/documentation.md
@@ -1,261 +1,7 @@
-# API Documentation Readability Rubric
+# Obsolete
 
-## Overview
-
-This section contains guidance on writing documentation for Fuchsia's APIs.  It
-applies both to public-facing APIs (those surfaced via an SDK) and
-Fuchsia-internal ones.  Public facing API documentation will be reviewed by the
-[API Council](council.md) for adherence to this rubric.
-
-## Overall commenting rules
-
-In most cases, documentation should follow the language's style guide for
-comments.  If there is a rule in this document that contradicts the
-language-specific rules, follow this document's guidance.  In some cases, the
-language-specific rules take precedence; these special cases are identified
-below.
-
-Here are the links to language-specific guidelines for languages likely to be
-used in the Fuchsia repository: [C and
-C++](https://fuchsia.googlesource.com/docs/+/master/development/languages/c-cpp/cpp-style.md),
-[Dart](https://fuchsia.googlesource.com/docs/+/master/development/languages/dart/style.md)
-[Rust](https://github.com/rust-lang-nursery/fmt-rfcs/blob/master/guide/guide.md),
-[Java](https://google.github.io/styleguide/javaguide.html),
-[Kotlin](https://kotlinlang.org/docs/reference/coding-conventions.html#documentation-comments).
-We also recommend reading [Google's guidelines on API
-documentation](https://developers.google.com/style/api-reference-comments).
-
-## Communicating with care
-
-Documentation is intended to be consumed by the general public, and should be
-written in a technical and neutral tone.  There are some explicit restrictions
-on what you can write below, but they aren't intended to be comprehensive - use
-good judgment!
-
- * Do not include any reference to anyone's proprietary information.  Do not use
-   sensitive information (personally identifiable information, authentication
-   keys, etc).
- * Do not use swear words or other potentially aggressive language (words like,
-   e.g., "stupid")
-
-## General style
-
- * Spelling, punctuation, and grammar matter.  Use US English spelling.  Use the
-   serial comma.
- * Do not list authors explicitly.  Author information goes out of date quickly,
-   as developers move to different projects.  Consider providing a maintainers
-   file, although be wary that this goes out of date, too.
- * Optimize your code for the intended display (e.g., use markdown or Javadoc as
-   intended).
-<!-- * Do not write TODO(username), write TODO(reference-to-bug).  Bug ownership
-   goes out of date quickly, as developers move to different projects.  This
-   includes documentation on unimplemented APIs and implementation notes. -->
-
-Only apply the following rules in the absence of language-specific practices and
-guidance:
-
- * Documentation should immediately precede the element it is documenting.
- * Use markdown for comments.  The style of markdown is the style understood by
-   the tool most likely to consume the API.
-   * Use backticks for code blocks instead of 4-space indents.
- * All comments should use complete sentences.
-
-## API elements
-
- * A **public facing API element** is one that is made available to developers
-   via an SDK.  All public facing API elements (including, but not limited to
-   methods, classes, fields, types) must have a description.  Internal libraries
-   should be documented; there should be a good reason if they are not.
-
- * All parameters must have a description, unless that description would be
-   redundant with the type and name.
-   * If it is not obvious from the type what a parameter's legal values are,
-     consider changing the type.  For example, {-1, 0, 1} is less useful than an
-     enum with {LESS\_THAN, EQUAL\_TO, GREATER\_THAN}.
-   * Otherwise, document the behavior of the API for all possible input values.
-     We discourage undocumented values.
-
- * All return values must have a description, unless that description would be
-   redundant with the type and name.
-   * If a method or function returns a subset of its return type, document the
-     subset.
-   * Document all returned errors and the circumstances under which they can be
-     produced.
-   * For example, if the method's return type is zx\_status\_t, and it only
-     returns ZX\_OK and ZX\_ERR\_INVALID\_ARGS, your documentation must state
-     that explicitly.
-   * If it is not immediately obvious what a particular return value means, it
-     must be documented.  For example, if a method returns ZX\_OK, you don't
-     need to document it.  If a method returns the length of a string, it
-     should be documented.
-
- * All possible thrown exceptions must have a description, which must include
-   the conditions under which they are thrown, unless obvious from the type and
-   name.
-   * Some third party code does not document exceptions consistently.  It may
-     be hard (or impossible) to document the behavior of code that depends such
-     APIs.  Best effort is acceptable; we can resolve resulting issues as they
-     arise.
-   * Document whether exceptions are recoverable and, if so, how to recover
-     from them.
-
- * For any API elements that are extensible, indicate whether they are intended
-   to be extended, and requirements for those who might want to extend them.
-   * If an API is extensible for internal reasons (e.g., testing), document
-     that.  For example, you should document if you have allowed a class to be
-     extended in order to make it easy to create test doubles.
-
- * Document deprecated API elements.
-   * Documentation on deprecated API elements must state what a user is expected
-     to do instead of using the API.
-   * Plans to eliminate the API should be clearly documented (if they exist).
-   * If an explanation of the deprecation status of an API element would reduce
-     the quality of the API documentation, consider providing a pointer to
-     further information, including URLs and bug identifiers.
-
-## API behavior
-
-Document user-facing invariants, as well as pre- and post-conditions.
- * As a rule, ensure that there are assertions / tests to enforce these
-   conditions.
- * Preconditions and postconditions that require explicit user action should
-   be documented.  For example, provide documentation if an `Init()` method
-   needs to be called before anything else happens.
- * Correlations between parameters or return values (e.g., one has to be less
-   than another) should be documented.
-
-### Concurrency
-
-Document the concurrency properties of APIs that have internal state.
-
- * FIDL servers may execute requests in an unpredictable order.  Documentation
-   should account for situations where this might affect the behavior the caller
-   observes.
- * Every API with internal state falls into one of the following categories.
-   Document which one, using the following terms:
-   * **Thread-safe**: This means invocations of individual elements of the API
-     (e.g., methods in a class) are atomic with respect to other concurrent
-     processes.  There is no need for a caller to use any external
-     synchronization (e.g., a caller should not have to acquire a lock for the
-     duration of the method invocation).
-   * **Thread-unsafe**: This means that all methods must use external
-     synchronization to ensure invariants are maintained (e.g., mutual
-     exclusion enforced by a lock).
-   * **Thread-hostile**: This means that the API element should not be accessed
-     from multiple threads (e.g., it has implementation details that rely on
-     unsynchronized access to static data behind the scenes, like strtok()).
-     This should include documentation about thread affinity (e.g., it uses
-     TLS).  It is only allowed in Fuchsia APIs by exception.
-   * **Special**: This means that the correct concurrent use of this API
-     requires thought, please read the docs.  This is especially relevant when
-     entities need to be initialized and references to them published in a
-     specific way.
-   * **Immutable**: The other four classes assume that internal state is
-     mutable and thread safety is guaranteed by synchronization.  Immutable
-     classes appear constant without any additional synchronization, but you
-     have to maintain strict rules about serialization / deserialization and
-     how references to the object are shared between threads.
- * An API is **blocking** if it is not guaranteed to make progress.  Document
-   the blocking properties of your APIs.
-   * If an API is blocking, the documentation must state what is required for
-     the code to make progress, unless blocking is a low probability event that
-     requires implementation understanding.
-     * An example of when you must document a method's blocking behavior is when
-       it blocks waiting for a response on a channel.
-     * An example of when you do not have to document a method's blocking
-       behavior is when it may block if lock starvation is a theoretical
-       possibility under high load.
-   * An API is not considered blocking only because it takes a long time to
-     finish.  A slow algorithm should not be documented to be blocking.
-   * Documentation should only state that an API is non-blocking when the
-     non-blocking behavior is critical to its use (for example, if an API
-     returns a future).
- *  An API is **reentrant** if it may be safely interrupted in the middle of its
-    execution and then called again.  Document the reentrance properties of your
-    APIs.
-    * APIs may be assumed to be reentrant.  Documentation must state if an API
-      is not reentrant.
- * Document whether a function relies on **thread-local storage (TLS)** to
-   maintain its invariants, and any preconditions and postconditions related to
-   that TLS (e.g., if it needs to call an initializer once per thread).
-
-### Ownership
-
-Document ownership and liveness properties.
- * For parameters or return values that are stored beyond the life of a
-   function, or resources allocated by the function and passed back to the
-   caller, or resources with particular ownership constraints that must be
-   observed by a set of APIs (i.e., shared resources), ownership and liveness
-   must be documented.
- * Document who is responsible for releasing any associated resources.
- * Where appropriate, documentation should state the protocol for releasing
-   those resources.  This can be a special issue when memory allocation
-   routines differ between the caller of an API and the API.
-   * Languages should call out default ownership behavior in their style
-     guides.
-
-### Nullness
-
-All parameters and return values must have their nullness properties defined (if
-they are of a nullable type).
- * Even in Dart!
- * Where appropriate, refer to parameters and return values as **nullable** (may
-   contain null) or **non-null** (may not contain null).
-
-### Units
-
-For all parameters and return types, units must be well defined (whether by
-documentation or by type).
-
-## Best Practices
-
-This section contains guidance that should be taken into consideration when
-writing comments.  It contains opinions, rather than the unambiguous rules given
-above.
-
-* A reader should not have to look at an API's implementation to figure out what
-  it does.  Consider writing documentation that would allow a reader to
-  implement your API independently based on the documentation.  If, to do this,
-  a comment needs to provide a level of detail that is not useful to most
-  programmers, consider putting that detail in a separate document and providing
-  a link to that document.
-* Avoid jargon that may not be obvious to the reader (think: "if I am
-  interested in this API, will I definitely know what this word means?").
-* Avoid abbreviations and acronyms.  When you need to use them, explain them.
-  If the abbreviation is widely used in the industry (e.g., "Transmission
-  Control Protocol / Internet Protocol" (TCP/IP)), you do not need to explain
-  it, but you should consider giving a link for more context.
-* Code samples should be considered whenever they might be useful.  Providing
-  an example can often make patterns clearer.  We recommend an example of API
-  for every top level API element (e.g., class).
-* It should be clear how to use your API from the comments.
-  * Consider writing examples as separate programs and linking to them, but be
-    careful about stale links in docs.
-  * Examples should all compile and run.
-* When someone who has read the docs asks a question that should be answered by
-  the docs, improve the docs.
-* If the documentation is very obvious from context, then err on the side of
-  brevity.  The Don't Repeat Yourself (DRY) principle applies.  The following is
-  not useful, because it repeats the same information twice:
-``` java
- /**
-  * Returns an instance of Foo.
-  * @return an instance of Foo.
-  */
- public Foo getFoo() { ... }
-```
-* Similarly, if the comment is very obvious, avoid making it.  If, for example,
-  a property is guaranteed by the type system, you do not need to document it
-  separately.  However, bear in mind that your API description should be enough
-  to enable an independent implementation.
-* Consider documenting performance considerations and resource consumption
-  issues, but also remember that such issues are often implementation dependent
-  and change over time, whereas the contract for your method will probably
-  remain the same.  Consider including this information in implementation notes
-  / release notes instead.
-* Similarly, consider avoiding documenting features that may change over time,
-  unless you specifically call out that feature may change over time.  The more
-  you prescribe, the less flexibility you give to future maintainers.  However,
-  recognize that it might not matter, since your users will depend on every
-  behavior.  See also [Hyrum's Law](http://www.hyrumslaw.com/).
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
diff --git a/development/api/fidl.md b/development/api/fidl.md
index 8210ce9..225b97b 100644
--- a/development/api/fidl.md
+++ b/development/api/fidl.md
@@ -1,1282 +1,7 @@
-# FIDL API Readability Rubric
+# Obsolete
 
-[TOC]
-
-## General Advice
-
-This section contains some general advice about defining interfaces in the
-[Fuchsia Interface Definition Language](../languages/fidl/README.md).
-
-### Protocols not objects
-
-FIDL is a language for defining interprocess communication protocols.  Although
-the syntax resembles a definition of an object-oriented interface, the design
-considerations are more akin to network protocols than to object systems.  For
-example, to design a high-quality interface, you need to consider bandwidth,
-latency, and flow control.  You should also consider that an interface is more
-than just a logical grouping of operations: an interface also imposes a FIFO
-ordering on requests and breaking an interface into two smaller interfaces means
-that requests made on the two different interfaces can be reordered with respect
-to each other.
-
-### Focus on the types
-
-A good starting point for designing your FIDL protocol is to design the data
-structures your protocol will use.  For example, a FIDL protocol about
-networking would likely contain data structures for various types of IP
-addresses and a FIDL protocol about graphics would likely contain data
-structures for various geometric concepts.  You should be able to look at the
-type names and have some intuition about the concepts the protocol manipulates
-and how the interfaces for manipulating those concepts might be structured.
-
-### Language neutrality
-
-There are FIDL backends for many different languages.  You should avoid
-over-specializing your FIDL definitions for any particular target language.
-Over time, your FIDL protocol is likely to be used by many different languages,
-perhaps even some languages that are not even supported today.  FIDL is the
-glue that holds the system together and lets Fuchsia support a wide variety of
-languages and runtimes.  If you over-specialize for your favorite language, you
-undermine that core value proposition.
-
-## Names
-
-```
-The Naming of Cats is a difficult matter,
-It isn't just one of your holiday games;
-  --- T.S. Eliot
-```
-
-Names defined in FIDL are used to generate identifiers in each target language.
-Some languages attach semantic or conventional meaning to names of various
-forms.  For example, in Go, whether the initial letter in an identifier is
-capitalized controls the visibility of the identifier.  For this reason, many of
-the language backends transform the names in your library to make them more
-appropriate for their target language.  The naming rules in this section are a
-balancing act between readability in the FIDL source, usability in each target
-language, and consistency across target languages.
-
-Avoid commonly reserved words, such as `goto`.  The language backends will
-transform reserved words into non-reserved identifiers, but these transforms
-reduce usability in those languages.  Avoiding commonly reserved words reduces
-the frequency with which these transformations are applied.
-
-While some FIDL keywords are also commonly reserved words in target languages,
-(such as `struct` in C and C++), and should thus be avoided, other FIDL keywords,
-particularly `request` and `handle`, are generally descriptive and can be
-used as appropriate.
-
-Names must not contain leading or trailing underscores.  Leading or trailing
-underscores have semantic meaning in some languages (e.g., leading underscores
-control visibility in Dart) and conventional meaning in other languages (e.g.,
-trailing underscores are conventionally used for member variables in C++).
-Additionally, the FIDL compiler uses leading and trailing underscores to munge
-identifiers to avoid collisions.
-
-### Libraries
-
-Library names are period-separated lists of identifiers. Portions of the library
-name other than the last are also referred to as namespaces.  Each component of
-the name is in lowercase and must match the following regular expression:
-`[a-z][a-z0-9]*`.
-
-We use these restrictive rules because different target languages have different
-restrictions on how they qualify namespaces, libraries, or packages.  We have
-selected a conservative least common denominator in order for FIDL to work well
-with our current set of target languages and with potential future target
-languages.
-
-Prefer functional names (e.g., `fuchsia.media`) over product or codenames (e.g.,
-`fuchsia.amber` or `fuchsia.mozart`).  Product names are appropriate when the
-product has some external existence beyond Fuchsia and when the interface is
-specific to that product.  For example, `fuchsia.cobalt` is a better name for
-the Cobalt interface than `fuchsia.metrics` because other metrics
-implementations (e.g., Firebase) are unlikely to implement the same protocol.
-
-FIDL libraries defined in the Fuchsia source tree (i.e., defined in
-fuchsia.googlesource.com) must be in the `fuchsia` top-level namespace (e.g.,
-`fuchsia.ui`) unless (a) the library defines portions of the FIDL language
-itself or its conformance test suite, in which case the top-level namespace must
-be `fidl`, or (b) the library is used only for internal testing and is not
-included in the SDK or in production builds, in which case the top-level
-namespace must be `test`.
-
-FIDL libraries defined in the Fuchsia source tree for the purpose of exposing
-hardware functionality to applications must be in the `fuchsia.hardware`
-namespace.  For example, an interface for exposing an ethernet device might
-be named `fuchsia.hardware.ethernet.Device`.  Higher-level functionality built
-on top of these interfaces does not belong in the `fuchsia.hardware` namespace.
-For example, it is more appropriate for network protocols to be under `fuchsia.net`
-than `fuchsia.hardware`.
-
-Avoid library names with more than two dots (e.g., `fuchsia.foo.bar.baz`).
-There are some cases when a third dot is appropriate, but those cases are rare.
-If you use more than two dots, you should have a specific reason for that
-choice.
-
-Prefer to introduce dependencies from more libraries with more specific names to
-libraries with less specific names rather than the reverse.  For example,
-`fuchsia.foo.bar` might depend on `fuchsia.foo`, but `fuchsia.foo` should not
-depend on `fuchsia.foo.bar`.  This pattern is better for extensibility because
-over time we can add more libraries with more specific names but there are only
-a finite number of libraries with less specific names.  Having libraries with
-less specific names know about libraries with more specific names privileges the
-current status quo relative to the future.
-
-Library names must not contain the following components: `common`, `service`,
-`util`, `base`, `f<letter>l`, `zx<word>`.  Avoid these (and other) meaningless
-names.  If `fuchsia.foo.bar` and `fuchsia.foo.baz` share a number of concepts
-that you wish to factor out into a separate library, consider defining those
-concepts in `fuchsia.foo` rather than in `fuchsia.foo.common`.
-
-### Top-level
-
-Avoid repeating the names from the library name.  For example, in the
-`fuchsia.process` library, an interface that launches process should be named
-`Launcher` rather than `ProcessLauncher` because the name `process` already
-appears in the library name.  In all target languages, top-level names are
-scoped by the library name in some fashion.
-
-### Primitive aliases
-
-Primitive aliases must be named in `lower_snake_case`.
-
-```
-using vaddr = uint64;
-```
-
-Primitive aliases must not repeat names from the enclosing library.  In all
-target languages, primitive aliases are replaced by the underlying primitive
-type and therefore do not cause name collisions.
-
-### Constants
-
-Constants must be named in `ALL_CAPS_SNAKE_CASE`.
-
-```
-const uint64 FOO_BAR = 4096;
-```
-
-Constant names must not repeat names from the enclosing library.  In all target
-languages, constant names are scoped by their enclosing library.
-
-### Interfaces
-
-Interfaces must be named in `UpperCamelCase` and must be noun phrases.  Typically,
-interfaces are named using nouns that suggest an action.  For example,
-`AudioRenderer` is a noun that suggests that the interface is related to
-rendering audio.  Similarly, `Launcher` is a noun that suggests that the
-interface is related to launching something.  Interfaces can also be passive
-nouns, particularly if they relate to some state held by the implementation.
-For example, `Directory` is a noun that suggests that the interface is used for
-interacting with a directory held by the implementation.
-
-Interface may be named using object-oriented design patterns.  For example,
-`fuchsia.fonts.Provider` uses the "provider" suffix, which indicates that the
-interface provides fonts (rather than represents a font itself).  Similarly,
-`fuchsia.tracing.Controller` uses the "controller" suffix, which indicates that
-the interface controls the tracing system (rather than represents a trace
-itself).
-
-The name `Manager` may be used as a name of last resort for an interface with
-broad scope.  For example, `fuchsia.power.Manager`.  However, be warned that
-"manager" interfaces tend to attract a large amount of loosely related
-functionality that might be better factored into multiple interfaces.
-
-Interfaces must not include the name "service."  All interfaces define services.
-The term is meaningless.  For example, `fuchsia.net.oldhttp.HttpService`
-violates this rubric in two ways.  First, the "http" prefix is redundant with
-the library name.  Second, the "service" suffix is banned.  Notice that the
-successor FIDL library, `fuchsia.net.http` simply omits this useless interface.
-
-### Methods
-
-Methods must be named in `UpperCamelCase` and must be verb phrases.  For
-example, `GetBatteryStatus` and `CreateSession` are verb phrases that indicate
-what action the method performs.
-
-Methods on "listener" or "observer" interfaces that are called when an event
-occurs should be prefixed with `On` and describe the event that occurred in the
-past tense.  For example, the `ViewContainerListener` interface has a method
-named `OnChildAttached`.  Similarly, events (i.e., unsolicited messages from the
-server to the client) should be prefixed with `On` and describe the event that
-occurred in the past tense.  For example, the `AudioCapturer` interface has an
-event named `OnPacketCaptured`.
-
-### Parameters
-
-Parameter must be named in `lower_snake_case`.
-
-### Structs and unions
-
-Structs and unions must be named in `UpperCamelCase` and must be noun phrases.
-For example, `Point` is a struct that defines a location in space and
-`KeyboardEvent` is a struct that defines a keyboard-related event.
-
-### Struct and union members
-
-Struct and union members must be named in `lower_snake_case`.  Prefer names with
-a single word when practical because single-word names render more consistently
-across target languages.  However, do not be afraid to use multiple words if a
-single word would be ambiguous or confusing.
-
-Member names must not repeat names from the enclosing type (or library).  For
-example, the `KeyboardEvent` member that contains the time the event was
-delivered should be named `time` rather than `event_time` because the name
-`event` already appears in the name of the enclosing type.  In all target
-languages, member names are scoped by their enclosing type.
-
-### Enums
-
-Enums must be named in `UpperCamelCase` and must be noun phrases.  For example,
-`PixelFormat` is an enum that defines how colors are encoded into bits in an
-image.
-
-### Enum members
-
-Enum members must be named in `ALL_CAPS_SNAKE_CASE`.
-
-Enum member names must not repeat names from the enclosing type (or library).
-For example, members of `PixelFormat` enum should be named `ARGB` rather than
-`PIXEL_FORMAT_ARGB` because the name `PIXEL_FORMAT` already appears in the name
-of the enclosing type.  In all target languages, enum member names are scoped by
-their enclosing type.
-
-## Organization
-
-### Syntax
-
- * Use 4 space indents.
- * Never use tabs.
- * Avoid trailing whitespace.
- * Separate declarations for `struct`, `union`, `enum`, and `interface` constructs from other declarations with one newline.
- * End files with exactly one newline character.
-
-### Comments
-
-Use `// comments` to document your library.  Place comments above the thing
-being described.  Use reasonably complete sentences with proper capitalization
-and periods:
-
-```
-struct Widget {
-    // Widgets must be published with monotonically increasing ids.
-    uint64 id;
-    // Relative to the center.
-    Point location;
-};
-```
-
-Types or values defined by some external source of truth should be commented
-with references to the external thing.  For example, reference the WiFi
-specification that describes a configuration structure.  Similarly, if a
-structure must match an ABI defined in a C header, reference the C header.
-
-If you would like your comments to "flow through" to the target language,
-then use either `///` as the comment introducer (yes, three forward slashes
-in a row) or the `[Doc = "this is a comment"]` attribute:
-
-```fidl
-/// this is a comment that flows through to the target
-
-[Doc = "and so is this"]
-```
-
-#### Flow-through vs. regular comment guidelines
-
-For flow through comments, the `///` form is preferred over the `[Doc = ]`
-form; the latter is intended as an internal implementation hook.
-
-When deciding what should be a regular "`//`" comment versus a flow-through
-comment, keep in mind the following.
-
-Regular comments:
-
- * internal "todo" comments
- * copyright notices
- * implementation details
-
-Flow-through comments:
-
- * descriptions of parameters, arguments, function
- * usage notes
-
-For example:
-
-```fidl
-// TODO -- this function needs additional error checks
-/// WatchedEvent describes events returned from a DirectoryWatcher.
-struct WatchedEvent {
-...
-```
-
-### Files
-
-A library is comprised of one or more files.  The files are stored in a
-directory hierarchy with the following conventions:
-
-```
-fidl/<library>/[<dir>/]*<file>.fidl
-```
-
-The `<library>` directory is named using the dot-separated name of the FIDL
-library.  The `<dir>` subdirectories are optional and typically not used for
-libraries with less than a dozen files.  This directory structure matches how
-FIDL files are included in the Fuchsia SDK.
-
-The division of a library into files has no technical impact on consumers of the
-library.  Declarations, including interfaces, can reference each other and
-themselves throughout the library, regardless of the file in which they appear.
-Divide libraries into files to maximize readability.
-
- * Prefer a DAG dependency diagram for files in a library.
-
- * Prefer keeping mutually referring definitions textually close to each other,
-   ideally in the same file.
-
- * For complex libraries, prefer defining pure data types or constants in leaf
-   files and defining interfaces that reference those types together in a trunk
-   file.
-
-### Ordinals
-
-Interfaces contain a number of methods.  In its declaration, each method is
-assigned a unique 32 bit identifier, called an ordinal.
-
-Interfaces evolve in two directions.  First, an interface can grow new methods,
-with new ordinals.  Second, a superinterface can be extended by a subinterface.
-The subinterface has all of the methods of its superinterface plus its own.
-
-The goal of the guidelines here is to avoid these extension mechanisms
-colliding.
-
- * Never use the zero ordinal. (The compiler forbids the zero ordinal.)
-
- * Ordinals within an interface should be allocated in contiguous blocks. For example:
-   * 0x80000001--0x80000007
-   * 1, 2, 3
-   * 1000--1010, 1100--1112, 1200--1999
-
- * New ordinals in an interface should use the next ordinal in the block. After
-   1, 2, and 3, use 4.
-
- * Related interfaces should consider using nearby and distinct ordinal blocks:
-
- * Interfaces A and B, in the same library, that refer to each other might
-   choose to allocate in blocks 0x100-0x1ff and 0x200-0x2ff respectively.
-
- * Interfaces that expect to be extended by subinterfaces should explicitly
-   claim ordinal blocks in a comment.
-
-### Library structure
-
-Carefully consider how you divide your type and interface definitions into
-libraries.  How you decompose these definitions into libraries has a large
-effect on the consumers of these definitions because a FIDL library is the unit
-of dependency and distribution for your protocols.
-
-The FIDL compiler requires that the dependency graph between libraries is a DAG,
-which means you cannot create a circular dependency across library boundaries.
-However, you can create (some) circular dependencies within a library.
-
-To decide whether to decompose a library into smaller libraries, consider the
-following questions:
-
- * Do the customers for the library break down into separate roles that would
-   want to use a subset of the functionality or declarations in the library?  If
-   so, consider breaking the library into separate libraries that target each
-   role.
-
- * Does the library correspond to an industry concept that has a generally
-   understood structure?  If so, consider structuring your library to match the
-   industry-standard structure.  For example, Bluetooth is organized into
-   `fuchsia.bluetooth.le` and `fuchsia.bluetooth.gatt` to match how these
-   concepts are generally understood in the industry.  Similarly,
-   `fuchsia.net.http` corresponds to the industry-standard HTTP network
-   protocol.
-
- * Do many other libraries depend upon the library?  If so, check whether those
-   incoming dependencies really need to depend on the whole library or whether
-   there is a "core" set of definitions that could be factored out of the
-   library to receive the bulk of the incoming dependencies.
-
-Ideally, we would produce a FIDL library structure for Fuchsia as a whole that
-is a global optimum.  However, Conway's law states that "organizations which
-design systems \[...\] are constrained to produce designs which are copies of the
-communication structures of these organizations."  We should spend a moderate
-amount of time fighting Conway's law.
-
-## Types
-
-As mentioned under "general advice," you should pay particular attention to the
-types you used in your protocol definition.
-
-### Be consistent
-
-Use consistent types for the same concept.  For example, use a uint32 or a int32
-for a particular concept consistently throughout your library.  If you create a
-struct for a concept, be consistent about using that struct to represent the
-concept.
-
-Ideally, types would be used consistently across library boundaries as well.
-Check related libraries for similar concepts and be consistent with those
-libraries.  If there are many concepts shared between libraries, consider
-factoring the type definitions for those concepts into a common library.  For
-example, `fuchsia.mem` and `fuchsia.math` contain many commonly used types for
-representing memory and mathematical concepts, respectively.
-
-### Prefer semantic types
-
-Create structs to name commonly used concepts, even if those concepts could be
-represented using primitives.  For example, an IPv4 address is an important
-concept in the networking library and should be named using a struct even
-through the data can be represented using a primitive:
-
-```
-struct Ipv4Address {
-    array<uint8>:4 octets;
-};
-```
-
-In performance-critical target languages, structs are represented in line, which
-reduces the cost of using structs to name important concepts.
-
-### Consider using fuchsia.mem.Buffer
-
-A Virtual Memory Object (VMO) is a kernel object that represents a contiguous
-region of virtual memory.  VMOs track memory on a per-page basis, which means a
-VMO by itself does not track its size at byte-granularity.  When sending memory
-in a FIDL message, you will often need to send both a VMO and a size.  Rather
-than sending these primitives separately, consider using `fuchsia.mem.Buffer`,
-which combines these primitives and names this common concept.
-
-### Specify bounds for vector and string
-
-Most `vector` and `string` declarations should specify a length bound.  Whenever
-you omit a length bound, consider whether the receiver of the message would
-really want to process arbitrarily long sequences or whether extremely long
-sequences represent abuse.
-
-Bear in mind that declarations that lack an upper bound are implicitly bounded
-by the maximum message length when sent over a `zx::channel`.  If there really
-are use cases for arbitrarily long sequences, simply omitting a bound might not
-address those use cases because clients that attempt to provide extremely long
-sequences might hit the maximum message length.
-
-To address use cases with arbitrarily large sequences, consider breaking the
-sequence up into multiple messages using one of the pagination patterns
-discussed below or consider moving the data out of the message itself, for
-example into a `fuchsia.mem.Buffer`.
-
-### Errors
-
-Select the appropriate error type for your use case and be consistent about how
-you report errors.
-
-Use the `status` type for errors related to kernel objects or IO.  For example,
-`fuchsia.process` uses `status` because the library is largely concerned with
-manipulating kernel objects.  As another example, `fuchsia.io` uses `status`
-extensively because the library is concerned with IO.
-
-Use a domain-specific enum error type for other domains.  For example, use an
-enum when you expect clients to receive the error and then stop rather than
-propagate the error to another system.
-
-If a method can return either an error or a result, use the following pattern:
-
-```
-enum MyStatus { OK; FOO; BAR; ... };
-
-interface Frobinator {
-    1: Frobinate(...) -> (MyStatus status, FrobinateResult? result);
-};
-```
-
-In some unusual situations, interfaces may include a string description of the
-error in addition to a `status` or enum value if the range of possible error
-conditions is large and descriptive error messages are likely to be useful to
-clients.  However, including a string invites difficulties.  For example,
-clients might try to parse the string to understand what happened, which means
-the exact format of the string becomes part of the interface, which is
-especially problematic when the strings are localized.  *Security note:*
-Similarly, reporting stack traces or exception messages to the client can
-unintentionally leak privileged information.
-
-### Should I define a struct to encapsulate method parameters (or responses)?
-
-Whenever you define a method, you need to decide whether  to pass parameters
-individually or to encapsulate the parameters in a struct.  Making the best
-choice involves balancing several factors.  Consider the questions below to help
-guide your decision making:
-
- * Is there a meaningful encapsulation boundary?  If a group of parameters makes
-   sense to pass around as a unit because they have some cohesion beyond this
-   method, you might want to encapsulate those parameters in a struct.
-   (Hopefully, you have already identified these cohesive groups when you
-   started designing your protocol because you followed the "general advice"
-   above and focused on the types early on.)
-
- * Would the struct be useful for anything beyond the method being called?  If
-   not, consider passing the parameters separately.
-
- * Are you repeating the same groups of parameters in many methods?  If so,
-   consider grouping those parameters into one or more structures.  You might
-   also consider whether the repetition indicates that these parameters are
-   cohesive because they represent some important concept in your protocol.
-
- * Are there a large number of parameters that are optional or otherwise are
-   commonly given a default value?  If so, consider using use a struct to reduce
-   boilerplate for callers.
-
- * Are there groups of parameters that are always null or non-null at the same
-   time?  If so, consider grouping those parameters into a nullable struct to
-   enforce that invariant in the protocol itself.  For example, the
-   `FrobinateResult` struct defined above contains values that are always null
-   at the same time when `error` is not `MyError.OK`.
-
-### Should I use string or vector?
-
-In FIDL, `string` data must be valid UTF-8, which means strings can represent
-sequences of Unicode code points but cannot represent arbitrary binary data.  In
-contrast, `vector` or `array` can represent arbitrary binary data and do not
-implicate Unicode.
-
-Use `string` for text data:
-
- * Use `string` to represent package names because package names are required to
-   be valid UTF-8 strings (with certain excluded characters).
-
- * Use `string` to represent file names within packages because file names
-   within packages are required to be valid UTF-8 strings (with certain excluded
-   characters).
-
- * Use `string` to represent media codec names because media codec names are
-   selected from a fixed vocabulary of valid UTF-8 strings.
-
- * Use `string` to represent HTTP methods because HTTP methods are comprised of
-   a fixed selection of characters that are always valid UTF-8.
-
-Use `vector` or `array` for small non-text data:
-
- * Use `vector<uint8>` for HTTP header fields because HTTP header fields do not
-   specify an encoding and therefore cannot necessarily be represented in UTF-8.
-
- * Use `array<uint8>:6` for MAC addresses because MAC address are binary data.
-
- * Use `array<uint8>:16` for UUIDs because UUIDs are (almost!) arbitrary binary
-   data.
-
-Use shared-memory primitives for blobs:
-
- * Use `fuchsia.mem.Buffer` for images and (large) protobufs, when it makes sense
-   to buffer the data completely.
- * Use `handle<socket>` for audio and video streams because data may arrive over
-   time, or when it makes sense to process data before completely written or
-   available.
-
-### Should I use vector or array?
-
-A `vector` is a variable-length sequence that is represented out-of-line in the
-wire format.  An `array` is a fixed-length sequence that is represented in-line
-in the wire format.
-
-Use `vector` for variable-length data:
-
- * Use `vector` for tags in log messages because log messages can have between
-   zero and five tags.
-
-Use `array` for fixed-length data:
-
- * Use `array` for MAC addresses because a MAC address is always six bytes long.
-
-### Should I use a struct or a table?
-
-Structs and tables provide semantically similar notions,
-and so it can seem complicated deciding which to prefer.
-
-For very high level IPCs, or for persistent storage, where
-serialization performance tends not to be a concern:
-- Tables provide some forwards and backwards compatibility, and so offer an
-  element of future proofing: prefer them for most concepts.
-- Take the performance benefits of structs only for concepts that are very
-  unlikely to change in the future (say `struct Vec3 { float x; float y; float z }`,
-  or `Ipv4Address`).
-
-Once serialization performance becomes an overriding concern (this is common on the
-data path for device drivers for example), we can begin to prefer structs only and
-rely on adding new methods to interfaces to account for future changes.
-
-### When should I use an enum?
-
-(Note: This section depends on a proposed FIDL 2.1 feature that makes enums
-extensible.)
-
-Use an enum if the set of enumerated values is bounded and controlled by the
-Fuchsia project.  For example, the Fuchsia project defines the pointer event
-input model and therefore controls the values enumerated by `PointerEventPhase`.
-
-In some scenarios, you should use an enum even if the Fuchsia project itself
-does not control the set of enumerated values if we can reasonably expect that
-people who will want to register new values will submit a patch to the Fuchsia
-source tree to register their values.  For example, texture formats need to be
-understood by the Fuchsia graphics drivers, which means new texture formats can
-be added by developers working on those drivers even if the set of texture
-formats is controlled by the graphics hardware vendors.  As a counter example,
-do not use an enum to represent HTTP methods because we cannot reasonably expect
-people who use novel HTTP methods to submit a patch to the Fuchsia source tree.
-
-For _a priori_ unbounded sets, a `string` might be a more appropriate choice if
-you foresee wanting to extend the set dynamically.  For example, use a `string`
-to represent media codec names because intermediaries might be able to do
-something reasonable with a novel media code name.
-
-If the set of enumerated values is controlled by an external entity, use an
-integer (of an appropriate size) or a `string`.  For example, use an integer (or
-some size) to represent USB HID identifiers because the set of USB HID
-identifiers is controlled by an industry consortium.  Similarly, use a `string`
-to represent a MIME type because MIME types are controlled (at least in theory)
-by an IANA registry.
-
-## Good Design Patterns
-
-This section describes several good design patterns that recur in many FIDL
-protocols.
-
-### Interface request pipelining
-
-One of the best and most widely used design patterns is _interface request
-pipelining_.  Rather than returning a channel that implements an interface, the
-client sends the channel and requests the server to bind an implementation of
-the interface to that channel:
-
-```
-GOOD:
-interface Foo {
-    1: GetBar(string name, request<Bar> bar);
-};
-
-BAD:
-interface Foo {
-    1: GetBar(string name) -> (Bar bar);
-};
-```
-
-This pattern is useful because the client does not need to wait for a round-trip
-before starting to use the `Bar` interface.  Instead, the client can queue
-messages for `Bar` immediately.  Those messages will be buffered by the kernel
-and processed eventually once an implementation of `Bar` binds to the interface
-request.  By contrast, if the server returns an instance of the `Bar` interface,
-the client needs to wait for the whole round-trip before queuing messages for
-`Bar`.
-
-If the request is likely to fail, consider extending this pattern with a reply
-that describes whether the operation succeeded:
-
-```
-interface CodecProvider {
-    1: TryToCreateCodec(CodecParams params, request<Codec> codec) -> (bool succeed);
-};
-```
-
-To handle the failure case, the client waits for the reply and takes some other
-action if the request failed.  Another approach is for the interface to have an
-event that the server sends at the start of the protocol:
-
-```
-interface Codec2 {
-    1: -> OnReady();
-};
-
-interface CodecProvider2 {
-    1: TryToCreateCodec(CodecParams params, request<Codec2> codec);
-};
-```
-
-To handle the failure case, the client waits for the `OnReady` event and takes
-some other action if the `Codec2` channel is closed before the event arrives.
-
-However, if the request is likely to succeed, having either kind of success
-signal can be harmful because the signal allows the client to distinguish
-between different failure modes that often should be handled in the same way.
-For example, the client should treat a service that fails immediately after
-establishing a connection in the same way as a service that cannot be reached in
-the first place.  In both situations, the service is unavailable and the client
-should either generate an error or find another way to accomplishing its task.
-
-### Flow Control
-
-FIDL messages are buffered by the kernel.  If one endpoint produces more
-messages than the other endpoint consumes, the messages will accumulate in the
-kernel, taking up memory and making it more difficult for the system to recover.
-Instead, well-designed protocols should throttle the production of messages to
-match the rate at which those messages are consumed, a property known as _flow
-control_.
-
-The kernel provides some amount of flow control in the form of back pressure on
-channels.  However, most protocols should have protocol-level flow control and
-use channel back pressure as a backstop to protect the rest of the system when
-the protocol fails to work as designed.
-
-Flow control is a broad, complex topic, and there are a number of effective
-design patterns.  This section discusses some of the more popular flow control
-patterns but is not exhaustive.  Protocols are free to use whatever flow control
-mechanisms best suit their use cases, even if that mechanism is not listed
-below.
-
-#### Prefer pull to push
-
-Without careful design, protocols in which the server pushes data to the client
-often have poor flow control.  One approach to providing better flow control is
-to have the client pull one or a range from the server.  Pull models have
-built-in flow control the client naturally limits the rate at which the server
-produces data and avoids getting overwhelmed by messages pushed from the server.
-
-A simple way to implement a pull-based protocol is to "park a callback" with the
-server using the _hanging get pattern_.  In this pattern, the client sends a
-`GetFoo` message, but the server does not reply immediately.  Instead, the
-server replies when a "foo" is available.  The client consumes the foo and
-immediately sends another hanging get.  The client and server each do one unit
-of work per data item, which means neither gets ahead of the other.
-
-The hanging get pattern works well when the set of data items being transferred
-is bounded in size and the server-side state is simple, but does not work well
-in situations where the client and server need to synchronize their work.
-
-#### Throttle push using acknowledgements
-
-One approach to providing flow control in protocols that use the push, is the
-_acknowledgment pattern_, in which the caller provides an acknowledgement
-response that the caller uses for flow control.  For example, consider this
-generic listener interface:
-
-```
-interface Listener {
-    1: OnBar(...) -> ();
-};
-```
-
-The listener is expected to send an empty response message immediately upon
-receiving the `OnBar` message.  The response does not convey any data to the
-caller.  Instead, the response lets the caller observe the rate at which the
-callee is consuming messages.  The caller should throttle the rate at which it
-produces messages to match the rate at which the callee consumes them.  For
-example, the caller might arrange for only one (or a fixed number) of messages
-to be in flight (i.e., waiting for acknowledgement).
-
-#### Events
-
-In FIDL, servers can send clients unsolicited messages called _events_.
-Protocols that use events need to provide particular attention to flow control
-because the event mechanism itself does not provide any flow control.
-
-A good use case for events is when at most one instance of the event will be
-sent for the lifetime of the channel.  In this pattern, the protocol does not
-need any flow control for the event:
-
-```
-interface DeathWish {
-    1: -> OnFatalError(status error_code);
-};
-```
-
-Another good use case for events is when the client requests that the server
-produce events and when the overall number of events produced by the server is
-bounded.  This pattern is a more sophisticated version of the hanging get
-pattern in which the server can respond to the "get" request a bounded number of
-times (rather than just once):
-
-```
-interface NetworkScanner {
-    1: ScanForNetworks();
-    2: -> OnNetworkDiscovered(string network);
-    3: -> OnScanFinished();
-};
-```
-
-If there is no a priori bound on the number of events, consider having the
-client acknowledge the events by sending a message.  This pattern is a more
-awkward version of the acknowledgement pattern in which the roles of client and
-server are switched.  As in the acknowledgement pattern, the server should
-throttle event production to match the rate at which the client consumes the
-events:
-
-```
-interface View {
-    1: -> OnInputEvent(InputEvent event);
-    2: NotifyInputEventHandled();
-};
-```
-
-One advantage to this pattern over the normal acknowledgement pattern is that
-the client can more easily acknowledge multiple events with a single message
-because the acknowledgement is disassociated from the event being acknowledged.
-This pattern allows for more efficient batch processing by reducing the volume
-of acknowledgement messages and works well for in-order processing of multiple
-event types:
-
-```
-interface View {
-    1: -> OnInputEvent(InputEvent event, uint64 seq);
-    2: -> OnFocusChangedEvent(FocusChangedEvent event, uint64 seq);
-    3: NotifyEventsHandled(uint64 last_seq);
-};
-```
-
-### Feed-forward dataflow
-
-Some protocols have _feed-forward dataflow_, which avoids round-trip latency by
-having data flow primarily in one direction, typically from client to server.
-The protocol only synchronizes the two endpoints when necessary.  Feed-forward
-dataflow also increases throughput because fewer total context switches are
-required to perform a given task.
-
-The key to feed-forward dataflow is to remove the need for clients to wait for
-results from prior method calls before sending subsequent messages.  For
-example, interface request pipelining removes the need for the client to wait
-for the server to reply with an interface before the client can use the
-interface.  Similarly, client-assigned identifiers (see below) removes the need
-for the client to wait for the server to assign identifiers for state held by
-the server.
-
-Typically, a feed-forward protocol will involve the client submitting a sequence
-of one-way method calls without waiting for a response from the server.  After
-submitting these messages, the client explicitly synchronizes with the server by
-calling a method such as `Commit` or `Flush` that has a reply.  The reply might
-be an empty message or might contain information about whether the submitted
-sequence succeeded.  In more sophisticated protocols, the one-way messages are
-represented as a union of command objects rather than individual method calls,
-see the _command union pattern_ below.
-
-Protocols that use feed-forward dataflow work well with optimistic error
-handling strategies.  Rather than having the server reply to every method with a
-status value, which encourages the client to wait for a round trip between each
-message, instead include a status reply only if the method can fail for reasons
-that are not under the control of the client.  If the client sends a message
-that the client should have known was invalid (e.g., referencing an invalid
-client-assigned identifier), signal the error by closing the connection.  If the
-client sends a message the client could not have known was invalid, either
-provide a response that signals success or failure (which requires the client to
-synchronize) or remember the error and ignore subsequent dependent requests
-until the client synchronizes and recovers from the error in some way.
-
-Example:
-
-```
-interface Canvas {
-    1: Flush() -> (status code);
-    2: Clear();
-    3: UploadImage(uint32 image_id, Image image);
-    4: PaintImage(uint32 image_id, float x, float y);
-    5: DiscardImage(uint32 image_id);
-    6: PaintSmileyFace(float x, float y);
-    7: PaintMoustache(float x, float y);
-};
-```
-
-### Client-assigned identifiers
-
-Often an interface will let a client manipulate multiple pieces of state held by
-the server.  When designing an object system, the typical approach to this
-problem is to create separate objects for each coherent piece of state held by
-the server.  However, when designing a protocol, using separate objects for each
-piece of state has several disadvantages:
-
-Creating separate interface instances for each logical object consumes kernel
-resources because each interface instance requires a separate channel object.
-Each interface instance maintains a separate FIFO queue of messages.  Using
-separate interface instances for each logical object means that messages sent
-to different objects can be reordered with respect to each other, leading to
-out-of-order interactions between the client and the server.
-
-The _client-assigned identifier pattern_ avoids these problems by having the
-client assign uint32 or uint64 identifiers to objects retained by the server.
-All the messages exchanged between the client and the server are funnelled
-through a single interface instance, which provides a consistent FIFO ordering
-for the whole interaction.
-
-Having the client (rather than the server) assign the identifiers allows for
-feed-forward dataflow because the client can assign an identifier to an object
-and then operate on that object immediately without waiting for the server to
-reply with the object's identifier.  In this pattern, the identifiers are valid
-only within the scope of the current connection, and typically the zero
-identifier is reserved as a sentinel.  *Security note:* Clients should not use
-addresses in their address space as their identifiers because these addresses
-can leak the layout of their address space.
-
-The client-assigned identifier pattern has some disadvantages.  For example,
-clients are more difficult to author because clients need to manage their own
-identifiers.  Developers commonly want to create a client library that provides
-an object-oriented facades for the service to hide the complexity of managing
-identifiers, which itself is an antipattern (see _client libraries_ below).
-
-A strong signal that you should create a separate interface instance to
-represent an object rather than using a client-assigned identifier is when you
-want to use the kernel's object capability system to protect access to that
-object.  For example, if you want a client to be able to interact with an object
-but you do not want the client to be able to interact with other objects,
-creating a separate interface instance means you can use the underlying channel
-as a capability that controls access to that object.
-
-### Command union
-
-In protocols that use feed-forward dataflow, the client often sends many one-way
-messages to the server before sending a two-way synchronization message.  If the
-protocol involves a particularly high volume of messages, the overhead for
-sending a message can become noticeable.  In those situations, consider using the
-_command union pattern_ to batch multiple commands into a single message.
-
-In this pattern, the client sends a `vector` of commands rather than sending an
-individual message for each command.  The vector contains a union of all the
-possible commands, and the server uses the union tag as the selector for command
-dispatch in addition to using the method ordinal number:
-
-```
-struct PokeCmd { int32 x; int32 y; };
-
-struct ProdCmd { string:64 message; };
-
-union MyCommand {
-    PokeCmd poke;
-    ProdCmd prod;
-};
-
-interface HighVolumeSink {
-  1: Enqueue(vector<MyCommand> commands);
-  2: Commit() -> (MyStatus result);
-};
-```
-
-Typically the client buffers the commands locally in its address space and sends
-them to the server in a batch.  The client should flush the batch to the server
-before hitting the channel capacity limits in either bytes and handles.
-
-For protocols with even higher message volumes, consider using a ring buffer in
-a `zx::vmo` for the data plane and an associated `zx::fifo` for the control
-plane.  Such protocols place a higher implementation burden on the client and
-the server but are appropriate when you need maximal performance.  For example,
-the block device protocol uses this approach to optimize performance.
-
-### Pagination
-
-FIDL messages are typically sent over channels, which have a maximum message
-size.  In many cases, the maximum message size is sufficient to transmit
-reasonable amounts of data, but there are use cases for transmitting large (or
-even unbounded) amounts of data.  One way to transmit a large or unbounded
-amount of information is to use a _pagination pattern_.
-
-#### Paginating Writes
-
-A simple approach to paginating writes to the server is to let the client send
-data in multiple messages and then have a "finalize" method that causes the
-server to process the sent data:
-
-```
-interface Foo {
-    1: AddBars(vector<Bar> bars);
-    2: UseTheBars() -> (...);
-};
-```
-
-For example, this pattern is used by `fuchsia.process.Launcher` to let the
-client send an arbitrary number of environment variables.
-
-A more sophisticated version of this pattern creates an interface that
-represents the transaction, often called a _tear-off interface_:
-
-```
-interface BarTransaction {
-    1: Add(vector<Bar> bars);
-    2: Commit() -> (...);
-};
-
-interface Foo {
-    1: StartBarTransaction(request<BarTransaction> transaction);
-};
-```
-
-This approach is useful when the client might be performing many operations
-concurrently and breaking the writes into separate messages loses atomicity.
-Notice that `BarTransaction` does not need an `Abort` method.  The better
-approach to aborting the transaction is for the client to close the
-`BarTransaction` interface.
-
-#### Paginating Reads
-
-A simple approach to paginating reads from the server is to let the server send
-multiple responses to a single request using events:
-
-```
-interface EventBasedGetter {
-    1: GetBars();
-    2: -> OnBars(vector<Bar> bars);
-    3: -> OnBarsDone();
-};
-```
-
-Depending on the domain-specific semantics, this pattern might also require a
-second event that signals when the server is done sending data.  This approach
-works well for simple cases but has a number of scaling problems.  For example,
-the protocol lacks flow control and the client has no way to stop the server if
-the client no longer needs additional data (short of closing the whole
-interface).
-
-A more robust approach uses a tear-off interface to create an iterator:
-
-```
-interface BarIterator {
-    1: GetNext() -> (vector<Bar> bars);
-};
-
-interface ChannelBasedGetter {
-    1: GetBars(request<BarIterator> iterator);
-};
-```
-
-After calling `GetBars`, the client uses interface request pipelining to queue
-the first `GetNext` call immediately.  Thereafter, the client repeatedly calls
-`GetNext` to read additional data from the server, bounding the number of
-outstanding `GetNext` messages to provide flow control.  Notice that the
-iterator need not require a "done" response because the server can reply with an
-empty vector and then close the iterator when done.
-
-Another approach to paginating reads is to use a token.  In this approach, the
-server stores the iterator state on the client in the form of an opaque token,
-and the client returns the token to the server with each partial read:
-
-```
-struct Token { array<uint8>:16 opaque; }
-interface TokenBasedGetter {
-  // If  token  is null, fetch the first N entries. If  token  is not null, return the N items starting at  token
-  // Returns as many entries as it can in  results  and populates  next_token  if more entries are available.
-  1: GetEntries(Token? token) -> (vector<Entry> entries, Token? next_token);
-}
-```
-
-This pattern is especially attractive when the server can escrow all of its
-pagination state to the client and therefore no longer need to maintain
-paginations state at all.  The server should document whether the client can
-persist the token and reuse it across instances of the interface.  *Security
-note:* In either case, the server must validate the token supplied by the client
-to ensure that the client's access is limited to its own paginated results and
-does not include results intended for another client.
-
-### Eventpair correlation
-
-When using client-assigned identifiers, clients identify objects held by the
-server using identifiers that are meaningful only in the context of their own
-connection to the server.  However, some use cases require correlating objects
-across clients.  For example, in `fuchsia.ui.scenic`, clients largely interact
-with nodes in the scene graph using client-assigned identifiers.  However,
-importing a node from another process requires correlating the reference to that
-node across process boundaries.
-
-The _eventpair correlation pattern_ solves this problem using a feed-forward
-dataflow by relying on the kernel to provide the necessary security.  First, the
-client that wishes to export an object creates a `zx::eventpair` and sends one
-of the entangled events to the server along with its client-assigned identifier
-of the object.  The client then sends the other entangled event to the other
-client, which forwards the event to the server with its own client-assigned
-identifier for the now-shared object:
-
-```
-interface Foo {
-    1: ExportThing(uint32 client_assigned_id, ..., handle<eventpair> export_token);
-};
-
-interface Bar {
-    1: ImportThing(uint32 some_other_client_assigned_id, ..., handle<eventpair> import_token);
-};
-```
-
-To correlate the objects, the server calls `zx_object_get_info` with
-`ZX_INFO_HANDLE_BASIC` and matches the `koid` and `related_koid` properties from
-the entangled event objects.
-
-### Eventpair cancellation
-
-When using tear-off transactions, the client can cancel long-running operations
-by closing the client end of the interface.  The server should listen for
-`ZX_CHANNEL_PEER_CLOSED` and abort the transaction to avoid wasting resources.
-
-There is a similar use case for operations that do not have a dedicated channel.
-For example, the `fuchsia.net.http.Loader` interface has a `Fetch` method that
-initiates an HTTP request.  The server replies to the request with the HTTP
-response once the HTTP transaction is complete, which might take a significant
-amount of time.  The client has no obvious way to cancel the request short of
-closing the entire `Loader` interface, which might cancel many other outstanding
-requests.
-
-The _eventpair cancellation pattern_ solves this problem by having the client
-include one of the entangled events from a `zx::eventpair` as a parameter to the
-method.  The server then listens for `ZX_EVENTPAIR_PEER_CLOSED` and cancels the
-operation when that signal is asserted.  Using a `zx::eventpair` is better than
-using a `zx::event` or some other signal because the `zx::eventpair` approach
-implicitly handles the case where the client crashes or otherwise tears down
-because the `ZX_EVENTPAIR_PEER_CLOSED` is generated automatically by the kernel
-when the entangled event retained by the client is destroyed.
-
-### Empty interfaces
-
-Sometimes an empty interface can provide value.  For example, a method that
-creates an object might also receive a `request<FooController>` parameter.  The
-caller provides an implementation of this empty interface:
-
-```
-interface FooController {};
-```
-
-The `FooController` does not contain any methods for controlling the created
-object, but the server can use the `ZX_CHANNEL_PEER_CLOSED` signal on the
-interface to trigger destruction of the object.  In the future, the interface
-could potentially be extended with methods for controlling the created object.
-
-## Antipatterns
-
-This section describes several antipatterns: design patterns that often provide
-negative value.  Learning to recognize these patterns is the first step towards
-avoiding using them in the wrong ways.
-
-### Client libraries
-
-Ideally, clients interface with protocols defined in FIDL using
-language-specific client libraries generated by the FIDL compiler.  This
-approach lets Fuchsia provide high-quality support for a large number of target
-languages, but sometimes the protocol is too low-level to program directly and
-a a hand-written client library is appropriate to provide an interface to the
-same underlying protocol that is easier to use correctly.
-
-For example, `fuchsia.io` has a client library, `libfdio.so`, which provides a
-POSIX-like frontend to the protocol.  Clients that expect a POSIX-style
-`open`/`close`/`read`/`write` interface can link against `libfdio.so` and speak
-the `fuchsia.io` protocol with minimal modification.  This client library
-provides value because the library adapts between an existing library interface
-and the underlying FIDL protocol.
-
-Another kind of client library that provides positive value is a framework.  A
-framework is an extensive client library that provides a structure for a large
-portion of the application.  Typically, a framework provides a significant
-amount of abstraction over a diverse set of protocols.  For example, Flutter is
-a framework that can be viewed as an extensive client library for the
-`fuchsia.ui` protocols.
-
-FIDL protocols should be fully documented regardless of whether the protocol has
-an associated client library.  An independent group of software engineers should
-be able to understand and correctly use the protocol directly given its
-definition without need to reverse-engineer the client library.  When the
-protocol has a client library, aspects of the protocol that are low-level and
-subtle enough to motivate you to create a client library should be documented
-clearly.
-
-The main difficulty with client libraries is that they need to be maintained for
-every target language, which tends to mean client libraries are missing (or
-lower quality) for less popular languages.  Client libraries also tend to ossify
-the underlying protocols because they cause every client to interact with the
-server in exactly the same way.  The servers grow to expect this exact
-interaction pattern and fail to work correctly when clients deviate from the
-pattern used by the client library.
-
-In order to include the client library in the Fuchsia SDK, we should provide
-implementations of the library in at least two languages.
-
-### Service hubs
-
-A _service hub_ is a `Discoverable` interface that simply lets you discover a
-number of other interfaces, typically with explicit names:
-
-```
-BAD:
-[Discoverable]
-interface ServiceHub {
-    1: GetFoo(request<Foo> foo);
-    2: GetBar(request<Bar> bar);
-    3: GetBaz(request<Baz> baz);
-    4: GetQux(request<Qux> qux);
-};
-```
-
-Particularly if stateless, the `ServiceHub` interface does not provide much
-value over simply making the individual services discoverable directly:
-
-```
-[Discoverable]
-interface Foo { ... };
-
-[Discoverable]
-interface Bar { ... };
-
-[Discoverable]
-interface Baz { ... };
-
-[Discoverable]
-interface Qux { ... };
-```
-
-Either way, the client can establish a connection to the enumerated services.
-In the latter case, the client can discover the same services through the normal
-mechanism used throughout the system to discover services.  Using the normal
-mechanism lets the core platform apply appropriate policy to discovery.
-
-However, service hubs can be useful in some situations.  For example, if the
-interface were stateful or was obtained through some process more elaborate than
-normal service discovery, then the interface could provide value by transferring
-state to the obtained services.  As another example, if the methods for
-obtaining the services take additional parameters, then the interface could
-provide value by taking those parameters into account when connecting to the
-services.
-
-### Overly object-oriented design
-
-Some libraries create separate interface instances for every logical object in
-the protocol, but this approach has a number of disadvantages:
-
- * Message ordering between the different interface instances is undefined.
-   Messages sent over a single interface are processed in FIFO order (in each
-   direction), but messages sent over different channels race.  When the
-   interaction between the client and the server is spread across many channels,
-   there is a larger potential for bugs when messages are unexpectedly
-   reordered.
-
- * Each interface instance has a cost in terms of kernel resources, waiting
-   queues, and scheduling.  Although Fuchsia is designed to scale to large
-   numbers of channels, the costs add up over the whole system and creating a
-   huge proliferation of objects to model every logical object in the system
-   places a large burden on the system.
-
-* Error handling and teardown is much more complicated because the number of
-  error and teardown states grows exponentially with the number of interface
-  instances involved in the interaction.  When you use a single interface
-  instance, both the client and the server can cleanly shut down the interaction
-  by closing the interface.  With multiple interface instances, the interaction
-  can get into states where the interaction is partially shutdown or where the
-  two parties have inconsistent views of the shutdown state.
-
- * Coordination across interface boundaries is more complex than within a single
-   interface because protocols that involve multiple interfaces need to allow
-   for the possibility that different interfaces will be used by different
-   clients, who might not completely trust each other.
-
-However, there are use cases for separating functionality into multiple
-interfaces:
-
- * Providing separate interfaces can be beneficial for security because some
-   clients might have access to only one of the interfaces and thereby be
-   restricted in their interactions with the server.
-
- * Separate interfaces can also more easily be used from separate threads.  For
-   example, one interface might be bound to one thread and another interface
-   might be bound to another thread.
-
- * Clients and servers pay a (small) cost for each method in an interface.
-   Having one giant interface that contains every possible method can be less
-   efficient than having multiple smaller interfaces if only a few of the
-   smaller interfaces are needed at a time.
-
- * Sometimes the state held by the server factors cleanly along method
-   boundaries.  In those cases, consider factoring the interface into smaller
-   interfaces along those same boundaries to provide separate interfaces for
-   interacting with separate state.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-A good way to avoid over object-orientation is to use client-assigned
-identifiers to model logical objects in the protocol.  That pattern lets clients
-interact with a potentially large set of logical objects through a single
-interface.
diff --git a/development/api/system.md b/development/api/system.md
index 13d2eea..225b97b 100644
--- a/development/api/system.md
+++ b/development/api/system.md
@@ -1,168 +1,7 @@
-# Zircon System Interface Rubric
+# Obsolete
 
-The Zircon system interface is expressed as the `libzircon.so` vDSO API surface.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-Functions that are part of the interface must have names that start with `zx_`
-and preprocessor macros must have names that start with `ZX_`.  Types defined as
-part of the interface must have names that begin with `zx_` and end with `_t`.
-
-Every function that is part of the interface must be documented with a markdown
-file in https://fuchsia.googlesource.com/zircon/+/master/docs/syscalls/ and
-linked from https://fuchsia.googlesource.com/zircon/+/master/docs/syscalls.md .
-
-## Function Names
-
-Functions must have names consisting entirely of lowercase letters and
-underscores and that conform to the following grammar:
-
-```
-zx_<noun>_<verb>{_<direct-object>}
-```
-
-For example:
-
-```
-zx_handle_close, zx_channel_write, zx_object_signal_peer
-```
-
-Typically, the noun is a kernel object type but can be other nouns, such as
-`clock` or `ticks` for which there is no corresponding kernel object. Other
-functions use more abstract nouns, such as `system` or `status`.
-
-The nouns and verbs must not contain underscores (to avoid confusing the
-grammar). The noun and verb should each be single English words but acronyms (or
-abbreviations) may be used if there is no suitable word or the word is too long.
-
-The direct object may contain underscores.
-
-Some functions perform composite operations. In such cases, the function may be
-named by concatenating the names of the component operations.
-
-Some functions operate on several types of kernel object, in which case the noun
-is a more abstract object type. For example, functions with the noun `object`
-operate on most kernel objects and functions with the noun `task` operate on
-jobs, processes, and threads.
-
-## Types
-
-Use `zx_status_t` to represent success and failure.
-
-Use fixed-size integer types. Functions must not use `short`, `int`, or
-`unsigned long` (or similar types). Instead, use types such as `int16_t`,
-`int32_t`, and `uint64_t`.
-
-Use `size_t` for buffer lengths, element sizes, and element counts.
-
-Use `void*` for pointers to arbitrary types in the caller's address space. Use
-`zx_vaddr_t` / `zx_paddr_t` for addresses that might be in other address spaces.
-
-Use `zx_time_t` for timeouts, which must be expressed as absolute deadlines in
-nanoseconds in the `ZX_CLOCK_MONOTONIC` timebase. In scenarios were absolute
-deadlines do not make sense (for example, timer slack), use `zx_duration_t` to
-represent an amount of time in nanoseconds with no specific timebase.
-
-## Parameters
-
-### Receiver
-
-The vast majority of functions act on a handle, which is a reference to a kernel
-object of a type matching the *noun* in the function name. This handle is the
-first argument to such functions and is referred to as the receiver.
-
-Use the name `handle` for the receiver.
-
-Object creation functions (eg, `zx_channel_create`, `zx_event_create`) may not
-take a handle argument. These functions implicitly operate on the current
-process.
-
-### Options Parameter
-
-Often functions include an `options` parameter to allow for flags which affect
-the operation, and include room for further flags being added to future
-revisions of the API.
-
-Use the type `uint32_t` and the name `options` for the `options` parameter.
-
-When present, an `options` parameter must be the first argument after the
-receiver handle or the first argument overall if the function does not have a
-receiver.
-
-An `options` parameter is not required for all functions.
-
-Individual option values must be defined as preprocessor macros that cast a
-numeric literal to `uint32_t`. The options must be bit flags that can be
-combined using the bitwise `|` operator.
-
-### Handles
-
-When a function is given a handle as a parameter, the function must either
-always consume the handle or never consume, with the following exceptions:
-
- * If the function takes an `options` parameter, the function may have a
-   non-default option to avoid consuming handles in various error conditions.
-
- * If the function does not take an `options` parameter, the function may avoid
-   consuming handles if/when it returns `ZX_ERR_SHOULD_WAIT`.
-
-### Buffers with Data, Count/Size, and/or Actual
-
-Always accompany arrays or buffers with a count or size (of type `size_t`),
-including strings. If the buffer is written by the function, the function must
-have an out parameter that returns the count or size of the data written.
-
-For read and write style operations, the pointer(s) to the buffer(s) are
-followed by the buffer count(s) or size(s), and if a short read or write is
-possible, an out parameter provides the actual count(s) or size(s) on success:
-
-```
-zx_status_t zx_socket_write(zx_handle_t handle, uint32_t options,
-                            const void* buffer, size_t size, size_t* actual);
-```
-
-When there are multiple buffers, the buffers, lengths, and out parameters appear
-interleaved in a consistent order. For example, see `zx_channel_read`:
-
-```
-zx_status_t zx_channel_read(zx_handle_t handle, uint32_t options,
-                            void* bytes, zx_handle_t* handles,
-                            uint32_t num_bytes, uint32_t num_handles,
-                            uint32_t* actual_bytes, uint32_t* actual_handles);
-```
-
-### Outputs
-
-An out parameter is a scalar value written by the function. For example, a
-function that returns the number of CPUs by writing to a `uint32_t` has an out
-parameter. If the function populates a buffer provided by the client, the buffer
-isn’t an out parameter.
-
-Out parameters always come at the end of the parameter list.
-
-An out parameter must not also be an in parameter. For example, if a function
-has an out parameter through which it returns the number of bytes written to a
-buffer, that parameter must not also be used by the function to receive the
-length of the buffer from the caller.
-
-## Return Type
-
-The vast majority of functions have a return type of `zx_status_t`, which is
-`ZX_OK` on success and `ZX_ERR_...` on failure.
-
-Do not return other values through `zx_status_t`, for example using the
-positive value range. Instead, use an out parameter.
-
-Other return types may be used for functions that cannot fail. For example,
-`zx_thread_exit` never fails to exit the thread and has a return type of void.
-Similarly, `zx_clock_get` cannot fail to get the current time and has a return
-type of `zx_time_t`.
-
-## Function-specific rules
-
-### zx_object_get_property versus zx_object_get_info
-
-There are two similar mechanisms for exposing data about objects:
-`zx_object_get_property` and `zx_object_get_info`. Prefer exposing data through
-`zx_object_get_property` if (a) the property can be set using
-`zx_object_set_property` or (b) the property exist across multiple types of
-objects. In other case, consider including the data in the general
-`zx_object_get_info` topic for the type of object that has the property.
diff --git a/development/api/tools.md b/development/api/tools.md
index 3217b8a..225b97b 100644
--- a/development/api/tools.md
+++ b/development/api/tools.md
@@ -1,9 +1,7 @@
-This section provides guidelines on *creating* CLI and GUI tools for
-Fuchsia.
+# Obsolete
 
-For information on *existing* tools, please refer to documentation for those
-tools.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-- [Command-line tool requirements](cli.md)
-    - [CLI --help requirements](cli_help.md)
-- GUI Tool requirements
\ No newline at end of file
diff --git a/development/benchmarking/catapult_user_guide.md b/development/benchmarking/catapult_user_guide.md
index 8475155..225b97b 100644
--- a/development/benchmarking/catapult_user_guide.md
+++ b/development/benchmarking/catapult_user_guide.md
@@ -1,86 +1,7 @@
-# Catapult User Guide (Version 1)
+# Obsolete
 
-* Updated: 2018 July 27
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-[TOC]
-
-## Overview
-
-The Catapult dashboard is the UI we send benchmark results to for monitoring and
-visualization.  The dashboard is maintained by the Chrome team.  This a short guide on how
-to find and use the results of your benchmarks in the dashboard.
-
-
-## Accessing the Dashboard
-
-*** promo
-**Be sure to sign into your google.com account or else Fuchsia data will be hidden.**
-
-The login button is in the top right corner of the screen.
-***
-
-The dashboard can be found at https://chromeperf.appspot.com/report.
-
-## Searching and Adding Graphs
-
-The dashboard displays a list of search boxes.  The placeholder names are relics from the
-days when Chrome infrastructure was still using BuildBot.  Since they are not relevant to
-Fuchsia infrastructure, we map our own data into these fields with the following scheme:
-
-* `Test suite` == the name of the benchmark suite.
-* `Bot` == A Fuchsia LUCI builder that has run the benchmark at least once.
-* `Subtest` == The name of the test case in your benchmark suite.
-
-Type the name of your benchmark suite in the first box to begin searching.   As an
-example, we can see the zircon_benchmarks suite if we type "zircon"
-
-![test_suite_example](/images/benchmarking/test_suite_example.png "test_suite_example")
-
-Select a builder and a subtest.  Note that if your subtest is named "foo", there will be
-multiple "foo_<metric_name>" subtests to choose from.  Each of these represents a metric
-computed from the sample(s) of that subtest.   For example: if "foo" generates N sample
-points each time the benchmark is run, then the subtest "foo_avg" is a plot of the
-averages of these N samples.
-
-When you're finished filling out each field, click "Add" to add your graph to the UI.
-You should see something like this:
-
-![graph_example](/images/benchmarking/graph_example.png "graph_exmaple")
-
-
-## Viewing sample metadata
-
-If you hover over a point in a graph, you can see some extra information such as the
-point's value, the date it was recorded, and a link to the log page of the build that
-generated it.
-
-![tooltip_example](/images/benchmarking/tooltip_example.png "tooltip_example")
-
-
-## Saving the View
-
-v1 of the Catapult dashboard UI does not have a built in mechanism for saving a collection
-of Graphs.  If you want to save a list of graphs so that you can share with others or
-re-open the list later, you can copy the URL from the Chrome Address Bar.
-
-Beware, you will have to re-copy the URL each time you add, modify or remove a graph. This
-includes moving the green slider beneath a graph or making any selections in the box to
-the right of the graph.
-
-
-## Enabling Regression Detection
-
-To enable regression detection, you must enable "monitoring" for a test by clicking the
-"Request Monitoring for Tests" button under the "Report issue" dropdown at the top of the
-page.
-
-![monitoring_button_example](/images/benchmarking/monitoring_button_example.png "monitoring_button_example")
-
-This will open a bug form you can fill out to enable monitoring for a benchmark.  The
-Chrome team has a Sheriff rotation (oncall rotation) to triage regression alerts.  The
-dashboard only allows triaging bugs in monorail, so we'll have to make due without JIRA
-support.
-
-See this link for more information about the [Sheriff rotation]
-
-[Sheriff rotation]: https://chromium.googlesource.com/chromium/src/+/master/docs/speed/perf_regression_sheriffing.md
diff --git a/development/benchmarking/results_schema.md b/development/benchmarking/results_schema.md
index 9528f3d..225b97b 100644
--- a/development/benchmarking/results_schema.md
+++ b/development/benchmarking/results_schema.md
@@ -1,88 +1,7 @@
-# Benchmark Results Schema
+# Obsolete
 
-* Updated: 2018 August 9
-
-[TOC]
-
-This document describes the JSON schema that Fuchsia benchmark results must
-follow in order to be uploaded to the performance dashboard.
-
-## Helper Libraries
-
-If you're creating a [trace-based benchmark], your exported results will
-already have the correct schema.
-
-If you're writing your own benchmark program, then you can use the existing
-Fuchsia libraries for your language for emitting the JSON data:
-
-* [C/C++]
-* [Go]
-
-NOTE: If your benchmark is in a different language, please provide a reuseable
-library or file a bug against IN to request one.
-
-[C/C++]: https://fuchsia.googlesource.com/zircon/+/master/system/ulib/perftest
-[Go]: https://fuchsia.googlesource.com/garnet/+/master/go/src/benchmarking
-[Dart]: #
-[trace-based benchmark]: trace_based_benchmarking.md
-
-## JSON Description
-
-```json
-[
-    {
-        "label":       string     // Name of the test case in the performance dashboard.
-        "test_suite":  string     // Name of the test suite in the performance dashboard.
-        "unit":        string     // One of the supported units (see below)
-        "values":      [v1, v2..] // Numeric values collected in this test case
-        "split_first": bool       // Whether to split the first element in |values| from the rest.
-    },
-    {
-        ...
-    }
-]
-```
-
-## Supported Units:
-
-In order to convert benchmark results to the format required by the performance
-dashboard, `unit` must be one of the following strings, which describe the units
-of the result's `values`.
-
-* `nanoseconds`  or `ns`
-* `milliseconds` or `ms`
-* `bytes/second`
-* `bytes`
-
-
-### Example
-
-```json
-[
-    {
-        "label": "Channel/WriteRead/64bytes",
-        "test_suite": "fuchsia.zircon_benchmarks",
-        "unit": "nanoseconds",
-        "values": [105.45, 697.916667, 672.743056],
-        "split_first": true
-    },
-    {
-        "label":"Channel/WriteRead/1024bytes",
-        "test_suite":"fuchsia.zircon_benchmarks",
-        "unit":"nanoseconds",
-        "values":[102.23, 1004.340278, 906.250000],
-        "split_first": true
-    }
-]
-```
-
-## split_first behavior
-
-split_first is useful when the first value in the test results is usually skewed
-due to external influence on the test (e.g. empty caches).  When true, benchmark
-results will appear as two separate series in the performance dashboard:
-
-1. `$label/samples_0_to_0` which tracks the first element in `values`, and
-1. `$label/samples_1_to_N` which tracks the remaining `values`.
-
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
diff --git a/development/benchmarking/running_on_ci.md b/development/benchmarking/running_on_ci.md
index 60aa5a7..225b97b 100644
--- a/development/benchmarking/running_on_ci.md
+++ b/development/benchmarking/running_on_ci.md
@@ -1,83 +1,7 @@
-# How to write benchmarks
+# Obsolete
 
-* Updated: 2018 August 9
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-[TOC]
-
-
-## Overview
-
-This guide will walk you through the process of writing a benchmark, running it at every
-commit, and automatically tracking the results in the [Performance Dashboard].
-
-Today we support automating benchmarks for these projects:
-* Garnet (Also runs Zircon benchmarks)
-* Peridot
-* Topaz
-
-## Writing a benchmark
-
-Fuchsia benchmarks are command-line executables that produce a JSON results file.  The
-executable must meet the following criteria:
-
-1. It accepts the location to the results file as a command line flag.
-2. It produces JSON results that match the [benchmark results schema]:
-
-## Building your benchmark
-
-Your benchmark executable should be built into a Fuchsia package.  For more information
-please read the [Fuchsia package documentation].
-
-## Automating your benchmark
-
-We have shell scripts that run all of a layer's benchmarks at every commit to that layer.
-
-* Garnet: [//garnet/tests/benchmarks](https://fuchsia.googlesource.com/garnet/+/master/tests/benchmarks)
-* Peridot: [//peridot/tests/benchmarks](https://fuchsia.googlesource.com/peridot/+/master/tests/benchmarks)
-* Topaz: [//topaz/tests/benchmarks](https://fuchsia.googlesource.com/topaz/+/master/tests/benchmarks)
-
-These shell scripts are written using a helper library called [Runbenchmarks].  Add a
-command to the appropriate script to execute your test.  See the existing commands for
-examples.
-
-## Testing
-
-At this point, you're ready to build Fuchsia and test that your benchmark runs
-successfully. Run the following in a shell:
-
-```sh
-fx set-petal $layer
-jiri update -gc
-# Benchmarks are not included in production packages, so use $layer/packages/kitchen_sink
-# or they will not be built.
-fx set <arch> --packages $layer/packages/kitchen_sink
-fx full-build && fx run
-```
-
-Once the Fuchsia shell is loaded:
-
-```sh
-# Run just your benchmark
-run my_benchmark [options]
-
-# Run all benchmarks for $layer
-/pkgfs/packages/${layer}_benchmarks/0/bin/benchmarks.sh /tmp
-```
-
-If no errors occurred, you should see your benchmark's output file in `/tmp`, along with
-the results files of other benchmarks.
-
-## Tracking in the performance dashboard
-
-Please see the [Performance Dashboard User Guide]
-
-NOTE: We do not yet have a User guide for the [Performance Dashboard Version 2].
-
-[benchmark results schema]: results_schema.md
-[Fuchsia package documentation]: /development/build/packages.md
-[Performance Dashboard]: https://chromeperf.appspot.com/report
-[Performance Dashboard User Guide]: catapult_user_guide.md
-[Performance Dashboard Version 2]: https://v2spa-dot-chromeperf.appspot.com/
-[Runbenchmarks]: https://fuchsia.googlesource.com/garnet/+/master/testing/runbenchmarks
-[//zircon/system/ulib/perftest]: https://fuchsia.googlesource.com/zircon/+/master/system/ulib/perftest/
-[//garnet/go/src/benchmarks]: https://fuchsia.googlesource.com/garnet/+/master/go/src/benchmarks
diff --git a/development/benchmarking/trace_based_benchmarking.md b/development/benchmarking/trace_based_benchmarking.md
index cf19d7b..225b97b 100644
--- a/development/benchmarking/trace_based_benchmarking.md
+++ b/development/benchmarking/trace_based_benchmarking.md
@@ -1,199 +1,7 @@
-# Trace-based benchmarking
+# Obsolete
 
-* Updated: 2018 Sep 18
-
-This document describes how to use trace-based benchmarking to measure and track
-performance of Fuchsia apps.
-
-[TOC]
-
-## Overview
-
-Trace-based benchmarks measure the performance of an application by running it
-under [tracing] and analyzing the collected traces to
-compute performance metrics.
-
-For a typical **service** application (application to which clients connect over
-FIDL), the following components participate in a benchmarking run:
-
- - **service binary** - the service being benchmarked.
- - **benchmark app** - a client app that connects to the service and
-     exercises the usage patterns we are interested in benchmarking.
- - **benchmark spec** - a JSON file specifying which trace events captured
-     during a run of the benchmark app should be measured, and how.
-
-The same framework can be also used to benchmark single binaries (without the
-client-server split).
-
-## Mechanics
-
-Trace-based benchmarks are run using the `trace` binary. The spec file needs to be
-passed to the tool as follows:
-
-```sh
-trace record --spec-file=<path to the spec file>
-```
-
-### Specification file
-
-The specification file configures tracing parameters and specifies measurements.
-(see [examples/benchmark] if you'd like to see a full example straight away)
-
-The file supports the following top level-parameters:
-
- - `app`: string, url of the application to be run
- - `args`: array of strings, startup arguments to be passed to the application
- - `categories`: array of strings, tracing categories to be enabled
- - `duration`: integer, maximum duration of tracing in seconds
- - `measure`: array of measurement specifications, see below
-
-Given the specification file, the `trace` tool runs the `app` with the given
-`args` for at most `duration` seconds and gathers trace events from the selected
-`categories`. Then, the tool computes the measurements specified in the
-`measure` section on the recorded trace events.
-
-Example:
-
-```{json}
-{
-  "app": "benchmark_example",
-  "args": [],
-  "categories": ["benchmark"],
-  "measure": [
-    ...
-  ]
-}
-```
-
-For any tracing parameters that can be passed both as arguments to `trace record`
-and set in the specification file, the command line value overrides the one from
-the file.
-
-
-### Measurement types
-
-The `trace` tool supports the following types of measurements:
-
- - `duration`
- - `time_between`
- - `argument_value`
-
-A `duration` measurement targets a single trace event and computes the
-duration of its occurrences. The target trace event can be recorded as a
-duration, an async, or a flow event.
-
-**Example**:
-
-```{json}
-    {
-      "type": "duration",
-      "event_name": "example",
-      "event_category": "benchmark"
-    },
-```
-
-
-A `time_between` measurement targets two trace events with the specified
-anchors (either the beginning or the end of the events) and computes the time
-between the consecutive occurrences of the two. The target events can be
-"duration", "async", "flow" or "instant" (in which case the anchor doesn't matter).
-Takes arguments: `first_event_name`, `first_event_category`,
-`first_event_anchor`, `second_event_name`, `second_event_category`,
-`second_event_anchor`.
-
-**Example**:
-
-```{json}
-    {
-      "type": "time_between",
-      "first_event_name": "task_end",
-      "first_event_category": "benchmark",
-      "second_event_name": "task_start",
-      "second_event_category": "benchmark"
-    }
-```
-
-In the example above the `time_between` measurement captures the time between
-the two instant events and measures the time between the end of one task and
-the beginning of another.
-
-
-An `argument_value` measurement is used to record a value of an argument passed
-to the trace event. Takes as arguments a name and category of the event, name of
-the argument to be recorded and unit in which it is measured. The type of trace
-event doesn't matter, but the recorded argument must have `uint64` type.
-
-**Example**:
-
-```{json}
-    {
-      "type": "argument_value",
-      "event_name": "example",
-      "event_category": "benchmark",
-      "argument_name": "disk_space_used",
-      "argument_unit": "Mb"
-    }
-```
-
-### Samples
-
-It is possible to specify an exact number of expected samples. In order to do
-so, an optional parameter `"expected_sample_count"` with a positive value must be
-specified for a given measurement. In that case, if the number of recorded
-samples does not match the one provided, an error will be logged and the
-measurement will produce no results (failing the benchmark).
-
-You can also specify the `"split_first"` flag to separate the first sample from
-the rest. This is useful for recording the "cold run" samples (see the
-[best practices] section). This flag is passed to the exported file as well, in
-compliance with the [results schema].
-
-### Full example
-
-See [examples/benchmark] for a full example of a traced-based benchmark.
-
-
-This example can be run with the following command:
-```{shell}
-trace record --spec-file=/pkgfs/packages/benchmark/0/data/benchmark_example.tspec
-```
-
-## Best practices
-
-### Consider reusing benchmark binaries
-
-The separation between specification files and benchmark binaries allows to
-define multiple benchmarks based on a single benchmark binary. Note that you can
-parametrize the benchmark binary by taking command line arguments which can be
-set to different values in each spec file.
-
-### Record "cold run" samples separately
-
-For any duration measurement that happens more than once, chances are that the
-first time has different performance characteristics that the subsequent ones.
-You can set `"split_first": true` to report and track the first sample
-separately.
-
-## Results
-
-By default, the results are printed on the command line in a human-friendly
-format.
-
-### Export
-
-If you prefer a machine-friendly format, pass the path to the output file to
-`trace record` as `--benchmark-results-file=<file>`.  See the [results schema]
-for the format of the resulting file.
-
-### Dashboard upload
-
-Dashboard upload integration and infra support is WIP as of March, 2018.  See
-the [dashboard user guide] and the instructions for [automating benchmarks].
-
-[automating benchmarks]: running_on_ci.md
-[dashboard user guide]: catapult_user_guide.md
-[examples/benchmark]: https://fuchsia.googlesource.com/garnet/+/master/examples/benchmark/
-[results schema]: results_schema.md
-[best practices]: #best-practices
-[tracing]: https://fuchsia.googlesource.com/garnet/+/master/docs/tracing_usage_guide.md
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
diff --git a/development/build/README.md b/development/build/README.md
index 1fc86ee..225b97b 100644
--- a/development/build/README.md
+++ b/development/build/README.md
@@ -1,9 +1,7 @@
-# Build system
+# Obsolete
 
-- [Overview](overview.md)
-- [Packages](packages.md)
-- [Runtime Build Information](build_information.md)
-- [Layout of "packages" directories](package_layout.md)
-- [Variants](variants.md)
-- [Toolchain](toolchain.md)
-- [Tools & dashboards](tools-dashboards.md)
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
+
diff --git a/development/build/build_information.md b/development/build/build_information.md
index 73636cc..225b97b 100644
--- a/development/build/build_information.md
+++ b/development/build/build_information.md
@@ -1,49 +1,7 @@
-# Fuchsia Build Information
+# Obsolete
 
-We collection metrics and error reports from devices in a few ways: Cobalt, feedback reports, crashpad crashes, manual reports from developers and QA.  Interpreting these signals requires knowing where they are generated from to varying levels of detail.  This document describes the places where version information about the system are stored for use in these types of reports.  Note that this information only applies to the base system - dynamically or ephemerally added software will not be included here.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-To access this data, add the feature "build-info" to the [component manifest](../../the-book/package_metadata.md#component-manifest) of the component that needs to read these fields.
-
-
-# Product
-## Location
-`/config/build-info/product`
-
-## Description
-String describing the product configuration used at build time.  Defaults to the value passed to “--products” in fx set.
-Example: “garnet/products/default.gni”, “topaz/products/dashboard.gni”
-
-# Board
-## Location
-`/config/build-info/board`
-
-## Description
-String describing the board configuration used at build time to specify the target hardware.  Defaults to the value passed to “--boards” in fx set.
-Example: “garnet/boards/x64.gni”
-
-# Version
-## Location
-`/config/build-info/version`
-
-## Description
-String describing the version of the build.  Defaults to the same string used currently in ‘last-update’.  Can be overridden by build infrastructure to provide a more semantically meaningful version, e.g. to include the release train the build was produced on.
-
-# Last-update
-## Location
-`/config/build-info/last-update`
-
-## Description
-String containing a timestamp of the most recent time ‘jiri update’ was executed.  Example: “2018-11-06T14:47:59-08:00”.
-
-# Snapshot
-## Location:
-`/config/build-info/snapshot`
-
-## Description
-Jiri snapshot of the most recent ‘jiri update’
-
-# Kernel version
-## Location:
-Stored in vDSO.  Accessed through [`zx_system_get_version`]( https://fuchsia.googlesource.com/zircon/+/master/docs/syscalls/system_get_version.md)
-
-Zircon revision computed during the kernel build process.
diff --git a/development/build/overview.md b/development/build/overview.md
index c676a0c..225b97b 100644
--- a/development/build/overview.md
+++ b/development/build/overview.md
@@ -1,230 +1,7 @@
-# The build system
+# Obsolete
 
-## Overview
-
-The Fuchsia build system aims at building both boot images and installable
-packages for various devices. To do so, it uses [GN][gn-main], a meta-build
-system that generates build files consumed by [Ninja][ninja-main], which
-executes the actual build. [Using GN build][gn-preso] is a good intro to GN.
-
-Note that Zircon uses an entirely different build system based on GNU Make.
-The rest of the build relies on Zircon being built ahead of time.
-
-## Products
-
-The contents of the generated image are controlled by a set of top level
-products. Products define sets of packages that are included in boot and
-system update images, preinstalled in paver images, and installable using the
-update system. [products](products.md) documents the structure and usage of
-fields in product definitions.
-
-## Packages
-
-The contents of products are packages, which may aggregate or reference other
-packages and GN labels that are to be built. See [packages](packages.md)
-for more information.
-
-## Build targets
-
-Build targets are defined in `BUILD.gn` files scattered all over the source
-tree. These files use a Python-like syntax to declare buildable objects:
-``` py
-import("//build/some/template.gni")
-
-my_template("foo") {
-  name = "foo"
-  extra_options = "//my/foo/options"
-  deps = [
-    "//some/random/framework",
-    "//some/other/random/framework",
-  ]
-}
-```
-Available commands (invoked using gn cli tool) and constructs (built-in target
-declaration types) are defined in the [GN reference][gn-reference]. There are
-also a handful of custom templates in `.gni` files in the
-[`//build` project][build-project].
-
-These custom templates mostly define custom target declaration types, such as
-the [package declaration type][packages-source].
-
-> TODO(pylaligand): list available templates
-
-## Executing a build
-
-The simplest way to this is through the `fx` tool, as described in
-[Getting Started](/getting_started.md#Setup-Build-Environment). Read on to see
-what `fx` does under the hood.
-
-### A
-
-The first step is to build Zircon which uses its own build system:
-```bash
-$ scripts/build-zircon.sh
-```
-
-This is what gets run under the hood by `fx build-zircon`, which is run by `fx
-full-build`.
-
-For a list of all options, run `build-zircon.sh -h`. See Zircon's
-[Getting started][zircon-getting-started] and
-[Makefile options][zircon-makefile-options] for details.
-
-### B
-
-Then configure the content of the generated image by choosing the top level
-product to build:
-```
-# --products and --packages can be omitted to use the defaults, which are
-# $layer/products/default.gni and empty, respectively.
-$ buildtools/gn gen out/x64 --args='import("//garnet/products/product_name.gni") fuchsia_packages=["garnet/packages/my_stuff"]'
-```
-
-This will create an `out/x64` directory containing Ninja files.
-
-The equivalent fx set command is:
-```
-$ scripts/fx set x64 --products garnet/products/base.gni --packages garnet/packages/my_stuff
-```
-
-For a list of all GN build arguments, run `buildtools/gn args out/x64 --list`.
-For documentation on the `select_variant` argument, see [Variants](variants.md).
-
-### C
-
-The final step is to run the actual build with Ninja:
-```
-$ buildtools/ninja -C out/<arch> -j 64
-```
-
-This is what gets run under the hood by `fx build`.
-
-## Rebuilding
-
-### After modifying non-Zircon files
-
-In order to rebuild the tree after modifying some sources, just rerun step
-**C**. This holds true even if you modify `BUILD.gn` files as GN adds Ninja
-targets to update Ninja targets if build files are changed! The same holds true
-for package files used to configure the build.
-
-### After modifying Zircon files
-
-You will want to rerun **A** and **C**.
-
-### After syncing sources
-
-You’ll most likely need to run **A** once if anything in the Zircon tree was
-changed. After that, run **C** again.
-
-
-## Tips and tricks
-
-## Inspecting all packages in a product
-
-```bash
-$ build/gn/preprocess_products.py --products '["garnet/products/default"]'
-```
-
-### Visualizing the hierarchy of build packages
-
-```bash
-$ scripts/visualize_module_tree.py > tree.dot
-$ dot -Tpng tree.dot -o tree.png
-```
-
-### Inspecting the content of a GN target
-
-```bash
-$ buildtools/gn desc out/x64 //path/to/my:target
-```
-
-### Finding references to a GN target
-
-```bash
-$ buildtools/gn refs out/x64 //path/to/my:target
-```
-
-### Referencing targets for the build host
-
-Various host tools (some used in the build itself) need to be built along with
-the final image.
-
-To reference a build target for the host toolchain from a module file:
-```
-//path/to/target(//build/toolchain:host_x64)
-```
-To reference a build target for the host toolchain from within a `BUILD.gn`
-file:
-```
-//path/to/target($host_toolchain)
-```
-
-### Building only a specific target
-
-If a target is defined in a GN build file as `//foo/bar/blah:dash`, that target
-(and its dependencies) can be built with:
-```bash
-$ buildtools/ninja -C out/x64 -j64 foo/bar/blah:dash
-```
-Note that this only works for targets in the default toolchain.
-
-### Exploring Ninja targets
-
-GN extensively documents which Ninja targets it generates. The documentation is
-accessible with:
-```bash
-$ buildtools/gn help ninja_rules
-```
-
-You can also browse the set of Ninja targets currently defined in your output
-directory with:
-```bash
-$ buildtools/ninja -C out/x64 -t browse
-```
-Note that the presence of a Ninja target does not mean it will be built - for
-that it needs to depend on the “default” target.
-
-### Understanding why Ninja does what it does
-
-Add `-d explain` to your Ninja command to have it explain every step of its
-execution.
-
-### Debugging build timing issues
-
-When running a build, Ninja keeps logs that can be used to generate
-visualizations of the build process:
-
-1. Delete your output directory - this is to ensure the logs represent only the
-   build iteration you’re about to run;
-1. Run a build as you would normally do;
-1. Get <https://github.com/nico/ninjatracing>;
-1. Run `ninjatracing <output directory>/.ninja_log > trace.json`;
-1. Load the resulting json file in Chrome in `about:tracing`.
-
-
-## Troubleshooting
-
-### My GN target is not being built!
-
-Make sure it rolls up to a label defined in a module file, otherwise the build
-system will ignore it.
-
-### GN complains about a missing `sysroot`.
-
-You likely forgot to run **A** before running **B**.
-
-> TODO(pylaligand): command showing path to default target
-
-
-### Internal GN setup
-
-> TODO(pylaligand): .gn, default target, mkbootfs, GN labels insertion
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-[gn-main]: https://chromium.googlesource.com/chromium/src/tools/gn/+/HEAD/README.md
-[gn-preso]: https://docs.google.com/presentation/d/15Zwb53JcncHfEwHpnG_PoIbbzQ3GQi_cpujYwbpcbZo/
-[ninja-main]: https://ninja-build.org/
-[gn-reference]: https://gn.googlesource.com/gn/+/master/docs/reference.md
-[build-project]: https://fuchsia.googlesource.com/build/+/master/
-[zircon-getting-started]: https://fuchsia.googlesource.com/zircon/+/master/docs/getting_started.md
-[zircon-makefile-options]: https://fuchsia.googlesource.com/zircon/+/master/docs/makefile_options.md
diff --git a/development/build/package_layout.md b/development/build/package_layout.md
index 135dd91..225b97b 100644
--- a/development/build/package_layout.md
+++ b/development/build/package_layout.md
@@ -1,73 +1,7 @@
-# Layout of Product and Package Directories
+# Obsolete
 
-Each [layer](/development/source_code/layers.md) of the Fuchsia source tree
-contains a top-level directory called `packages` containing all the
-[build packages](packages.md) for that layer. The present document describes
-the packages that are common to all of the layers. Each layer will introduce
-additional packages specific to that layer.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-## Directory map
-
-In the diagram below, "pkg" refers to Fuchsia packages, the unit of installation
-in Fuchsia.
-
-```
-//<layer>/products
-    default          # default build configuration for this layer
-                     # by convention, default preinstalls development tools,
-                     # and makes all prod packages available.
-//<layer>/packages
-    <layer>          # all production pkg up to this layer
-    buildbot         # all pkg declared at this layer; used by CQ/CI
-    default          # monolith packages for daily development at this layer
-    preinstall       # devtools for daily development at this layer
-    kitchen_sink     # all pkg up to this layer
-    all              # grab bag of every pkg in this layer
-    prod/            # pkg that can be picked up in production
-    tests/           # correctness tests (target & host)
-    tools/           # dev tools not for prod (target & host)
-    benchmarks/      # performance tests
-    examples/        # pkg demonstrating features offered by this layer
-  * experimental/    # pkg not quite ready for prod
-  * config/          # config files for the system (e.g. what to boot into)
-    sdk/             # SDK definitions
-    ...              # each layer will also define additional packages
-```
-
-## Cross-layer dependencies
-
-- `<layer>(N)` depends on `<layer>(N-1)` and adds all the production artifacts
-  of (N)
-  - this defines a pure production build
-- `buildbot(N)` depends on `<layer>(N-1)` and adds all artifacts of (N)
-  - this defines a build suitable for verifying the integrity of (N)
-- `kitchen_sink(N)` depends on `kitchen_sink(N-1)` and adds all artifacts of (N)
-  - this defines a build suitable for developing (N) as well as its dependencies
-
-## Inner-layer dependencies
-
-Most directories in a `packages` directory contain a special `all` package which
-aggregates all packages in this directory. Every `all` package should roll up to
-the root `all` package, thereby creating a convenient shortcut to build "all
-packages in the layer".
-Note that the directories that do not require aggregation are marked with `*` in
-the diagram above.
-
-## Disabling packages
-
-Some packages might need to get (temporarily) disabled as refactorings occur in
-the Fuchsia codebase. In order to disable a package `<layer>/<type>/foo`, move
-it under `<layer>/<type>/disabled/foo` and remove it from `<layer>/<type>/all`.
-Note that this does not apply to packages in directories that do not require
-aggregation, as these packages are strictly opt-in already.
-
-## Verification
-
-The [`//scripts/packages/verify_layer`][verify-layer] tool is used to verify
-that a layer's `packages` and `products` directory's structure matches the
-description in the present document.
-
-Note that only package files are allowed in such a directory, with the exception
-of `README.md` files for documentation purposes.
-
-[verify-layer]: https://fuchsia.googlesource.com/scripts/+/master/packages/README.md
diff --git a/development/build/packages.md b/development/build/packages.md
index 691968c..225b97b 100644
--- a/development/build/packages.md
+++ b/development/build/packages.md
@@ -1,92 +1,7 @@
-### Packages
+# Obsolete
 
-**Build packages** are defined in JSON files which can be found at:
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-* Garnet Layer Packages: [`//garnet/packages/`][garnet-packages-source].
-* Peridot Layer Packages: [`//peridot/packages/`][peridot-packages-source].
-* Topaz Layer Packages: [`//topaz/packages/`][topaz-packages-source].
-
-Build packages are a Fuchsia-specific feature built on top of GN to help
-customize Fuchsia builds.
-
-A build package file contains references to other build packages it expands
-on (`imports`) and the Fuchsia packages it adds to the build (`packages`):
-```json
-{
-    "imports": [
-        "garnet/packages/prod/network”,
-    ],
-    "packages": [
-        "//garnet/examples/http/wget"
-    ]
-}
-```
-
-Build packages define an aggregation of one or more build labels, either by
-importing other packages, or by referencing build labels. GN [parses the JSON
-package definitions][preprocess-build-packages-py] early on in the build
-(often referenced from [product definitions][products], and those definitions
-determine what else GN has to do.
-
-**Fuchsia packages**, not to be confused with build packages, are artifacts
-of the Fuchsia build system, generated by the GN targets listed in `packages`.
-A Fuchsia package includes a manifest of its contents, and zero or more
-executables and their assets.
-
-For example, the above build packages file adds a Fuchsia package called
-"wget" to the build. This package contains the binaries built
-from the build target of the same name in `//garnet/examples/http/wget/BUILD.gn`:
-
-```py
-package("wget") {
-  deps = [
-    # The path to the dependency that creates the wget binary.
-    ":bin"
-  ],
-  binaries = [{
-    name = "wget"
-  }]
-}
-```
-
-The `binaries` field in the package definition specifies that this package
-includes a single binary named `wget`. The `binaries` field does not create
-the binary--that's the job of the package's dependencies list, specified in
-`deps`:
-
-```py
-# Executable defines a c++ binary, the label of the executable target will
-# be the same as the name of the produced binary file.
-executable("bin") {
-  output_name = "wget"
-
-  sources = [
-    "wget.cc",
-  ]
-
-  deps = [
-    # This executable also has its own dependencies.
-    "//garnet/public/lib/app/cpp",
-    "//garnet/public/lib/fidl/cpp",
-  ]
-}
-```
-
-The `binaries` field in a `package` target lets GN know to deploy the
-binary within Fuchsia when you boot your Fuchsia OS image, allowing you
-to run your binary from inside the Fuchsia shell:
-
-```bash
-$ wget google.com
---2018-06-13 17:04:44--  http://google.com/
-$
-```
-
-
-
-
-[garnet-packages-source]: https://fuchsia.googlesource.com/garnet/+/master/packages/
-[peridot-packages-source]: https://fuchsia.googlesource.com/peridot/+/master/packages/
-[topaz-packages-source]: https://fuchsia.googlesource.com/topaz/+/master/packages/
-[preprocess-build-packages-py]: https://fuchsia.googlesource.com/build/+/master/gn/prepreprocess_build_packages.py
-[products]: products.md
diff --git a/development/build/products.md b/development/build/products.md
index 6769825..225b97b 100644
--- a/development/build/products.md
+++ b/development/build/products.md
@@ -1,74 +1,7 @@
-# Products
+# Obsolete
 
-**Products** are defined in JSON files which can be found at:
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-* Garnet Layer Products: [`//garnet/products/`][garnet-products-source].
-* Peridot Layer Products: [`//peridot/products/`][peridot-products-source].
-* Topaz Layer Products: [`//topaz/products/`][topaz-products-source].
-
-Products are a Fuchsia-specific feature built on top of GN to help customize
-Fuchsia builds. Products reference [packages](packages.md) and coarsely
-define which build artifacts the packages are added to.
-
-## Package Sets
-
-A product can import one or more packages into three different package sets
-of build artifacts, as defined below. The package sets influence what
-packages are included in parts of build output.
-
-### monolith
-
-The `monolith` section of a **product** defines the list of [build
-packages](packages.md) that are to be included in the disk images, system
-update images and package repository. Membership of a package in the
-`monolith` dependency set takes precedence over membership in other package
-sets.
-
-### preinstall
-
-The `preinstall` section of a **product** defines the list of [build
-packages](packages.md) that are to be preinstalled in the disk image
-artifacts of the build, and will also be made available in the package
-repository. These packages are not added to the system update images or
-packages.
-
-### available
-
-The `available` section of a **product** defines the list of [build
-packages](packages.md) that are added to the package repository only. These
-packages will be available for runtime installation, but are not found in
-system update images nor are they preinstalled in any disk images. All
-members of `monolith` and `preinstall` are inherently `available`.
-
-## Defaults & Conventions
-
-### product: default
-
-The `default` product for a layer, found in `//<layer>/products/default` by
-convention contains:
-
-* `monolith` - a common minimal base for this layer that makes up a system
-  update.
-* `preinstall` - a set of most commonly used development tools for the layer
-  and other common work-items.
-* `available` - all `prod` packages for the layer.
-
-By convention, the `default` product for a higher layer should be additive
-from the layer below.
-
-## Inspecting Products
-
-As products reference [packages](packages.md) and packages may reference
-other packages, it is useful to be able to inspect the expanded and filtered
-set of build labels that will make up each package set in a product. The
-[preprocess products][preprocess-products-py] script is the tool that
-produces this for the build and can be run by hand:
-
-```bash
-$ python build/gn/preprocess_products.py --products '["garnet/products/default"]'
-```
-
-[garnet-products-source]: https://fuchsia.googlesource.com/garnet/+/master/products/
-[peridot-products-source]: https://fuchsia.googlesource.com/peridot/+/master/products/
-[topaz-products-source]: https://fuchsia.googlesource.com/topaz/+/master/products/
-[preprocess-products-py]: https://fuchsia.googlesource.com/build/+/master/gn/preprocess_products.py
diff --git a/development/build/toolchain.md b/development/build/toolchain.md
index 0e893ad..225b97b 100644
--- a/development/build/toolchain.md
+++ b/development/build/toolchain.md
@@ -1,435 +1,7 @@
-# Toolchain
+# Obsolete
 
-Fuchsia is using Clang as the official compiler.
-
-## Prerequisites
-
-You need [CMake](https://cmake.org/download/) version 3.8.0 and newer to
-execute these commands. This was the first version to support Fuchsia.
-
-While CMake supports different build systems, we recommend using
-[Ninja](https://github.com/ninja-build/ninja/releases) which installed
-to be present on your system.
-
-## Getting Source
-
-The example commands below use `${LLVM_SRCDIR}` to refer to the root of
-your LLVM source tree checkout and assume the [monorepo
-layout](https://llvm.org/docs/Proposals/GitHubMove.html#monorepo-variant).
-When using this layout, each sub-project has its own top-level
-directory.
-
-The
-[https://fuchsia.googlesource.com/third_party/llvm-project](https://fuchsia.googlesource.com/third_party/llvm-project)
-repository emulates this layout via Git submodules and is updated
-automatically by Gerrit. You can use the following command to download
-this repository including all the submodules after setting the
-`${LLVM_SRCDIR}` variable:
-
-```bash
-LLVM_SRCDIR=${HOME}/llvm-project
-git clone --recurse-submodules https://fuchsia.googlesource.com/third_party/llvm-project ${LLVM_SRCDIR}
-```
-
-To update the repository including all the submodules, you can use:
-
-```bash
-git pull --recurse-submodules
-```
-
-Alternatively, you can use the semi-official monorepo
-[https://github.com/llvm-project/llvm-project-20170507](https://github.com/llvm-project/llvm-project-20170507)
-maintained by the LLVM community. This repository does not use
-submodules which means you can use the standard Git workflow:
-
-```bash
-git clone https://github.com/llvm-project/llvm-project-20170507 ${LLVM_SRCDIR}
-```
-
-### Fuchsia SDK
-
-Before building the runtime libraries that are built along with the
-toolchain, you need a Fuchsia SDK. We expect that the SDK is located in
-the directory pointed to by the `${SDK_DIR}` variable:
-
-```bash
-SDK_DIR=${HOME}/sdk/garnet
-```
-
-To download the latest SDK, you can use the following:
-
-```bash
-./buildtools/cipd install fuchsia/sdk/linux-amd64 latest -root ${SDK_DIR}
-```
-
-Alternatively, you can build the Garnet SDK from source using the
-following commands:
-
-```bash
-./scripts/build-zircon.sh
-
-gn gen --args='target_cpu="x64" fuchsia_packages=["garnet/packages/sdk/garnet"]' out/x64
-ninja -C out/x64
-
-gn gen --args='target_cpu="arm64" fuchsia_packages=["garnet/packages/sdk/garnet"]' out/arm64
-ninja -C out/arm64
-
-./scripts/sdk/create_layout.py --manifest out/x64/gen/garnet/public/sdk/garnet_molecule.sdk --output ${SDK_DIR}
-./scripts/sdk/create_layout.py --manifest out/arm64/gen/garnet/public/sdk/garnet_molecule.sdk --output ${SDK_DIR} --overlay
-```
-
-## Building Clang
-
-The Clang CMake build system supports bootstrap (aka multi-stage)
-builds. We use two-stage bootstrap build for the Fuchsia Clang compiler.
-
-The first stage compiler is a host-only compiler with some options set
-needed for the second stage. The second stage compiler is the fully
-optimized compiler intended to ship to users.
-
-Setting up these compilers requires a lot of options. To simplify the
-configuration the Fuchsia Clang build settings are contained in CMake
-cache files which are part of the Clang codebase.
-
-You can build Clang toolchain for Fuchsia using the following commands.
-These must be run in a separate build directory, which you must create.
-This directory can be a subdirectory of `${LLVM_SRCDIR}` so that you
-use `LLVM_SRCDIR=..` or it can be elsewhere, with `LLVM_SRCDIR` set
-to an absolute or relative directory path from the build directory.
-
-```bash
-cmake -GNinja \
-  -DLLVM_ENABLE_PROJECTS="clang;lld" \
-  -DLLVM_ENABLE_RUNTIMES="compiler-rt;libcxx;libcxxabi;libunwind" \
-  -DSTAGE2_FUCHSIA_SDK=${SDK_DIR} \
-  -C ${LLVM_SRCDIR}/clang/cmake/caches/Fuchsia.cmake \
-  ${LLVM_SRCDIR}/llvm
-ninja stage2-distribution
-```
-
-To include compiler runtimes and C++ library for Linux, you need to use
-`LINUX_<architecture>_SYSROOT` flag to point at the sysroot and specify
-the correct host triple. For example, to build the runtimes for
-`x86_64-linux-gnu` using the sysroot from your Fuchsia checkout, you
-would use:
-
-```bash
-  -DBOOTSTRAP_LLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu \
-  -DSTAGE2_LINUX_x86_64-linux-gnu_SYSROOT=${FUCHSIA}/buildtools/linux-x64/sysroot \
-```
-
-To install the compiler just built into `/usr/local`, you can use the
-following command:
-
-```bash
-ninja stage2-install-distribution
-```
-
-To use the compiler just built without installing it into a system-wide
-shared location, you can just refer to its build directory explicitly as
-`${LLVM_OBJDIR}/tools/clang/stage2-bins/bin/` (where `LLVM_OBJDIR` is
-your LLVM build directory).
-
-*** note
-**Note:** the second stage build uses LTO (Link Time Optimization) to
-achieve better runtime performance of the final compiler. LTO often
-requires a large amount of memory and is very slow. Therefore it may not
-be very practical for day-to-day development.
-***
-
-## Developing Clang
-
-When developing Clang, you may want to use a setup that is more suitable for
-incremental development and fast turnaround time.
-
-The simplest way to build LLVM is to use the following commands:
-
-```bash
-cmake -GNinja \
-  -DCMAKE_BUILD_TYPE=Debug \
-  -DLLVM_ENABLE_PROJECTS="clang;lld" \
-  ${LLVM_SRCDIR}/llvm
-ninja
-```
-
-You can enable additional projects using the `LLVM_ENABLE_PROJECTS`
-variable. To enable all common projects, you would use:
-
-```bash
-  -DLLVM_ENABLE_PROJECTS="clang;lld;compiler-rt;libcxx;libcxxabi;libunwind"
-```
-
-Similarly, you can also enable some projects to be built as runtimes
-which means these projects will be built using the just-built rather
-than the host compiler:
-
-```bash
-  -DLLVM_ENABLE_PROJECTS="clang;lld" \
-  -DLLVM_ENABLE_RUNTIMES="compiler-rt;libcxx;libcxxabi;libunwind" \
-```
-
-Clang is a large project and compiler performance is absolutely critical. To
-reduce the build time, we recommend using Clang as a host compiler, and if
-possible, LLD as a host linker. These should be ideally built using LTO and
-for best possible performance also using Profile-Guided Optimizations (PGO).
-
-To set the host compiler to Clang and the host linker to LLD, you can
-use the following extra flags:
-
-```bash
-  -DCMAKE_C_COMPILER=${CLANG_TOOLCHAIN_PREFIX}clang \
-  -DCMAKE_CXX_COMPILER=${CLANG_TOOLCHAIN_PREFIX}clang++ \
-  -DLLVM_ENABLE_LLD=ON
-```
-
-This assumes that `${CLANG_TOOLCHAIN_PREFIX}` points to the `bin` directory
-of a Clang installation, with a trailing slash (as this Make variable is used
-in the Zircon build). For example, to use the compiler from your Fuchsia
-checkout (on Linux):
-
-```bash
-CLANG_TOOLCHAIN_PREFIX=${FUCHSIA}/buildtools/linux-x64/clang/bin/
-```
-
-*** note
-**Note:** that Fuchsia Clang installation only contains static libc++
-host library (on Linux), so you will need the following two flags to
-avoid linker errors:
-```bash
-  -DCMAKE_EXE_LINKER_FLAGS="-ldl -lpthread" \
-  -DCMAKE_SHARED_LINKER_FLAGS="-ldl -lpthread"
-```
-***
-
-### Sanitizers
-
-Most sanitizers can be used on LLVM tools by adding
-`LLVM_USE_SANITIZER=<sanitizer name>` to your cmake invocation. MSan is
-special however because some LLVM tools trigger false positives. To
-build with MSan support you first need to build libc++ with MSan
-support. You can do this in the same build. To set up a build with MSan
-support first run CMake with `LLVM_USE_SANITIZER=Memory` and
-`LLVM_ENABLE_LIBCXX=ON`.
-
-```bash
-cmake -GNinja \
-  -DCMAKE_BUILD_TYPE=Debug \
-  -DCMAKE_C_COMPILER=${CLANG_TOOLCHAIN_PREFIX}clang \
-  -DCMAKE_CXX_COMPILER=${CLANG_TOOLCHAIN_PREFIX}clang++ \
-  -DLLVM_ENABLE_PROJECTS="clang;lld;libcxx;libcxxabi;libunwind" \
-  -DLLVM_USE_SANITIZER=Memory \
-  -DLLVM_ENABLE_LIBCXX=ON \
-  -DLLVM_ENABLE_LLD=ON \
-  ${LLVM_SRCDIR}/llvm
-```
-
-Normally you would run Ninja at this point but we want to build
-everything using a sanitized version of libc++ but if we build now it
-will use libc++ from `${CLANG_TOOLCHAIN_PREFIX}` which isn't sanitized.
-So first we build just the cxx and cxxabi targets. These will be used in
-place of the ones from `${CLANG_TOOLCHAIN_PREFIX}` when tools
-dynamically link against libcxx
-
-```bash
-ninja cxx cxxabi
-```
-
-Now that we have a sanitized version of libc++ we can have our build use
-it instead of the one from `${CLANG_TOOLCHAIN_PREFIX}` and then build
-everything.
-
-```bash
-ninja
-```
-
-Putting that all together:
-
-```bash
-cmake -GNinja \
-  -DCMAKE_BUILD_TYPE=Debug \
-  -DCMAKE_C_COMPILER=${CLANG_TOOLCHAIN_PREFIX}clang \
-  -DCMAKE_CXX_COMPILER=${CLANG_TOOLCHAIN_PREFIX}clang++ \
-  -DLLVM_USE_SANITIZER=Address \
-  -DLLVM_ENABLE_LIBCXX=ON \
-  -DLLVM_ENABLE_LLD=ON \
-  ${LLVM_SRCDIR}/llvm
-ninja libcxx libcxxabi
-ninja
-```
-
-### [Googlers only] Goma
-
-Ensure Goma is installed on your machine for faster builds; Goma
-accelerates builds by distributing compilation across many machines. If
-you have Goma installed in `${GOMA_DIR}` (by default `${HOME}/goma`),
-you can enable Goma use with the following extra flags:
-
-```bash
-  -DCMAKE_C_COMPILER_LAUNCHER=${GOMA_DIR}/gomacc \
-  -DCMAKE_CXX_COMPILER_LAUNCHER=${GOMA_DIR}/gomacc \
-  -DLLVM_PARALLEL_LINK_JOBS=${LINK_JOBS}
-```
-
-The number of link jobs is dependent on RAM size, for LTO build you will
-need at least 10GB for each job.
-
-To build Clang with Goma, use:
-```bash
-ninja -j${JOBS}
-```
-
-Use `-j100` for Goma on macOS and `-j1000` for Goma on Linux. You may
-need to tune the job count to suit your particular machine and workload.
-
-*** note
-**Note:** that in order to use Goma, you need a host compiler that is
-supported by Goma such as the Fuchsia Clang installation. See above on
-how to configure your LLVM buile to use a different host compiler.
-***
-
-To verify your compiler is available on Goma, you can set
-`GOMA_USE_LOCAL=0 GOMA_FALLBACK=0` environment variables. If the
-compiler is not available, you will see an error.
-
-### Fuchsia Configuration
-
-When developing Clang for Fuchsia, you can also use the cache file to
-test the Fuchsia configuration, but run only the second stage, with LTO
-disabled, which gives you a faster build time suitable even for
-incremental development, without having to manually specify all options:
-
-```bash
-cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug \
-  -DCMAKE_C_COMPILER=${CLANG_TOOLCHAIN_PREFIX}clang \
-  -DCMAKE_CXX_COMPILER=${CLANG_TOOLCHAIN_PREFIX}clang++ \
-  -DLLVM_ENABLE_LTO=OFF \
-  -DLLVM_ENABLE_PROJECTS="clang;lld" \
-  -DLLVM_ENABLE_RUNTIMES="compiler-rt;libcxx;libcxxabi;libunwind" \
-  -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu \
-  -DLINUX_x86_64-linux-gnu_SYSROOT=${FUCHSIA}/buildtools/linux-x64/sysroot \
-  -DFUCHSIA_SDK=${SDK_DIR} \
-  -C ${LLVM_SRCDIR}/clang/cmake/caches/Fuchsia-stage2.cmake \
-  ${LLVM_SRCDIR}/llvm
-ninja distribution
-```
-
-With Goma for even faster turnaround time:
-
-```bash
-cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug \
-  -DCMAKE_C_COMPILER=${CLANG_TOOLCHAIN_PREFIX}clang \
-  -DCMAKE_CXX_COMPILER=${CLANG_TOOLCHAIN_PREFIX}clang++ \
-  -DCMAKE_C_COMPILER_LAUNCHER=${GOMA_DIR}/gomacc \
-  -DCMAKE_CXX_COMPILER_LAUNCHER=${GOMA_DIR}/gomacc \
-  -DCMAKE_EXE_LINKER_FLAGS="-ldl -lpthread" \
-  -DCMAKE_SHARED_LINKER_FLAGS="-ldl -lpthread" \
-  -DLLVM_PARALLEL_LINK_JOBS=${LINK_JOBS} \
-  -DLLVM_ENABLE_LTO=OFF \
-  -DLLVM_ENABLE_PROJECTS="clang;lld" \
-  -DLLVM_ENABLE_RUNTIMES="compiler-rt;libcxx;libcxxabi;libunwind" \
-  -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu \
-  -DLINUX_x86_64-linux-gnu_SYSROOT=${FUCHSIA}/buildtools/linux-x64/sysroot \
-  -DFUCHSIA_SDK=${SDK_DIR} \
-  -C ${LLVM_SRCDIR}/clang/cmake/caches/Fuchsia-stage2.cmake \
-  ${LLVM_SRCDIR}/llvm
-ninja distribution -j${JOBS}
-```
-
-## Testing Clang
-
-To run Clang tests, you can use the `check-<component>` target:
-
-```
-ninja check-llvm check-clang
-```
-
-You can all use `check-all` to run all tests, but keep in mind that this
-can take significant amount of time depending on the number of projects
-you have enabled in your build.
-
-### Building Fuchsia with custom Clang locally
-
-You can start building test binaries right away by using the Clang in
-`${LLVM_OBJDIR}/bin/`, or in
-`${LLVM_OBJDIR}/tools/clang/stage2-bins/bin/` (depending on whether you
-did the two-stage build or the single-stage build, the binaries will be
-in a different location). However, if you want to use your Clang to
-build Fuchsia, you will need to set some more arguments/variables.
-
-If you are only interested in building Zircon, set the following
-Make variables:
-
-```bash
-make USE_CLANG=true CLANG_TOOLCHAIN_PREFIX=${CLANG_DIR}
-```
-
-`${CLANG_DIR}` is the path to the `bin` directory for your Clang build,
-e.g. `${LLVM_OBJDIR}/bin/`.
-
-*** note
-**Note:** that trailing slash is important.
-***
-
-Then run `fx build-zircon` as usual.
-
-For layers-above-Zircon, it should be sufficient to pass
-`--args clang_prefix="${CLANG_DIR}"` to `fx set`, then run `fx build` as usual.
-
-*** note
-**Note:** that since `fx full-build` implicitly builds Zircon, for a full build,
-you also need to set the environment variables necessary for Zircon.
-***
-
-To ensure the environment variables are set every time you build, you may want
-to run `fx set`, and then manually edit your `${FUCHSIA_SOURCE}/.config` file,
-adding the following line:
-
-```bash
-export USE_CLANG=true CLANG_TOOLCHAIN_PREFIX=${LLVM_OBJDIR}/bin/
-```
-
-### Building Fuchsia with custom Clang on bots (Googlers only)
-
-Fuchsia's infrastructure has support for using a non-default version of Clang
-to build. Only Clang instances that have been uploaded to CIPD or Isolate are
-available for this type of build, and so any local changes must land in
-upstream and be built by the CI or production toolchain bots.
-
-You will need the infra codebase and prebuilts. Directions for checkout are on
-the infra page.
-
-To trigger a bot build with a specific revision of Clang, you will need the Git
-revision of the Clang with which you want to build. This is on the [CIPD page](https://chrome-infra-packages.appspot.com/p/fuchsia/clang),
-or can be retrieved using the CIPD CLI. You can then run the following command:
-
-```bash
-export FUCHSIA_SOURCE=<path_to_fuchsia>
-export BUILDER=<builder_name>
-export REVISION=<clang_revision>
-
-export INFRA_PREBUILTS=${FUCHSIA_SOURCE}/fuchsia-infra/prebuilt/tools
-
-cd ${FUCHSIA_SOURCE}/fuchsia-infra/recipes
-
-${INFRA_PREBUILTS}/led get-builder 'luci.fuchsia.ci:${BUILDER}' | \
-${INFRA_PREBUILTS}/led edit-recipe-bundle -O | \
-jq '.userland.recipe_properties."$infra/fuchsia".clang_toolchain.type="cipd"' | \
-jq '.userland.recipe_properties."$infra/fuchsia".clang_toolchain.instance="git_revision:${REVISION}"' | \
-${INFRA_PREBUILTS}/led launch
-```
-
-It will provide you with a link to the BuildBucket page to track your build.
-
-You will need to run `led auth-login` prior to triggering any builds, and may need to
-file an infra ticket to request access to run led jobs.
-
-## Additional Resources
-
-Documentation:
-* [Getting Started with the LLVM System](http://llvm.org/docs/GettingStarted.html)
-* [Building LLVM with CMake](http://llvm.org/docs/CMake.html)
-* [Advanced Build Configurations](http://llvm.org/docs/AdvancedBuilds.html)
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-Talks:
-* [2016 LLVM Developers’ Meeting: C. Bieneman "Developing and Shipping LLVM and Clang with CMake"](https://www.youtube.com/watch?v=StF77Cx7pz8)
-* [2017 LLVM Developers’ Meeting: Petr Hosek "Compiling cross-toolchains with CMake and runtimes build"](https://www.youtube.com/watch?v=OCQGpUzXDsY)
diff --git a/development/build/tools-dashboards.md b/development/build/tools-dashboards.md
index 4ee3ede..225b97b 100644
--- a/development/build/tools-dashboards.md
+++ b/development/build/tools-dashboards.md
@@ -1,10 +1,7 @@
-## Tools
+# Obsolete
 
-- `fx rolling-commits` - displays the commits not yet rolled to a given layer
-- `fx rolling-commits --layer <layer>`
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-## Dashboards
-
-- [Repo and roller builders](https://luci-milo.appspot.com/p/fuchsia)
-- [Build status dashboard](https://fuchsia-dashboard.appspot.com/)
-- [Dashboard component](https://fuchsia.googlesource.com/topaz/+/master/app/dashboard/)
diff --git a/development/build/variants.md b/development/build/variants.md
index 8f7b058..225b97b 100644
--- a/development/build/variants.md
+++ b/development/build/variants.md
@@ -1,64 +1,7 @@
-# Fuchsia Build System: Variants
+# Obsolete
 
-The Fuchsia GN build machinery allows for separate components to be built
-in different "variants".  A variant usually just means using extra compiler
-options, but they can do more than that if you write some more GN code.
-The variants defined so far enable things like
-[sanitizers](https://github.com/google/sanitizers/wiki) and
-[LTO](https://llvm.org/docs/LinkTimeOptimization.html).
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-The GN build argument
-[`select_variant`](https://fuchsia.googlesource.com/garnet/+/master/docs/gen/build_arguments.md#select_variant)
-controls which components are built in which variants.  It applies
-automatically to every `executable`, `loadable_module`, or `driver_module`
-target in GN files.  It's a flexible mechanism in which you give a list of
-matching rules to apply to each target to decide which variant to use (if
-any).  To support this flexibility, the value for `select_variant` uses a
-detailed GN syntax.  For simple cases, this can just be a list of strings.
-
-Here's an example running `gn gen` directly:
-
-```sh
-./buildtools/gn gen out/x64 --args='select_variant=["host_asan", "asan/cat", "asan/ledger"]'
-```
-
-This does the same thing using the `fx set` tool:
-
-```sh
-fx set x64 --variant={host_asan,asan/cat,asan/ledger}
-```
-
- 1. The first switch applies the `host_asan` matching rule, which enables
-    [AddressSanitizer](https://clang.llvm.org/docs/AddressSanitizer.html)
-    for all the executables built to run on the build host.
-
- 2. The second switch applies the `asan` matching rule, which enables
-    AddressSanitizer for executables built to run on the target (i.e. the
-    Fuchsia device).  The `/cat` suffix constrains this matching rule only
-    to the binary named `cat`.
-
- 3. The third switch is like the second, but matches the binary named `ledger`.
-
-The GN code supports much more flexible matching rules than just the binary
-name, but there are no shorthands for those.  To do something more complex,
-set the
-[`select_variant`](https://fuchsia.googlesource.com/garnet/+/master/docs/gen/build_arguments.md#select_variant)
-GN build argument directly.
-
- * You can do this via the `--args` switch to `gn gen` once you have the
-   syntax down.
-
- * The easiest way to experiment is to start with some `--variant` switches
-   that approximate what you want and then edit the `select_variant` value
-   `fx set` produces:
-   * You can just edit the `args.gn` file in the GN output directory
-     (e.g. `out/x64/args.gn`) and the next `ninja` run (aka `fx build`)
-     will re-run `gn gen` with those changes.
-   * You can use the command `./buildtools/gn args out/x64`, which
-     will run your `$EDITOR` on the `args.gn` file and then do `gn gen`
-     immediately so you can see any errors in your GN syntax.
-
-To see the list of variants available and learn more about how to define
-new ones, see the
-[`known_variants`](https://fuchsia.googlesource.com/garnet/+/master/docs/gen/build_arguments.md#known_variants)
-build argument.
diff --git a/development/hardware/developing_on_nuc.md b/development/hardware/developing_on_nuc.md
index e772b48..225b97b 100644
--- a/development/hardware/developing_on_nuc.md
+++ b/development/hardware/developing_on_nuc.md
@@ -1,92 +1,7 @@
-# Developing with Fuchsia on a NUC
+# Obsolete
 
-This document describes how to get a NUC up and running with Fuchsia.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-[1. Get Parts](#parts)<br/>
-[2. Prepare the NUC](#nuc)<br/>
-[3. Install Fuchsia](#install)<br/>
-[4. Update NUC BIOS to allow netbooting](#bios)<br/>
-
------
-
-## 1. Get Parts <a name="parts"/>
-
-You’ll need the following:
-
-- USB 3.0 Drive
-- NUC
-- RAM
-- m.2 SSD
-- Keyboard
-- Mouse
-- Monitor that supports HDMI
-- HDMI cable
-- ethernet cable
-- Magnetic tip phillips head screwdriver.
-
-This table shows what I bought from Amazon.
-
-| Item | Link | Notes: |
-| ---- | ---- | ------ |
-| NUC | [B01MSZLO9P](https://www.amazon.com/gp/product/B01MSZLO9P) | Get a NUC7 or NUC6 for gpu support. |
-| RAM | [B01BIWKP58](https://www.amazon.com/gp/product/B01BIWKP58) | Works fine. |
-| SSD (Only need one, | [B01IAGSDJ0](https://www.amazon.com/gp/product/B01IAGSDJ0) | Works fine. |
-| I bought some of each) | [B00TGIVZTW](https://www.amazon.com/gp/product/B00TGIVZTW) | Works fine. |
-| | [B01M9K0N8I](https://www.amazon.com/gp/product/B01M9K0N8I) | Works fine. |
-| | | |
-| **Optional:** | | |
-| Keyboard and Mouse | [B00B7GV802](https://www.amazon.com/gp/product/B00B7GV802) | Works fine.  Next time I'd get a keyboard with a smaller foot print. |
-| Monitor | [B015WCV70W](https://www.amazon.com/gp/product/B015WCV70W) | Works fine. |
-| HDMI Cable | [B014I8SIJY](https://www.amazon.com/gp/product/B014I8SIJY) | Works fine. |
-| USB 3.0 drive | [B01BGTG41W](https://www.amazon.com/gp/product/B01BGTG41W) | Works fine. |
-
------
-
-## 2. Prepare the NUC <a name="nuc"/>
-NUCs don’t come with RAM or an SSD so you need to install them.
-<br/><center><img width="50%" src="images/developing_on_nuc/parts.jpg"/></center><br/>
-
-1. Remove the phillips screws in the bottom feet of the NUC.
-<br/><center><img width="50%" src="images/developing_on_nuc/nuc_bottom.jpg"/></center>
-<br/><center><img width="50%" src="images/developing_on_nuc/nuc_inside.jpg"/></center><br/><br/>
-1. Install the RAM.
-1. Remove the phillips screw that will hold the SSD in place (phillips screwdriver with magnetic tip is useful here).
-1. Install the SSD.
-1. Screw the SSD in place using screw from 3.
-<br/><center><img width="50%" src="images/developing_on_nuc/parts_installed.jpg"/></center><br/><br/>
-1. Replace bottom and screw feet back in.
-1.(Optional) Apply fuchsia logo.
-<br/><center><img width="50%" src="images/developing_on_nuc/nuc_fuchsia.jpg"/></center><br/><br/>
-1. Plug power, ethernet, HDMI, keyboard, and mouse into NUC.
-
------
-
-## 3. Update NUC BIOS to enable EFI booting <a name="bios"/>
-
-1. Reboot NUC.
-1. Press F2 while booting to enter BIOS.
-1. In the Boot Order window on the left click the Legacy tab.
-1. Uncheck ‘Legacy Boot’.
-<br/><center><img width="50%" src="images/developing_on_nuc/bios.jpg"/></center><br/><br/>
-1. Press the X in the top right to leave the BIOS.  Ensure you save before exiting.
-
------
-
-## 4. Build Fuchsia <a name="build"/>
-
-1. Follow the [getting started guidelines](../../getting_started.md)
-
------
-
-## 5. Pave Fuchsia <a name="pave"/>
-
-1. Plug in your USB key to your build workstation
-1. Identify the path to your USB key by running `fx list-usb-disks`
-1. Create a Zedboot USB by running `fx mkzedboot /path/to/usb/disk`
-1. Plug the Zedboot USB key into the NUC and boot it
-1. Run `fx pave` on your workstation
-
------
-
-
-All done!
diff --git a/development/hardware/pixelbook.md b/development/hardware/pixelbook.md
index eebc44a..225b97b 100644
--- a/development/hardware/pixelbook.md
+++ b/development/hardware/pixelbook.md
@@ -1,141 +1,7 @@
-# Preparing to install Fuchsia on Pixelbook
+# Obsolete
 
-## Update ChromeOS
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-If your Pixelbook has never been booted, it is best to boot it normally to check
-for any critical updates, as follows:
-
-1. Boot the Pixelbook normally. Opening the lid usually powers on the device.
-If this doesn't work, the power button is on the left side of the device, near
-the front of the wrist rest.
-2. Tap the "Let's go" button.
-3. Connect to a wired or wireless network.
-4. Accept the terms to proceed to the update check step.
-5. The device should check for updates, install any found.
-6. After rebooting from any updates, tap 'Browse as Guest' in the lower left
-corner.
-7. From the browser UI, go into "Settings->About Chrome OS" or "Help->About Chrome
-OS" and confirm the version is &gt;=62.
-
-## Put your device into developer mode
-***WARNING: This will erase any state stored locally on your Pixelbook***
-
-1. Power off the Pixelbook.
-2. Go into Recovery Mode.
-Hold down Esc+Refresh (first and third buttons on the top row of the keyboard).
-Then press the Power button (bottom left side of the device).
-3. Start by disabling OS verification by pressing Ctrl+D. You should see "To turn OS verification OFF, press ENTER". Press Enter to confirm.
-4. When your device reboots, you'll get confirmation that OS verification is OFF. Press Ctrl+D again to enter Developer Mode.
-5. Wait for the device to re-configure itself, which will take several minutes.
-Initially it may not appear to be doing anything. Let the device sit for a
-minute or two. You will hear two loud &lt;BEEP&gt;s early in the process. The
-process is complete when you hear two more loud &lt;BEEP&gt;s.
-6. The device should reboot itself when the Developer Mode transition is
-complete. You can now jump to Step #2 in the "Boot from USB" section.
-
-## Boot from USB
-
-1. Boot into ChromeOS.
-2. You should see a screen that says "OS verification is OFF" and approximately
-30 seconds later the boot will continue. Wait for the Welcome or Login screen
-to load. **Ignore** any link for "Enable debugging features".
-3. Press Ctrl+Alt+Refresh/F3 to enter a command shell. If pressing this key
-combination has no effect, try rebooting the Pixelbook once more.
-4. Enter 'chronos' as the user with a blank password
-5. Enable USB booting by running `sudo crossystem dev_boot_usb=1`
-6. (optional) Default to USB booting by running `sudo crossystem dev_default_boot=usb`.
-7. Plug the USB drive into the Pixelbook.
-8. Reboot by typing `sudo reboot`
-9. On the "OS verification is OFF" screen press Ctrl+U to bypass the timeout and
-boot from USB immediately. (See [Tips and Tricks](#tips-and-tricks) for other
-short circuit options)
-
-The USB drive is only needed for booting when you want to re-pave or otherwise
-netboot the device. If you didn't make USB booting the default (Step #6), you
-will need to press Ctrl+U at the grey 'warning OS-not verified' screen to boot
-from USB when you power on your device. If the device tries to boot from USB,
-either because that is the default or you pressed Ctrl+U, and the device fails
-to boot from USB you'll hear a fairly loud &lt;BEEP&gt;. Note that ChromeOS
-bootloader USB enumeration during boot has been observed to be slow. If you're
-having trouble booting from USB, it may be helpful to remove other USB devices
-until the device is through the bootloader and also avoid using a USB hub.
-
-## Tips and Tricks
-
-By default the ChromeOS bootloader has a long timeout to allow you to press
-buttons. To shortcut this you can press Ctrl+D or Ctrl+U when on the grey screen
-that warns that the OS will not be verified. Ctrl+D will cause the device to
-skip the timeout and boot from its default source. Ctrl+U will skip the timeout
-and boot the device from USB.
-
-### Going back to ChromeOS
-
-To go back to ChromeOS you must modify the priority of the Fuchsia kernel
-partition to be lower than that of at least one of the two ChromeOS kernel
-partitions.
-
-1. Press Alt+Esc to get to a virtual console
-2. Find the disk that contains the KERN-A, KERN-B, and KERN-C partitions with
-the `lsblk` command. Below this is device 000, note how the device path of the
-kernel partitions is an extension of that device.
-
-        $ lsblk
-        ID  SIZE TYPE             LABEL                FLAGS  DEVICE
-        000 232G                                              /dev/sys/pci/00:1e.4/pci-sdhci/sdhci/sdmmc/block
-        001   5G data             STATE                       /dev/sys/pci/00:1e.4/pci-sdhci/sdhci/sdmmc/block/part-000/block
-        002  16M cros kernel      KERN-A                      /dev/sys/pci/00:1e.4/pci-sdhci/sdhci/sdmmc/block/part-001/block
-        003   4G cros rootfs      ROOT-A                      /dev/sys/pci/00:1e.4/pci-sdhci/sdhci/sdmmc/block/part-002/block
-        004  16M cros kernel      KERN-B                      /dev/sys/pci/00:1e.4/pci-sdhci/sdhci/sdmmc/block/part-003/block
-        005   4G cros rootfs      ROOT-B                      /dev/sys/pci/00:1e.4/pci-sdhci/sdhci/sdmmc/block/part-004/block
-        006  64M cros kernel      KERN-C                      /dev/sys/pci/00:1e.4/pci-sdhci/sdhci/sdmmc/block/part-005/block
-        007   4G cros rootfs      ROOT-C                      /dev/sys/pci/00:1e.4/pci-sdhci/sdhci/sdmmc/block/part-006/block
-3. Use the `gpt` command to look at the device's (eg. 000) partition map.
-
-        $ gpt dump /dev/class/block/000
-        blocksize=0x200 blocks=488554496
-        Partition table is valid
-        GPT contains usable blocks from 34 to 488554462 (inclusive)
-        Paritition 0: STATE
-            Start: 478035968, End: 488521727 (10485760 blocks)
-            id:   51E8D442-0419-2447-96E5-49CB60CF0B25
-            type: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
-            flags: 0x0000000000000000
-        Paritition 1: KERN-A
-            Start: 20480, End: 53247 (32768 blocks)
-            id:   054CD627-F23C-5C40-8035-C188FA57DE9C
-            type: FE3A2A5D-4F32-41A7-B725-ACCC3285A309
-            flags: priority=2 tries=0 successful=1
-        Paritition 2: ROOT-A
-            Start: 8704000, End: 17092607 (8388608 blocks)
-            id:   936E138F-1ACF-E242-9C5B-3667FAA3C10C
-            type: 3CB8E202-3B7E-47DD-8A3C-7FF2A13CFCEC
-            flags: 0x0000000000000000
-        Paritition 3: KERN-B
-            Start: 53248, End: 86015 (32768 blocks)
-            id:   A8667891-8209-8648-9D5E-63DC9B8D0CB3
-            type: FE3A2A5D-4F32-41A7-B725-ACCC3285A309
-            flags: priority=1 tries=0 successful=1
-        Paritition 4: ROOT-B
-            Start: 315392, End: 8703999 (8388608 blocks)
-            id:   8B5D7BB4-590B-E445-B596-1E7AA1BB501F
-            type: 3CB8E202-3B7E-47DD-8A3C-7FF2A13CFCEC
-            flags: 0x0000000000000000
-        Paritition 5: KERN-C
-            Start: 17092608, End: 17223679 (131072 blocks)
-            id:   C7D6B203-C18F-BC4D-9160-A09BA8970CE1
-            type: FE3A2A5D-4F32-41A7-B725-ACCC3285A309
-            flags: priority=3 tries=15 successful=1
-        Paritition 6: ROOT-C
-            Start: 17223680, End: 25612287 (8388608 blocks)
-            id:   769444A7-6E13-D74D-B583-C3A9CF0DE307
-            type: 3CB8E202-3B7E-47DD-8A3C-7FF2A13CFCEC
-            flags: 0x0000000000000000
-4. KERN-C typically hosts the Zircon kernel. KERN-A and KERN-B typically have
-ChromeOS kernels. To go to ChromeOS we need to lower the priority of KERN-C
-here by referencing the **partition** index on the **disk** that has that
-partition.
-
-        $ gpt edit_cros 5 -P 0 /dev/class/block/000
-5. Reboot
-
-To go back to the Fuchsia kernel, just re-pave the device.
diff --git a/development/languages/c-cpp/README.md b/development/languages/c-cpp/README.md
index d8334b0..225b97b 100644
--- a/development/languages/c-cpp/README.md
+++ b/development/languages/c-cpp/README.md
@@ -1,11 +1,7 @@
-C/C++
-=====
+# Obsolete
 
-- [Naming conventions](naming.md)
-- [C style guide](c-style.md)
-- [C++ style guide](cpp-style.md)
-- [Library restrictions](library_restrictions.md)
-- [Testing FAQ](testing_faq.md)
-- [Syslog](syslog.md)
-- [Perftest micro-benchmark library](
-https://fuchsia.googlesource.com/zircon/+/master/system/ulib/perftest/README.md)
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
+
diff --git a/development/languages/c-cpp/c-style.md b/development/languages/c-cpp/c-style.md
index 8c29fe5..225b97b 100644
--- a/development/languages/c-cpp/c-style.md
+++ b/development/languages/c-cpp/c-style.md
@@ -1,4 +1,7 @@
-C style guide
-=============
+# Obsolete
 
-_To be started..._
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
+
diff --git a/development/languages/c-cpp/cpp-style.md b/development/languages/c-cpp/cpp-style.md
index 7ea5a5f..225b97b 100644
--- a/development/languages/c-cpp/cpp-style.md
+++ b/development/languages/c-cpp/cpp-style.md
@@ -1,85 +1,7 @@
-C++ style guide
-===============
+# Obsolete
 
-The Fuchsia project follows the [Google C++ style guide][google-guide], with a
-few exceptions.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-By policy, code should be formatted by clang-format which should handle many
-decisions.
-
-### Exceptions
-
-#### Braces
-
-Always use braces `{ }` when the contents of a block are more than one line.
-This is something you need to watch since Clang-format doesn't know to add
-these.
-
-```cpp
-// Don't do this.
-while (!done)
-  doSomethingWithAReallyLongLine(
-       wrapped_arg);
-
-// Correct.
-while (!done) {
-  doSomethingWithAReallyLongLine(
-       wrapped_arg);
-}
-```
-
-
-#### Conditionals and loops
-
-Do not use spaces inside parentheses (the Google style guide discourages but
-permits this).
-
-Do not use the single-line form for short conditionals and loops (the Google
-style guide permits both forms):
-
-```cpp
-// Don't do this:
-if (x == kFoo) return new Foo();
-
-// Correct.
-if (x == kFoo)
-  return new Foo;
-```
-
-#### Namespace Names
-
-* Nested namespaces are forbidden, with the following exceptions:
-  - `internal` (when required to hide implementation details of templated code)
-  - code generated by the FIDL compiler
-* The following top-level namespaces are forbidden:
-  - `internal`
-  - `fuchsia` (except in code generated by the FIDL compiler)
-* Namespaces in SDK libraries must be kept to as short a list as possible.
-  A later document will provide an explicit list of allowed namespaces; in the
-  meantime, new namespaces should be introduced thoughtfully.
-* Namespaces in non-SDK libraries should also be chosen so as to reduce the risk
-  of clashes. Very generic nouns (eg. `media`) are best avoided.
-
-Rationale: [Tip of the Week #130: Namespace Naming][totw-130]
-
-[google-guide]: https://google.github.io/styleguide/cppguide.html
-[totw-130]: https://abseil.io/tips/130
-
-#### `#include`s
-
-`#include`s use either `<angle brackets>` or `"quotes"` depending on context.
-
-1) Use `""` if the path is from the root of the source tree (e.g.
-   `"garnet/foo/bar/baz.h"`) or if the include is in the same directory as the
-   includer (e.g. `"baz.h"`).
-2) Use `<>` otherwise, which typically means the header is a "public" header of
-   some sort (e.g. `<lib/foo/bar.h>` or `<zircon/foo.h>`).
-
-* Third-party headers may be included using the root-relative path (e.g.
-  `"third_party/skia/include/core/SkPaint.h"`) or a public include path (e.g.
-  `<gtest/gtest.h>`).
-* Public headers should use `<>` with their canonical path (e.g.
-  `<lib/foo/bar.h>`) even if included from the same directory.
-* Non-public headers should use root-relative paths (e.g.
-  `"garnet/foo/bar/baz.h"`) even if included from the same directory, except in
-  cases where this would be inconsistent with existing code (e.g. zircon).
diff --git a/development/languages/c-cpp/library_restrictions.md b/development/languages/c-cpp/library_restrictions.md
index ee3fbbe..225b97b 100644
--- a/development/languages/c-cpp/library_restrictions.md
+++ b/development/languages/c-cpp/library_restrictions.md
@@ -1,20 +1,7 @@
-# Library restrictions
+# Obsolete
 
-## third_party/absl-cpp
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-Decision: **do not use** `<absl/synchronization/*>`. On Fuchsia, these classes
-bottom out in `pthread_mutex_t` and `pthread_cond_t`, which are not the most
-efficient primitives on Fuchsia. When `ABSL_INTERNAL_USE_NONPROD_MUTEX` is
-defined, these primitives bottom out in something much more sophisticated.
-Instead, please use `<lib/sync/*.h>`, which bottoms out in optimal
-synchronization primitives on Fuchsia.
-
-## third_party/googletest
-
-*** aside
-Note that the googletest library includes both the former gtest and gmock
-projects.
-***
-
-Decision: **do not use** the mocking functionality of gmock (`MOCK_METHOD` and
-`EXPECT_CALL`). It is allowed to use gmock matchers (such as `ElementsAre()`).
diff --git a/development/languages/c-cpp/naming.md b/development/languages/c-cpp/naming.md
index 166a9b5..225b97b 100644
--- a/development/languages/c-cpp/naming.md
+++ b/development/languages/c-cpp/naming.md
@@ -1,81 +1,7 @@
-Naming C/C++ objects
-====================
+# Obsolete
 
-## Include paths
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-The following guidelines apply to libraries which are meant to be used
-extensively, e.g. in an upper layer of the Fuchsia codebase or via an SDK,
-where "upper layer of the Fuchsia codebase" means "garnet" and above
-(peridot, topaz, vendor/foo).
-
-There are three categories of headers: system, fuchsia, other.
-
-#### For system headers
-
-```
-<zircon/foo/bar.h>
-```
-
-###### Rationale
-
-These headers describe kernel interfaces (syscalls, related structs and
-defines), shared definitions and data structures between kernel and userspace
-(and bootloader), that are often useful to higher layers as well.
-
-###### Notes
-
-- Headers may be installed straight under `zircon/`.
-- This does not include things like wrappers on syscall interfaces like zx.
-
-###### Examples
-
-- `zircon/process.h`
-- `zircon/syscalls/hypervisor.h`
-
-
-#### For global headers
-
-```
-<fuchsia/foo/bar.h>
-```
-
-###### Rationale
-
-These are libraries that define a low level ABI/API in Fuchsia but are not
-specific to the kernel.
-
-###### Notes
-
-- FIDL-generated code for Fuchsia APIs in that very namespace,
-  as well as C/C++ wrapper libraries around these APIs are installed here.
-- Headers may be installed straight under `fuchsia/`.
-
-###### Examples
-
-- `fuchsia/fdio/fdio.h`
-- `fuchsia/pixelformat.h`
-
-
-#### For other headers
-
-```
-<lib/foo/bar.h>
-```
-
-###### Rationale
-
-Some libraries in that space are not necessarily Fuchsia-specific, or they
-may be Fuchsia-specific but do not fall into either of the above categories.
-We use a rather bland namespace that will likely not cause any collisions in
-the outside world: "lib".
-
-###### Notes
-
-- Headers may not be placed straight under `lib/`. Subdirectories (`lib/foo/`)
-  are mandatory.
-
-###### Examples
-
-- `lib/app/cpp/startup_context.h`
-- `lib/fbl/array.h`
-- `lib/zx/event.h`
diff --git a/development/languages/c-cpp/syslog.md b/development/languages/c-cpp/syslog.md
index 34c065e..225b97b 100644
--- a/development/languages/c-cpp/syslog.md
+++ b/development/languages/c-cpp/syslog.md
@@ -1,123 +1,7 @@
-# Syslog
+# Obsolete
 
-This document explains how to get started with syslogger APIs.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-## In C
-
-### BUILD.gn dependency
-
-```gn
-//zircon/public/lib/syslog
-```
-
-### Initialization
-
-Logger can only be initialized once.
-
-#### Basic initialization
-
-```C
-#include <lib/syslog/global.h>
-
-int main(int argc, char** argv) {
-    fx_log_init();
-}
-```
-
-#### Initialization with tags
-
-```C
-#include <lib/syslog/global.h>
-
-int main(int argc, char** argv) {
-    fx_logger_config_t config = {.min_severity = FX_LOG_INFO,
-                                 .console_fd = -1,
-                                 .log_service_channel = ZX_HANDLE_INVALID,
-                                 .tags = (const char * []) {"gtag", "gtag2"},
-                                 .num_tags = 2};
-    fx_log_init_with_config(&config);
-}
-```
-
-### Log messages
-
-```C
-FX_LOGF(INFO, "tag", "my msg: %d", 10);
-FX_LOG(INFO, "tag", "my msg");
-FX_LOGF(INFO, NULL, "my msg: %d", 10);
-```
-
-### Reference
-
-[C APIs](https://fuchsia.googlesource.com/zircon/+/master/system/ulib/syslog/include/lib/syslog/global.h)
-
-## In C++
-
-From garnet and above layers.
-
-### BUILD.gn dependency
-
-```gn
-//garnet/public/lib/syslog/cpp
-```
-
-### sandboxing dependency
-
-```
-{
-    "sandbox": {
-        "services": [
-            "fuchsia.logger.LogSink"
-        ]
-    }
-}
-```
-
-### Initialization
-
-Logger can only be initialized once.
-
-#### Basic initialization
-
-```C++
-#include "lib/syslog/cpp/logger.h"
-
-int main(int argc, char** argv) {
-    syslog::InitLogger();
-}
-```
-
-#### Initialization with tags
-
-```C++
-#include "lib/syslog/cpp/logger.h"
-
-int main(int argc, char** argv) {
-     syslog::InitLogger({"tag1", "tag2"});
-}
-```
-
-#### Initialization using command line
-
-```C++
-#include "lib/fxl/command_line.h"
-#include "lib/fsl/syslogger/init.h"
-
-int main(int argc, char** argv) {
-    auto command_line = fxl::CommandLineFromArgcArgv(argc, argv);
-    fsl::InitLoggerFromCommandLine(command_line, {"my_program"});
-}
-```
-
-### Log messages
-
-```C++
-FX_LOGS(INFO) << "my message";
-FX_LOGST(INFO, "tag") << "my message";
-```
-
-### Reference
-
-[C++ APIs](https://fuchsia.googlesource.com/garnet/+/master/public/lib/syslog/cpp/logger.h)
-<br/>
-[FSL initialization API](https://fuchsia.googlesource.com/garnet/+/master/public/lib/fsl/syslogger/init.h)
diff --git a/development/languages/c-cpp/testing_faq.md b/development/languages/c-cpp/testing_faq.md
index 4e3f831..225b97b 100644
--- a/development/languages/c-cpp/testing_faq.md
+++ b/development/languages/c-cpp/testing_faq.md
@@ -1,23 +1,7 @@
-# Testing C/C++: Questions and Answers
+# Obsolete
 
-You are encouraged to add your own questions (and answers) here!
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-[TOC]
-
-## Q: Do we have Sanitizer support?
-
-A: This is work in progress (SEC-27). ASAN is the closest to release (just
-requires symbolization, TC-21).
-
-## Q: How do I run with ASAN?
-
-A: TBD
-
-## Q: Do we have Fuzzers enabled?
-
-A: No, sanitizer work takes precedence. Automated fuzz testing is SEC-44.
-
-## Q: Do we use gmock?
-
-A: Using the mocking functionality of gmock is
-[disallowed](library_restrictions.md).
diff --git a/development/languages/dart/README.md b/development/languages/dart/README.md
index 164ec6c..225b97b 100644
--- a/development/languages/dart/README.md
+++ b/development/languages/dart/README.md
@@ -1,66 +1,7 @@
-# Dart
+# Obsolete
 
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-## Overview
-
-Dart artifacts are not built the same way in Fuchsia as they are on other
-platforms.
-
-Instead of relying on [`pub`][pub] to manage dependencies, sources of
-third-party packages we depend on are checked into the tree under
-[`//third_party/dart-pkg`][dart-3p].
-This is to ensure we use consistent versions of our dependencies across multiple
-builds.
-
-Likewise, no build output is placed in the source tree as everything goes under
-`out/`. That includes `.packages` files which are generated as part of the build
-based on a target's dependency.
-
-
-## Targets
-
-There are five gn targets for building Dart:
-- [`dart_library`][target-library] defines a library that can be used by other
-Dart targets;
-- [`dart_app`][target-app] defines a Dart executable for Fuchsia;
-- [`dart_tool`][target-tool] defines a Dart tool for the host;
-- [`flutter_app`][target-flutter] defines a [Flutter][flutter] application;
-- [`dart_test`][target-test] defines a group of test.
-
-See the definitions of each of these targets for how to use them.
-
-
-## Package layout
-
-We use a layout very similar to the [standard layout][package-layout].
-
-```
-my_package/
-  |
-  |-- pubspec.yaml           # Empty, used as a marker [mandatory]
-  |-- BUILD.gn               # Contains all targets
-  |-- analysis_options.yaml  # Analysis configuration [mandatory]
-  |-- lib/                   # dart_library contents
-  |-- bin/                   # dart_binary's (target) or dart_tool's (host)
-  |-- test/                  # dart_test contents
-```
-
-## Going further
-
-- [Running analysis](analysis.md)
-- [Style](style.md)
-- [Testing](testing.md)
-- [Logging](logging.md)
-- [Using FIDL](fidl.md)
-- [Managing third_party dependencies](third_party.md)
-- [IDEs](ides.md)
-
-
-[pub]: https://www.dartlang.org/tools/pub/get-started "Pub"
-[package-layout]: https://www.dartlang.org/tools/pub/package-layout "Package layout"
-[target-library]: https://fuchsia.googlesource.com/build/+/master/dart/dart_library.gni "dart_library target"
-[target-app]: https://fuchsia.googlesource.com/topaz/+/master/runtime/dart_runner/dart_app.gni "dart_app target"
-[target-tool]: https://fuchsia.googlesource.com/build/+/master/dart/dart_tool.gni "dart_tool target"
-[target-flutter]: https://fuchsia.googlesource.com/topaz/+/master/runtime/flutter_runner/flutter_app.gni "flutter_app target"
-[target-test]: https://fuchsia.googlesource.com/topaz/+/master/runtime/dart/dart_test.gni "dart_test target"
-[flutter]: https://flutter.io/ "Flutter"
diff --git a/development/languages/dart/analysis.md b/development/languages/dart/analysis.md
index 9f28e75..225b97b 100644
--- a/development/languages/dart/analysis.md
+++ b/development/languages/dart/analysis.md
@@ -1,45 +1,7 @@
-# Analysis
+# Obsolete
 
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-Analysis is run as part of the Fuchsia build.
-
-For each `dart_library` target, an analysis script gets
-also generated in the output directory under:
-```sh
-out/<build-type>/gen/path/to/package/package.analyzer.sh
-```
-Running this script will perform an analysis of the target's sources.
-Note that other templates usually define a Dart library they build upon. For
-example, a `flutter_app` `//foo/bar` will yield a `//foo/bar:bar_dart_library`
-target which can also be analyzed.
-
-As with standard Dart packages, analysis options are defined in an
-`analysis_options.yaml` file, which must be placed at the package root.
-This file may refer to a common set of options by way of an `include` directive:
-```
-include: relative/path/to/options.file
-```
-A canonical set is available at `//topaz/tools/analysis_options.yaml`.
-It is customary to merely include that set from a local options file:
-```
-include: path/to/topaz/tools/analysis_options.yaml
-```
-
-Analysis may be disabled altogether for a given target with:
-```
-dart_library("foo") {
-  disable_analysis = true
-}
-```
-
-The `//scripts/run-dart-action.py` script makes it easy to run the analysis over
-multiple targets:
-```sh
-scripts/run-dart-action.py analyze --out out/<build-type> --tree //topaz/shell/*
-```
-
-Regular analyzer flags may also be passed:
-```sh
-scripts/run-dart-action.py analyze --out out/<build-type> --fatal-warnings --lints
-```
-This holds true for the individual analysis scripts.
diff --git a/development/languages/dart/fidl.md b/development/languages/dart/fidl.md
index 599bf43..225b97b 100644
--- a/development/languages/dart/fidl.md
+++ b/development/languages/dart/fidl.md
@@ -1,45 +1,7 @@
-# FIDL
+# Obsolete
 
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-[FIDL targets][fidl] generate implicit Dart bindings targets. To use the
-bindings generated for:
-```
-//foo/bar
-//foo/bar:blah
-```
-add a dependency on:
-```
-//foo/bar:bar_dart
-//foo/bar:blah_dart
-```
-and import the resulting Dart sources with:
-```
-import "package:foo.bar/baz.dart";
-import "package:foo.bar..blah/baz.dart";
-```
-
-
-## Known issues
-
-### Multiple FIDL targets in a single BUILD file
-
-If two FIDL targets coexist in a single BUILD file:
-
-* their respective, generated files will currently be placed in the same
-  subdirectory of the output directory.  This means that files belonging to one
-  target will be available to clients of the other target, and this will likely
-  confuse the analyzer.  This should not be a build issue now but could become
-  one once the generated Dart files are placed in separate directories if
-  clients do not correctly set up their dependencies.
-* depending on one of these targets from *another* FIDL target that is used by
-  a Dart package leads to a `Unable to read Dart source ...` error. The
-  bindings generator for FIDL builds Dart package names based on the directory
-  structure containing the included FIDL file, while GN (used to compute
-  dependencies for the Dart package) does so using the full GN target name. For
-  example: depending on `lib/foo/fidl:bar` generates a package like
-  `lib.foo.fidl._bar`. Depending on the top-level target `lib/foo/fidl`
-  generates the package `lib.foo.fidl`, which coincides with the Dart FIDL
-  binding's assumptions.
-
-
-[fidl]: https://fuchsia.googlesource.com/build/+/master/fidl/fidl.gni "FIDL"
diff --git a/development/languages/dart/ides.md b/development/languages/dart/ides.md
index bd4c5b5..225b97b 100644
--- a/development/languages/dart/ides.md
+++ b/development/languages/dart/ides.md
@@ -1,57 +1,7 @@
-# IDEs
+# Obsolete
 
-### Dart SDK
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-A prebuilt Dart SDK is available for IDE consumption at:
-`//third_party/dart/tools/sdks/<linux|mac>/dart-sdk`.
-Note that this SDK is sometimes a few days behind the version of
-`//third_party/dart`. If you require an up-to-date SDK, one gets built with
-Fuchsia at:
-`//out/<build-type>/dart_host/dart-sdk`.
-
-## Visual Studio Code
-
-1. Download and install [Visual Studio Code](https://code.visualstudio.com/)
-1. [optional] Setup VS Code to launch from the command line
-    * For Macs: To allow running VS Code from the terminal using the `code` command, follow the instructions [here](https://code.visualstudio.com/docs/setup/mac#_launching-from-the-command-line)
-
-    * For Linux and Windows: This should already be done as part of the installation
-1. Install the following extensions:
-    * [Dart Code](https://marketplace.visualstudio.com/items?itemName=Dart-Code.dart-code): Support for programming in Dart
-    * [FIDL language support](https://marketplace.visualstudio.com/items?itemName=fuchsia-authors.language-fidl): Syntax highlighting support for Fuchsia's FIDL files
-    * [GN](https://marketplace.visualstudio.com/items?itemName=npclaudiu.vscode-gn): Syntax highlighting for GN build files
-    * Optional but helpful git extensions:
-      * [Git Blame](https://marketplace.visualstudio.com/items?itemName=waderyan.gitblame): See git blam information in the status bar
-      * [Git History](https://marketplace.visualstudio.com/items?itemName=donjayamanne.githistory): View git log, file history, etc.
-1. Here are some helpful user settings for Dart, you can open your user settings by typing `Ctrl+,`:
-```json
-{
-  // Auto-formats your files when you save
-  "editor.formatOnSave": true,
-
-  // Settings only when working in Dart
-  "[dart]": {
-        // Adds a ruler at 80 characters
-        "editor.rulers": [
-            80
-        ],
-
-        // Makes the tab size 2 spaces
-        "editor.tabSize": 2,
-    },
-}
-
-```
-
-
-## Troubleshooting
-
-When you find the Dart analysis is not working properly in your IDE, try the
-following:
-- Delete `//out` and rebuild. Specifically, a release build overrides a debug
-  build. This means that if you have a broken release build, any release build
-  overrides a debug build. With a broken release build, no amount of correct
-  rebuilding on debug will solve the issue until you delete
-  `//out/release-x64`.
-- Delete the .packages file in your project and rebuild.
-- Reboot your machine.  (This has sometimes fixed the issue.)
diff --git a/development/languages/dart/logging.md b/development/languages/dart/logging.md
index ac1b4c0..225b97b 100644
--- a/development/languages/dart/logging.md
+++ b/development/languages/dart/logging.md
@@ -1,64 +1,7 @@
-# Logging
+# Obsolete
 
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-It is highly recommended that you use `lib.logging` package when you want to add
-logging statements to your Dart package.
-
-Include the `lib.logging` package in your BUILD.gn target as a dependency:
-```
-deps = [
-  ...
-  "//topaz/public/dart/logging:lib.logging",
-  ...
-]
-```
-
-In the main function of your Dart / Flutter app, call the `setupLogger()`
-function to make sure logs appear in the Fuchsia console in the desired format.
-```dart
-import 'package:lib.logging/logging.dart';
-
-main() {
-  setupLogger();
-}
-```
-
-After setting this up, you can call one of the following log methods to add log
-statements to your code:
-```dart
-import 'package:lib.logging/logging.dart';
-
-// add logging statements somewhere in your code as follows:
-log.info('hello world!');
-```
-
-The `log` object is a `Logger` instance as documented [here][logger-doc].
-
-
-## Log Levels
-
-The log methods are named after the supported log levels. To list the log
-methods in descending order of severity:
-```dart
-log.shout()    // maps to LOG_FATAL in FXL.
-log.severe()   // maps to LOG_ERROR in FXL.
-log.warning()  // maps to LOG_WARNING in FXL.
-log.info()     // maps to LOG_INFO in FXL.
-log.fine()     // maps to VLOG(1) in FXL.
-log.finer()    // maps to VLOG(2) in FXL.
-log.finest()   // maps to VLOG(3) in FXL.
-```
-
-By default, all the logs of which level is INFO or higher will be shown in the
-console. Because of this, Dart / Flutter app developers are highly encouraged to
-use `log.fine()` for their typical logging statements for development purposes.
-
-Currently, the log level should be adjusted in individual Dart apps by providing
-the `level` parameter in the `setupLogger()` call. For example:
-```dart
-setupLogger(level: Level.ALL);
-```
-will make all log statements appear in the console.
-
-
-[logger-doc]: https://www.dartdocs.org/documentation/logging/0.11.3%2B1/logging/Logger-class.html
diff --git a/development/languages/dart/mods.md b/development/languages/dart/mods.md
index cf643cf..225b97b 100644
--- a/development/languages/dart/mods.md
+++ b/development/languages/dart/mods.md
@@ -1,202 +1,7 @@
-# Flutter Module Development
+# Obsolete
 
-This directory demonstrates how you create modules with Dart and Flutter. At the
-moment this document assumes that every module gets built as part of the core
-fuchsia build and included in the bootfs.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-# Example Modules
-
-## Hello
-
-(located in `//topaz/examples/ui/hello_mod/`)
-
-This example demonstrates how to create a minimal flutter module and implement
-the `Module` interface. It shows a simple flutter text widget displaying "hello"
-on the screen.
-
-## Running the Examples on Fuchsia
-
-You can run an example module without going through the full-blown session shell.
-The available URLs for for flutter module examples are:
-
-*   `hello_mod`
-
-After a successful build of fuchsia, type the following command from the zx
-console to run the basemgr with the dev session shell:
-
-```
-killall scenic  # Kills all other mods.
-basemgr --session_shell=dev_session_shell --session_shell_args=--root_module=hello_mod
-```
-
-# Basics
-
-A flutter module is a flutter app which use [ModuleDriver](
-https://fuchsia.googlesource.com/topaz/+/master/public/lib/app_driver/dart/lib/src/module_driver.dart)
-. An example of a minimal
-flutter module is available in [//topaz/examples/ui/hello_mod/](
-https://fuchsia.googlesource.com/topaz/+/master/examples/ui/hello_mod/).
-
-Below we reproduce the contents of `main()` from that example:
-
-```dart
-final ModuleDriver _driver = ModuleDriver();
-
-void main() {
-  setupLogger(name: 'Hello mod');
-
-  _driver.start().then((ModuleDriver driver) {
-      log.info('Hello mod started');
-    });
-
-  runApp(
-    MaterialApp(
-      title: 'Hello mod',
-      home: ScopedModel<_MyModel>(
-        model: _MyModel(),
-        child: _MyScaffold(),
-      ),
-    ),
-  );
-}
-```
-
-# Importing Packages
-
-## Adding Dependency to BUILD.gn
-
-To import a dart package written within the fuchsia tree, the dependency should
-be added to the project's `BUILD.gn`. The `BUILD.gn` file for the hello_mod
-example looks like this:
-
-```gn
-import("//topaz/runtime/flutter_runner/flutter_app.gni")
-
-flutter_app("hello_mod") {
-  main_dart = "main.dart"
-  package_name = "hello_mod"
-  fuchsia_package_name = "hello_mod"
-  deps = [
-    "//topaz/public/dart/widgets:lib.widgets",
-    "//topaz/public/lib/app_driver/dart",
-  ]
-}
-```
-
-There are two types of dart packages we can include as `BUILD.gn` dependencies.
-
-### 1. Normal Dart Packages
-
-Any third-party dart packages, or regular dart packages manually written in the
-fuchsia tree. Import them with their relative paths from the `<fuchsia_root>`
-directory followed by two slashes. Third-party dart packages are usually located
-at `//third_party/dart-pkg/pub/<package_name>`.
-
-### 2. FIDL-Generated Dart Bindings
-
-To use any FIDL generated dart bindings, you need to first look at the
-`BUILD.gn` defining the `fidl` target that contains the desired `.fidl` file.
-For example, let's say we want to import and use the `module.fidl` file (located
-in `//peridot/public/lib/module/fidl/`) in our dart code. We should first
-look at the `BUILD.gn` file, in this case `//peridot/public/lib/BUILD.gn`. In
-this file we can see that the `module.fidl` file is included in the
-`fidl("fidl")` target.
-
-```
-fidl("fidl") {
-  sources = [
-    ...
-    "module/fidl/module.fidl",   # This is the fidl we want to use for now.
-    ...
-  ]
-}
-```
-
-This means that we need to depend on this group of fidl files. In our module's
-`BUILD.gn`, we can add the dependency with the following syntax:
-
-`"//<dir>:<fidl_target_name>_dart"`
-
-Once this is done, we can use all the interfaces defined in `.fidl` files
-contained in this `story` fidl target from our code.
-
-## Importing in Dart Code
-
-Once the desired package is added as a BUILD.gn dependency, the dart files in
-those packages can be imported in our dart code. Importing dart packages in
-fuchsia looks a bit different than normal dart packages. Let's look at the
-import statements in `main.dart` of the hello_world example.
-
-```dart
-import 'package:lib.app.dart/app.dart';
-import 'package:lib.app.fidl/service_provider.fidl.dart';
-import 'package:apps.modular.services.story/link.fidl.dart';
-import 'package:apps.modular.services.module/module.fidl.dart';
-import 'package:apps.modular.services.module/module_context.fidl.dart';
-import 'package:lib.fidl.dart/bindings.dart';
-
-import 'package:flutter/widgets.dart';
-```
-
-To import things in the fuchsia tree, we use dots (`.`) instead of slashes (`/`)
-as path delimiter. For FIDL-generated dart files, we add `.dart` at the end of
-the corresponding fidl file path. (e.g. `module.fidl.dart`)
-
-# Using FIDL Dart Bindings
-
-See the [FIDL tutorial](../fidl/tutorial/tutorial-dart.md).
-
-## Things to Watch Out For
-
-### Handles Can Only Be Used Once
-
-Once an `InterfaceHandle<Foo>` is bound to a proxy, the handle cannot be used in
-other places. Often, in case you have to share the same service with multiple
-parties (e.g. sharing the same `fuchsia::modular::Link` service across multiple
-modules), the service will provide a way to obtain a duplicate handle (e.g.
-`fuchsia::modular::Link::Dup()`).
-
-You can also call `unbind()` method on `ProxyController` to get the usable
-`InterfaceHandle<Foo>` back, which then can be used by someone else.
-
-### Proxies and Bindings Should Be Closed Properly
-
-You need to explicitly close `FooProxy` and `FooBinding` objects that are bound
-to channels, when they are no longer in use. You do not need to explicitly close
-`InterfaceRequest<Foo>` or `InterfaceHandle<Foo>` objects, as those objects
-represent unbound channels.
-
-If you don't close or unbind these objects and they get picked up by the garbage
-collector, then FIDL will terminate the process and (in debug builds) log the
-Dart stack for when the object was bound. The only exception to this rule is for
-*static* objects that live as long as the isolate itself. The system is able to
-close these objects automatically for you as part of an orderly shutdown of the
-isolate.
-
-If you are writing a Flutter widget, you can override the `dispose()` function
-on `State` to get notified when you're no longer part of the tree. That's a
-common time to close the proxies used by that object as they are often no longer
-needed.
-
-# Other Useful Tips
-
-## Getting the Atom dartlang plugin to work correctly
-
-You need to have the correct `.packages` file generated for the dart packages in
-fuchsia tree. After building fuchsia, run this script form the terminal of your
-development machine:
-
-```
-<fuchsia_root>$ scripts/symlink-dot-packages.py
-```
-
-Also, for flutter projects, the following line should be manually added to the
-`.packages` file manually (fill in the fuchsia root dir of yours):
-
-```
-sky_engine:file:///<abs_fuchsia_root>/third_party/dart-pkg/git/flutter/bin/cache/pkg/sky_engine/lib/
-```
-
-You might have to relaunch Atom to get everything working correctly. With this
-`.packages` files, you get all dartanalyzer errors/warnings, jump to definition,
-auto completion features.
diff --git a/development/languages/dart/style.md b/development/languages/dart/style.md
index cba217a..225b97b 100644
--- a/development/languages/dart/style.md
+++ b/development/languages/dart/style.md
@@ -1,335 +1,7 @@
-Dart style guide
-================
+# Obsolete
 
-The Fuchsia project follows the guidelines in [Effective Dart][effective-dart],
-but with some additions.
-
-All code must be formatted using `dartfmt` before being checked in.
-
-# Additional Style Rules
-
-### DON'T follow the Flutter repository style guide.
-
-The Flutter project's style guide is meant to be used for code in the Flutter
-framework itself. It is not intended as style guidance for projects using
-Flutter. All code in the Fuchsia repository should follow the standard
-Dart style. Although we are not following the style, the Flutter's guide on
-documentation and development is still useful.
-
-### DO use trailing commas on all tree structures longer than one line.
-
-Without trailing commas, code that builds widget trees or similar types of
-code tends to be hard to read. Adding the trailing commas allows `dartfmt`
-to do its job correctly.
-
-#### Without trailing commas:
-``` dart
-children.add(Expanded(
-  child: Center(
-      child: Container(
-          width: 64.0, height: 64.0, child: FuchsiaSpinner())),
-));
-```
-
-#### With trailing commas:
-``` dart
-children.add(Expanded(
-  child: Center(
-      child: Container(
-        width: 64.0,
-        height: 64.0,
-        child: FuchsiaSpinner(),
-      ),
-   ),
-));
-```
-
-### DO order members using the Dart Analyzer.
-In Visual Studio Code, this is the Dart: Organize Members command available
-in the Command Palette. (Control+Shift+P or View -> Command Palette)
-
-This formatter doesn’t appear to be available outside of the supported IDEs.
-
-### PREFER to keep lines below 80 characters unless it would be more readable.
-This is a slight amendment from the general Dart [rule][dartstyle-80-chars].
-Unlike that rule, it is fine to have lines above 80 characters in the Fuchsia
-repository, as long as it improves readability, and dartfmt won't automatically
-truncate the line.
-
-# Additional Usage Rules
-
-## Repositories and Files
-
-### DO follow the [Fuchsia layer repository structure][Fuchsia-directory-style].
-
-### DO prefix library names in `/lib` and `/public/lib` with `lib.`
-#### Example:
-```
-Dart_library("lib.settings") {
-  package_name = "lib.settings"
-  ...
-}
-```
-
-### PREFER minimizing the number of public members exposed in a package.
-This can be done by only making things public when needed, and keeping all
-implementation detail libraries in the `/src` directory. Assume anything
-public in the `lib` directory will be re-used.
-
-### CONSIDER exporting publicly visible classes in a single `.dart` file.
-
-For multiple classes that are used together but are in different files,
-it’s more convenient for users of your library to import a single file rather
-many at once. If the user wants narrower imports they can always restrict
-visibility using the `show` keyword.
-
-This also helps minimize the publicly visible surface.
-
-Example:
-``` dart
-/// In src/apple.dart
-class Apple {}
-
-/// In src/orange.dart
-class Orange {}
-
-/// In src/veggies.dart
-class Potato {}
-class Tomato {}
-
-/// In botanical_fruits.dart
-export 'src/apple.dart';
-export 'src/orange.dart';
-// Can also be: export 'src/veggies.dart' hide Potato;
-export 'src/veggies.dart' show Tomato;
-
-/// In squeezer.dart
-import 'package:plants/botanical_fruits.dart' show Orange;
-
-```
-
-### DO import all files within a package using relative paths.
-
-Mixing and matching relative and absolute paths within a single package
-causes Dart to act as if there were two separate imports of identical files,
-which will introduce errors in typechecking. Either format works as long as
-it is consistent. Within the Fuchsia repository, relative paths are used.
-
-This does not apply to external libraries, as only the absolute path can be
-used.
-
-#### Good:
-``` dart
-import 'access_point.dart';
-```
-
-#### Bad:
-``` dart
-import 'package:wifi/access_point.dart';
-```
-
-### DO use namespacing when you import FIDL packages.
-
-This adds clarity and readability. FIDL namespaces (library statements) are not 
-respected in Dart (e.g. `fuchsia.io.Node` becomes `Node`). 
-Because of tight namespaces, people tend to use more generic names in FIDL 
-(Error, File, Node, etc.), which result in more collisions/ambiguity in Dart.
-
-#### Good:
-
-``` dart
-import 'package:fidl_fuchsia_file/fidl.dart' as file_fidl;
-...
-
-file_fidl.File.get(...) ...
-```
-
-#### Bad:
-
-``` dart
-import 'package:fidl_fuchsia_file/fidl.dart';
-...
-
-File.get(...) ...
-```
-
-### DO use namespacing when there is ambiguity, e.g. in class names.
-
-There are often functions or classes that can collide, e.g. `File` or `Image`.
-If you don't namespace, there will be a compile error.
-
-#### Good:
-
-``` dart
-import 'dart:ui' as ui;
-
-import 'package:flutter/material.dart';
-...
-
-ui.Image(...) ...
-```
-
-#### Bad:
-
-``` dart
-import 'dart:ui';
-
-import 'package:flutter/material.dart';
-...
-
-Image(...) ... // Which Image is this?
-```
-
-### PREFER to use `show` if you only have a few imports from that package. Otherwise, use `as`.
-
-Using `show` can avoid collisions without requiring you to prepend
-namespaces to types, leading to cleaner code.
-
-#### Good:
-
-``` dart
-import 'package:fancy_style_guide/style.dart' as style;
-import 'package:flutter/material.dart';
-import 'package:math/simple_functions.dart' show Addition, Subtraction;
-```
-
-#### Bad:
-
-``` dart
-import 'package:flutter/material.dart show Container, Row, Column, Padding,
-  Expanded, ...;
-```
-
-## Coding practicies
-
-### DON'T use `new` or use `const` redundantly.
-
-Dart 2 makes the `new` optional for constructors, with an aim at removing them
-in time. The `const` keyword is also optional where it can be inferred by the
-compiler.
-
-`const` can be inferred in:
-* A const collection literal.
-* A const constructor call.
-* A metadata annotation.
-* The initializer for a const variable declaration.
-* A switch case expression&mdash;the part right after case before the :, not
-  the body of the case.
-
-This guidance will eventually be part of Effective Dart due to the changes for
-Dart 2.
-
-#### Good:
-``` dart
-final foo = Foo();
-const foo = Foo();
-const foo = const <Widget>[A(), B()];
-const Foo(): bar = Bar();
-```
-
-#### Bad:
-``` dart
-final foo = new Foo();
-const foo = const Foo();
-foo = const [const A(), const B()];
-const Foo(): bar = const Bar();
-
-```
-
-### DON'T do useful work in assert statements.
-
-Code inside assert statements are not executed in production code. Asserts
-should only check conditions and be side-effect free.
-
-### PREFER to use `const` over `final` over `var`.
-
-This minimizes the mutability for each member or local variable.
-
-### PREFER return `Widget` instead of a specific type of Flutter widget.
-
-As your project evolves, you may change the widget type that is returned in your
-function. For example, you might wrap your widget with a Center. Returning
-`Widget` simplifies the refactoring, as the method signature wouldn't have to
-change.
-
-#### Good:
-
-``` dart
-Widget returnContainerWidget() {
-  return Container();
-}
-```
-
-#### Bad:
-
-``` dart
-Container returnContainerWidget() {
-  return Container();
-}
-```
-
-# Additional Design Rules
-
-### PREFER storing state in Models instead of state.
-
-When storing state that Flutter widgets need to access, prefer to use
-`ScopedModel` and `ScopedModelDescendant` instead of `StatefulWidget`.
-A `StatefulWidget` should contain only internal widget state that can be lost
-without any consequences.
-
-Examples of stuff to store in a `ScopedModel`:
-* User selections
-* App state
-* Anything that needs to be shared by widgets
-
-Examples of stuff to store in a `StatefulWidget`'s `State`:
-* Animation state that doesn't need to be controlled
-
-### AVOID mixing named and positional parameters.
-
-Instead, `@required` should be used in place of required positional parameters.
-
-### PREFER named parameters.
-
-In most situations, named parameters are less error prone and easier to read
-than positional parameters, optional or not. They give users to pass in the
-parameters in whatever order they please, and make Flutter trees especially
-clearer.
-
-In the Fuchsia repository, positional parameters should be reserved for simple
-operational functions with only a few parameters.
-
-#### Good:
-``` dart
-int add(int a, int b);
-int addNumbers(int a, [int b, int c, int d]);
-Foo fromJson(String json);
-void load(String file);
-
-Widget buildButton({
-  @required Widget child,
-  VoidCallback onTap,
-  double width,
-  bool isDisabled = false,
-});
-```
-
-#### Bad:
-``` dart
-int add({int a, int b});
-Foo fromJson({@required String json});
-
-Widget buildButton(
-  Widget child,
-  VoidCallback onTap, [
-  double width,
-  bool isDisabled = false,
-]);
-```
-
-### DO add [logging statements][dart-logging]
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-[effective-dart]: https://www.dartlang.org/guides/language/effective-dart
-[fuchsia-directory-style]: /development/source_code/layer_repository_structure.md#
-[dart-logging]: /development/languages/dart/logging.md
-[dartstyle-80-chars]: https://www.dartlang.org/guides/language/effective-dart/style#avoid-lines-longer-than-80-characters
diff --git a/development/languages/dart/testing.md b/development/languages/dart/testing.md
index bddb8a9..225b97b 100644
--- a/development/languages/dart/testing.md
+++ b/development/languages/dart/testing.md
@@ -1,43 +1,7 @@
-# Testing
+# Obsolete
 
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-The `dart_test` target is appropriate for unit tests.
-Each target yields a test script in the output directory under:
-```sh
-out/<build-type>/gen/path/to/package/target_name.sh
-```
-This script simply runs the given tests in the Flutter shell *on the host*.
-
-The `//scripts/run-dart-action.py` script may be used to run multiple test
-suites at once:
-```sh
-scripts/run-dart-action.py test --out out/<build-type> --tree //topaz/shell/*
-```
-It also works with a single suite:
-```sh
-scripts/run-dart-action.py test --out out/<build-type> --tree //topaz/shell/armadillo:test
-```
-
-## Code coverage
-
-To generate an HTML coverage report from all `dart_test`s, first build them
-with `fx build` and then run:
-```sh
-scripts/dart/report_coverage.py --report-dir ...
-```
-
-This script runs all of the dart tests in your `<out>/host_tests/` dir with
-coverage enabled. Under the hood, each test uses the coverage collection support
-from [flutter](
-https://github.com/flutter/flutter/wiki/Test-coverage-for-package:flutter).
-
-The basic logic is:
-```
-for test in host_tests:
-  covered_lines += lines in test's package that were covered by test
-  total_lines += all lines in test's package
-```
-
-So if there are packages that have no tests at all, they won't be considered in
-the denominator of the report, which can give you a misleadingly high coverage
-number.
diff --git a/development/languages/dart/third_party.md b/development/languages/dart/third_party.md
index 5ca4c3a..225b97b 100644
--- a/development/languages/dart/third_party.md
+++ b/development/languages/dart/third_party.md
@@ -1,37 +1,7 @@
-# Third-party Dart packages
+# Obsolete
 
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-There are two types of third-party dependencies in the Fuchsia tree:
-- extracted from [pub][pub];
-- sync'd from Git.
-
-## Pub dependencies
-
-Pub dependencies are host at [`//third-party/dart-pkg`][dart-3p]. That project
-is regularly kept up-to-date with [a script][dart-3p-script] that relies on the
-`pub` tool to resolve versions and fetch sources for the packages that are used
-in the tree.
-This script uses a set of canonical local packages which are assumed to be
-providing the necessary package coverage for the entire tree.
-
-Additionally, projects may request third-party dependencies to be imported
-through the following procedure:
-1. create a `dart_dependencies.yaml` file in the project
-2. add the desired dependencies in that file:
-```
-name: my_project
-dependencies:
-  foo: ^4.0.0
-  bar: >=0.1.0
-```
-3. add a reference to the file in `//scripts/dart/update_3p_packages.py`
-4. run that script
-5. merge your changes to `dart_dependencies.yaml` to master
-6. merge the files downloaded by running the 'update_3p_packages.py' script, and the script itself, to master.
-7. in the '//topaz/manifest/dart' manifest, update the project node 'third_part/dart-pkg' revision attribute with the SHA from your commit in step 6.
-8. merge your change to the '//topaz/manifest/dart' manifest file to master.
-
-
-[pub]: https://pub.dartlang.org/ "Pub"
-[dart-3p]: https://fuchsia.googlesource.com/third_party/dart-pkg/+/master "Third-party dependencies"
-[dart-3p-script]: https://fuchsia.googlesource.com/scripts/+/master/dart/update_3p_packages.py "Dependencies script"
diff --git a/development/languages/fidl/README.md b/development/languages/fidl/README.md
index 7a64276..225b97b 100644
--- a/development/languages/fidl/README.md
+++ b/development/languages/fidl/README.md
@@ -1,21 +1,7 @@
-# FIDL
+# Obsolete
 
-FIDL (or "**F**uchsia **I**nterface **D**efinition **L**anguage) is the IPC system for Fuchsia.
-
-The following topics are presented:
-
-* [Introduction](intro/README.md) &mdash; a brief overview of what FIDL is; a quick start
-* [Guides](guides/README.md) &mdash; high-level use cases
-* [Tutorial](tutorial/README.md) &mdash; language-specific "how-to"s based on the Guides
-* [Effective FIDL] &mdash; specific advice about best practices
-* [Reference](reference/README.md) &mdash; a technical deep dive for the interested developer,
-	featuring FIDL grammar, language features, on-wire format, building, and so on.
-
-# Supported Languages
-
-* [C](languages/c.md)
-* [C++](languages/cpp.md)
-* [Dart](languages/dart.md)
-* [Go](languages/go.md)
-* [Rust](languages/rust.md)
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
diff --git a/development/languages/fidl/guides/README.md b/development/languages/fidl/guides/README.md
index 2d0f715..225b97b 100644
--- a/development/languages/fidl/guides/README.md
+++ b/development/languages/fidl/guides/README.md
@@ -1,13 +1,7 @@
+# Obsolete
 
-# The FIDL Guides
-
-This is a placeholder for Guides.
-Our goal here is to provide a language-agnostic (high-level) view of
-various use cases for FIDL, such as:
-
-* error codes using FIDL enums
-* IP addresses using FIDL unions
-* fire-and-forget messages (for example, for configuration)
-* RPC style messages (when you need to wait for the reply)
-* notifications (when you want to receive messages asynchronously)
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
diff --git a/development/languages/fidl/intro/README.md b/development/languages/fidl/intro/README.md
index 9514843..225b97b 100644
--- a/development/languages/fidl/intro/README.md
+++ b/development/languages/fidl/intro/README.md
@@ -1,263 +1,7 @@
-# Overview
+# Obsolete
 
-This document is a description of the Fuchsia Interface Definition Language
-(FIDL) purpose, high-level goals, and requirements.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-## Related Documents
-
-*   [Wire Format Specification]
-*   [Language Specification]
-*   [Compiler Specification]
-*   [API Readability / Style Guide]
-*   [C Language Bindings]
-*   [C++ Language Bindings]
-*   [Examples]: Some small example code used during development
-*   [Tutorial]: A tutorial on using FIDL services in several languages
-
-<!-- Reference links because these are used again below. -->
-
-[Wire Format Specification]: ../reference/wire-format/index.md
-[Language Specification]: ../reference/language.md
-[Compiler Specification]: ../reference/compiler.md
-[API Readability / Style Guide]: ../../../api/fidl.md
-[C Language Bindings]: ../languages/c.md
-[C++ Language Bindings]: ../languages/cpp.md
-[Examples]: https://fuchsia.googlesource.com/zircon/+/master/system/host/fidl/examples
-[Tutorial]: ../tutorial/README.md
-
-[TOC]
-
-## Overview
-
-The Fuchsia Interface Definition Language (FIDL) is the language used to
-describe interprocess communication (IPC) protocols used by programs running on
-the Fuchsia Operating System. FIDL is supported by a toolchain (compiler) and
-runtime support libraries (bindings) to help developers use IPC effectively.
-
-Goals
-
-Fuchsia extensively relies on IPC since it has a microkernel architecture
-wherein most functionality is implemented in user space outside of the kernel,
-including privileged components such as device drivers. Consequently the IPC
-mechanism must be efficient, deterministic, robust, and easy to use.
-
-**IPC efficiency** pertains to the computational overhead required to generate,
-transfer, and consume messages between processes. IPC will be involved in all
-aspects of system operation so it must be efficient. The FIDL compiler must
-generate tight code without excess indirection or hidden costs. It should be at
-least as good as hand-rolled code would be where it matters most.
-
-**IPC determinism** pertains to the ability to perform transactions within a
-known resource envelope. IPC will be used extensively by critical system
-services such as filesystems which serve many clients and which must perform in
-predictable ways. The FIDL wire format must offer strong static guarantees such
-as ensuring that structure size and layout is invariant thereby alleviating the
-need for dynamic memory allocation or complex validation rules.
-
-**IPC robustness** pertains to the need to consider IPC as an essential part of
-the operating system's ABI. Maintaining binary stability is crucial. Mechanisms
-for protocol evolution must be designed conservatively so as not to violate the
-invariants of existing services and their clients, particularly when the need
-for determinism is also considered. The FIDL bindings must perform effective,
-lightweight, and strict validation.
-
-**IPC ease of use** pertains to the fact that IPC protocols are an essential
-part of the operating system's API. It is important to provide good developer
-ergonomics for accessing services via IPC. The FIDL code generator removes the
-burden of writing IPC bindings by hand. Moreover, the FIDL code generator can
-produce different bindings to suit the needs of different audiences and their
-idioms.
-
-TODO: express goal of meeting the needs of different audiences using
-appropriately tailored bindings, eg. system programming native vs. event-driven
-dispatch vs. async calls, etc... say more things about FIDL as our system API,
-SDK concerns, etc.
-
-Requirements
-
-# Purpose
-
-*   Describe data structures and interfaces used by IPC protocols on Zircon.
-*   Optimized for interprocess communication only; FIDL must not be persisted to
-    disk or used for network transfer across device boundaries.
-*   Efficiently transport messages consisting of data (bytes) and capabilities
-    (handles) over Zircon channels between processes running on the same
-    device.
-*   Designed specifically to facilitate effective use of Zircon primitives; not
-    intended for use on other platforms; not portable.
-*   Offers convenient APIs for creating, sending, receiving, and consuming
-    messages.
-*   Perform sufficient validation to maintain protocol invariants (but no more
-    than that).
-
-# Efficiency
-
-*   Just as efficient (speed and memory) as using hand-rolled data structures
-    would be.
-*   Wire format uses uncompressed native datatypes with host-endianness and
-    correct alignment to support in-place access of message contents.
-*   No dynamic memory allocation is required to produce or to consume messages
-    when their size is statically known or bounded.
-*   Explicitly handle ownership with move-only semantics.
-*   Data structure packing order is canonical, unambiguous, and has minimum
-    padding.
-*   Avoid back-patching pointers.
-*   Avoid expensive validation.
-*   Avoid calculations which may overflow.
-*   Leverage pipelining of interface requests for asynchronous operation.
-*   Structures are fixed size; variable-size data is stored out-of-line.
-*   Structures are not self-described; FIDL files describe their contents.
-*   No versioning of structures, but interfaces can be extended with new methods
-    for protocol evolution.
-
-# Ergonomics
-
-*   Programming language bindings maintained by Fuchsia team:
-    *   C, C++ (native), C++ (idiomatic), Dart, Go, Rust
-*   Keeping in mind we might want to support other languages in the future, such
-    as:
-    *   Java, Javascript, etc.
-*   The bindings and generated code are available in native or idiomatic flavors
-    depending on the intended application.
-*   Use compile-time code generation to optimize message serialization,
-    deserialization, and validation.
-*   FIDL syntax is familiar, easily accessible, and programming language
-    agnostic.
-*   FIDL provides a library system to simplify deployment and use by other
-    developers.
-*   FIDL expresses the most common data types needed for system APIs; it does
-    not seek to provide a comprehensive one-to-one mapping of all types offered
-    by all programming languages.
-
-# Implementation
-
-*   Compiler is written in C++ to be usable by components built in Zircon.
-
-*   Compiler is portable and can be built with a host toolchain.
-
-*   We will not support FIDL bindings for any platform other than Fuchsia.
-
-## Where to Find the Code
-
-- [The compiler](https://fuchsia.googlesource.com/zircon/+/master/system/host/fidl)
-- [C bindings](https://fuchsia.googlesource.com/zircon/+/master/system/ulib/fidl)
-- [C++ bindings](https://fuchsia.googlesource.com/garnet/+/master/public/lib/fidl/cpp)
-- [Go bindings](https://fuchsia.googlesource.com/third_party/go/+/master/src/syscall/zx/fidl/)
-- [Rust bindings](https://fuchsia.googlesource.com/garnet/+/master/public/lib/fidl/rust)
-
-## Constituent Parts of Specification
-
-### FIDL Wire Format
-
-The FIDL wire format specified how FIDL messages are represented in memory for
-transmission over IPC.
-
-The FIDL wire format is documented [Wire Format Specification].
-
-### FIDL Language
-
-The FIDL language is the syntax by which interfaces are described in ***.fidl**
-files.
-
-The FIDL language is documented [Language Specification].
-
-### FIDL Compiler
-
-The FIDL compiler generates code for programs to use and implement interfaces
-described by the FIDL language.
-
-The FIDL compiler is documented [Compiler Specification].
-
-### FIDL Bindings
-
-FIDL bindings are language-specific runtime support libraries and code
-generators which provide APIs for manipulating FIDL data structures and
-interfaces.
-
-Languages-specific topics:
-
-*   [C Language Bindings]
-*   [C++ Language Bindings]
-
-Bindings are available in various flavors depending on the language:
-
-*   **Native bindings**: designed for highly sensitive contexts such as device
-    drivers and high-throughput servers, leverage in-place access, avoid memory
-    allocation, but may require somewhat more awareness of the constraints of
-    the protocol on the part of the developer.
-*   **Idiomatic bindings**: designed to be more developer-friendly by copying
-    data from the wire format into easier to use data types (such as heap-backed
-    strings or vectors), but correspondingly somewhat less efficient as a
-    result.
-
-Bindings offer several various ways of invoking interface methods depending on
-the language:
-
-*   **Send/receive**: read or write messages directly to a channel, no built-in
-    wait loop (C)
-*   **Callback-based**: received messages are dispatched asynchronously as
-    callbacks on an event loop (C++, Dart)
-*   **Port-based**: received messages are delivered to a port or future (Rust)
-*   **Synchronous call**: waits for reply and return it (Go, C++ unit tests)
-
-Bindings provide some or all of the following principal operations:
-
-*   **Encode**: in-place transform native data structures into the wire format
-    (coupled with validation)
-*   **Decode**: in-place transform wire format data into native data structures
-    (coupled with validation)
-*   **Copy/Move To Idiomatic Form**: copy contents of native data structures
-    into idiomatic data structures, handles are moved
-*   **Copy/Move To Native Form**: copy contents of idiomatic data structures
-    into native data structures, handles are moved
-*   **Clone**: copy native or idiomatic data structures (that do not contain
-    move-only types)
-*   **Call**: invoke interface method
-
-## Workflow
-
-This section describes the workflow of authors, publishers, and consumers of IPC
-protocols described using FIDL.
-
-# Authoring FIDL
-
-The author of a FIDL based protocol creates one or more ***.fidl files** to
-describe their data structures and interfaces.
-
-FIDL files are grouped into one or more **FIDL libraries** by the author. Each
-library represents a group of logically related functionality with a unique
-library name. FIDL files within the same library implicitly have access to all
-other declarations within the same library. The order of declarations within the
-FIDL files that make up a library is not significant.
-
-FIDL files of one library can access declarations within another FIDL library by
-**importing** the other FIDL module. Importing other FIDL libraries makes their
-symbols available for use thereby enabling the construction of protocols derived
-from them. Imported symbols must be qualified by the library name or by an alias
-to prevent namespace collisions.
-
-# Publishing FIDL
-
-The publisher of a FIDL based protocol is responsible for making FIDL libraries
-available to consumers. For example, the author may disseminate FIDL libraries in
-a public source repository or distribute them as part of an SDK.
-
-Consumers need only point the FIDL compiler at the directory which contains the
-FIDL files for a library (and its dependencies) to generate code for that
-library. The precise details for how this is done will generally be addressed by
-the consumer's build system.
-
-# Consuming FIDL
-
-The consumer of a FIDL based protocol uses the FIDL compiler to generate code
-suitable for use with their language runtime specific bindings. For certain
-language runtimes, the consumer may have a choice of a few different flavors of
-generated code all of which are interoperable at the wire format level but
-perhaps not at the source level.
-
-In the Fuchsia world build environment, generating code from FIDL libraries will
-be done automatically for all relevant languages by individual FIDL build
-targets for each library.
-
-In the Fuchsia SDK environment, generating code from FIDL libraries will be done
-as part of compiling the applications which use them.
diff --git a/development/languages/fidl/languages/c.md b/development/languages/fidl/languages/c.md
index a91ebdd..225b97b 100644
--- a/development/languages/fidl/languages/c.md
+++ b/development/languages/fidl/languages/c.md
@@ -1,558 +1,7 @@
+# Obsolete
 
-# C Language Bindings
-
-This document is a description of the Fuchsia Interface Definition Language
-(FIDL) implementation for C, including its libraries and code generator.
-
-[TOC]
-
-## Design
-
-### Goals
-
- * Support encoding and decoding FIDL objects with C11.
- * Generate headers which are compatible with C11 and C++14.
- * Small, fast, efficient.
- * Depend only on a small subset of the standard library.
- * Minimize code expansion through table-driven encoding and decoding.
- * Support two usage styles: raw and simple.
-
-### Raw Usage Style
-
- * Optimized to meet the needs of low-level systems programming.
- * Represent data structures whose memory layout coincides with the wire format.
- * Support in-place access and construction of FIDL objects.
- * Defer all memory allocation decisions to the client.
- * Code generator only produces type declarations, data tables, and simple inline functions.
- * Client is fully responsible for dispatching incoming method calls on
-   interfaces (write their own switch statement and invoke argument decode
-   functions).
-
-### Simple Usage Style
-
- * Optimized to meet the needs of driver developers.
- * Supports only a simple subset of the FIDL language.
- * Represent data structures whose memory layout coincides with the wire format.
- * Defer all memory allocation decisions to the client.
- * Code generator produces simple C functions for sending, receiving, and
-   dispatching messages.
-
-### Encoding Tables
-
-To avoid generating any non-inline code whatsoever, the C language bindings
-instead produce encoding tables which describe how objects are encoded.
-
-### Introspection Tables
-
-To allow for objects to be introspected (eg. printed), the C language bindings
-produce introspection tables which describe the name and type signature of each
-method of each interface and data structure.
-
-Although small, introspection tables will be stripped out by the linker if
-unused.
-
-### Mapping FIDL Types to C Types
-
-This is the mapping from FIDL types to C types which the code generator
-produces.
-
-| FIDL                                     | C Type                     |
-|------------------------------------------|----------------------------|
-| `bool`                                   | `bool`                     |
-| `int8`                                   | `int8_t`                   |
-| `uint8`                                  | `uint8_t`                  |
-| `int16`                                  | `int16_t`                  |
-| `uint16`                                 | `uint16_t`                 |
-| `int32`                                  | `int32_t`                  |
-| `uint32`                                 | `uint32_t`                 |
-| `int64`                                  | `int64_t`                  |
-| `uint64`                                 | `uint64_t`                 |
-| `float32`                                | `float`                    |
-| `float64`                                | `double`                   |
-| `handle`, `handle?`, `handle`, `handle?` | `zx_handle_t`              |
-| `string`, `string?`                      | `fidl_string_t`            |
-| `vector`, `vector?`                      | `fidl_vector_t`            |
-| `array<T>:N`                             | `T[N]`                     |
-| `Interface`, `Interface?`                | typedef to `zx_handle_t`   |
-| `request<I>`, `request<I>?`              | typedef to `zx_handle_t`   |
-| `Struct`                                 | `struct Struct`            |
-| `Struct?`                                | `struct Struct*`           |
-| `Union`                                  | `struct Union`             |
-| `Union?`                                 | `struct Union*`            |
-| `Enum`                                   | typedef to underlying type |
-
-## zircon/fidl.h
-
-The `zircon/fidl.h` header defines the basic constructs of the FIDL wire format.
-The header is part of the Zircon system headers and depends only on other Zircon
-system headers and a small portion of the C standard library.
-
-### fidl_message_header_t
-
-```c
-typedef struct fidl_message_header {
-    zx_txid_t txid;
-    uint32_t reserved0;
-    uint32_t flags;
-    uint32_t ordinal;
-} fidl_message_header_t;
-```
-
-Defines the initial part of every FIDL message sent over a channel. The header
-is immediately followed by the body of the payload. Currently, there are no
-flags to be set, and so `flags` must be zero.
-
-### fidl_string_t
-
-```c
-typedef struct fidl_string {
-    // Number of UTF-8 code units (bytes), must be 0 if |data| is null.
-    uint64_t size;
-
-    // Pointer to UTF-8 code units (bytes) or null
-    char* data;
-} fidl_string_t;
-```
-
-Holds a reference to a variable-length string.
-
-When decoded, **data** points to the location within the buffer where the string
-content lives, or **NULL** if the reference is null.
-
-When encoded, **data** is replaced by **FIDL_ALLOC_PRESENT** when the reference
-is non-null or **FIDL_ALLOC_ABSENT** when the reference is null. The location of
-the string's content is determined by the depth-first traversal order of the
-message during decoding.
-
-### fidl_vector_t
-
-```c
-typedef struct fidl_vector {
-    // Number of elements, must be 0 if |data| is null.
-    uint64_t count;
-
-    // Pointer to element data or null.
-    void* data;
-} fidl_vector_t;
-```
-
-Holds a reference to a variable-length vector of elements.
-
-When decoded, **data** points to the location within the buffer where the
-elements live, or **NULL** if the reference is null.
-
-When encoded, **data** is replaced by **FIDL_ALLOC_PRESENT** when the reference
-is non-null or **FIDL_ALLOC_ABSENT** when the reference is null. The location of
-the vector's content is determined by the depth-first traversal order of the
-message during decoding.
-
-### fidl_msg_t
-
-```c
-typedef struct fidl_msg {
-    // The bytes of the message.
-    //
-    // The bytes of the message might be in the encoded or decoded form.
-    // Functions that take a |fidl_msg_t| as an argument should document whether
-    // the expect encoded or decoded messages.
-    //
-    // See |num_bytes| for the number of bytes in the message.
-    void* bytes;
-
-    // The handles of the message.
-    //
-    // See |num_bytes| for the number of bytes in the message.
-    zx_handle_t* handles;
-
-    // The number of bytes in |bytes|.
-    uint32_t num_bytes;
-
-    // The number of handles in |handles|.
-    uint32_t num_handles;
-} fidl_msg_t;
-```
-
-Represents a FIDL message, including both `bytes` and `handles`. The message
-might be in the encoded or decoded format. The ownership semantics for the
-memory referred to by `bytes` and `handles` is defined by the context in which
-the `fidl_msg_t` struct is used.
-
-### fidl_txn_t
-
-```c
-typedef struct fidl_txn fidl_txn_t;
-struct fidl_txn {
-    // Replies to the outstanding request and complete the FIDL transaction.
-    //
-    // Pass the |fidl_txn_t| object itself as the first paramter. The |msg|
-    // should already be encoded. This function always consumes any handles
-    // present in |msg|.
-    //
-    // Call |reply| only once for each |txn| object. After |reply| returns, the
-    // |txn| object is considered invalid and might have been freed or reused
-    // for another purpose.
-    zx_status_t (*reply)(fidl_txn_t* txn, const fidl_msg_t* msg);
-};
-```
-
-Represents a outstanding FIDL transaction that requires a reply. Used by the
-simple C bindings to route replies to the correct transaction on the correct
-channel.
-
-## Raw Bindings
-
-### fidl_encode / fidl_encode_msg
-
-Declared in
-[lib/fidl/coding.h](https://fuchsia.googlesource.com/zircon/+/master/system/ulib/fidl/include/lib/fidl/coding.h),
-defined in
-[encoding.cpp](https://fuchsia.googlesource.com/zircon/+/master/system/ulib/fidl/encoding.cpp).
-
-Encodes and validates exactly **num_bytes** of the object in **bytes** in-place
-by performing a depth-first traversal of the encoding data from **type**
-to fix up internal references. Replaces internal pointers references with
-`FIDL_ALLOC_ABSENT` or `FIDL_ALLOC_PRESENT` to indicate presence.
-Extracts non-zero internal handle references out of **bytes**, stores up to
-**max_handles** of them sequentially in **handles**, and replaces their location
-in **bytes** with `FIDL_HANDLE_PRESENT` to indicate their presence. Sets
-**actual_handles_out** to the number of handles stored in **handles**.
-
-To prevent handle leakage, this operation ensures that either all handles within
-**bytes** are moved into **handles** in case of success or they are all closed in
-case of an error.
-
-If a recoverable error occurs, such as encountering a null pointer for a
-required sub-object, **bytes** remains in an unusable partially modified state.
-
-All handles in **bytes** which were already been consumed up to the point of the
-error are closed and **actual_handles_out** is set to zero. Depth-first traversal of
-the object then continues to completion, closing all remaining handles in **bytes**.
-
-If an unrecoverable error occurs, such as exceeding the bound of the buffer,
-exceeding the maximum nested complex object recursion depth, encountering
-invalid encoding table data, or a dangling pointer, the behavior is undefined.
-
-On success, **bytes** and **handles** describe an encoded object ready to be sent
-using `zx_channel_send()`.
-
-If anything other than `ZX_OK` is returned, **error_msg_out** will be set.
-
-Result is...
-
-*   `ZX_OK`: success
-*   `ZX_ERR_INVALID_ARGS`:
-    *   **type** is null
-    *   **bytes** is null
-    *   **actual_handles_out** is null
-    *   **handles** is null and **max_handles** != 0
-    *   **type** is not a FIDL struct
-    *   there are more than **max_handles** in **bytes**
-    *   the total length of the object in **bytes** determined by the traversal
-        does not equal precisely **num_bytes**
-    *   **bytes** contains an invalid union field, according to **type**
-    *   a required pointer reference in **bytes** was null
-    *   a required handle reference in **bytes** was `ZX_HANDLE_INVALID`
-    *   a bounded string or vector in **bytes** is too large, according to
-        **type**
-    *   a pointer reference in **bytes** does not have the expected value
-        according to the traversal
-    *   `FIDL_RECURSION_DEPTH` was exceeded (see
-        [wire format](../reference/wire-format/index.md))
-
-This function is effectively a simple interpreter of the contents of the
-type. Unless the object encoding includes internal references which
-must be fixed up, the only work amounts to checking the object size and the
-ranges of data types such as enums and union tags.
-
-### fidl_decode / fidl_decode_msg
-
-Declared in
-[lib/fidl/coding.h](https://fuchsia.googlesource.com/zircon/+/master/system/ulib/fidl/include/lib/fidl/coding.h),
-defined in
-[decoding.cpp](https://fuchsia.googlesource.com/zircon/+/master/system/ulib/fidl/decoding.cpp).
-
-Decodes and validates the object in **bytes** in-place by performing a
-depth-first traversal of the encoding data from **type** to fix up internal
-references. Patches internal pointers within **bytes** whose value is
-`FIDL_ALLOC_PRESENT` to refer to the address of the out-of-line data they
-reference later in the buffer. Populates internal handles within **bytes**
-whose value is `FIDL_HANDLE_PRESENT` to their corresponding handle taken
-sequentially from **handles**.
-
-To prevent handle leakage, this operation ensures that either all handles in
-**handles** from **handles[0]** to **handles[num_handles - 1]** are moved into
-**bytes** in case of success or they are all closed in case of an error.
-
-The **handles** array is not modified by the operation.
-
-If a recoverable error occurs, a result is returned, **bytes** remains in an
-unusable partially modified state, and all handles in **handles** are closed.
-
-If an unrecoverable error occurs, such as encountering an invalid **type**,
-the behavior is undefined.
-
-If anything other than `ZX_OK` is returned, **error_msg_out** will be set.
-
-Result is...
-
-*   `ZX_OK`: success
-*   `ZX_ERR_INVALID_ARGS`:
-    *   **type** is null
-    *   **bytes** is null
-    *   **handles** is null but **num_handles** != 0.
-    *   **handles** is null but **bytes** contained at least one valid handle
-        reference
-    *   **type** is not a FIDL struct
-    *   the total length of the object determined by the traversal does not equal
-        precisely **num_bytes**
-    *   the total number of handles determined by the traversal does not equal
-        precisely **num_handles**
-    *   **bytes** contains an invalid union field, according to **type**
-    *   a required pointer reference in **bytes** is `FIDL_ALLOC_ABSENT`.
-    *   a required handle reference in **bytes** is `ZX_HANDLE_INVALID`.
-    *   **bytes** contains an optional pointer reference which is marked
-        as `FIDL_ALLOC_ABSENT` but has size > 0.
-    *   a bounded string or vector in **bytes** is too large, according to
-        **type**
-    *   a pointer reference in **bytes** has a value other than
-        `FIDL_ALLOC_ABSENT` or `FIDL_ALLOC_PRESENT`.
-    *   a handle reference in **bytes** has a value other than
-        `ZX_HANDLE_INVALID` or `FIDL_HANDLE_PRESENT`.
-    *   `FIDL_RECURSION_DEPTH` was exceeded (see
-        [wire format](../reference/wire-format/index.md))
-
-This function is effectively a simple interpreter of the contents of the
-type. Unless the object encoding includes internal references which
-must be fixed up, the only work amounts to checking the object size and the
-ranges of data types such as enums and union tags.
-
-### fidl_validate
-
-Declared in
-[system/ulib/fidl/include/lib/fidl/coding.h](
-https://fuchsia.googlesource.com/zircon/+/master/system/ulib/fidl/include/lib/fidl/coding.h),
-defined in
-[system/ulib/fidl/validating.cpp](
-https://fuchsia.googlesource.com/zircon/+/master/system/ulib/fidl/validating.cpp).
-
-Validates the object in **bytes** in-place by performing a depth-first
-traversal of the encoding data from **type** to fix up internal
-references. This performs the same validation as **fidl_decode()**, but
-does not modify any passed-in data.
-
-The **bytes** buffer is not modified by the operation.
-
-If anything other than `ZX_OK` is returned, **error_msg_out** will be set.
-
-Result is the same as for **fidl_encode()** above.
-
-This function is effectively a simple interpreter of the contents of the
-type. Unless the object encoding includes internal references which
-must be fixed up, the only work amounts to checking the object size and the
-ranges of data types such as enums and union tags.
-
-### fidl_epitaph_write
-
-Declared in
-[lib/fidl/epitaph.h](https://fuchsia.googlesource.com/zircon/+/master/system/ulib/fidl/include/lib/fidl/epitaph.h),
-defined in
-[epitaph.c](https://fuchsia.googlesource.com/zircon/+/master/system/ulib/fidl/epitaph.c).
-
-This function sends an epitaph with the given error number down the given
-channel.  An epitaph is a special message, with ordinal 0xFFFFFFFF, which
-contains an error code.  The epitaph must be the last thing sent down the
-channel before it is closed.
-
-### Sending Messages
-
-The client performs the following operations to send a message through a
-channel.
-
-*   Obtain a buffer large enough to hold the entire message.
-*   Write the message header into the buffer, which includes the transaction id
-    and method ordinal.
-*   Write the message body into the buffer, which includes the method arguments
-    and any secondary objects (see
-    [wire format](../reference/wire-format/index.md)
-    for a definition of secondary objects).
-*   Call **fidl_encode()** to encode the message and handles for
-    transfer, taking care to pass a pointer to the **encoding table** of the
-    message.
-*   Call **zx_channel_write()** to send the message buffer and its associated
-    handles.
-*   Discard or reuse the buffer. (No need to release handles since they were
-    transferred.)
-
-For especially simple messages, it may be possible to skip the encoding step
-altogether (or do it manually).
-
-### Receiving Messages
-
-The client performs the following operations to receive a message through a
-channel.
-
-*   Obtain a buffer large enough to hold the largest possible message which can
-    be received by this protocol. (May dynamically allocate the buffer after
-    getting the incoming message size from the channel.)
-*   Call **zx_channel_read()** to read the message into the buffer and its
-    associated handles.
-*   Dispatch the message based on the method ordinal stored in the message
-    header. If the message is invalid, close the handles and skip to the last
-    step.
-*   Call **fidl_decode()** to decode and validate the message and handles
-    for access, taking care to pass a pointer to the **encoding table** of the
-    message.
-*   If the message is invalid, skip to last step. (No need to release handles
-    since they will be closed automatically by the decoder.)
-*   Consume the message.
-*   Discard or reuse the buffer.
-
-For especially simple messages, it may be possible to skip the encoding step
-altogether (or do it manually).
-
-### Closing Channels
-
-The C language bindings do not provide any special affordances for closing
-channels.  Per the FIDL specification, an epitaph must be sent as the last
-message prior to closing a channel.  Code should call **fidl_epitaph_write()**
-prior to closing a channel.
-
-### Dispatching Messages
-
-The C language bindings do not provide any special affordances for dispatching
-interface method calls. The client should dispatch manually based on the
-interface method ordinal, such as by using a **switch** statement.
-
-## Simple Bindings
-
-The simple C bindings provide easy-to-use C bindings for a subset of the FIDL
-language.
-
-### Simple Layout
-
-In order to generate simple C bindings for an interface, the interface must have
-the `[Layout="Simple"]` attribute. This attribute enforces that the interface,
-including the types referenced by the interface, conform to the language subset
-supported by FIDL.
-
-Specifically, every message in the interface (including both requests and
-response) must not have any secondary objects except strings and vectors of
-handles or primitives (see
-[wire format](../reference/wire-format/index.md)
-for a definition of secondary objects). This invariant simplifies the memory
-ownership semantics. Additionally, all strings and vectors must have explicit
-non-maximal length bounds. `vector<int64>:64` is a vector with such a bound, while
-`vector<int64>` lacks an explicit non-maximal bound. This requirement simplifies
-buffer management for clients that receive these values.
-
-For example, structs and unions can embed other structs and unions, but they
-cannot contain nullable references to other structs or unions because nullable
-structs and unions are stored out-of-line in secondary objects. Nullable handles
-and interfaces are allowed because they're stored inline as `ZX_HANDLE_INVALID`.
-
-Below is an example of an interface that meets these requirements:
-
-```fidl
-library unn.fleet;
-
-struct SolarPosition {
-    array<int64>:3 coord;
-};
-
-enum Alert {
-    GREEN = 1;
-    YELLOW = 2;
-    RED = 3;
-};
-
-[Layout="Simple"]
-interface SpaceShip {
-    1: AdjustHeading(SolarPosition destination) -> (int8 result);
-    2: ScanForLifeforms() -> (vector<uint32>:64 life_signs);
-    3: SetDefenseCondition(Alert alert);
-};
-```
-
-### Client
-
-For clients, the simple C bindings generate a function for each method that
-takes a channel as its first parameter. These functions are safe to use from any
-thread and do not require any coordination:
-
-```c
-zx_status_t unn_fleet_SpaceShipSetDefenseCondition(
-    zx_handle_t channel,
-    const unn_fleet_Alert* alert);
-```
-
-If the method has a response, the generated function will wait synchronously for
-the server to reply. If the response contains any data, the data is returned to
-the caller through out parameters:
-
-```c
-zx_status_t unn_fleet_SpaceShipAdjustHeading(
-    zx_handle_t channel,
-    const unn_fleet_SolarPosition* destination,
-    int8_t* result);
-```
-
-The `zx_status_t` returned by these functions indicates whether the transport
-was successful. Protocol-level status is communicated through out parameters.
-
-### Server
-
-For servers, the simple C bindings generate an ops table that contains a
-function pointer for every method in the interface and a dispatch method that
-decodes the `fidl_msg_t` and calls the appropriate function pointer:
-
-```c
-typedef struct unn_fleet_SpaceShip_ops {
-    zx_status_t (*AdjustHeading)(void* ctx,
-                                 const unn_fleet_SolarPosition* destination,
-                                 fidl_txn_t* txn);
-    zx_status_t (*ScanForLifeforms)(void* ctx, fidl_txn_t* txn);
-    zx_status_t (*SetDefenseCondition)(void* ctx, const unn_fleet_Alert* alert);
-} unn_fleet_SpaceShip_ops_t;
-
-zx_status_t unn_fleet_SpaceShip_dispatch(
-    void* ctx,
-    fidl_txn_t* txn,
-    fidl_msg_t* msg,
-    const unn_fleet_SpaceShip_ops_t* ops);
-```
-
-The `ctx` parameter is an opaque parameter that is passed through the dispatch
-function to the appropriate function pointer. You can use the `ctx` parameter to
-pass contextual information to the method implementations.
-
-The `txn` parameter is passed through the dispatch function to function pointers
-for methods that have responses. To reply to a message, the implementation of
-that method should call the appropriate reply function:
-
-```c
-zx_status_t unn_fleet_SpaceShipScanForLifeforms_reply(
-    fidl_txn_t* txn,
-    const uint32_t* life_signs_data,
-    size_t life_signs_count);
-```
-
-For example, `ScanForLifeforms` might be implemented as follows:
-
-```c
-static zx_status_t SpaceShip_ScanForLifeforms(void* ctx, fidl_txn_t* txn) {
-    uint32_t life_signs[4] = {42u, 32u, 79u, 23u};
-    return unn_fleet_SpaceShipScanForLifeforms_reply(txn, life_signs, 4);
-}
-```
-
-These reply functions encode the reply and call through the `reply` function
-pointer on `fidl_msg_t`.
-
-### Binding
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-FIDL also provides `fidl_bind`, defined in
-[lib/fidl/bind.h](https://fuchsia.googlesource.com/zircon/+/master/system/ulib/fidl-async/include/lib/fidl-async/bind.h),
-that binds a generated
-dispatch function to an `async_dispatcher_t`. The `fidl_bind` function creates
-an `async_wait_t` that waits for messages on the channel and calls through the
-given dispatcher (and ops table) when they arrive.
diff --git a/development/languages/fidl/languages/cpp.md b/development/languages/fidl/languages/cpp.md
index 7ea50ee..225b97b 100644
--- a/development/languages/fidl/languages/cpp.md
+++ b/development/languages/fidl/languages/cpp.md
@@ -1,666 +1,7 @@
+# Obsolete
 
-# C++ Language Bindings
-
-This document is a description of the Fuchsia Interface Definition Language
-(FIDL) implementation for C++, including its libraries and code generator.
-
-See [Overview][fidl-overview] for more information about FIDL's overall
-purpose, goals, and requirements, as well as links to related documents.
-
-This specification builds on the [C Language
-Bindings](c.md) and reuses many of its elements where
-appropriate.
-
-[TOC]
-
-## Design
-
-### Goals
-
-*   Support encoding and decoding FIDL messages with C++14.
-*   Small, fast, efficient.
-*   Depend only on a small subset of the standard library.
-*   Minimize code expansion through table-driven encoding and decoding.
-*   Support two usage styles using different generated code: native and
-    idiomatic.
-*   All code produced to support the idiomatic style can be stripped out if
-    unused.
-*   Reuse encoders, decoders, and data tables generated for C language bindings.
-
-### Native Usage Style
-
-*   Optimized to meet the needs of low-level systems programming while providing
-    slightly more safety and convenience than the C bindings.
-*   Represent data structures whose memory layout coincides with the wire
-    format.
-*   Support in-place access and construction of FIDL messages.
-*   Defer all memory allocation decisions to the client.
-*   Code generator only produces type declarations, data tables, and simple
-    inline functions.
-*   Client is fully responsible for dispatching incoming method calls on
-    interfaces (write their own switch statement and invoke argument decode
-    functions).
-*   Essentially just like C language bindings but using zero-cost C++ features
-    such as namespaces, string views, and array containers.
-*   Specifically does not use owned handle types such as zx::handle (libzx)
-    because they require making non-POD structs with constructors and
-    destructors.
-    *   This is worth discussing further. Using zx::handle would be convenient
-        but it leads to awkward questions such as to whether destruction of FIDL
-        structs should be recursive (follow pointers, iterate over array
-        members). These are more easily tackled in the idiomatic form, hence it
-        is tempting to let the native form be purely POD and avoid destructors.
-    *   Could consider making a zx::unowned_handle which lacks a destructor and
-        would therefore be POD.
-
-### Idiomatic Usage Style
-
-*   Optimized to meet the needs of high-level service programming.
-*   Represent data structures using idiomatic C++ types such as std::vector,
-    std::optional, and std::string.
-*   Use smart pointers to manage heap allocated objects.
-*   Use zx::handle (libzx) to manage handle ownership.
-*   Can copy (move) data from in-place buffers to idiomatic heap allocated
-    objects.
-*   Can copy (move) data from idiomatic heap allocated objects to in-place
-    buffers.
-*   Code generator produces somewhat more code, including constructors,
-    destructors, interface proxies, interface stubs, copy/move functions, and
-    conversions to/from native style.
-*   Client performs interface dispatch by subclassing a provided stub and
-    implementing the virtual methods for each operation.
-
-### Comparison of Usage Styles
-
-<table>
-  <tr>
-   <td>
-   </td>
-   <td><strong>C style</strong>
-   </td>
-   <td><strong>C++ native style</strong>
-   </td>
-   <td><strong>C++ idiomatic style</strong>
-   </td>
-  </tr>
-  <tr>
-   <td><strong>audience</strong>
-   </td>
-   <td>drivers
-   </td>
-   <td>drivers
-   </td>
-   <td>high-level services
-   </td>
-  </tr>
-  <tr>
-   <td><strong>abstraction overhead</strong>
-   </td>
-   <td>almost zero
-   </td>
-   <td>almost zero
-   </td>
-   <td>heap allocation, construction, destruction
-   </td>
-  </tr>
-  <tr>
-   <td><strong>type safe types</strong>
-   </td>
-   <td>enums, structs, unions
-   </td>
-   <td>enums, structs, unions
-   </td>
-   <td>enums, structs, unions, handles, interfaces
-   </td>
-  </tr>
-  <tr>
-   <td><strong>storage</strong>
-   </td>
-   <td>in-place buffer
-   </td>
-   <td>in-place buffer
-   </td>
-   <td>heap
-   </td>
-  </tr>
-  <tr>
-   <td><strong>lifecycle</strong>
-   </td>
-   <td>manual free (POD)
-   </td>
-   <td>manual free (POD)
-   </td>
-   <td>automatic free (RAII)
-   </td>
-  </tr>
-  <tr>
-   <td><strong>receive behavior</strong>
-   </td>
-   <td>decode in-place
-   </td>
-   <td>decode in-place
-   </td>
-   <td>decode then move to heap
-   </td>
-  </tr>
-  <tr>
-   <td><strong>send behavior</strong>
-   </td>
-   <td>encode in-place
-   </td>
-   <td>encode in-place
-   </td>
-   <td>move to buffer then encode
-   </td>
-  </tr>
-  <tr>
-   <td><strong>calling interface methods</strong>
-   </td>
-   <td>manual proxy
-   </td>
-   <td>manual proxy
-   </td>
-   <td>call through proxies, register callbacks
-   </td>
-  </tr>
-  <tr>
-   <td><strong>implementing interface methods</strong>
-   </td>
-   <td>manual dispatch
-   </td>
-   <td>manual dispatch
-   </td>
-   <td>implement stub object, invoke callbacks
-   </td>
-  </tr>
-  <tr>
-   <td><strong>generated code</strong>
-   </td>
-   <td>structures, data tables, inline functions
-   </td>
-   <td>structures, data tables, inline functions
-   </td>
-   <td>structures, data tables, constructors, destructors, proxies, stubs, inline functions
-   </td>
-  </tr>
-  <tr>
-   <td><strong>generated code footprint</strong>
-   </td>
-   <td>small (data tables only)
-   </td>
-   <td>small (data tables only)
-   </td>
-   <td>moderate (data tables, constructors, destructors, proxies, and stubs)
-   </td>
-  </tr>
-  <tr>
-   <td><strong>friendliness</strong>
-   </td>
-   <td>surly
-   </td>
-   <td>aloof
-   </td>
-   <td>genial
-   </td>
-  </tr>
-</table>
-
-_Point for discussion: given how close the C++ native style is to the C style
-(mostly syntactic benefits), we might want to consider deferring its
-implementation or finding some other middle ground like in-place friendly
-non-POD with weak RAII semantics (don't traverse pointers)._
-
-## Code Generator
-
-### Mapping Declarations
-
-#### Mapping FIDL Types to C++ Types
-
-This is the mapping from FIDL types to C types which the code generator
-produces.
-
-<table>
-  <tr>
-   <td><strong>FIDL</strong>
-   </td>
-   <td><strong>Native C++ Style</strong>
-   </td>
-   <td><strong>Idiomatic C++ Style</strong>
-   </td>
-  </tr>
-  <tr>
-   <td>bool
-   </td>
-   <td>bool,
-<em>assuming sizeof(bool) ==1</em>
-   </td>
-   <td>bool
-   </td>
-  </tr>
-  <tr>
-   <td>int8
-   </td>
-   <td>int8_t
-   </td>
-   <td>int8_t
-   </td>
-  </tr>
-  <tr>
-   <td>uint8
-   </td>
-   <td>uint8_t
-   </td>
-   <td>uint8_t
-   </td>
-  </tr>
-  <tr>
-   <td>int16
-   </td>
-   <td>int16_t
-   </td>
-   <td>int16_t
-   </td>
-  </tr>
-  <tr>
-   <td>uint16
-   </td>
-   <td>uint16_t
-   </td>
-   <td>uint16_t
-   </td>
-  </tr>
-  <tr>
-   <td>int32
-   </td>
-   <td>int32_t
-   </td>
-   <td>int32_t
-   </td>
-  </tr>
-  <tr>
-   <td>uint32
-   </td>
-   <td>uint32_t
-   </td>
-   <td>uint32_t
-   </td>
-  </tr>
-  <tr>
-   <td>int64
-   </td>
-   <td>int64_t
-   </td>
-   <td>int64_t
-   </td>
-  </tr>
-  <tr>
-   <td>uint64
-   </td>
-   <td>uint64_t
-   </td>
-   <td>uint64_t
-   </td>
-  </tr>
-  <tr>
-   <td>float32
-   </td>
-   <td>float
-   </td>
-   <td>float
-   </td>
-  </tr>
-  <tr>
-   <td>float64
-   </td>
-   <td>double
-   </td>
-   <td>double
-   </td>
-  </tr>
-  <tr>
-   <td>handle, handle?
-   </td>
-   <td>zx_handle_t, or perhaps zx::unowned_handle
-   </td>
-   <td>zx::handle
-   </td>
-  </tr>
-  <tr>
-   <td>handle<T>, handle<T>?
-   </td>
-   <td>zx_handle_t, or perhaps zx::unowned_T
-   </td>
-   <td>zx::T <em>(subclass of zx::object<T>)</em>
-   </td>
-  </tr>
-  <tr>
-   <td>string
-   </td>
-   <td>fidl::string
-   </td>
-   <td>std::string
-   </td>
-  </tr>
-  <tr>
-   <td>string?
-   </td>
-   <td>fidl::string
-   </td>
-   <td>std::optional<std::string>
-   </td>
-  </tr>
-  <tr>
-   <td>vector<T>
-   </td>
-   <td>fidl::vector<T>
-   </td>
-   <td>std::vector<T>
-   </td>
-  </tr>
-  <tr>
-   <td>vector<T>?
-   </td>
-   <td>fidl::vector<T>
-   </td>
-   <td>std::optional<std::vector>
-   </td>
-  </tr>
-  <tr>
-   <td>array<T>:N
-   </td>
-   <td>fidl::array<T, N>
-   </td>
-   <td>std::array<T, N>
-   </td>
-  </tr>
-  <tr>
-   <td><em>Interface, Interface?</em>
-   </td>
-   <td><em>interface named typedef to zx_handle_t</em>
-<p>
-<em>eg. typedef zx_handle_t Foo;</em>
-   </td>
-   <td><em>Interface</em>Ptr
-   </td>
-  </tr>
-  <tr>
-   <td><em>request<Interface>, request<Interface>?</em>
-   </td>
-   <td><em>interface_request named typedef to zx_handle_t</em>
-<p>
-<em>eg. typedef zx_handle_t FooRequest;</em>
-   </td>
-   <td><em>Interface</em>Request
-   </td>
-  </tr>
-  <tr>
-   <td><em>Struct</em>
-   </td>
-   <td>struct <em>Struct</em>
-   </td>
-   <td><em>Struct</em>Ptr
-   </td>
-  </tr>
-  <tr>
-   <td><em>Struct?</em>
-   </td>
-   <td>struct <em>Struct*</em>
-   </td>
-   <td><em>Struct</em>Ptr
-   </td>
-  </tr>
-  <tr>
-   <td><em>Union</em>
-   </td>
-   <td>struct <em>Union</em>
-   </td>
-   <td><em>Union</em>Ptr
-   </td>
-  </tr>
-  <tr>
-   <td><em>Union?</em>
-   </td>
-   <td><em>struct Union*</em>
-   </td>
-   <td><em>Union</em>Ptr
-   </td>
-  </tr>
-  <tr>
-   <td><em>Enum</em>
-   </td>
-   <td><em>enum class Foo : data type</em>
-   </td>
-   <td><em>enum class Foo : data type</em>
-   </td>
-  </tr>
-</table>
-
-#### Mapping FIDL Identifiers to C++ Identifiers
-
-TODO: discuss reserved words, name mangling
-
-#### Mapping FIDL Type Declarations to C++ Types
-
-TODO: discuss generated namespaces, constants, enums, typedefs, encoding tables
-
-## Bindings Library
-
-### Dependencies
-
-Only depends on Zircon system headers, libzx, and a portion of the C and C++
-standard libraries.
-
-Does not depend on libftl or libmtl.
-
-### Code Style
-
-To be discussed.
-
-The native bindings library uses C++ standard library style, eg. function names
-are lower-case with underscores.
-
-The idiomatic bindings library could use Google C++ style to match FIDL v1.0 but
-though this may ultimately be more confusing, especially given style choices in
-Zircon so we may prefer to follow the C++ standard library style here as well.
-
-### Native Types
-
-#### fidl::string
-
-```cpp
-class string {
-   public:
-    void init(size_t size, uint8_t* data);
-    size_t size() const;
-    bool empty() const;
-    bool null() const;
-    uint8_t* data();
-    const uint8_t* data() const;
-    uint8_t& operator[](size_t pos);
-    const uint8_t& operator[](size_t pos) const;
-    iterator begin();
-    // etc...
-
-   private:
-    fidl_string string_;
-};
-```
-
-Holds a reference to a variable-length string stored within the buffer. C++
-wrapper of **fidl_string**.
-
-No constructor or destructor so this is POD.
-
-#### fidl::vector<T>
-
-```cpp
-template <typename T>
-class vector {
-   public:
-    void init(size_t size, T* data);
-    size_t size() const;
-    bool empty() const;
-    bool null() const;
-    T* data();
-    const T* data() const;
-    T& operator[](size_t pos);
-    const T& operator[](size_t pos) const;
-    iterator begin();
-    // etc...
-
-   private:
-    fidl_vector vector_;
-};
-```
-
-Holds a reference to a variable-length vector of elements stored within the
-buffer. C++ wrapper of **fidl_vector**.
-
-No constructor or destructor so this is POD.
-
-#### fidl::array<T, N>
-
-```cpp
-template <typename T, size_t N>
-class array {
-   public:
-    size_t size() const;
-    bool empty() const;
-    bool null() const;
-    T* data();
-    const T* data() const;
-    T& operator[](size_t pos);
-    const T& operator[](size_t pos) const;
-    iterator begin();
-    // etc...;
-
-   private:
-    T[N] array_;
-};
-
-```
-
-Holds a reference to a fixed-length array of elements stored within the buffer.
-Similar to std::array<T, N> but intended purely for in-place use.
-
-No constructor or destructor so this is POD.
-
-#### fidl::buffer
-
-```cpp
-class buffer {
-   public:
-    buffer(size_t max_capacity = ZX_MAX_MESSAGE_SIZE);
-    ~buffer();
-
-    template <typename T>
-    T* append();
-
-    fidl::string append_string(size_t size);
-    template <typename T>
-    fidl::string append_string(const char* text);
-
-    fidl::vector<T> append_vector(size_t size);
-
-    const uint8_t* data() const;
-    size_t size() const;
-
-    zx_status_t encode(const fidl_encoding_table* encoding_table,
-                       std::vector<zx_handle_t>* out_handles);
-
-    zx_status_t decode(const fidl_encoding_table* encoding_table,
-                       const std::vector<zx_handle_t>& out_handles);
-};
-```
-
-Helper for constructing messages laid out in depth-first traversal order.
-Generally takes care of the messy pointer arithmetic for building messages
-in-place.
-
-TBD: It might be even more convenient to make a more specialized encode_buffer
-which knows the encoding table of the message being constructed. Maybe do
-something similar for incoming messages.
-
-##### Example
-
-```cpp
-zx_status_t say_hello(const zx::channel& channel, const char* text,
-                      zx::handle token) {
-    assert(strlen(text) <= MAX_TEXT_SIZE);
-
-    fidl::buffer buf();
-
-    auto header = buf.append<fidl_message_header>();
-    header->transaction_id = 1;
-    header->flags = 0;
-    header->ordinal = example_Animal_Say_ordinal;
-
-    auto args = buf.append<example::Animal::Say_args>();
-    args->text = buf.append_string(text);
-    args->token = std::move(token);
-
-    std::vector<zx::handle> handles;
-    zx_status_t status =
-        buf.encode(example::Animal::Say_args::encoding, &handles);
-    if (status == ZX_OK) {
-        status =
-            channel.write(0, buf.data(), buf.size(),
-                          reinterpret_cast<const zx_handle_t*>(handles.data()),
-                          handles.size());
-    }
-    return status;
-}
-```
-
-### Idiomatic Types
-
-TODO: adopt main ideas from FIDL 1.0
-
-InterfacePtr<T> / interface_ptr<T>?
-
-InterfaceRequest<T> / interface_req<T>?
-
-async waiter
-
-etc...
-
-## Suggested API Improvements over FIDL v1
-
-The FIDL v1 API for calling and implementing FIDL interfaces has generally been
-fairly effective so we would like to retain most of its structure in the
-idiomatic FIDL v2 bindings. However, there are a few areas that could be
-improved.
-
-TODO: actually specify the intended API
-
-### Handling Connection Errors
-
-Handling connection errors systematically has been a cause of concern for
-clients of FIDL v1 because method result callbacks and connection error
-callbacks are implemented by different parts of the client program.
-
-It would be desirable to consider an API which allows for localized handling of
-connection errors at the point of method calls (in addition to interface level
-connection error handling as before).
-
-See https://fuchsia-review.git.corp.google.com/#/c/23457/ for one example of how
-a client would otherwise work around the API deficiency.
-
-One approach towards a better API may be constructed by taking advantage of the
-fact that std::function<> based callbacks are always destroyed even if they are
-not invoked (such as when a connection error occurs). It is possible to
-implement a callback wrapper which distinguishes these cases and allows clients
-to handle them more systematically. Unfortunately such an approach may not be
-able to readily distinguish between a connection error vs. proxy destruction.
-
-Alternately we could wire in support for multiple forms of callbacks or for
-multiple callbacks.
-
-Or we could change the API entirely in favor of a more explicit Promise-style
-mechanism.
-
-There are lots of options here...
-
-TBD (please feel free to amend / expand on this)
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-[fidl-overview]: ../README.md
diff --git a/development/languages/fidl/languages/dart.md b/development/languages/fidl/languages/dart.md
index 6c4538f..225b97b 100644
--- a/development/languages/fidl/languages/dart.md
+++ b/development/languages/fidl/languages/dart.md
@@ -1,4 +1,7 @@
+# Obsolete
 
-# Dart Language Bindings
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-(to be completed)
diff --git a/development/languages/fidl/languages/go.md b/development/languages/fidl/languages/go.md
index 9eaeaf9..225b97b 100644
--- a/development/languages/fidl/languages/go.md
+++ b/development/languages/fidl/languages/go.md
@@ -1,4 +1,7 @@
+# Obsolete
 
-# Go Language Bindings
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-(to be completed)
diff --git a/development/languages/fidl/languages/rust.md b/development/languages/fidl/languages/rust.md
index 73d1a45..225b97b 100644
--- a/development/languages/fidl/languages/rust.md
+++ b/development/languages/fidl/languages/rust.md
@@ -1,4 +1,7 @@
+# Obsolete
 
-# Rust Language Bindings
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-(to be completed)
diff --git a/development/languages/fidl/reference/README.md b/development/languages/fidl/reference/README.md
index f1cc5de..225b97b 100644
--- a/development/languages/fidl/reference/README.md
+++ b/development/languages/fidl/reference/README.md
@@ -1,68 +1,7 @@
-# Introduction
+# Obsolete
 
-The reference section provides the following material:
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-* [Attributes](attributes.md) &mdash; describes the available FIDL attributes
-* [Compiler](compiler.md) &mdash; describes the organization of the compiler
-* [Editors](editors.md) &mdash; discusses support for FIDL in IDEs and stand-alone editors
-* [FIDL Tuning Proposals](ftp/README.md) &mdash; accepted and rejected changes for FIDL
-* [Grammar](grammar.md) &mdash; the FIDL grammar
-* [JSON IR](json-ir.md) &mdash; a tour of the JSON Intermediate Representation (**JSON IR**) generator
-* [Language](language.md) &mdash; defines the syntax of the FIDL language
-* [Wire Format](wire-format/index.md) &mdash; details the byte-by-byte organization of data
-* [Host](host.md) &mdash; summary of the parts of FIDL that are allowed on host
-
-### Readability rubric
-
-Fuchsia has adopted a
-[readability rubric](../../../api/fidl.md)
-for FIDL libraries.
-
-## Bindings
-
-### C
-
-- [Documentation](../languages/c.md)
-- [Echo server example](https://fuchsia.googlesource.com/garnet/+/master/examples/fidl/echo2_server_c/)
-
-### C++
-
-- [Documentation](../languages/cpp.md)
-- [Echo server example](https://fuchsia.googlesource.com/garnet/+/master/examples/fidl/echo2_server_cpp/)
-- [Echo client example](https://fuchsia.googlesource.com/garnet/+/master/examples/fidl/echo2_client_cpp/)
-
-### Dart
-
-- [Documentation](../languages/dart.md)
-- [Echo server example](https://fuchsia.googlesource.com/topaz/+/master/examples/fidl/echo_server_dart/)
-- [Echo client example](https://fuchsia.googlesource.com/topaz/+/master/examples/fidl/echo_client_dart/)
-
-### Go
-
-- [Documentation](../languages/go.md)
-- [Echo server example](https://fuchsia.googlesource.com/garnet/+/master/examples/fidl/echo2_server_go/)
-- [Echo client example](https://fuchsia.googlesource.com/garnet/+/master/examples/fidl/echo2_client_go/)
-
-### Rust
-
-- [Documentation](../languages/rust.md)
-- [Echo server example](https://fuchsia.googlesource.com/garnet/+/master/examples/fidl/echo2_server_rust/)
-- [Echo client example](https://fuchsia.googlesource.com/garnet/+/master/examples/fidl/echo2_client_rust/)
-
-## Learning
-
-See the [tutorial](../tutorial/README.md) to learn about FIDL service development.
-
-FIDL Plugins exist for multiple editors and IDEs.  See the
-[editor page](editors.md) to learn more.
-
-## FIDL Tuning Proposals
-
-Substantial changes to FIDL (whether the language, the wire format, or
-language bindings) are described in [FIDL Tuning Proposals]. These
-decisions are recorded here for posterity. This includes both accepted
-and rejected designs. [FTP-001] describes the proposal process itself.
-Use the [template](ftp/template.md) when starting a new proposal.
-
-[FIDL Tuning Proposals]: ftp/README.md
-[FTP-001]: ftp/ftp-001.md
diff --git a/development/languages/fidl/reference/attributes.md b/development/languages/fidl/reference/attributes.md
index fe5bc61..225b97b 100644
--- a/development/languages/fidl/reference/attributes.md
+++ b/development/languages/fidl/reference/attributes.md
@@ -1,77 +1,7 @@
+# Obsolete
 
-# FIDL Attributes
-
-The following FIDL attributes are discussed:
-
-* [Discoverable]
-* [Doc]
-* [Internal]
-* [Layout]
-
-An attribute preceeds a FIDL element, for example:
-
-```fidl
-[Layout = "Simple"]
-struct MyStruct { ...
-```
-
-It's used to either modify the characteristics of the element, or provide documentation.
-
-> Note that the attribute applies *only* to the *next* element, not all subsequent ones.
-> Elements after the current one revert to having no attributes.
-
-## Discoverable
-
-Causes the service's name to be made available for lookup.
-A service with a `[Discoverable]` attribute can be found at run-time.
-That is to say, you can "request" this service, and zircon will locate it and provide access to it.
-
-## Doc
-
-In FIDL, comments can start with two ("`//`") or three slashes ("`///`"), or they can be
-embodied within a `[Doc]` attribute.
-The two-slash variant does not propagate the comments to the generated target, whereas
-both the three-slash and `[Doc]` variants do.
-
-That is:
-
-```fidl
-/// Foo
-struct MyFooStruct { ...
-```
-
-and
-
-```fidl
-[Doc = "Foo"]
-struct MyFooStruct { ...
-```
-
-have the same effect &mdash; the text of the comment is
-emitted into the generated code, in a manner compatible with the syntax of the target language.
-
-## Internal
-
-This marks internal libraries, such as library `zx`.
-It should be used only by Fuchsia developers.
-
-## Layout
-
-This attribute currently has one valid value, `Simple`, and is meaningful only on interfaces.
-
-It's used to indicate that all arguments and returns must contain objects that are of a fixed size.
-The arguments and returns themselves, however, can be dynamically sized string or vector of primitives.
-
-To clarify with an example, the following is valid:
-
-```fidl
-[Layout = "Simple"]
-interface MyInterface {
-    1: DynamicCountOfFixedArguments(vector<uint8>:1024 inputs);
-};
-```
-
-Here, the argument is a dynamically sized `vector` of unsigned 8-bit integers called `inputs`, with a maximum bound of 1024 elements.
-
-The benefit of `[Layout = "Simple"]` is that the data can be directly mapped without having to be copied and assembled.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
diff --git a/development/languages/fidl/reference/compiler.md b/development/languages/fidl/reference/compiler.md
index 3e1e229..225b97b 100644
--- a/development/languages/fidl/reference/compiler.md
+++ b/development/languages/fidl/reference/compiler.md
@@ -1,84 +1,7 @@
-# Compiler Interface
+# Obsolete
 
-This document describes the command-line interface to the FIDL compiler.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-Information on the internals of that tool lives
-[alongside the source of the tool](https://fuchsia.googlesource.com/zircon/+/master/system/host/fidl/README.md).
-
-See [Overview](../intro/README.md) for more information about FIDL's overall
-purpose, goals, and requirements, as well as links to related documents.
-
-## Overview
-
-The FIDL compiler is split into a frontend and a number of backends. The
-compiler processes one library at a time. The frontend consumes the FIDL
-declarations for the library (as well as for all transitive dependencies),
-performs semantic analysis, and outputs an intermediate representation of the
-library. The backends consume the intermediate representation and generate
-language-specific bindings for the library.
-
-## Frontend
-
-The frontend is a command-line program named `fidlc`. The `fidlc` compiler takes
-a number of arguments:
-
- * `--c-header HEADER_PATH`. If present, this flag instructs `fidlc` to output
-   a C header at the given path. In principle, the C header generation could
-   have been implemented as a C backend, but for some practical reasons, we
-   integrated the C header generation directly into the frontend.
-
- * `--tables TABLES_PATH`. If present, this flag instructs `fidlc` to output
-   coding tables at the given path. The coding tables are required to encode and
-   decode messages from the C and C++ bindings.
-
- * `--json JSON_PATH`. If present, this flag instructs `fidlc` to output the
-   library's intermediate representation at the given path. The intermediate
-   representation is JSON that conforms to [a particular schema](https://fuchsia.googlesource.com/zircon/+/master/system/host/fidl/schema.json).
-   The intermediate representation is used as input to the various backends.
-
- * `--name LIBRARY_NAME`. If present, this flag instructs `fidlc` to validate
-   that the library being compiled has the given name. This flag is useful to
-   cross-check between the library's declaration in a build system and the
-   actual contents of the library.
-
- * `--files [FIDL_FILE...]...`. Each `--file [FIDL_FILE...]` chunk of arguments
-   describes a library, all of which must share the same top-level library name
-   declaration. Libraries must be presented in dependency order, with later
-   libraries able to use declarations from preceding libraries but not vice versa.
-   Output is only generated for the final library, not for each of its dependencies.
-
-All of the arguments can also be provided via a response file, denoted as
-`@responsefile`. The contents of the file at `responsefile` will be interpreted
-as a whitespace-delimited list of arguments. Response files cannot be nested,
-and must be the only argument.
-
-## Backend
-
-The backend is a command-line program named `fidlgen`. The `fidlgen` compiler
-takes a number of arguments:
-
- * `--json` (required). The path to the intermediate representation of the
-   library. The intermediate representation is JSON that conforms to
-   [a particular schema](https://fuchsia.googlesource.com/zircon/+/master/system/host/fidl/schema.json).
-
- * `--generators` (required). A comma-separated list of generators to run on the
-   given library. The following generators are currently supported: `cpp`, `go`,
-   `dart`, and `rust`.
-
- * `--output-base` (required). The base file name for files generated by this
-   generator. The generator will create files by adding extensions to this file
-   name. For example, the `cpp` backend generates two files, one with the `.h`
-   extension and another with the `.cc` extension.
-
- * `--include-base` (required). The base directory relative to which C and C++
-   `#include` directives should be computed. For example, when the `cpp` backend
-   generates an `#include` directive to reference the `.h` file from the `.cc`
-   file, the backend will create the `#include` path relative to this directory.
-
-## Limitations
-
-For the `cpp` backend, the generated `.h` file must be includeable as
-`#include <fuchsia/cpp/$LIBRARY_NAME.h>`, where `$LIBRARY_NAME` is the name of
-the corresponding FIDL library. Typically, that means that the `--output-base`
-flag will have the value `$INCLUDE_BASE/fuchsia/cpp/$LIBRARY_NAME`, where
-`$INCLUDE_BASE` is the value of the `--include-base` flag.
diff --git a/development/languages/fidl/reference/editors.md b/development/languages/fidl/reference/editors.md
index 4adc8b5..225b97b 100644
--- a/development/languages/fidl/reference/editors.md
+++ b/development/languages/fidl/reference/editors.md
@@ -1,45 +1,7 @@
-# Editors
+# Obsolete
 
-Several editors have support for FIDL.
-
-## Atom
-
-To install
-
-    pushd ~/.atom/packages
-    git clone https://fuchsia.googlesource.com/atom-language-fidl
-    popd
-
-## IntelliJ / Android Studio
-
-There is an IntelliJ plugin available for FIDL.  It adds syntax and parsing
-support.  To install it, choose **Settings > Plugins**, then click **Browse
-Repositories** and search for **FIDL**.
-
-## Sublime Text
-
-[Sublime syntax highlighting support can be found here](https://fuchsia.googlesource.com/garnet/+/master/public/lib/fidl/tools/sublime).
-
-To install, go to **Sublime Text > Preferences > Browse Packages** and copy the
-files ``FIDL.sublime-syntax``, and ``Comments (FIDL).tmPreferences`` into the
-**User** package.
-
-## Vim
-
-[Vim syntax highlighting support and instructions can be found here](https://fuchsia.googlesource.com/garnet/+/master/public/lib/fidl/tools/vim).
-
-## Visual Studio Code
-
-There is a (Visual Studio Code extension available) at
-<https://marketplace.visualstudio.com/items?itemName=fuchsia-authors.language-fidl>.
-
-## Contributing
-
-Contributions to the various plugins are welcome. Their respective code lives at
-
-* **Atom**: <https://fuchsia.googlesource.com/atom-language-fidl/>
-* **IntelliJ**: <https://fuchsia.googlesource.com/intellij-language-fidl/>
-* **Sublime**: <https://fuchsia.googlesource.com/garnet/+/master/public/lib/fidl/tools/sublime>
-* **vim**: <https://fuchsia.googlesource.com/garnet/+/master/public/lib/fidl/tools/vim>
-* **Visual Studio Code**: <https://fuchsia.googlesource.com/vscode-language-fidl/>
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
diff --git a/development/languages/fidl/reference/ftp/README.md b/development/languages/fidl/reference/ftp/README.md
index afd96fc..225b97b 100644
--- a/development/languages/fidl/reference/ftp/README.md
+++ b/development/languages/fidl/reference/ftp/README.md
@@ -1,16 +1,7 @@
-# FIDL Tuning Proposals
+# Obsolete
 
-FTP                   | Submitted  | Reviewed   | Title
-----------------------|------------|------------|----------------------------------
-[FTP-001](ftp-001.md) | 2018-07-17 |            | FTP process
-[FTP-002](ftp-002.md) | 2018-07-17 |            | Type aliases with "using" keyword
-[FTP-009](ftp-009.md) | 2018-07-31 | 2018-08-20 | Documentation comments
-[FTP-012](ftp-012.md) | 2018-08-30 | 2018-09-11 | Empty structs
-[FTP-007](ftp-007.md) | 2018-07-27 | 2018-09-20 | Tables
-[FTP-008](ftp-008.md) | 2018-07-19 | 2018-10-04 | Epitaphs
-FTP-013               | 2018-09-10 | 2018-10-11 | [Deprecated] Attribute
-FTP-015               | 2018-09-26 | 2018-10-11 | Extensible Unions
-FTP-021               | 2018-10-31 | 2018-11-01 | Soft Transitions for Methods Add / Remove
-[FTP-020](ftp-020.md) | 2018-10-26 | 2018-11-29 | Interface Ordinal Hashing
-FTP-014               | 2019-09-18 | 2018-12-06 | Error Handling
-FTP-023               | 2018-12-10 | 2019-01-09 | Compositional Model for Protocols
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
+
diff --git a/development/languages/fidl/reference/ftp/ftp-001.md b/development/languages/fidl/reference/ftp/ftp-001.md
index 2ea2ae6..225b97b 100644
--- a/development/languages/fidl/reference/ftp/ftp-001.md
+++ b/development/languages/fidl/reference/ftp/ftp-001.md
@@ -1,206 +1,7 @@
-# FIDL Tuning Proposal 001
+# Obsolete
 
-A Modest Proposal
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-Field     | Value
-----------|--------------------------
-Status    | Accepted
-Authors   | kulakowski@google.com
-Submitted | 2018-07-17
-Reviewed  |
-
-[TOC]
-
-## Summary
-
-The FIDL Tuning Proposal (FTP) process is designed to provide a
-uniform and recorded path for making changes to the [FIDL] language,
-bindings, and tools.
-
-## Motivation
-
-There are several motivations for creating such an FTP system.
-
-[FIDL] (the Fuchsia IPC system) is subject to a number of design
-constraints. These include performance, safety, and ergonomics. These
-are often at odds with each other, and the requirement to support IPC
-bindings in various target languages adds further tradeoffs. The FTP
-proposal system provides a way to litigate and to record decisions
-about these tradeoffs.
-
-Recording decisions is valuable for several reasons. First, it
-provides a way to prevent revisiting the same decisions over and over
-when nothing has changed, while still allowing revisiting decisions
-when underlying assumptions actually have changed. Second, it provides
-new team members, or new clients of Fuchsia, some context into how
-FIDL has evolved and why certain decisions were made.
-
-Finally, FIDL, as a sort of programming language, invites bikeshedding
-at a scale only [Wadler's law] can enable. This provides a place for
-such things to occur that isn't a several hundred person email list.
-
-## Design
-
-An FTP (FIDL Tuning Proposal) goes through several stages. These
-stages correspond to the Status: field of the heading of the template.
-
-NB: The template is currently Google-internal.
-
-### Draft
-
-One or more people get excited about a change! They make a copy of the
-tuning template, and start writing and designing. The proposal should
-address each of the section headings in the template, even if it is
-only to say "Not Applicable".
-
-At this stage they may start soliciting feedback on the draft from impacted parties.
-
-### Comment
-
-At this stage, the FTP is formally circulated for commentary to the
-Fuchsia engineering organization. The authors of the proposal should
-solicit feedback from those especially likely to be impacted by the
-proposal.
-
-For now, proposals should be left open for comment for at least one
-week, subject to reviewer discretion. It may be reasonable to be
-shorter for less controversial FTPs, and longer to wait for feedback
-from a particular person or group to come in.
-
-Anyone may make a blocking comment on an FTP. Blocking comments do not
-prevent a particular accept-or-reject outcome from the review process,
-but reviewers are required to acknowledge the feedback given in the
-comment as part of the final FTP.
-
-### Review
-
-At this point the FTP, along with all outstanding commentary, is
-reviewed.
-
-The proposal is reviewed by members of the Fuchsia FIDL team
-(unofficially know as luthiers), and anyone they see fit to include or
-to delegate to in the process. For example, they may include a
-particular language expert when making a decision about that
-language's bindings. If necessary, controversial decisions can be
-escalated like any other technical decision in Fuchsia.
-
-The review can ultimately have three outcomes.
-
-First, there may be outstanding questions or feedback required to make
-a decision. In this case the FTP is moved back to the Comment stage.
-
-Second, the proposal may be Rejected, with reviewers providing a
-rationale as to why.
-
-Third, it may be Accepted.
-
-### Rejected
-
-Rejected FTPs are valuable records of engineering decisions. When
-rejected, the rationale for rejected should be added to the FTP. The
-FTP will then be copied to the public record of all FTPs for
-posterity.
-
-The given rationale should be actionable in the following two senses.
-
-First, what would have to change about the world to have accepted this
-proposal?
-
-Second, the rationale should address any blocking comments raised
-during the Comment period.
-
-### Accepted
-
-Accepted FTPs will also have a rationale section appended to them
-after review, and will receive a tracking bug.
-
-The same constraints apply to the acceptance rationale as the
-rejection rationale. In particular, any blocking comments need to be
-addressed.
-
-Then it's off to the races to implement the change.
-
-### Implemented
-
-At this stage, the proposal is landed. All the code has been
-changed. The [tutorial] has been updated. The bug is marked
-done. [FIDL] is in a more perfect tuning.
-
-The final step of the process is landing a markdown-ified version of
-the FTP into the Fuchsia tree. This applies whether or not the
-proposal was accepted, as being able to point at already considered
-but rejected proposal is a substantial part of the value of this
-process.
-
-## Documentation and Examples
-
-This document (FTP-001) is the first such example of this process.
-
-Ideally the template, plus the final version of this proposal, are
-sufficient documentation for the process.
-
-## Backwards Compatibility
-
-n/a
-
-## Performance
-
-n/a
-
-## Security
-
-I believe this plan will have the modest benefit of providing a place
-for security review to happen. Currently all changes to FIDL are
-discussed via chat or code review. There's no paper trail, prior to
-the FTP process.
-
-## Testing
-
-It feels easier to talk about success than about testing for this
-plan.
-
-The immediate success criteria for this process will be whether the
-several outstanding ideas for changing FIDL go through the process
-without it being onerous.
-
-One long term success metric would be whether old FTPs are regularly
-pointed at.
-
-## Drawbacks, Alternatives, and Unknowns
-
-There's a small cost to serializing changes to FIDL through a slightly
-formal process. I believe that the cost is in fact small, in
-comparison to the engineering work needed to implement any change
-(especially as our ABIs harden and breaking changes get harder), and
-to the payoff of recording these decisions.
-
-The biggest alternative I considered was a more open
-version. Currently, the comment and review process is currently only
-visible or open to Googlers. I believe that this is the correct
-decision for now, with an eye towards re-evaluating in the future.
-
-I also wonder if there is a better way to capture commentary than a
-Google Doc, especially at the point of "freezing" the FTP into an
-accepted or rejected state.
-
-I suspect we may want a version of this that captures decisions made
-about FIDL prior to the adoption of this process.
-
-Finally, I wondered about how formal to be about acception or
-rejection criteria. I believe that this can evolve into something more
-formal over time, if needed, with the help of early FTP's decision
-rationales.
-
-## Prior Art and References
-
-Several open source programming languages have enhancement proposals
-or RFC mechanisms.
-
-In particular, I looked a lot at the [Python PEP] process and the
-[Rust RFC] process while drafting this document.
-
-[FIDL]: ../README.md
-[Python PEP]: https://www.python.org/dev/peps/
-[Rust RFC]: https://github.com/rust-lang/rfcs
-[tutorial]: ../../tutorial/README.md
-[Wadler's Law]: https://wiki.haskell.org/Wadler's_Law
diff --git a/development/languages/fidl/reference/ftp/ftp-002.md b/development/languages/fidl/reference/ftp/ftp-002.md
index b014c56..225b97b 100644
--- a/development/languages/fidl/reference/ftp/ftp-002.md
+++ b/development/languages/fidl/reference/ftp/ftp-002.md
@@ -1,108 +1,7 @@
-# FIDL Tuning Proposal 002
+# Obsolete
 
-`using evolution = uint64;`
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-Field     | Value
-----------|--------------------------
-Status    | Accepted
-Authors   | abarth@google.com
-Submitted | 2018-07-17
-Reviewed  |
-
-[TOC]
-
-## Summary
-
-Add a mechanism to give more descriptive names to primitive types.
-Remove status as a built-in feature of the language.  Introduce a zx
-library to contain the primitive types from `<zircon/types.h>`.
-
-## Motivation
-
-Often developers want to assign more descriptive names to primitive
-types.  For example, `status` is a more descriptive name for `int32`,
-but `status` is built into the language and other types cannot be used
-in the same way.
-
-## Design
-
-This proposal affects only the FIDL source language.
-
-1. Extend the `using` keyword to be able to assign descriptive names
-   to primitive types.  Specifically, add the following production to
-   the FIDL grammar:
-
-```
-using-list = ( using | using-declaration )* ;
-using-declaration = "using" , IDENTIFIER ,  "=" , primitive-type , ";" ;
-```
-
-1. Remove the `status` primitive type from the language.  The `status`
-   primitive type can now be defined using the language itself instead
-   of being a built-in feature.
-
-1. Remove the `status` reserved word.  We no longer need to reserve
-   the word `status` now that we can define the name in the language.
-   Add a `zx` library that contains declarations for the primitive
-   types defined by the Zircon system interface.  Ideally, this
-   library would be generated from a future syscalls.abigen that
-   contained this information.  For example:
-
-```
-library zx;
-
-using status = int32;
-using time = uint64;
-using duration = uint64;
-[...]
-```
-
-Notice that these declarations must appear in the using-list and must
-refer directly to primitive types.  This approach avoids complexity in
-the compiler because their use can be immediately translated into the
-underlying primitive type.
-
-Further, notice that there are no proposed changes to the generated
-code in any target language.  These types are represented in the
-target languages using the underlying primitive types.
-
-## Documentation and Examples
-
-Example usage
-
-```
-    1: AdvanceTime(zx.duration duration) -> (zx.status status);
-```
-
-## Backwards Compatibility
-
-This change is a non-backwards compatible change to the FIDL source
-language because it removes the `status` primitive type.  However,
-migrating existing clients of `status` is trivial because they can
-simply use `zx.status` instead.
-
-## Performance
-
-The proposed change has no impact on performance.
-
-## Security
-
-The proposed change has no impact on security.
-
-## Testing
-
-The feature will be tested in the fidl-test suite in Zircon by adding
-a FIDL file that uses each of the types from the `zx` library.
-
-## Drawbacks, Alternatives, and Unknowns
-
-This proposal is straightforward to implement in the FIDL frontend and
-requires no changes to the language-specific backends.
-
-An alternative is to not solve the problem and continue to use
-primitive types directly.
-
-## Prior Art and References
-
-This feature is very common in programming languages.  The syntax is
-borrowed loosely from C++.
diff --git a/development/languages/fidl/reference/ftp/ftp-007.md b/development/languages/fidl/reference/ftp/ftp-007.md
index 647bcf9..225b97b 100644
--- a/development/languages/fidl/reference/ftp/ftp-007.md
+++ b/development/languages/fidl/reference/ftp/ftp-007.md
@@ -1,245 +1,7 @@
-# FIDL Tuning Proposal 007
+# Obsolete
 
-A mechanism for forward and backward compatible compound data types.
-
-Field     | Value
-----------|--------------------------
-Status    | Accepted
-Authors   | ctiller@google.com
-Submitted | 2018-07-27
-Reviewed  | 2018-09-20
-
-[TOC]
-
-## Summary
-
-Add a mechanism for forward and backwards compatible compound data types to the FIDL language.
-
-## Motivation
-
-FIDL structs provide no mechanism to mutate the schema over time.
-Tables are similar to structs, but add ordinals to each field to allow structure evolution:
-- New fields can be added and ignored by existing code
-- Old (deprecated) fields can be skipped over by newer code
-
-Tables are necessarily more complicated than structs, and so processing them will
-be slower and serializing them will use more space.
-As such, it's preferred to keep structs as is and introduce something new.
-
-Additionally, having an evolvable schema opens the way to having a
-variant of FIDL that can be sensibly serialized to disk or over a network.
-
-An example table might look like:
-
-```fidl
-table Station {
-    1: string name;
-    3: bool encrypted;
-    2: uint32 channel;
-};
-```
-
-## Design
-
-### Source Language
-
-Add the **table_declaration** to the FIDL grammar:
-
-```
-declaration = const-declaration | enum-declaration | interface-declaration |
-              struct-declaration | union-declaration | table-declaration ;
-
-table-declaration = ( attribute-list ) , "table" , IDENTIFIER , "{" , ( table-field , ";" )* , "}" ;
-
-table-field = table-field-ordinal , table-field-declaration ;
-
-table-field-ordinal = ordinal , ":" ;
-
-table-field-declaration = struct-field | "reserved" ;
-```
-
-Notes:
-- Ordinals must start at 1 and no gaps are allowed in the ordinal space (if the largest
-  ordinal is 7, then all of 1,2,3,4,5,6,7 must be present).
-- No two fields can claim the same ordinal.
-- A "reserved" field is dropped by the compiler after checks for ordinal clashes have occurred.
-  It allows annotation that a field was used in some previous version of the table but was
-  dropped, so that future revisions do not accidentally reuse that ordinal.
-- Nullable fields are **not allowed** on tables.
-
-A table can be used anywhere a struct can currently be used in the language.
-Particularly:
-- structs and unions can contain tables
-- tables can contain structs and unions
-- interface arguments can be tables
-- tables can be made optional
-
-### Wire Format
-
-Tables are stored as a packed `vector<envelope>`,
-each element of the vector is one ordinal element (so index 0 is ordinal 1,
-index 1 is ordinal 2, etc.).
-We describe envelopes below.
-
-A table must only store envelopes up to the last present one, i.e. the maximal set ordinal.
-This ensures a canonical representation. For instance, if no field is set, the correct
-encoding is an empty vector.
-For a table with field at ordinal 5, but with fields set only up to ordinal 3, the correct
-encoding is a vector of 3 envelopes.
-
-#### Envelopes
-
-An `envelope` stores a variable size, uninterpreted payload out-of-line.
-The payload may contain an arbitrary number of bytes and handles.
-This organization allows for encapsulation of one FIDL message inside of another.
-
-Envelopes are stored as a record consisting of:
-* `num_bytes` : 32-bit unsigned number of bytes in envelope, always a multiple of 8,
-  must be zero if envelope is null
-* `num_handles` : 32-bit unsigned number of handles in envelope,
-  must be zero if envelope is null
-* `data` : 64-bit presence indication or pointer to out-of-line data
-
-The `data` field has two different behaviors.
-
-When encoded for transfer, `data` indicates presence of content:
-* `FIDL_ALLOC_ABSENT` (all 0 bits): envelope is null
-* `FIDL_ALLOC_PRESENT` (all 1 bits): envelope is non-null,
-  data is the next out-of-line object
-
-When decoded for consumption, `data` is a pointer to content.
-* `0` : envelope is null
-* `<valid pointer>` : envelope is non-null, data is at indicated memory address
-
-For handles, the envelope reserves storage for the handles immediately following the content.
-When decoded, assuming `data` is not null, `data` points to the first byte of data.
-
-The envelope is padded to the next 8 byte object alignment (which, in practice means that
-there's no additional padding).
-
-### Language Bindings
-
-Instead of generating data fields like structs, tables generate a set of methods per field.
-For instance, in C++ we would have:
-
-```cpp
-class SampleTable {
- public:
-  // For "1: int32 foo;"
-  const int32* foo();         // getter, returns nullptr if foo not present
-  bool has_foo();             // presence check
-  int32* mutable_foo();       // mutable getter, forces a default value if not set
-  void set_foo(int32 x);      // set value
-  void clear_foo();           // remove from structure
-  optional<int32> take_foo(); // get foo if present, remove from structure
-};
-```
-
-### Style Guide
-
-#### Should I use a struct or a table?
-
-Structs and tables provide semantically similar notions,
-and so it can seem complicated deciding which to prefer.
-
-For very high level IPCs, or for persistent storage, where
-serialization performance tends not to be a concern:
-- Tables provide some forwards and backwards compatibility, and so offer an
-  element of future proofing: prefer them for most concepts.
-- Take the performance benefits of structs only for concepts that are very
-  unlikely to change in the future (say `struct Vec3 { float x; float y; float z }`,
-  or `Ipv4Address`).
-
-Once serialization performance becomes an overriding concern (this is common on the
-data path for device drivers for example), we can begin to prefer structs only and
-rely on adding new methods to interfaces to account for future changes.
-
-## Backwards Compatibility
-While this change introduces two keywords, `table` and `reserved`.
-there are no backwards compatibility concerns.
-
-## Performance
-Use of this feature is opt-in, and should have no impact on IPC performance if it's not used.
-We expect build performance differences to be within measurable noise.
-
-## Security
-No impact on security.
-
-## Testing
-Additional tests for each language binding will be needed, and tests for `fidlc`.
-
-An extended version of the echo suite to use tables would be appropriate.
-
-Adding a fuzzer for table encode/decode would be beneficial &mdash;
-there are always tricky cases in parsing.
-
-## Drawbacks, Alternatives, and Unknowns
-
-There are two big questions to be answered in this space:
-- Ordinals vs strings for field identification (ordinals force schemas to be shipped)
-- If ordinals: sparse vs dense ordinal spaces per message
-
-### Tables as Vector of Unions
-
-It was proposed that we consider `table` as a `vector<union>`.
-This brings two problems:
-- The most efficient implementation of a reader of this format must be less efficient
-  than the most efficient implementation of a reader for the proposed table format
-  &mdash; so we permanently limit our peak performance.
-- It doesn't bring any wire compatibility guarantees!
-  A vector necessarily needs to carry a length as well as a body, and so a union is
-  never convertible on the wire into a table with this proposal (and the number of
-  times we'd want to make that transformation seems low).
-
-Instead, by introducing the envelope primitive, we can write down and reason
-about the compatibility guarantees in the same fashion... *and* we get to share
-some tricky implementation details between tables and extensible unions (in development),
-*and* we get to expose a useful primitive up in the language for almost-free.
-
-### Ordinals vs Strings
-
-Use of ordinals requires having a schema present at compilation time,
-but allows for more efficient implementations (string handling will always
-be slower than integer handling).
-Since FIDL already requires schema presence during compilation, it's hoped that
-ordinals over strings here is non-controversial.
-
-### Dense vs Sparse Packing
-
-The question of a dense vs sparse ordinal space is likely to be more controversial.
-There are two camps in existing practice:
-- Thrift and Protobuf use a sparse ordinal space &mdash; fields can be given any ordinal value.
-- FlatBuffers and Cap'n'Proto use a dense ordinal space &mdash;
-  fields must be given consecutive ordinals.
-
-The Protobuf wire format, when paired with a typical Protobuf implementation that parses
-into a fixed size struct, has a bug whereby the amount of memory used by a decoded memory
-is uncorrelated with the number of bytes that are transmitted on the wire.
-To see this, imagine a message which has 10000 fields that are (optional) `int64`s.
-A sender could choose to send just one, resulting in a message that's just a few bytes on
-the wire, but almost 100kB in memory.
-By sending many of these as RPCs, it tends to be easy to thwart flow control
-implementations and cause OOMs.
-
-An alternative implementation strategy for sparse ordinals (as suggested in earlier conversations),
-would be to send an ordered array of `(ordinal, value)` tuples.
-Implementations choosing in-place decoding would have to rely on binary searches through data
-to find an ordinal.
-It avoids the flow control bug noted previously, but introduces what could be some large
-inefficiencies at runtime as we perform a potentially incredible number of binary searches.
-
-Cap'n'Proto implements a very complex algorithm for dealing with ordinals,
-and since we'd like to avoid that complexity it's not discussed further here.
-
-FlatBuffers has a very similar wire format to what is proposed in this document:
-utilizing its dense ordinal space to provide a single array lookup to find the
-data for a field (or that it's null).
-
-## Prior Art and References
-
-- FlatBuffers algorithm is analogous to this one, but has been adapted here
-  to better fit with FIDL conventions.
-- Protobuf (we believe) originally popularized the ordinal/value representation,
-  and its use at scale within Google has demonstrated the scheme's robustness over the years.
-- Cap'n'Proto and Thrift each provide small twists on the above.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
diff --git a/development/languages/fidl/reference/ftp/ftp-008.md b/development/languages/fidl/reference/ftp/ftp-008.md
index d8af61c..225b97b 100644
--- a/development/languages/fidl/reference/ftp/ftp-008.md
+++ b/development/languages/fidl/reference/ftp/ftp-008.md
@@ -1,244 +1,7 @@
-# FIDL Tuning Proposal 008
+# Obsolete
 
-Here lies your server.
-
-Field     | Value
-----------|--------------------------
-Status    | Accepted
-Authors   | jeremymanson@google.com
-Submitted | 2018-07-19
-Reviewed  | 2018-10-04
-
-[TOC]
-
-## Summary
-
-The goal of this proposal is to allow a server to send a message prior to
-closing a connection that provides an indication of why the connection is being
-closed. While
-[epitaphs](../wire-format/index.md#epitaph-control-message-ordinal-0xffffffff)
-are covered in the specification, they are not implemented yet.
-
-## Motivation
-
-Currently, there is no standard way for servers to communicate to clients why a
-connection has been closed. This has the effect that the responsibility for
-ensuring error handling falls to the developer.  The developer can either
-foresee this, and build special error handling into their message, or simply
-ignore error handling (and risk undiagnosable errors).
-
-One use case is for servers where errors are mostly fatal, and when they happen,
-all connections to clients are closed. In such cases, developers want a
-general-purpose error reporting mechanism, because all active calls to methods
-will be terminated with the same error. The alternative of declaring a potential
-error for each method would be cumbersome and awkward.
-
-This FTP does not have a goal of providing an extensive error reporting
-mechanism. Specifically, the ability to communicate large amounts of detail
-(including detailed messages, process state, or propagated causes) to the other
-end of the connection is out of scope.
-
-This FTP also does not have a goal of defining a set of common error codes.
-
-## Design
-
-This proposal modifies the wire format, the source language, and the first class
-language bindings.
-
-### Wire Format
-
-The wire format specification currently has a section on Epitaphs. This section
-will be revised to read as follows:
-
-
-```
-Epitaph (Control Message Ordinal 0xFFFFFFFF)
-
-An epitaph is a message with ordinal **0xFFFFFFFF**.  A server may send an
-epitaph as the last message prior to closing the connection, to provide an
-indication of why the connection is being closed.  No further messages may be
-sent through the channel after the epitaph.  Epitaphs are not sent from clients
-to servers.
-
-When a client receives an epitaph message, it can assume that it has received
-the last message, and the channel is about to be closed. The contents of the
-epitaph message explain the disposition of the channel.
-
-The epitaph contains an error status.  The error status of the epitaph is stored
-in the reserved uint32 of the message header.  The reserved word is treated as
-being of type **zx_status_t**: negative numbers are reserved for system error
-codes, positive numbers are reserved for application error codes, and ZX_OK is
-used to indicate normal connection closure.  The message is otherwise empty.
-```
-
-### Source Language
-
-The source language specification currently has a section on
-[Epitaphs](../language.md#interfaces).
-It will be updated appropriately.
-
-### First class language bindings
-
-Implementations should account for the fact that, if an Epitaph message is sent,
-it should be the last message prior to closure, and for the fact that errors are
-handled differently in different languages (via, for example, delivery of error
-codes in C/C++, Result<T, E> in Rust, and exceptions in Dart).
-
-We will add a method fidl_epitaph_write(channel, zx_status_t) to the C bindings,
-as well as a fidl_epitaph_t type.
-
-We will add the following documentation to the C bindings to the section on Raw
-Bindings:
-
-```
-fidl_epitaph_write
-
-Declared in lib/fidl/epitaph.h, defined in epitaph.c.
-
-This function sends an epitaph with the given error number down the given
-channel.  An epitaph is a special message, with ordinal 0xFFFFFFFF, which
-contains an error code.  The epitaph must be the last thing sent down the
-channel before it is closed.
-```
-
-
-CL for the C changes: https://fuchsia-review.googlesource.com/c/zircon/+/178250
-
-We will change the C++ bindings to do the following:
-
-fidl::Binding will immediately close the channel on receipt of an Epitaph.
-
-Developers will be able to close the channel with fidl::Binding::Close
-
-Error codes will be propagated to the error handler set by the client using
-set_error_handler().  We will add a new error_handler variant that takes a
-closure that takes an int variable representing the error code, and remove the
-existing one.  Potential future work involves having a "sensible default" error
-handler, although it is not currently clear what this would be.
-
-Any pending reads from this channel will return ```ZX_ERR_PEER_CLOSED```.
-
-CL for C++ bindings: https://fuchsia-review.googlesource.com/c/garnet/+/177939
-
-The other bindings need to be updated, including Dart, Rust, and Go.
-
-## Documentation and Examples
-
-
-The documentation will be updated as described in the previous section.
-
-
-### Guidance for Developers
-
-The purpose of an epitaph is to enable a server to provide actionable
-information to the client regarding the disposition of the channel and requests
-that may have been in flight.
-
-This section describes the intended behavior and usage of epitaphs.
-
-1. An epitaph message is only ever sent from a server to a client, never in the
-   other direction.  If sent, it must be the last message sent by the server to
-   the client before the server closes its end of the channel.
-
-2. When a client receives an epitaph message, it must immediately close its end
-   of the channel.  It must not attempt to read any further messages from the
-   channel that may have been sent by a non-conforming server implementation.
-
-3. When a client observes peer closed without having received an epitaph, then
-   it must proceed as if it has received a ```ZX_ERR_PEER_CLOSED``` epitaph;
-   these two states are semantically equivalent.
-
-4. A server is expected to send a ```ZX_OK``` epitaph when the closure of the
-   channel was an anticipated side-effect of the protocol reaching its
-   designated successful end state.
-
-   a. Example: When a client calls Commit() on an interface representing an
-   individual database transaction, the server should attempt to apply the
-   requested changes.  If successful, the server must send a ```ZX_OK``` epitaph
-   before closing its end of the channel.  The client may reasonably construe
-   that the ```ZX_OK``` epitaph indicates that the transaction was successfully
-   committed.
-
-   b. Counter-example: Many protocols do not have designated successful end
-   states; the client expects to be able to connect to a server and issue an
-   unbounded number of requests without observing peer closed until such time as
-   the client closes its own end of the channel.  In these situations, the
-   server closing its end of the channel constitutes an abnormal end state, so
-   the server should never send a ```ZX_OK``` epitaph.
-
-5. A server may send a non-```ZX_OK``` epitaph prior to closing its end of a
-   channel for any reason other than the protocol reaching its designated
-   successful end state.  We suggest the following convention:
-
-   a. If the server is closing the connection because the client sent it an
-   malformed FIDL message, it should send a ```ZX_ERR_INVALID_ARGS``` epitaph.
-
-   b. If the server is closing the connection because the client sent it a
-   request that is not valid in its present state, it should send a
-   ```ZX_ERR_BAD_STATE``` epitaph.
-
-   c. If the server was unreachable (e.g. could not be started) when the client
-   attempted to connect to it via a service discovery mechanism, this mechanism
-   should send a ```ZX_ERR_UNAVAILABLE``` epitaph.  (See also this sketch.)
-
-   d. If the server is unable to continue serving the protocol for reasons that
-   are not in response to actions performed by the client (e.g. shutting down or
-   out of memory), it does not have to send any epitaph.  The client will
-   perceive this as ```ZX_ERR_PEER_CLOSED``` as described above.
-
-   e. If a server encounters an application specific error, it should send an
-   application-defined error code.  For example, if the server controls a
-   filesystem, and the user tries to perform a write that it is not allowed to
-   perform, it may wish to close the connection with an error.
-
-   f. This list is not exhaustive.  A server may send other errors as
-   appropriate.  As per usual, FIDL authors are advised to clearly document the
-   errors their protocols may return, including epitaphs.
-
-## Backwards Compatibility
-
-The FIDL documentation currently states that 0x80000001 is the ordinal for an
-epitaph.  We are changing it to 0xFFFFFFFF, because 0x80000001 is in use by IO.
-Nothing is currently relying on Epitaphs using 0x80000001.  Otherwise, there
-are no backwards compatibility concerns.
-
-## Performance
-
-n/a
-
-## Security
-
-Not applicable.
-
-## Testing
-
-Unittests for this feature will be added to the appropriate FIDL bindings. After
-each supported FIDL binding gets support, we should augment the set of [FIDL
-compatibility
-tests](https://fuchsia.googlesource.com/garnet/+/01fe719f1e9d19c0dc4dabdf02dd659122bbae45/bin/fidl_compatibility_test/).
-
-## Drawbacks, Alternatives, and Unknowns
-
-We considered making a ```System``` interface containing the ```Epitaph```
-event, which would be the parent of all other interface messages.  Epitaphs, on
-their own, do not warrant such a large change.  There are also currently two
-implementation hurdles to this.  First, derived types do not currently work,
-although that is supposed to change soon.  Next, because this proposal changes
-the runtime, and the FIDL parser / generator depends on the runtime, introducing
-a System message and trying to use it in the runtime would result in a circular
-dependency.
-
-The API changes that will result from this FTP will not prevent Epitaph support
-from moving into a future System message.
-
-An idea was floated of incorporating some epitaph handling into the source
-language, allowing the ```zx_status``` flag to be mapped as a FIDL-defined enum.
-This is deferred to future work.
-
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-The proposed implementation is racy.  If one thread writes a message
-concurrently with another thread closing the channel, the epitaph may be written
-prior to the other thread's message, but before the call to
-```zx_channel_close()```.  Alternatives include locking the channel or providing
-an explicit system call.  We are starting with the thread-unsafe version to
-further develop our understanding of the problem space.
diff --git a/development/languages/fidl/reference/ftp/ftp-009.md b/development/languages/fidl/reference/ftp/ftp-009.md
index d7a7408..225b97b 100644
--- a/development/languages/fidl/reference/ftp/ftp-009.md
+++ b/development/languages/fidl/reference/ftp/ftp-009.md
@@ -1,120 +1,7 @@
-# FIDL Tuning Proposal 009
+# Obsolete
 
-What's up, Doc?
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-Field     | Value
-----------|--------------------------
-Status    | Accepted
-Authors   | kulakowski@google.com
-Submitted | 2018-07-31
-Reviewed  | 2018-08-20
-
-[TOC]
-
-## Summary
-
-Documenting FIDL.
-
-## Motivation
-
-Not only is good documentation an important part of scaling a team, documenting our APIs is an important part of defining a stable API. The Fuchsia API is primarily implemented in FIDL and a large amount of documentation is being left in comments that is hard to surface. Even worse, it is not uncommon for people to look at generated bindings to figure out how to use an interface. This proposal is the first step of a comprehensive documentation strategy for the FIDL language and it’s interfaces.
-
-## Design
-
-There are two proposed FIDL source language changes. A standard `Doc` attribute and syntactic sugar to improve the ergonomics of writing documentation.
-
-
-### Doc Attribute
-Arbitrary attributes are an already supported component of the FIDL language. Standardizing on the `Doc` attribute is for the tooling that generates the formated documentation. Using an attribute as the basis of the documentation tooling also allows for additional options to be added to the formatted output without breaking changes.
-
-
-```FIDL
-[Discoverable, Doc = "Primary Bluetooth control service to access bluetooth"]
-interface Control {
-  ...
-  [Doc = "Sets the public Bluetooth |name| for this device"]
-  10: SetName(string? name) -> (fuchsia.bluetooth.Status status);
-}
-```
-Currently, there can be only one `Doc` attribute per language element. This makes it so all text must be put into the Attribute braces, which could lead to excessively long lines.
-
-
-### Syntactic Sugar
-
-To address the poor ergonomics of using attributes, a layer of syntactic sugar is proposed.
-
-This involves a small change to the FIDL language specification. Comments are currently ignored during the lexing of FIDL. This FTP does not address adding general comments to the AST, only documentation comments.
-
-
-Attributes are the primary way that the FIDL language expresses the idea of metadata attached to structures. Having documentation comments as just a special case of this simplifies the consumption of the metadata in the IR.
-
-
-The suggested modification of the grammar is in the appendix of the FTP, but mostly involves adding an additional rule and minor rule re-ordering.
-
-``` documentation-comment = "///", STRING-LITERAL, "\n" ```
-
-```
-interface Control {
-  /// Sent when an adapter with the given |identifier| has been
-  /// removed from the system.
-  10102: -> OnAdapterRemoved(string identifier);
-}
-
-```
-
-This would de-sugar to:
-```
- [Doc=”Sent when an adapter with the given |identifier| has been\n removed from the system\n”]
-```
-
-### Documentation comment contents
-Doc comments are primarily freeform text. Any specific style of formatting is up to the author, team, or future style guides. The only primitive added is an identifier marker, currently proposed as pipes (|) encasing the local identifier. Unqualified identifiers are scoped to the members beneath the object that the attribute is attached too. A fully qualified identifier can be used (Ex: |fuchsia.bluetooth.ErrorCode|) to refer to objects outside of the current scope.
-
-
-Eventually, fidldoc documentation generation should fail if any of the identifiers are missing, but the attribute will still be included and passed into language bindings. This will prevent documentation rot. Adding the identifiers to the IR or as part of the parsing step is intentionally avoided due to complicating these steps. Extracting the identifiers belongs in the documentation tooling (fidldoc). Documentation generation should be added as a mandatory part of a standard debug build and the overall build should fail if the documentation is not successfully generated.
-
-
-### Additional tooling
-A standard tool, called fidldoc, should be added to the tools directory. Fidldoc will generate markdown after consuming the FIDL JSON IR.
-Markdown is the current format that we are using with the other first-class language’s documentation tooling.
-
-
-### Other
-The Wire format is unaffected by these changes. How language bindings chose to surface docstrings, or if they surface them, is left as an implementation detail for their respective communities or potentially as additional FTPs.
-
-The style guide should be amended to prefer `///` over the doc attribute, but otherwise is left alone.
-
-
-## Documentation and Examples
-Triple comments are a relatively common way of  denoting documentation comments and should not be a large barrier to understanding the fidl language.
-Example using triple comments should be added to the existing documentation as well as an explanation of how to use the attribute annotations.
-
-The primary way that people will consume this feature is in the generated output.
-
-
-Backwards Compatibility
-This feature is already backwards compatible with all recent prior fidlc compilers. While the new functionality will not exist for the triple comment syntactic sugar, they do not break earlier compilers.
-
-Document attribute comments will work without any language changes.
-
-## Performance
-No performance changes are expected except for a small increase in the JSON IR size. We will also generate documentation at compile time which will slow down the build a small amount.
-
-## Security
-
-n/a
-
-## Testing
-
-n/a
-
-## Drawbacks, Alternatives, and Unknowns
-
-General agreement of the approach and the specific syntax used are required for adoption. The syntax is easily modified (and bikeshedded) and does alter the core ideas of the proposal.
-
-Potential alternatives with regards to fidldoc is that the compiler generates the documentation itself. It may also be worth using the existing backend generator approach for this. Output format of the generated documentation may also be up for discussion.
-
-Another alternative is to represent the documentation comments as first-class citizens in the AST. While there aren’t any real drawbacks to this strategy, you lose some of the extensibility benefits of modeling it as an attribute. Someday we may want to add additional information for our documentation tooling and the attribute style makes this possible without breaking changes. For example, we may want to allow specifying the markdown language of the comment. This would then keep all of the information for generating the documentation within the same output (the attributes). It also enforces a nice regularity where the doc comments and attributes, which have similar placement constraints, are parsed in the same way.
-
-## Prior Art and References
-Most languages have documentation tooling. This draws from prior art of dartdoc, rustdoc, and javadoc (mostly in what not to do)
diff --git a/development/languages/fidl/reference/ftp/ftp-012.md b/development/languages/fidl/reference/ftp/ftp-012.md
index 09b3829..225b97b 100644
--- a/development/languages/fidl/reference/ftp/ftp-012.md
+++ b/development/languages/fidl/reference/ftp/ftp-012.md
@@ -1,100 +1,7 @@
-# FIDL Tuning Proposal 012
+# Obsolete
 
-Empty Structs
-
-Field     | Value
-----------|--------------------------
-Status    | Accepted
-Authors   | ianloic@google.com
-Submitted | 2018-08-30
-Reviewed  | 2018-09-11
-
-[TOC]
-
-## Summary
-
-Allow empty structs in FIDL library declarations and define the encoding
-of that to be a struct with a single zero-valued `uint8`.
-
-## Motivation
-
-Today, we see the need for empty structs come up in various areas.
-For instance, when using the
-[command pattern](../../../../../development/api/fidl.md#Command-union)
-where one of the commands does not require any arguments.
-Say you have a "ping" command, where simply selecting this union option is enough to convey the intent.
-Generalizing, empty structs are useful to represent 'unit types' when simulating
-[Algebraic Data Types](https://en.wikipedia.org/wiki/Algebraic_data_type).
-
-However, empty structs are disallowed in some target languages: you can't have empty C/C++
-structs, and we want FIDL wire encoding to be mappable to C data types.
-
-As a result of the need, and the current constraint, we've seen a proliferation
-of structs that are semantically empty, but in practice have a single small
-placeholder field so that they compile.
-
-Here are some examples:
-
-- [fuchsia.modular.GlobalScope](https://fuchsia.googlesource.com/peridot/+/b952e49b1d2743ee2621c0ddb45cbdb7774b8f0c/public/fidl/fuchsia.modular/user_intelligence/scope.fidl#22)
-- [fuchsia.modular.FocusStory](https://fuchsia.googlesource.com/peridot/+/5ed52652adfeb70c011a5d86acfd3bbfb768b13e/public/fidl/fuchsia.modular/suggestion/proposal.fidl#74)
-
-This proposal would decouple the constraints of a particular set of languages from
-the FIDL language while maintaining wire format compatibility with C structs.
-
-## Design
-
-The FIDL frontend compiler should accept empty struct definitions.
-The TypeShape of an empty struct should be the same as a struct with a single `uint8` field.
-
-Bindings generators for languages that can handle empty structs should generate
-actual empty structs but care must be taken to ensure that empty structs are
-correctly encoded as a struct that takes a byte.
-For C and C++ a single `uint8_t __reserved` field should be generated.
-
-## Implementation Strategy
-
-1. Allow `fidlc` to accept empty structs and synthesize a `uint8` field in the IR.
-2. Update the `fidl_compatibility_test` to include an empty struct.
-3. Update the documentation.
-4. Update `fidlc` to not emit a bonus bogus field for empty structs, update
-   the bindings generators and validate that this works using `fidl_compatibility_test`.
-5. Remove the placeholder fields from the structs identified above.
-
-## Documentation and Examples
-
-The FIDL documentation already includes (invalid)
-[examples](../language.md#identifiers) of empty structs.
-The language documentation could simply remove the
-[constraint on zero-length structs](../language.md#structs).
-The [wire format](../wire-format/index.md#Structs)
-definition would gain a description of how to encode empty structs.
-
-## Backwards Compatibility
-
-This change is backwards compatible as it loosens rather than constrains the FIDL language.
-If interface authors replace a semantically empty struct that contains just
-a byte sized placeholder field (`boolean`, `uint8`, `int8`) with an empty struct then
-that will be even be represented the same on the wire.
-
-## Performance
-
-This should have no impact on build or IPC performance but for languages that
-allow empty structs they will save on the work of moving around meaningless values.
-
-## Security
-
-No impact.
-
-## Testing
-
-The compilation of empty structs will be added as a `fidlc` test.
-The wire format of empty structs will be tested as part of the `fidl_compatibility_test`.
-
-## Drawbacks, Alternatives, and Unknowns
-
-We could leave things the way they are but this seems like a simple improvement.
-
-## Prior Art and References
-
-Most programming languages and IDLs allow empty structs.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
diff --git a/development/languages/fidl/reference/ftp/ftp-020.md b/development/languages/fidl/reference/ftp/ftp-020.md
index f87e0fd..225b97b 100644
--- a/development/languages/fidl/reference/ftp/ftp-020.md
+++ b/development/languages/fidl/reference/ftp/ftp-020.md
@@ -1,513 +1,7 @@
-# FIDL Tuning Proposal 020
+# Obsolete
 
-Interface Ordinal Hashing
-
-*"60% of the time, it's the answer to an interview question"*
-
-Field     | Value
-----------|--------------------------
-Status    | Accepted
-Authors   | {apang,ianloic}@google.com
-Submitted | 2018-10-26
-Reviewed  | 2018-11-29
-
-## Summary
-
-We propose removing the programmer's ability to manually
-specify the ordinal for interface methods [[1]](#Footnote1).
-Instead, the compiler generates the ordinal based on a hash of the
-fully-qualified method name, i.e. the library name, interface name & method name.
-Method renames will be ABI-compatible via a new `Selector` attribute (see
-[below](#the-selector-attribute-method-renaming)).
-
-We specifically restrict this FTP to propose ordinal hashing for interfaces only;
-not enums, tables nor extensible unions.
-We believe the use-cases for those structures are different enough that they need further
-investigation and a different FTP.
-
-## Example
-
-Currently, a FIDL author would write:
-
-```fidl
-library foo;
-
-interface Science {
-    1: Hypothesize();
-    2: Investigate();
-    3: Explode();
-    4: Reproduce();
-};
-```
-
-This FTP would enable the ordinal indexes to be dropped:
-
-```fidl
-interface Science {
-    Hypothesize();  // look, no ordinals!
-    Investigate();
-    Explode();
-    Reproduce();
-};
-```
-
-Under-the-hood, the compiler effectively generates ordinals that look like this:
-
-```fidl
-interface Science {
-    // ordinal = SHA-256 of the fully-qualified method name,
-    // i.e. "foo.Science/MethodName", truncated to 32 bits
-    0xf0b6ede8: Hypothesize();
-    0x1c50e6df: Investigate();
-    0xff408f25: Explode();
-    0x0c2a400e: Reproduce();
-};
-```
-
-## Motivation
-
-- Manually specifying ordinals is largely mechanical.
-  It's less work to write an interface if you don't need to think about them.
-- If a good hash is used, it's extremely unlikely that hashing will result in ordinals clashing,
-  which is an improvement on humans manually writing ordinals (particularly if interface
-  inheritance is used).
-  See the [Ordinal Clashing section below](#Ordinal Clashing & Conflict Resolution]
-  for more information.
-- Programmers must currently ensure that ordinals for different methods do not clash.
-  This is easy for interfaces with few methods, but if an interface has many
-  methods, this can become non-trivial.
-  There are different coding styles and schools of thought for ordinal numbering,
-  which leads to inconsistent coding style.
-    - Most interfaces start at 1 and go upwards.
-    - However, some authors prefer grouping different interface methods in ranges
-      (e.g., 1-10, 100-110, etc).
-    - Removing manually-numbered ordinals also removes this inconsistent style,
-      and removes the need for the author to make the decision about which style to use.
-- Interface inheritance may lead to unanticipated clashing of ordinals.
-  Two attempts have been made so far to solve this:
-    - FTP-010 (**rejected**) proposed an `OrdinalRange` attribute so that interface
-      inheritance could be more predictable; it was rejected.
-    - `FragileBase` [[2]](#Footnote2) is the current stop-gap solution, but doesn't solve the core
-      problem of ensuring that ordinals don't clash.
-    - If ordinals are hashed and the interface and library name are used to compute
-      the hash, hashing ordinals will not result in clashing ordinals, which solves
-      the interface inheritance problem (outside of extremely rare hash collisions).
-
-## Design
-
-### Hash
-
-The hashed ordinal is derived by a [SHA-256](https://en.wikipedia.org/wiki/SHA-2) hash of:
-
-    library name (encoded as UTF-8; no trailing \0)
-    ".", ASCII 0x2e
-    interface name (encoded as UTF-8; no trailing \0)
-    "/", ASCII 0x2f
-    method name (encoded as UTF-8; no trailing \0)
-
-For example, the following FIDL declaration:
-
-```fidl
-library foo;
-
-interface Science {
-    Hypothesize();
-    Investigate();
-    Explode();
-    Reproduce();
-};
-```
-
-will have the following byte patterns used to calculate the ordinal hash:
-
-    foo.Science/Hypothesize
-    foo.Science/Investigate
-    foo.Science/Explode
-    foo.Science/Reproduce
-
-The `.` and `/` separators are used since `fidlc` already outputs fully-qualified
-method names in this format (c.f. [`fidlc`'s **NameName()** method](https://fuchsia-review.googlesource.com/c/zircon/+/master/system/host/fidl/include/fidl/names.h)).
-
-Once the SHA-256 hash is computed:
-
-1. The upper 32 bits of the SHA-256 hash are extracted (e.g., `echo -n foo.Science.Hypothesize | shasum -a 256 | head -c8`)
-2. The upper bit is set to 0, resulting in an effective 31-bit hash value that's
-   zero-padded to 32 bits.
-   (31 bits are used since the FIDL wire format reserves the most significant bit in the 32-bit ordinal.)
-
-In pseudo-code:
-
-```c
-full_hash = sha256(library_name + "." + interface_name + "/" + method_name)
-ordinal = full_hash[0] |
-        full_hash[1] << 8 |
-        full_hash[2] << 16 |
-        full_hash[3] << 24;
-ordinal &= 0x7fffffff;
-```
-
-###  The Selector Attribute & Method Renaming
-
-We define a `Selector` attribute that will be used by the compiler to compute
-the hashed ordinal instead of using the method name.
-If a method name does not have the `Selector` attribute, the method name will
-be used as the `Selector`.
-(The interface and library names are still used in the hash computation.)
-
-`Selector` can be used to rename a method without breaking ABI compatibility,
-which was one advantage of manually-specified ordinals.
-For example, if we wish to rename the `Investigate` method to `Experiment` in
-the `Science` interface, we can write:
-
-```fidl
-interface Science {
-    [Selector="Investigate"] Experiment();
-};
-```
-
-We allow the `Selector` attribute on methods only.
-Renaming libraries is considered rare, and preserving ABI-compatibility in
-this situation is not a high priority.
-Similarly for renaming an interface.
-Additionally, the interaction of a renamed interface with a `Discoverable`
-attribute would be confusing: which name is the discoverable one?
-
-### Ordinal Clashing & Conflict Resolution
-
-If a hashed ordinal results in a clash or conflict with another hashed ordinal
-in the same interface, the compiler will emit an error, and rely on a human
-to specify a [`Selector`](#the-selector-attribute-method-renaming)
-attribute to resolve the conflict [[3]](#Footnote3).
-
-For example, if the method name `Hypothesize` conflicts with the method
-name `Investigate`, we could add `Selector` to `Hypothesize` to avoid the conflict:
-
-```fidl
-interface Science {
-    [Selector="Hypothesize_"] Hypothesize();
-    Investigate();  // should no longer conflict with Hypothesize_
-};
-```
-
-We will update the
-[FIDL readability rubric](../../../../../development/api/fidl.md)
-to recommend appending "_" to the method name for the `Selector` to resolve clashes.
-`fidlc` will also suggest this fix.
-
-Note that ordinals are only required to be unique per-interface, similarly to
-manually-specified ordinals.
-If we wish ordinals to be unique across all interfaces, that should be
-proposed in another FTP.
-
-Back-of-the-envelope calculations show that, with 31 bits and 100 methods on
-an interface, the chance of collision is .0003%, so we expect hash collisions
-to be extremely rare.
-
-### Selector Bikeshed
-
-There were other suggestions for `Selector`:
-
-- `WireName` (`abarth`)
-- `OriginalName` (`ctiller`)
-- `Salt` (`abarth`; slightly different since it suggested adding a compiler-specified
-  salt instead of an alternate name)
-- `OrdinalName`
-
-We chose `Selector` since we believe it more closely reflects the intent of
-the attribute than either WireName or OriginalName.
-
-We chose to have the programmer specify the ordinal name, rather
-than the ordinal index, for several reasons:
-
-- requiring the index would be more tedious (e.g. copy-and-paste of the raw
-  SHA-256 hash value in case of a conflict),
-- specifying the ordinal name enables ABI-compatible method renaming, and
-- specifying the name instead of the index arguably keeps the abstraction level
-  the same in the programmer's head as they write the interface, rather than
-  going one level of abstraction lower, requiring them to think about ordinals.
-
-### The Zero Ordinal
-
-Zero is an [invalid ordinal](../wire-format/index.md#transactional-messages).
-If a method name hashes to zero, the compiler will treat it as a hash conflict
-and require the user to specify a `Selector` that does not hash to zero.
-
-We considered having `fidlc` automatically re-hash the name by deterministically
-transforming it, but felt that:
-
-- any such algorithm would be non-obvious, and
-- the zero case is extremely rare,
-
-and that therefore this approach didn't warrant complicating both the ergonomics and the compiler implementation.
-
-### Events
-
-This FTP also covers events, which are considered a subset of methods by the FIDL language docs
-[[4]](#Footnote4).
-
-### Compiler & Bindings Changes
-
-We believe that only `fidlc` needs to be modified to support ordinal hashing;
-code generation back-ends do not need to be modified.
-This is because `fidlc` computes the ordinals and emits them in the JSON IR to back-ends.
-
-Bindings do not need to change.
-
-## Implementation Strategy
-
-We intend to implement this in distinct phases:
-
-1. Add code to fidlc to compute hashes.
-2. Add support for attributes to libraries.
-3. Broadcast intent-to-change to fuchsia eng so they are aware of potential issues.
-    a. Propose that manual ordinals will be deprecated on a certain date, when
-       we expect the next step is completed.
-4. In the same CL:
-    a. Modify the FIDL grammar's interface-method rule to make ordinals optional;
-       see below for more details.
-    b. Ignore manually-specified ordinals, and use the hashed ordinal for the
-       ordinal name passed to code-generation back-ends.
-    c. Manually fix any existing hash collisions by adding the `Selector` attribute.
-5. Test the changes over two weeks to ensure there's no production problems.
-    a. New FIDL interfaces written in this time should not use ordinals.
-    b. Manual ordinals are regarded as deprecated, though fidlc will not emit
-       warnings about this.
-    c. Work with teams to ensure no manually-specified ordinals remain in interfaces.
-    c. At the end of the two weeks, update the FIDL formatter to remove ordinals,
-       and mass-apply it to the entire Fuchsia tree.
-6. Remove support for manually-specified ordinals.
-
-The above is a
-[soft transition](../../../../../development/workflows/multilayer_changes.md#soft-transitions-preferred);
-changing `fidlc` to use the hashed ordinals (step 4b) should not break the rollers,
-since rollers build from a single version of the entire tree.
-
-In [jeremymanson@google.com's implementation of this FTP](https://fuchsia-review.googlesource.com/c/zircon/+/227623),
-he chose to prefer a manually-specified ordinal over a hashed ordinal, which
-diverges from step 4b above.
-This keeps all existing interfaces that use manually-specified ordinals ABI-compatible,
-and only uses hashed ordinals when ordinals aren't specified.
-
-## Ergonomics
-
-Advantages:
-- Writing interfaces should be simpler.
-
-Disadvantages:
-- Programmers will need to understand a new attribute, `Selector`, that serves
-  two purposes: renaming and conflict resolution.
-- It may not be apparent that changing a method name breaks ABI compatibility,
-  which wasn't the case with programmer-specified ordinals.
-  User education (e.g. better documentation) can ameliorate this.
-    - Note that other component systems, such as COM and Objective-C, typically
-      also break ABI compatibility when interface methods are renamed.
-      So, this behavior probably familiar to developers who have used similar systems.
-- The loss of manual control over ordinal numbers may result in less debuggability
-  in unusual cases where e.g. multiple FIDL interfaces are being used on the same Zircon channel.
-
-Note that the authors originated this FTP largely for ergonomics reasons.
-
-## Documentation and Examples
-
-We expect to make changes to the FIDL attributes, grammar, language and wire format docs.
-The API readability rubric doc should also be updated, as noted in the
-[`Selector` section](#the-selector-attribute-method-renaming).
-
-## Backwards Compatibility
-
-- Hashed ordinals are ABI-incompatible with manually specified ordinals, by design.
-  We expect this to be a non-issue, since
-    - the `fidlc` change is binary (either hashed xor manual ordinals will be used), and
-    - `fidlc` is used to build the entire tree, so
-    - all parts of the tree will consistently use the chosen ordinal scheme.
-- Hashed ordinals are **API (source)-compatible**.
-  Existing source files will be kept compatible; manual ordinals will be
-  deprecated (see Implementation Strategy).
-- Errors will occur if two different builds of fidlc (i.e. two different builds
-  of the Fuchsia source tree) are used, and FIDL interfaces are used to
-  communicate across machines.
-  The authors know of no current uses of this, so this should not be an issue.
-
-## Performance
-
-We expect a negligible slowdown to `fidlc`, as it now has to hash all method
-names in an interface to compute them.
-
-We expect an insignificant runtime performance impact.
-Compilers may have generated jump tables for manually-specified ordinals
-that were previously small and contiguous, which will become binary searches
-through a sparse ordinal space when hashed ordinals are used.
-The same mechanism may also impact binary size in an insignificant fashion.
-(Table-driven dispatch will likely ameliorate both the size and speed concerns.)
-
-## Security
-
-We do not expect runtime security issues, since ordinal hashing has no runtime
-changes except changing the ordinal values sent over-the-wire.
-
-The use of a cryptographic hash (SHA-256) may lead some to believe the hash needs
-to be cryptographically strong; we do not believe there are security issues since:
-- the FIDL compiler will check for hash collisions at compile time and require
-  human input to resolve them, and
-- we use SHA-256 not for cryptographic purposes, but because we'd like a hash
-  that is extremely unlikely to result in collisions.
-  CRC-32 (or even **strlen()**) would work too, but would probably result in more
-  collisions, which would simply be inconvenient.
-
-Truncation of the SHA-256 hash may also concern some, but again, we do not
-believe there are security issues since the FIDL compiler statically checks for hash collisions
-[[5]](#Footnote5).
-
-## Testing
-ianloic@google.com has analyzed existing FIDL interfaces and determined
-that there are zero hash collisions.
-
-We'll carefully consider how to test the case of an actual hash collision, since
-artificially generating hash collisions with a good hash is difficult (by design).
-
-Otherwise, the typical battery of unit tests, CQ tests,
-[compatibility tests](https://fuchsia.git.corp.google.com/garnet/+/master/public/lib/fidl/compatibility_test/README.md)
-and manual testing should suffice to ensure that ordinal hashing is robust.
-
-## Drawbacks, Alternatives, and Unknowns
-
-This FTP intentionally only addresses ordinal hashing for interfaces.
-It does not propose changes to the manually-enumerated ordinals for enums,
-tables nor extensible unions.
-
-Perfect hashing was suggested by jeffbrown@google.com, and was considered.
-The FTP authors are not very familiar with perfect hashing schemes, but believe
-that the addition of extra methods over time would change the hashes of existing
-methods and therefore break ABI compatibility, making perfect hashing unsuitable.
-Dynamic perfect hashing may be possible, but raises the same question of
-changing hashes, and is also less well-known and more complicated than standard
-hashing, which doesn't warrant further investigation.
-
-Another approach to removing manual ordinals is to send the full method name
-across the wire, which is done in many (most?) other RPC systems (see [References] below).
-This has runtime performance implications that arguably conflict with FIDL's intended use-cases.
-
-We considered being able to specify the hash used so it can be changed later,
-if SHA-256 ended up having problems that another hash would solve.
-This design is common in security applications, where a widely-used cryptographic
-hash [will have vulnerabilities](http://valerieaurora.org/hash.html) discovered later.
-However, specifying the hash would likely require changes to the wire format,
-and require all language bindings to implement code to select hash algorithms,
-significantly complicating both compiler and bindings code.
-We did not think that trade-off was worthwhile.
-We recognize that
-[`git` also took this attitude toward SHA-1](https://lwn.net/Articles/715716/),
-and is now somewhat back-tracking on the decision, but think we think our use case is
-different enough to justify hard-coding the hash algorithm.
-
-## Explorations
-
-- A space-efficient means of identifying a method could lead to an efficient
-  first-class representation of a method, making methods first-class.
-    - This could, e.g., enable methods to be used as arguments in FIDL calls, or
-      have a FIDL method return another method as a result.
-      There are arguably existing use cases for this already, where methods return
-      an interface with a single method as a proxy for returning an actual method.
-- The proposed 31 bits of hashing could be expanded to, e.g., 64/128/53 bits;
-  SHA-256 provides lots o'bits.
-- Rename `ordinal` to `selector`, which is an existing concept that serves the same
-  purpose in other languages and component systems.
-- It may be worth distinguishing between method name and interface name, so we
-  have the two distinct pieces of data.
-  This enables referring to the interface name uniquely, and the method name uniquely.
-  We probably need more than 32 bits for this.
-- As mentioned above, enums, tables, and extensible unions are out-of-scope.
-  That said, we do think this FTP could apply to them.
-  Initial thoughts:
-    - We're unsure whether enums would want this feature.
-      The simpler and standardized consecutive integer numbering seems sufficient.
-    - This could probably be applied as-is to extensible unions.
-    - Tables would need a different wire format to adopt ordinal hashing, since
-      ordinals currently need to be contiguous due to the packed representation.
-- FIDL currently reserves the ordinal upper bit, and explicitly says in docs that
-  a range of the upper bits is intended for use as control flow etc.
-  The authors think that one of the reasons for this may also have to do with
-  clashing ordinals.
-  Do we want to revisit this?
-    - Expanding the ordinal space to 64 bits (mentioned above) will largely solve this.
-    - abarth@google.com suggested on the Fuchsia IPC chat room to reserve only `0xFFFFxxxx`.
-- We could include the method's argument types in the calculated hash, which
-  would support method overloading if we'd like that in the future.
-    - jeffbrown@google.com mentions that hashing full method signatures may limit
-      opportunities for interface extension, and that overloading maps poorly
-      onto many programming languages.
-- Since ordinal hashing should resolve ordinals clashing when interface inheritance
-  is used, the [FragileBase] attribute could also be removed.
-    - Code Search shows ~9 uses of `FragileBase`.
-- The authors were concerned that an interface that has evolved significantly
-  over time may become hard to read if many methods have `Selector` attributes on them.
-    - One approach to solving this is to adopt something similar to
-      [Objective-C categories](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/CustomizingExistingClasses/CustomizingExistingClasses.html#//apple_ref/doc/uid/TP40011210-CH6-SW2)
-      or [C# partial classes](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/partial-classes-and-methods),
-      where an already-existing declared interface can be "extended" to have attributes added to it in a separate declaration.
-
-## Prior Art and References
-
-Interestingly, we do not know of any other method dispatch or RPC system that
-uses a hash of the method name to identify which method to call.
-
-Most RPC systems call methods by name (e.g. gRPC/Protobuf service, Thrift, D-Bus).
-For in-process method calls, Objective-C uses a guaranteed-unique char* pointer
-value, called a selector, to identify the method that should be called on a class.
-The Objective-C runtime can map selectors to stringified method names and vice versa.
-For out-of-process method calls, Objective-C distributed objects uses the method
-name for invocation.
-COM directly uses the C++ vtable for in-process calls, and therefore depends
-on ABI and compiler support to support method dispatch.
-apang@google.com suggested ordinal hashing for tables in ctiller@google.com's Phickle proposal.
-ianloic@google.com and apang@google.com met on Thu 2018/10/18 to whiteboard this.
-
---------------------------------------------------------------------------------------------
-
-##### Footnote1
-
-Mojo/FIDL1 also didn't require the programmer to specify ordinals;
-instead, they were sequentially generated (similarly to FlatBuffers's
-implicit tag numbering for table fields).
-
-##### Footnote2
-
-Previously, you could create a FIDL interface that inherited from
-whichever other FIDL interface you liked.
-However, the interface and the superinterface share the same ordinal space,
-which means if you added a method to an interface you might break a
-subinterface in some other, far away library.
-
-There are several proposals kicking around FIDL-land for resolving the
-inheritance / ordinal collision problem, but until we figured out how we
-want to solve this problem, we've switched the default for interfaces to
-forbid inheritance.
-An interface can still opt in to allowing subinterfaces using the
-`[FragileBase]` attribute.
-
-If you run into this issue, the compiler should print out an error message
-with a brief explanation.
-I (abarth@google.com) have added the `[FragileBase]` attribute
-everywhere we use FIDL interface inheritance in the Fuchsia Source Tree
-(hopefully!).
-
-Please let me know if you have any questions or run into any trouble.
---abarth@google.com
-
-##### Footnote3
-
-We do not believe that there'll be sufficient ordinal clashes to warrant any
-extra implementation and cognitive complexity added by automatic conflict resolution.
-We can revisit this decision without breaking backward-compatibility if data
-shows that ordinal clashing becomes problematic.
-
-##### Footnote4
-
-If only results are declared, the method is referred to as an event.
-It then defines an unsolicited message from the server.
-
-##### Footnote5
-
-jln@google.com writes, "Yes it's ok to truncate SHA-2 and no, it doesn't matter where you truncate."
-
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
diff --git a/development/languages/fidl/reference/ftp/template.md b/development/languages/fidl/reference/ftp/template.md
index 4d9b107..225b97b 100644
--- a/development/languages/fidl/reference/ftp/template.md
+++ b/development/languages/fidl/reference/ftp/template.md
@@ -1,10 +1,7 @@
+# Obsolete
 
-@@@ This file is for reference only to ensure that each FTP has a consistent header
-
-Field     | Value
-----------|--------------------------
-Status    | Accepted / Rejected
-Authors   | <username>@google.com
-Submitted | YYYY-MM-DD
-Reviewed  | YYYY-MM-DD
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
diff --git a/development/languages/fidl/reference/grammar.md b/development/languages/fidl/reference/grammar.md
index c897a0d..225b97b 100644
--- a/development/languages/fidl/reference/grammar.md
+++ b/development/languages/fidl/reference/grammar.md
@@ -1,149 +1,7 @@
-# Grammar
+# Obsolete
 
-## Modified BNF rules
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-This is the grammar for FIDL source files. The grammar is expressed in
-a modified BNF format.
-
-A nonterminal symbol matches a sequence of other symbols, delimited by
-commas.
-```
-nonterminal = list , of , symbols ;
-```
-
-Some symbols are terminals, which are either in all caps or are in
-double quotes.
-```
-another-nonterminal = THESE , ARE , TERMINALS , AND , SO , IS , "this" ;
-```
-
-Alternation is expressed with a pipe.
-```
-choice = this | that | the-other ;
-```
-
-An option (zero or one) is expressed with parentheses.
-```
-optional = ( maybe , these ) , but , definitely , these ;
-```
-
-Repetition (zero or more) is expressed with parentheses and a star.
-```
-zero-or-more = ( list-part )* ;
-```
-
-Repetition (one or more) is expressed with parentheses and a plus.
-```
-one-or-more = ( list-part )+ ;
-
-```
-
-## Tokens
-
-Whitespace and comments are ignored during lexing, and thus not
-present in the following grammar. Comments are C++-style `//` until
-the end of the line.
-
-TODO(US-238): Eventually comments will be read as part of a
-documentation generation system.
-
-## The grammar
-
-`file` is the starting symbol.
-
-```
-file = library-header , ( using-list ) , declaration-list ;
-
-library-header = ( attribute-list ) , "library" , compound-identifier , ";" ;
-
-using-list = ( using | using-declaration )* ;
-
-using-declaration = "using" , IDENTIFIER ,  "=" , primitive-type , ";" ;
-
-declaration-list = ( declaration , ";" )* ;
-
-compound-identifier = IDENTIFIER ( "." , IDENTIFIER )* ;
-
-using = "using" , compound-identifier , ( "as" , IDENTIFIER ) , ";" ;
-
-declaration = const-declaration | enum-declaration | interface-declaration |
-              struct-declaration | union-declaration | table-declaration ;
-
-const-declaration = ( attribute-list ) , "const" , type , IDENTIFIER , "=" , constant ;
-
-enum-declaration = ( attribute-list ) , "enum" , IDENTIFIER , ( ":" , integer-type ) ,
-                   "{" , ( enum-member , ";" )+ , "}" ;
-
-enum-member = IDENTIFIER , ( "=" , enum-member-value ) ;
-
-enum-member-value = IDENTIFIER | NUMERIC-LITERAL ;
-
-interface-declaration = ( attribute-list ) , "interface" , IDENTIFIER ,
-                        ( ":" , super-interface-list ) , "{" , ( interface-method , ";" )*  , "}" ;
-
-super-interface-list = compound-identifier
-                     | compound-identifier , "," , super-interface-list
-
-interface-method = ordinal , ":" , interface-parameters
-
-interface-parameters = IDENTIFIER , parameter-list , ( "->" , parameter-list )
-                     | "->" , IDENTIFIER , parameter-list
-
-parameter-list = "(" , ( parameters ) , ")" ;
-
-parameters = parameter | parameter , "," , parameters ;
-
-parameter = type , IDENTIFIER ;
-
-struct-declaration = ( attribute-list ) , "struct" , IDENTIFIER , "{" , ( struct-field , ";" )* , "}" ;
-
-struct-field = type , IDENTIFIER , ( "=" , constant ) ;
-
-union-declaration = ( attribute-list ) , "union" , IDENTIFIER , "{" , ( union-field , ";" )+ , "}" ;
-
-union-field = type , IDENTIFIER ;
-
-table-declaration = ( attribute-list ) , "table" , IDENTIFIER , "{" , ( table-field , ";" )* , "}" ;
-
-table-field = table-field-ordinal , table-field-declaration ;
-
-table-field-ordinal = ordinal , ":" ;
-
-table-field-declaration = struct-field | "reserved" ;
-
-attribute-list = "[" , attributes, "]" ;
-
-attributes = attribute | attribute , "," , attributes ;
-
-attribute = IDENTIFIER , ( "=", STRING-LITERAL ) ;
-
-type = identifier-type | array-type | vector-type | string-type | handle-type
-                       | request-type | primitive-type ;
-
-identifier-type = compound-identifier , ( "?" ) ;
-
-array-type = "array" , "<" , type , ">" , ":" , constant ;
-
-vector-type = "vector" , "<" , type , ">" , ( ":" , constant ) , ( "?" ) ;
-
-string-type = "string" , ( ":" , constant ) , ( "?" ) ;
-
-handle-type = "handle" , ( "<" , handle-subtype , ">" ) , ( "?" ) ;
-
-handle-subtype = "process" | "thread" | "vmo" | "channel" | "event" | "port" |
-                 "interrupt" | "debuglog" | "socket" | "resource" | "eventpair" |
-                 "job" | "vmar" | "fifo" | "guest" | "timer" ;
-
-request-type = "request" , "<" , compound-identifier , ">" , ( "?" ) ;
-
-primitive-type = integer-type | "bool" | "float32" | "float64" ;
-
-integer-type = "int8" | "int16" | "int32" | "int64" |
-               "uint8" | "uint16" | "uint32" | "uint64" ;
-
-constant = compound-identifier | literal ;
-
-ordinal = NUMERIC-LITERAL ;
-
-literal = STRING-LITERAL | NUMERIC-LITERAL | TRUE | FALSE ;
-```
diff --git a/development/languages/fidl/reference/host.md b/development/languages/fidl/reference/host.md
index e8882cd..225b97b 100644
--- a/development/languages/fidl/reference/host.md
+++ b/development/languages/fidl/reference/host.md
@@ -1,29 +1,7 @@
-# Host Side Fidl
+# Obsolete
 
-This document is a short summary of what's available now for host side FIDL, and what may be available in the future.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-## What’s Available?
-
-Encoding and decoding of structs and tables that contain no zircon handles in C++ only.
-
-* Use of handles (or consequently FIDL interface requests and the like) will cause the host side libraries to fail.
-* In the future this will be verified via a mechanism like NoHandles.
-
-## What’s not Available?
-
-Any use of interfaces.
-
-* Trying to use a FIDL file that mentions an interface will cause the host side runtime to fail to compile.
-* In the future some verification mechanism will be available here too.
-
-## What is out of scope?
-
-Emulation of arbitrary zircon handles (particularly VMO’s).
-
-## What is possibly in scope?
-
-Interfaces communicating over a socket transport (implies not exchanging handles).
-
-## What is undecided?
-
-Emulation of channels on host side (maybe via overnet).
diff --git a/development/languages/fidl/reference/json-ir.md b/development/languages/fidl/reference/json-ir.md
index 43def58..225b97b 100644
--- a/development/languages/fidl/reference/json-ir.md
+++ b/development/languages/fidl/reference/json-ir.md
@@ -1,655 +1,7 @@
+# Obsolete
 
-# FIDL JSON Internal Representation
-
-For all backends (except C), the FIDL compiler operates in two phases.
-A first phase parses the FIDL file(s) and produces a JSON-based Intermediate
-Representation (**IR**).
-A second phase takes the IR as input, and produces the appropriate language-specific output.
-
-This section documents the JSON IR.
-
-> If you're curious about the JSON IR, you can generate it by running
-> the FIDL compiler with the `json` output directive:
->
-> `fidlc --json outputfile.json --files inputfile.fidl`
-
-## A simple example
-
-To get started, we can see how a simple example looks.
-We'll use the `echo2.fidl` ["Hello World Echo Interface"](../tutorial/README.md)
-example from the tutorial:
-
-```fidl
-library echo2;
-
-[Discoverable]
-interface Echo {
-    1: EchoString(string? value) -> (string? response);
-};
-```
-
-The tutorial goes through this line-by-line, but the summary is that we create a
-discoverable interface called `Echo` with a method called `EchoString`.
-The `EchoString` method takes an optional string called `value` and returns
-an optional string called `response`.
-
-Regardless of the FIDL input, the FIDL compiler generates a JSON data set with
-the following overall shape:
-
-```json
-{
-  "version": "0.0.1",
-  "name": "libraryname",
-  "library_dependencies": [],
-  "const_declarations": [],
-  "enum_declarations": [],
-  "interface_declarations": [],
-  "struct_declarations": [],
-  "table_declarations": [],
-  "union_declarations": [],
-  "declaration_order": [],
-  "declarations": {}
-}
-```
-
-The JSON members (name-value pairs) are as follows:
-
-Name                    | Meaning
-------------------------|-----------------------------------------------------------------------
-version                 | A string indicating the version of the JSON IR schema
-name                    | A string indicating the given `library` name
-library_dependencies    | A list of dependencies on other libraries
-const_declarations      | A list of consts
-enum_declarations       | A list of enums
-interface_declarations  | A list of interfaces provided
-struct_declarations     | A list of structs
-table_declarations      | A list of tables
-union_declarations      | A list of unions
-declaration_order       | A list of the object declarations, in order of declaration
-declarations            | A list of declarations and their types
-
-Not all members have content.
-
-So, for our simple example, here's what the JSON IR looks like (line
-numbers have been added for reference; they are not part of the generated code):
-
-```json
-[01]    {
-[02]      "version": "0.0.1",
-[03]      "name": "echo2",
-[04]      "library_dependencies": [],
-[05]      "const_declarations": [],
-[06]      "enum_declarations": [],
-[07]      "interface_declarations": [
-
-(content discussed below)
-
-[53]      ],
-[54]      "struct_declarations": [],
-[55]      "table_declarations": [],
-[56]      "union_declarations": [],
-[57]      "declaration_order": [
-[58]        "echo2/Echo"
-[59]      ],
-[60]      "declarations": {
-[61]        "echo2/Echo": "interface"
-[62]      }
-[63]    }
-```
-
-Lines `[01]` and `[63]` wrap the entire JSON object.
-
-Line `[02]` is the version number of the JSON IR schema.
-
-Line `[03]` is the name of the library, and is copied from the FIDL `library` directive.
-
-Lines `[04]`, `[05]` and `[06]` are the library dependencies, constant declarations,
-and enumeration declarations.
-Our simple example doesn't have any, so they just have a zero-sized (empty) array
-as their value ("`[]`").
-Similarly, there are no structs (line `[54]`), tables (`[55]`) or unions (`[56]`).
-The declaration order (`[57]`..`[59]`) isn't that interesting either,
-because there's only the one declaration, and, finally, the
-declarations member (`[60]`..`[62]`) just indicates the declared object (here, `echo2/Echo`)
-and its type (it's an `interface`).
-
-## The interface
-
-Where things are interesting, though, is starting with line `[07]` &mdash; it's the interface
-declaration for all interfaces in the file.
-
-Our simple example has just one interface, the `Echo` interface, so there's just one
-array element:
-
-```json
-[07]      "interface_declarations": [
-[08]        {
-[09]          "name": "echo2/Echo",
-[10]          "maybe_attributes": [
-[11]            {
-[12]              "name": "Discoverable",
-[13]              "value": ""
-[14]            }
-[15]          ],
-[16]          "methods": [
-[17]            {
-[18]              "ordinal": 1,
-[19]              "name": "EchoString",
-[20]              "has_request": true,
-[21]              "maybe_request": [
-[22]                {
-[23]                  "type": {
-[24]                    "kind": "string",
-[25]                    "nullable": true
-[26]                  },
-[27]                  "name": "value",
-[28]                  "size": 16,
-[29]                  "alignment": 8,
-[30]                  "offset": 16
-[31]                }
-[32]              ],
-[33]              "maybe_request_size": 32,
-[34]              "maybe_request_alignment": 8,
-[35]              "has_response": true,
-[36]              "maybe_response": [
-[37]                {
-[38]                  "type": {
-[39]                    "kind": "string",
-[40]                    "nullable": true
-[41]                  },
-[42]                  "name": "response",
-[43]                  "size": 16,
-[44]                  "alignment": 8,
-[45]                  "offset": 16
-[46]                }
-[47]              ],
-[48]              "maybe_response_size": 32,
-[49]              "maybe_response_alignment": 8
-[50]            }
-[51]          ]
-[52]        }
-[53]      ],
-```
-
-Each interface declaration array element contains:
-
-*   Line `[09]`: the name of the object (`echo2/Echo` &mdash; this gets matched
-    up with the `declarations` member contents starting on line `[60]`),
-*   Lines `[10]`..`[15]`: an optional list of attributes (we had marked it as
-    `Discoverable` &mdash; if we did not specify any attributes then we wouldn't
-    see lines `[10]` through `[15]`), and
-*   Lines `[16]`..`[51]`: an optional array of methods.
-
-The methods array lists the defined methods in declaration order (giving details
-about the ordinal number, the name of the method, whether it has a request
-component and a response component, and indicates the sizes and alignments of
-those componenets).
-
-The JSON output has two `bool`s, `has_request` and `has_response`,
-that indicate if the interface defines a request and a response, respectively.
-
-Since the string parameters within the request and response are both optional,
-the parameter description specifies `"nullable": true` (line `[25]` and `[40]`).
-
-### What about the sizes?
-
-The `size` members might be confusing at first; it's important here to note
-that the size refers to the size of the *container* and not the *contents*.
-
-> You may wish to refer to the [on-wire](wire-format/index.md) format document when
-> reading this part.
-
-Lines `[36]` through `[47]`, for example, define the `response` string container.
-It's 16 bytes long, and consists of two 64-bit values:
-
-*   a size field, indicating the number of bytes in the string (we don't rely
-    on NUL termination), and
-*   a data field, which indicates presence or pointer, depending on context.
-
-For the data field, two interpretations are possible.
-In the "wire format" version (that is, as the data is encoded for transmission),
-the data field has one of two values: zero indicates the string is null,
-and `UINTPTR_MAX` indicates that the data is present.
-(See the [Wire Format](wire-format/index.md) chapter for details).
-
-However, when this field has been read into memory and is decoded for consumption,
-it contains a 0 (if the string is null), otherwise it's a pointer
-to where the string content is stored.
-
-The other fields, like `alignment` and `offset`, also relate to the
-[on-wire](wire-format/index.md) data marshalling.
-
-## Of structs, tables, and unions
-
-Expanding on the structs, tables, and unions (`struct_declarations`, `table_declarations`,
-and `union_declarations`) from above, suppose we have a simple FIDL file like
-the following:
-
-```fidl
-library foo;
-
-union Union1 {
-    int64 x;
-    float64 y;
-};
-
-table Table1 {
-    1: int64 x;
-    2: int64 y;
-    3: reserved;
-};
-
-struct Struct1 {
-    int64 x;
-    int64 y;
-};
-```
-
-The JSON that's generated will contain common elements for all three types.
-Generally, the form taken is:
-
-```json
-"<TYPE>_declarations": [
-  {
-    <HEADER>
-    "members": [
-      <MEMBER>
-      <MEMBER>...
-    ],
-    <TRAILER>
-  }
-]
-```
-Where:
-
-Element     | Meaning
-------------|-------------------------------------------------------------------------------------
-`<TYPE>`    | one of `struct`, `table`, or `union`
-`<HEADER>`  | contains the name of the structure, table, or union, and optional characteristics
-`<MEMBER>`  | contains information about an element member
-`<TRAILER>` | contains more information about the structure, table, or union
-
-### The `struct_declarations`
-
-For the `struct_declarations`, the FIDL code above generates the following (we'll come back
-and look at the `members` part shortly):
-
-```json
-[01] "struct_declarations": [
-[02]   {
-[03]     "name": "foo/Struct1",
-[04]     "anonymous": false,
-[05]     "members": [
-[06]       <MEMBER>
-[07]       <MEMBER>
-[08]     ],
-[09]     "size": 16,
-[10]     "max_out_of_line": 0,
-[11]     "alignment": 8,
-[12]     "max_handles": 0
-[13]   }
-[14] ],
-```
-
-Specifically, the `<HEADER>` section (lines `[03]` and `[04]`) contains a `"name"` field (`[03]`).
-This is a combination of the `library` name and the name of the structure, giving `foo/Struct1`.
-
-Next, the `"anonymous"` field (`[04]`) is used to indicate if the structure is
-anonymous or named, just like in C.
-Since neither `table` nor `union` can be anonymous, this field is
-present only with `struct`.
-
-Saving the member discussion for later, the `<TRAILER>` (lines `[09]` through `[12]`)
-has the following fields:
-
-Field             | Meaning
-------------------|-------------------------------------------------------------------------------
-`size`            | The total number of bytes contained in the structure
-`max_out_of_line` | The maximum size of out-of-line data
-`alignment`       | Alignment requirements of the object
-`max_handles`     | The maximum number of handles
-
-These four fields are common to the `table_declarations` as well as the `union_declarations`.
-
-### The `table_declarations` and `union_declarations`
-
-The `table_declarations` and `union_declarations` have the same `<HEADER>` fields
-as the `struct_declarations`, except that they don't have an `anonymous` field,
-and the `table_declarations` doesn't have an `offset` field.
-A `table_declarations` does, however, have some additional fields in its `<MEMBER>` part,
-we'll discuss these below.
-
-### The `<MEMBER>` part
-
-Common to all three of the above (`struct_definition`, `table_definition`, and `union_definition`)
-is the `<MEMBER>` part.
-
-It describes each struct, table, or union member.
-
-Let's look at the `<MEMBER>` part for the `struct_declarations` for the first member,
-`int64 x`:
-
-```json
-[01] "members": [
-[02]   {
-[03]     "type": {
-[04]       "kind": "primitive",
-[05]       "subtype": "int64"
-[06]     },
-[07]     "name": "x",
-[08]     "size": 8,
-[09]     "max_out_of_line": 0,
-[10]     "alignment": 8,
-[11]     "offset": 0,
-[12]     "max_handles": 0
-[13]   },
-```
-
-The fields here are:
-
-Field             | Meaning
-------------------|-------------------------------------------------------------------------------
-`type`            | A description of the type of the member
-`name`            | The name of the member
-`size`            | The number of bytes occupied by the member
-`max_out_of_line` | The maximum size of out-of-line data
-`alignment`       | Alignment requirements of the member
-`offset`          | Offset of the member from the start of the structure
-`max_handles`     | The maximum number of handles
-
-The second member, `int64 y` is identical except:
-*   its `"name"` is `"y"` instead of `"x"`,
-*   its `offset` is `8` instead of `0`.
-
-#### `max_out_of_line`
-
-The `max_out_of_line` field indicates the maximum number of bytes which may be stored out-of-line.
-For instance with strings, the character array itself is stored out-of-line (that is, as data that
-follows the structure), with the string's size and presence indicator being stored in-line.
-
-#### `max_handles`
-
-The `max_handles` field indicates the maximum number of handles to associate with the object.
-Since in this case it's a simple integer, the value is zero because an integer doesn't carry
-any handles.
-
-#### The `<MEMBER>` part of a `table_declarations`
-
-A `table_declarations` has the same `<MEMBER>` fields as the `struct_declarations` described
-above, minus the `offset` and `anonymous` fields, plus two additional fields:
-
-Field      | Meaning
------------|--------------------------------------------------------------------------------------
-`ordinal`  | This is the "serial number" of this table member
-`reserved` | A flag indicating if this table member is reserved for future use
-
-> Note that if the `reserved` flag indicates the table member is reserved for future use, then
-> there is no definition of the member given; conversely, if the flag indicates the
-> member is not reserved, then the member definition follows immediately after.
-
-In our FIDL example above, the `table_declarations` has the following `<MEMBER>` part for the
-first member, `x`:
-
-```json
-[01] "members": [
-[02]   {
-[03]     "ordinal": 1,
-[04]     "reserved": false,
-[05]     "type": {
-[06]       "kind": "primitive",
-[07]       "subtype": "int64"
-[08]     },
-[09]     "name": "x",
-[10]     "size": 8,
-[11]     "max_out_of_line": 0,
-[12]     "alignment": 8,
-[13]     "max_handles": 0
-[14]   },
-```
-
-Here, the `ordinal` (`[03]`) has the value `1`, and the `reserved` flag (`[04]`) indicates
-that this field is not reserved (this means that the field is present).
-This matches the FIDL declaration from above:
-
-```fidl
-table Table1 {
-    1: int64 x;
-    2: int64 y;
-    3: reserved;
-};
-```
-
-The `<MEMBER>` part for the second member, `y`, is almost identical:
-
-```json
-[01] "members": [
-[02]   ... // member data for "x"
-[03]   {
-[04]     "ordinal": 2,
-[05]     "reserved": false,
-[06]     "type": {
-[07]       "kind": "primitive",
-[08]       "subtype": "int64"
-[09]     },
-[10]     "name": "y",
-[11]     "size": 8,
-[12]     "max_out_of_line": 0,
-[13]     "alignment": 8,
-[14]     "max_handles": 0
-[15]   },
-```
-
-The difference is that the `ordinal` field (`[04]`) has the value `2` (again, corresponding to what
-we specified in the FIDL code above).
-
-Finally, the third `<MEMBER>`, representing the reserved member, is a little different:
-
-```json
-[01] "members": [
-[02]   ... // member data for "x"
-[03]   ... // member data for "y"
-[04]   {
-[05]     "ordinal": 3,
-[06]     "reserved": true
-[07]   }
-```
-
-As you'd expect, the `ordinal` value (`[05]`) is `3`, and the `reserved` flag (`[06]`) is
-set to `true` this time, indicating that this is indeed a reserved member.
-The `true` value means that the field is *not* specified (that is, there are no `"type"`,
-`"name"`, `"size"`, and so on fields following).
-
-#### The `<MEMBER>` part of a `union_declarations`
-
-The `<MEMBER>` part of a `union_declarations` is identical to that of a `struct_declarations`,
-except that:
-
-*   there is no `max_handles` field (unions can't contain handles)
-*   the `offset` field may refer to the same offset for multiple members
-
-Recall that a `union` is an "overlay" &mdash; several different data layouts are considered to
-be sharing the space.
-In the FIDL code we saw above, we said that the data can be a 64-bit integer (called `x`)
-or it could be a floating point value (called `y`).
-
-This explains why both `offset` fields have the same value &mdash; `x` and `y` share the
-same space.
-
-Here are just the `offset` parts (and some context) for the `union_declarations` from
-the FIDL above:
-
-```json
-[01] "union_declarations": [
-[02]   {
-[03]     "name": "foo/Union1",
-[04]     "members": [
-[05]       {
-[06]         "name": "x",
-[07]         "offset": 8
-[08]       },
-[09]       {
-[10]         "name": "y",
-[11]         "offset": 8
-[12]       }
-[13]     ],
-[14]     "size": 16,
-[15]   }
-[16] ],
-```
-
-The natural questions you may have are, "why do the offsets (`[07]` and `[11]`) start at 8
-when there's nothing else in the union?
-And why is the size of the union 16 bytes (`[14]`) when there's only 8 bytes of data
-present?"
-
-Certainly, in C you'd expect that a union such as:
-
-```c
-union Union1 {
-  int64_t x;
-  double y;  // "float64" in FIDL
-};
-```
-
-would occupy 8 bytes (the size required to store the largest element),
-and that both `x` and `y` would start at offset zero.
-
-In FIDL, unions have the special property that there's an identifier at the beginning that
-is used to tell which member the union is holding.
-It's as if we had this in the C version:
-
-```c
-enum Union1_types { USING_X, USING_Y };
-
-struct Union1 {
-  Union1_types which_one;
-  union {
-    int64_t x;
-    double y;
-  };
-};
-```
-
-That is to say, the first field of the data structure indicates which interpretation of
-the union should be used: the 64-bit integer `x` version, or the floating point `y`
-version.
-
-> In the FIDL implementation, the "tag" or "discriminant" (what we called `which_one`
-> in the C version) is a 32-bit unsigned integer.
-> Since the alignment of the union is 8 bytes, 4 bytes of padding are added after the
-> tag, giving a total size of 16 bytes for the union.
-
-### Aggregates
-
-More complicated aggregations of data are, of course, possible.
-You may have a struct (or table or union) that contains other structures (or tables
-or unions) within it.
-
-As a trivial example, just to show the concept, let's include the `Union1` union as
-member `u` (line `[09]` below) within our previous structure:
-
-```fidl
-[01] union Union1 {
-[02]     int64 x;
-[03]     float64 y;
-[04] };
-[05]
-[06] struct Struct1 {
-[07]     int64 x;
-[08]     int64 y;
-[09]     Union1 u;
-[10] };
-```
-
-This changes the JSON output for the `Struct1` `struct_declarations` as follows:
-
-```json
-[01] "struct_declarations": [
-[02]   {
-[03]     "name": "foo/Struct1",
-[04]     "anonymous": false,
-[05]     "members": [
-[06]       ... // member data for "x" as before
-[07]       ... // member data for "y" as before
-[08]       {
-[09]         "type": {
-[10]           "kind": "identifier",
-[11]           "identifier": "foo/Union1",
-[12]           "nullable": false
-[13]         },
-[14]         "name": "u",
-[15]         "size": 16,
-[16]         "max_out_of_line": 0,
-[17]         "alignment": 8,
-[18]         "offset": 16,
-[19]         "max_handles": 0
-[20]       }
-[21]     ],
-[22]     "size": 32,
-[23]     "max_out_of_line": 0,
-[24]     "alignment": 8,
-[25]     "max_handles": 0
-[26]   }
-[27] ],
-```
-
-The changes are as follows:
-
-*   New `<MEMBER>` entry for the union `u` (`[08]` through `[20]`),
-*   The `size` (`[22]`) of the `struct_declarations` has now doubled to `32`
-
-We'll examine these in order.
-
-Whereas in the previous examples we had simple `"type"` fields, e.g.:
-
-```json
-"type": {
-  "kind": "primitive",
-  "subtype": "int64"
-},
-```
-
-(and, for the union's `float64 y`, we'd have `"subtype": "float64"`),
-we now have:
-
-```json
-"type": {
-  "kind": "identifier",
-  "identifier": "foo/Union1",
-  "nullable": false
-},
-```
-
-The `"kind"` is an `identifier` &mdash; this means that it's a symbol of some
-sort, one that is defined elsewhere (and indeed, we defined `foo/Union1` in
-the FIDL file as a union).
-
-The `"nullable"` flag indicates if the member is optional or mandatory, just like
-we discussed above in the section on [Interfaces](#The-interface).
-In this case, since `"nullable"` is `false`, the member is mandatory.
-
-Had we specified:
-
-```fidl
-union Union1 {
-    int64 x;
-    float64 y;
-};
-
-struct Struct1 {
-    int64 x;
-    int64 y;
-    Union1? u;  // "?" indicates nullable
-};
-```
-
-Then we'd see the `"nullable"` flag set to `true`, indicating that the union
-`u` is optional.
-
-When the `nullable` flag is set (indicating optional), the union value is
-stored out-of-line and the in-line indication consists of just a presence and
-size indicator (8 bytes).
-This causes the `max_out_of_line` value to change from 0 to 16 (because that's
-the size of the out-of-line data), and the size of the entire `struct_declarations`
-object shrinks from the 32 shown above to 24 bytes &mdash; `16 - 8 = 8` bytes less.
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
diff --git a/development/languages/fidl/reference/language.md b/development/languages/fidl/reference/language.md
index c86e367..225b97b 100644
--- a/development/languages/fidl/reference/language.md
+++ b/development/languages/fidl/reference/language.md
@@ -1,615 +1,7 @@
-# Language Specification
+# Obsolete
 
-This document is a specification of the Fuchsia Interface Definition Language
-(**FIDL**) syntax.
-
-See [Overview](../README.md) for more information about FIDL's overall
-purpose, goals, and requirements, as well as links to related documents.
-
-You can find a modified [EBNF description of the FIDL grammar here](grammar.md).
-
-[TOC]
-
-## Syntax
-
-FIDL provides a syntax for declaring named
-constants, enums, structs, tables, unions, and interfaces. These declarations are
-collected into libraries for distribution.
-
-FIDL declarations are stored in plain text UTF-8 files. Each file consists of a
-sequence of semicolon-delimited declarations. The order of declarations within a
-FIDL file, or among FIDL files within a library, is irrelevant. FIDL does not
-require (or support) forward declarations of any kind.
-
-### Tokens
-
-#### Comments
-
-FIDL comments start with two (`//`) or three (`///`) forward slashes, continue
-to the end of the line, and can contain UTF-8 content (which is, of course, ignored).
-The three-forward-slash variant is a "documentation comment", and causes the comment
-text to be emitted into the generated code (as a comment, escaped correctly
-for the target language).
-
-```fidl
-// this is a comment
-/// and this one is too, but it also ends up in the generated code
-struct Foo { // plain comment
-    int32 f; // as is this one
-}; // and this is the last one!
-```
-
-Note that documentation comments can also be provided via the
-[`[Doc]` attribute](attributes.md#Doc).
-
-#### Keywords
-
-The following are keywords in FIDL.
-
-```
-array, as, bool, const, enum, float32, float64, handle, int8, int16,
-int32, int64, interface, library, request, string, struct, table, uint8,
-uint16, uint32, uint64, union, using, vector
-```
-
-#### Identifiers
-
-FIDL identifiers must match the regex `[a-zA-Z]([a-zA-Z0-9_]*[a-zA-Z0-9])?`.
-
-In words: identifiers must start with a letter, can contain letters,
-numbers, and underscores, but cannot end with an underscore.
-
-Identifiers are case-sensitive.
-
-```fidl
-// a library named "foo"
-library foo;
-
-// a struct named "Foo"
-struct Foo { };
-
-// a struct named "struct"
-struct struct { };
-```
-
-> Note that while using keywords as identifiers is supported, it can lead to confusion,
-> and should the be considered on a case-by-case basis. See the `Names` section of the
-> [Readability Rubric](../../../api/fidl.md#Names)
-
-#### Qualified Identifiers
-
-FIDL always looks for unqualified symbols within the scope of the current
-library. To reference symbols in other libraries, they must be qualified by
-prefixing the identifier with the library name or alias.
-
-**objects.fidl:**
-
-```fidl
-library objects;
-using textures as tex;
-
-interface Frob {
-    // "Thing" refers to "Thing" in the "objects" library
-    // "tex.Color" refers to "Color" in the "textures" library
-    1: Paint(Thing thing, tex.Color color);
-};
-
-struct Thing {
-    string name;
-};
-```
-
-**textures.fidl:**
-
-```fidl
-library textures;
-
-struct Color {
-    uint32 rgba;
-};
-```
-
-#### Literals
-
-FIDL supports integer, floating point, boolean, string, and enumeration literals, using
-a simplified syntax familiar to C programmers (see below for examples).
-
-#### Constants
-
-FIDL supports the following constant types: booleans, signed and unsigned integers,
-floating point values, strings, and enumerations.
-The syntax is similar to C:
-
-```fidl
-const bool enabled_flag = true;
-const int8 offset = -33;
-const uint16 answer = 42;
-const uint32 population_2018 = 7700000000;
-const uint64 diamond = 0x183c7effff7e3c18;
-const uint64 fuchsia = 4054509061583223046;
-const string username = "squeenze";
-const float32 min_temp = -273.15;
-const float64 conversion_factor = 1.41421358;
-const Beverage my_drink = WATER;
-```
-
-These declarations introduce a name within their scope.
-The constant's type must be either a primitive or an enum.
-
-Constant expressions are either literals or the names of other
-constant expressions.
-
-> For greater clarity, there is no expression processing in FIDL; that is,
-> you *cannot* declare a constant as having the value `6 + 5`, for
-> example.
-
-#### Declaration Separator
-
-FIDL uses the semi-colon **';'** to separate adjacent declarations within the
-file, much like C.
-
-### Libraries
-
-Libraries are named containers of FIDL declarations.
-
-Each library has a name consisting of a single identifier (e.g., "objects"),
-or multiple identifiers separated by dots (e.g., "mozart.composition").
-Library names are used in [Qualified Identifiers](#qualified-identifiers).
-
-```fidl
-// library identifier separated by dots
-library mozart.composition;
-
-// "using" to import library "mozart.buffers"
-using mozart.buffers;
-
-// "using" to import library "mozart.geometry" and create a shortform called "geo"
-using mozart.geometry as geo;
-
-```
-
-Libraries may declare that they use other libraries with a "using" declaration.
-This allows the library to refer to symbols defined in other libraries upon which
-they depend. Symbols which are imported this way may be accessed by:
-
-*   qualifying them with the fully qualified library name (as in _"mozart.geometry.Rect"_),
-*   specifying just the library name (as in _"geometry.Rect"_), or,
-*   using a library alias (as in _"geo.Rect"_).
-
-In the source tree, each library consists of a directory with some number of
-**.fidl** files. The name of the directory is irrelevant to the FIDL compiler
-but by convention it should resemble the library name itself. A directory should
-not contain FIDL files for more than one library.
-
-The scope of "library" and "using" declarations is limited to a single file.
-Each individual file within a FIDL library must restate the "library"
-declaration together with any "using" declarations needed by that file.
-
-The library's name may be used by certain language bindings to provide scoping
-for symbols emitted by the code generator.
-
-For example, the C++ bindings generator places declarations for the
-FIDL library "fuchsia.ui" within the C++ namespace
-"fuchsia::ui". Similarly, for languages such as Dart and Rust which
-have their own module system, each FIDL library is compiled as a
-module for that language.
-
-### Types and Type Declarations
-
-#### Primitives
-
-*   Simple value types.
-*   Not nullable.
-
-The following primitive types are supported:
-
-*    Boolean                 **`bool`**
-*    Signed integer          **`int8 int16 int32 int64`**
-*    Unsigned integer        **`uint8 uint16 uint32 uint64`**
-*    IEEE 754 Floating-point **`float32 float64`**
-
-Numbers are suffixed with their size in bits, **`bool`** is 1
-byte.
-
-##### Use
-
-```fidl
-// A record which contains fields of a few primitive types.
-struct Sprite {
-    float32 x;
-    float32 y;
-    uint32 index;
-    uint32 color;
-    bool visible;
-};
-```
-
-#### Enums
-
-*   Proper enumerated types.
-*   Discrete subset of named values chosen from an underlying integer primitive
-    type.
-*   Not nullable.
-*   Enums must have at least one member.
-
-##### Declaration
-
-The ordinal index is **required** for each enum element. The underlying type of
-an enum must be one of: **int8, uint8, int16, uint16, int32, uint32, int64,
-uint64**. If omitted, the underlying type is assumed to be **uint32**.
-
-```fidl
-// An enum declared at library scope.
-enum Beverage : uint8 {
-    WATER = 0;
-    COFFEE = 1;
-    TEA = 2;
-    WHISKEY = 3;
-};
-
-// An enum declared at library scope.
-// Underlying type is assumed to be uint32.
-enum Vessel {
-    CUP = 0;
-    BOWL = 1;
-    TUREEN = 2;
-    JUG = 3;
-};
-```
-
-##### Use
-
-Enum types are denoted by their identifier, which may be qualified if needed.
-
-```fidl
-// A record which contains two enum fields.
-struct Order {
-    Beverage beverage;
-    Vessel vessel;
-};
-```
-
-#### Arrays
-
-*   Fixed-length sequences of homogeneous elements.
-*   Elements can be of any type including: primitives, enums, arrays, strings,
-    vectors, handles, structs, tables, unions.
-*   Not nullable themselves; may contain nullable types.
-
-##### Use
-
-Arrays are denoted **`array<T>:n`** where _T_ can
-be any FIDL type (including an array) and _n_ is a positive
-integer constant expression which specifies the number of elements in
-the array.
-
-```fidl
-// A record which contains some arrays.
-struct Record {
-    // array of exactly 16 floating point numbers
-    array<float32>:16 matrix;
-
-    // array of exactly 10 arrays of 4 strings each
-    array<array<string>:4>:10 form;
-};
-```
-
-#### Strings
-
-*   Variable-length sequence of UTF-8 encoded characters representing text.
-*   Nullable; null strings and empty strings are distinct.
-*   Can specify a maximum size, eg. **`string:40`** for a
-    maximum 40 byte string.
-
-##### Use
-
-Strings are denoted as follows:
-
-*   **`string`** : non-nullable string (validation error
-    occurs if null is encountered)
-*   **`string?`** : nullable string
-*   **`string:N, string:N?`** : string, and nullable string, respectively,
-    with maximum length of _N_ bytes
-
-```fidl
-// A record which contains some strings.
-struct Record {
-    // title string, maximum of 40 bytes long
-    string:40 title;
-
-    // description string, may be null, no upper bound on size
-    string? description;
-};
-```
-
-> Strings should not be used to pass arbitrary binary data since bindings enforce
-> valid UTF-8. Instead, consider `vector<uint8>` for small data or
-> [`fuchsia.mem.Buffer`](../../../api/fidl.md#consider-using-fuchsia_mem_buffer)
-> for blobs. See
-> [Should I use string or vector?](../../../api/fidl.md#should-i-use-string-or-vector)
-> for details.
-
-#### Vectors
-
-*   Variable-length sequence of homogeneous elements.
-*   Nullable; null vectors and empty vectors are distinct.
-*   Can specify a maximum size, eg. **`vector<T>:40`** for a
-    maximum 40 element vector.
-*   There is no special case for vectors of bools. Each bool element takes one
-    byte as usual.
-
-##### Use
-
-Vectors are denoted as follows:
-
-*   **`vector<T>`** : non-nullable vector of element type
-    _T_ (validation error occurs if null is encountered)
-*   **`vector<T>?`** : nullable vector of element type
-    _T_
-*   **`vector<T>:N, vector<T>:N?`** : vector, and nullable vector, respectively,
-    with maximum length of _N_ elements
-
-_T_ can be any FIDL type.
-
-```fidl
-// A record which contains some vectors.
-struct Record {
-    // a vector of up to 10 integers
-    vector<int32>:10 params;
-
-    // a vector of bytes, no upper bound on size
-    vector<uint8> blob;
-
-    // a nullable vector of up to 24 strings
-    vector<string>:24? nullable_vector_of_strings;
-
-    // a vector of nullable strings, no upper bound on size
-    vector<string?> vector_of_nullable_strings;
-
-    // a vector of vectors of 16-element arrays of floating point numbers
-    vector<vector<array<float32>:16>> complex;
-};
-```
-
-#### Handles
-
-*   Transfers a Zircon capability by handle value.
-*   Stored as a 32-bit unsigned integer.
-*   Nullable by encoding as a zero-valued handle.
-
-##### Use
-
-Handles are denoted:
-
-*   **`handle`** : non-nullable Zircon handle of
-    unspecified type
-*   **`handle?`** : nullable Zircon handle of
-    unspecified type
-*   **`handle<H>`** : non-nullable Zircon handle
-    of type _H_
-*   **`handle<H>?`** : nullable Zircon handle of
-    type _H_
-
-_H_ can be one of: `channel, event, eventpair, fifo, job,
-process, port, resource, socket, thread, vmo`. New types will
-be added to the FIDL language as they are added to Zircon.
-
-```fidl
-// A record which contains some handles.
-struct Record {
-    // a handle of unspecified type
-    handle h;
-
-    // an optional channel
-    handle<channel>? c;
-};
-```
-
-#### Structs
-
-*   Record type consisting of a sequence of typed fields.
-*   Declaration is not intended to be modified once deployed; use interface
-    extension instead.
-*   Reference may be nullable.
-*   Structs contain zero or more members.
-
-##### Declaration
-
-```fidl
-struct Point {
-    float32 x;
-    float32 y;
-};
-struct Color {
-    float32 r;
-    float32 g;
-    float32 b;
-};
-```
-
-#### Use
-
-Structs are denoted by their declared name (eg. **Circle**) and nullability:
-
-*   **`Circle`** : non-nullable Circle
-*   **`Circle?`** : nullable Circle
-
-```fidl
-struct Circle {
-    bool filled;
-    Point center;    // Point will be stored in-line
-    float32 radius;
-    Color? color;    // Color will be stored out-of-line
-    bool dashed;
-};
-```
-
-#### Tables
-
-*   Record type consisting of a sequence of typed fields with ordinals.
-*   Declaration is intended for forward and backward compatibility in the face of schema changes.
-*   Reference may be nullable.
-*   Tables contain zero or more members.
-
-##### Declaration
-
-```fidl
-table Profile {
-    1: vector<string> locales;
-    2: vector<string> calendars;
-    3: vector<string> time_zones;
-};
-```
-
-#### Use
-
-Tables are denoted by their declared name (eg. **Profile**) and nullability:
-
-*   **`Profile`** : non-nullable Profile
-*   **`Profile?`** : nullable Profile
-
-Here, we show how `Profile` evolves to also carry temperature units.
-A client aware of the previous definition of `Profile` (without temperature units)
-can still send its profile to a server which has been updated to handle the larger
-set of fields.
-
-```fidl
-enum TemperatureUnit {
-    CELSIUS = 1;
-    FAHRENHEIT = 2;
-};
-
-table Profile {
-    1: vector<string> locales;
-    2: vector<string> calendars;
-    3: vector<string> time_zones;
-    4: TemperatureUnit temperature_unit;
-};
-```
-
-#### Unions
-
-*   Tagged option type consisting of tag field and variadic contents.
-*   Declaration is not intended to be modified once deployed; use interface
-    extension instead.
-*   Reference may be nullable.
-*   Unions contain one or more members. A union with no members would have
-    no inhabitants and thus would make little sense in a wire format.
-
-##### Declaration
-
-```fidl
-union Pattern {
-    Color color;        // the Pattern contains either a Color
-    Texture texture;    // or a Texture, but not both at the same time
-};
-struct Color {
-    float32 r;
-    float32 g;
-    float32 b;
-};
-struct Texture { string name; };
-```
-
-##### Use
-
-Union are denoted by their declared name (eg. **Pattern**) and nullability:
-
-*   **`Pattern`** : non-nullable Shape
-*   **`Pattern?`** : nullable Shape
-
-```fidl
-struct Paint {
-    Pattern fg;
-    Pattern? bg;
-};
-```
-
-#### Interfaces
-
-*   Describe methods which can be invoked by sending messages over a channel.
-*   Methods are identified by their ordinal index. Ordinals must be stated
-    explicitly to reduce the chance that developers might break interfaces by
-    reordering methods and to help with interface extension and derivation.
-    *   Method ordinals are unsigned values in the range **0x00000001** to
-        **0x7fffffff**.
-    *   The FIDL wire format internally represents ordinals as 32-bit values but
-        reserves the range **0x80000000** to **0xffffffff** for protocol control
-        messages, so these values cannot be associated with methods.
-*   Each method declaration states its arguments and results.
-    *   If no results are declared, then the method is one-way: no response will
-        be generated by the server.
-    *   If results are declared (even if empty), then the method is two-way:
-        each invocation of the method generates a response from the server.
-    *   If only results are declared, the method is referred to as an
-        *event*. It then defines an unsolicited message from the server.
-
-*   When a server of an interface is about to close its side of the channel, it
-    may elect to send an **epitaph** message to the client to indicate the
-    disposition of the connection. The epitaph must be the last message
-    delivered through the channel. An epitaph message includes a 32-bit int
-    value of type **zx_status_t**.  Negative values are reserved for system
-    error codes.  Positive values are reserved for application errors.  A status
-    of ZX_OK indicates successful operation.
-
-*   **Interface extension:** New methods can be added to existing interfaces as
-    long as they do not collide with existing methods.
-*   **Interface derivation:** New interfaces can be derived from any number of
-    existing interfaces as long as none of their methods use the same ordinals.
-    (This is purely a FIDL language feature, does not affect the wire format.)
-
-##### Declaration
-
-```fidl
-interface Calculator {
-    1: Add(int32 a, int32 b) -> (int32 sum);
-    2: Divide(int32 dividend, int32 divisor)
-    -> (int32 quotient, int32 remainder);
-    3: Clear();
-    4: -> OnClear();
-};
-
-interface RealCalculator : Calculator {
-    1001: AddFloats(float32 a, float32 b) -> (float32 sum);
-};
-
-interface Science {
-    2001: Hypothesize();
-    2002: Investigate();
-    2003: Explode();
-    2004: Reproduce();
-};
-
-interface ScientificCalculator : RealCalculator, Science {
-    3001: Sin(float32 x) -> (float32 result);
-};
-```
-
-##### Use
-
-Interfaces are denoted by their name, directionality of the channel, and
-optionality:
-
-*   **`Interface`** : non-nullable FIDL interface (client
-    endpoint of channel)
-*   **`Interface?`** : nullable FIDL interface (client
-    endpoint of channel)
-*   **`request<Interface>`** : non-nullable FIDL interface
-    request (server endpoint of channel)
-*   **`request<Interface>?`** : nullable FIDL interface request
-    (server endpoint of channel)
-
-```fidl
-// A record which contains interface-bound channels.
-struct Record {
-    // client endpoint of a channel bound to the Calculator interface
-    Calculator c;
-
-    // server endpoint of a channel bound to the Science interface
-    request<Science> s;
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-    // optional client endpoint of a channel bound to the
-    // RealCalculator interface
-    RealCalculator? r;
-};
-```
diff --git a/development/languages/fidl/reference/wire-format/index.md b/development/languages/fidl/reference/wire-format/index.md
index 6c958f6..225b97b 100644
--- a/development/languages/fidl/reference/wire-format/index.md
+++ b/development/languages/fidl/reference/wire-format/index.md
@@ -1,919 +1,7 @@
-# Wire Format Specification
+# Obsolete
 
-This document is a specification of the Fuchsia Interface Definition Language
-(FIDL) data structure encoding.
-
-See [Overview](../README.md) for more information about FIDL's overall
-purpose, goals, and requirements, as well as links to related documents.
-
-[TOC]
-
-## Design
-
-### Goals
-
-*   Efficiently transfer messages between processes.
-*   General purpose, for use with device drivers, high-level services, and
-    applications.
-*   Optimized for Zircon IPC only; portability is not a goal.
-*   Optimized for direct memory access; inter-machine transport is not a goal.
-*   Optimized for 64-bit only; no accommodation for 32-bit environments.
-*   Uses uncompressed native data types with host-endianness and correct
-    alignment to support in-place access of message contents.
-*   Compatible with C structure in-memory layout (with suitable field ordering
-    and packing annotations).
-*   Structures are fixed size and inlined; variable-sized data is stored
-    out-of-line.
-*   Structures are not self-described; FIDL files describe their contents.
-*   No versioning of structures, but interfaces can be extended with new methods
-    for protocol evolution.
-*   No offset calculations required, very little arithmetic which may overflow.
-*   Support fast single-pass encoding and validation (as a combined operation).
-*   Support fast single-pass decoding and validation (as a combined operation).
-
-### Messages
-
-A **message** is a contiguous data structure represented using the FIDL Wire
-Format, consisting of a single **in-line primary object** followed by a sequence
-of **out-of-line secondary objects** stored in **traversal order**.
-
-#### Objects
-
-Messages are aggregates of **objects**.
-
-The **primary object** of a message is simply the first object it contains. It
-is always a **struct** of fixed size whose type (and size) is known from the
-context (such as by examining the **method ordinal** in the **interface call
-header**).
-
-To store variable-size or optional data, the primary object may refer to
-**secondary objects**, such as string content, vector content, structs, and
-unions. Secondary objects are stored **out-of-line** sequentially in traversal
-order following the object which reference them. In encoded messages, the
-presence of secondary objects is marked by a flag. In decoded messages, the
-flags are substituted with pointers to their location in memory (or null
-pointers when absent).
-
-Primary and secondary objects are 8-byte aligned and stored sequentially in
-traversal order without gaps other than the minimum required padding to maintain
-object alignment.
-
-Objects may also contain **in-line objects** which are aggregated within the
-body of the containing object, such as embedded structs and fixed-size arrays of
-structs. The alignment factor of in-line objects is determined by the alignment
-factor of their most restrictive member.
-
-In the following example, each Rect structure contains two Point objects which
-are stored in-line whereas each Region structure contains a vector with a
-variable number of Rect objects which are stored sequentially out-of-line. In
-this case, the secondary object is the vector's content (as a unit).
-
-```fidl
-struct Region {
-    vector<Rect> rects;
-};
-struct Rect {
-    Point top_left;
-    Point bottom_right;
-};
-struct Point { uint32 x, y; };
-```
-
-![drawing](objects.png)
-
-#### Traversal Order
-
-The **traversal order** of a message is a determined by a recursive depth-first
-walk of all of the **objects** it contains, as obtained by following the chain
-of references.
-
-Given the following structure:
-
-```fidl
-struct Cart {
-    vector<Item> items;
-};
-struct Item {
-    Product product;
-    uint32 quantity;
-};
-struct Product {
-    string sku;
-    string name;
-    string? description;
-    uint32 price;
-};
-```
-
-The depth-first traversal order for a Cart message is defined by the following
-pseudo-code:
-
-```
-visit Cart:
-    for each Item in Cart.items vector data:
-        visit Item.product:
-            visit Product.sku
-            visit Product.name
-            visit Product.description
-            visit Product.price
-        visit Item.quantity
-```
-
-#### Dual Forms
-
-The same message content can be expressed in two forms -- **encoded** and
-**decoded** -- which have the same size and overall layout but differ in terms
-of their representation of pointers (memory addresses) or handles
-(capabilities).
-
-FIDL is designed such that **encoding** and **decoding** of messages can occur
-in place in memory assuming that objects have been stored in traversal order.
-
-The representation of encoded messages is unambiguous. There is exactly one
-possible encoding for all messages of the same type with the same content.
-
-![drawing](dual-forms.png)
-
-#### Encoded Messages
-
-An **encoded message** has been prepared for transfer to another process: it
-does not contain pointers (memory addresses) or handles (capabilities).
-
-During **encoding**…
-
-*   all pointers to sub-objects within the message are replaced with flags which
-    indicate whether their referent is present or not-present in traversal order
-*   all handles within the message are extracted to an associated **handle
-    vector** and replaced with flags which indicate whether their referent is
-    present or not-present in traversal order
-
-The resulting **encoding message** and **handle vector** can then be sent to
-another process using **zx_channel_call()** or a similar IPC mechanism.
-
-#### Decoded Messages
-
-A **decoded message** has been prepared for use within a process's address
-space: it may contain pointers (memory addresses) or handles (capabilities).
-
-During **decoding**...
-
-*   all pointers to sub-objects within the message are reconstructed using the
-    encoded present / not-present flags in traversal order
-*   all handles within the message are restored from the associated **handle
-    vector** using the encoded present / not-present flags in traversal order
-
-The resulting **decoded message** is ready to be consumed directly from memory.
-
-## Data Types
-
-### Primitives
-
-*   Value stored in native machine format.
-*   Packed with natural alignment.
-    *   Each _m_-byte primitive is stored on an _m_-byte boundary.
-*   Not nullable.
-
-The following primitive types are supported:
-
-Category                | Types
------------------------ | ----------------------------
-Boolean                 | `bool`
-Signed integer          | `int8 int16 int32 int64`
-Unsigned integer        | `uint8 uint16 uint32 uint64`
-IEEE 754 Floating-point | `float32 float64`
-
-Number types are suffixed with their size in bits, `bool` is 1 byte.
-
-### Enums
-
-*   Primitive value representing a proper enumerated type; bit fields are not
-    valid enums.
-*   Stored directly using their underlying primitive type.
-*   Not nullable.
-
-From the perspective of the wire format, enums are just fancy names for
-primitive types.
-
-For example, an enum whose underlying type is
-`int32` is stored in exactly the same way as any
-ordinary C `int32_t` would be.
-
-### Arrays
-
-*   Fixed length sequence of homogeneous elements.
-*   Packed with natural alignment of their elements.
-    *   Alignment of array is the same as the alignment of its elements.
-    *   Each subsequent element is aligned on element's alignment boundary.
-*   The stride of the array is exactly equal to the size of the element (which
-    includes the padding required to satisfy element alignment constraints).
-*   Not nullable.
-*   There is no special case for arrays of bools. Each bool element takes one
-    byte as usual.
-
-Arrays are denoted:
-
-*   `array<T>:n`: where *T* can be any FIDL type
-    (including an array) and *n* is the number of elements in the array.
-
-![drawing](arrays.png)
-
-### Strings
-
-*   Variable-length sequence of UTF-8 encoded characters representing text.
-*   Nullable; null strings and empty strings are distinct.
-*   Can specify a maximum size, e.g. `string:40` for
-    a maximum 40 byte string.
-*   String content does not have a null-terminator.[^1]
-
-*   Stored as a 16 byte record consisting of:
-
-    *   `size` : 64-bit unsigned number of code
-        units (bytes)
-    *   `data` : 64-bit presence indication or
-        pointer to out-of-line string data
-
-*   When encoded for transfer, `data` indicates
-    presence of content:
-
-    *   `0` : string is null
-    *   `UINTPTR_MAX` : string is non-null, data is
-        the next out-of-line object
-
-*   When decoded for consumption, `data` is a
-    pointer to content.
-
-    *   `0` : string is null
-    *   `<valid pointer>` : string is non-null, data
-        is at indicated memory address
-
-Strings are denoted as follows:
-
-*   `string` : non-nullable string (validation error
-    occurs if null `data` is encountered)
-*   `string?` : nullable string
-*   `string:N, string:N?` : string with maximum
-    length of <em>N</em> bytes
-
-![drawing](strings.png)
-
-### Vectors
-
-*   Variable-length sequence of homogeneous elements.
-*   Nullable; null vectors and empty vectors are distinct.
-*   Can specify a maximum size, e.g. `vector<T>:40`
-    for a maximum 40 element vector.
-*   Stored as a 16 byte record consisting of:
-    *   `size` : 64-bit unsigned number of elements
-    *   `data` : 64-bit presence indication or
-        pointer to out-of-line element data
-*   When encoded for transfer, `data` indicates
-    presence of content:
-    *   `0` : vector is null
-    *   `UINTPTR_MAX` : vector is non-null, data is
-        the next out-of-line object
-*   When decoded for consumption, `data` is a
-    pointer to content.
-    *   `0` : vector is null
-    *   `<valid pointer>` : vector is non-null, data
-        is at indicated memory address
-*   There is no special case for vectors of bools. Each bool element takes one
-    byte as usual.
-
-Vectors are denoted as follows:
-
-*   `vector<T>` : non-nullable vector of element
-    type <em>T</em> (validation error occurs if null
-    `data` is encountered)
-*   `vector<T>?` : nullable vector of element type
-    <em>T</em>
-*   `vector<T>:N, vector<T>:N?` : vector with
-    maximum length of <em>N</em> elements
-
-<em>T</em> can be any FIDL type.
-
-![drawing](vectors.png)
-
-### Handles
-
-*   Transfers a Zircon capability by handle value.
-*   Stored as a 32-bit unsigned integer.
-*   Nullable by encoding as a zero-valued[^2] handle (equivalent to
-    `ZX_HANDLE_INVALID`).
-
-*   When encoded for transfer, the stored integer indicates presence of handle:
-
-    *   `0` : handle is null
-    *   `UINT32_MAX` : handle is non-null, handle
-        value is the next entry in handle table
-
-*   When decoded for consumption, the stored integer is handle value itself.
-
-    *   `0` : handle is null
-    *   `<valid handle>` : handle is non-null,
-        handle value is provided in-line
-
-Handles are denoted:
-
-*   `handle` : non-nullable Zircon handle of
-    unspecified type
-*   `handle?` : nullable Zircon handle of
-    unspecified type
-*   `handle<H>` : non-nullable Zircon handle of type
-    <em>H</em>
-*   `handle<H>?` : nullable Zircon handle of type
-    <em>H</em>
-*   `Interface` : non-nullable FIDL interface
-    (client endpoint of channel)
-*   `Interface?` : nullable FIDL interface (client
-    endpoint of channel)
-*   `request<Interface>` : non-nullable FIDL interface
-    request (server endpoint of channel)
-*   `request<Interface>?` : nullable FIDL interface request
-    (server endpoint of channel)
-
-<em>H</em> can be one of[^3]: `channel, event, eventpair, fifo,
-job, process, port, resource, socket, thread, vmo`
-
-### Structs
-
-*   Record type consisting of a sequence of typed fields.
-
-*   Alignment factor of structure is defined by maximal alignment factor of any
-    of its fields.
-
-*   Structure is padded with zeroes so that its size is a multiple of its
-    alignment factor.
-
-    *   e.g. 1. a struct with an **int32** and an **int8** field has an
-        alignment of 4 bytes (due to **int32**) and a size of 8 bytes (3 bytes
-        of padding)
-    *   e.g. 2. a struct with a **bool** and a **string** field has an alignment
-        of 8 bytes (due to **string**) and a size of 24 bytes (7 bytes of
-        padding)
-    *   e.g. 3. a struct with a **bool** and a **uint8[2]** field has an
-        alignment of 1 byte and a size of 3 bytes (no padding!)
-
-*   In general, changing the definition of a struct will break binary
-    compatibility; instead prefer to extend interfaces by adding new methods
-    which use new structs.
-
-*   A struct with no fields (an "empty" struct) has a size of 1 and an alignment
-    of 1.
-
-    *   An empty struct is exactly equivalent to a struct with a single
-        **uint8** field that contains a value of zero.
-
-Storage of a structure depends on whether it is nullable at point of reference.
-
-*   Non-nullable structures:
-    *   Contents are stored in-line within their containing type, enabling very
-        efficient aggregate structures to be constructed.
-    *   The structure layout does not change when inlined; its fields are not
-        repacked to fill gaps in its container.
-*   Nullable structures:
-    *   Contents are stored out-of-line and accessed through an indirect
-        reference.
-    *   When encoded for transfer, stored reference indicates presence of
-        structure:
-        *   `0` : reference is null
-        *   `UINTPTR_MAX` : reference is non-null,
-            structure content is the next out-of-line object
-    *   When decoded for consumption, stored reference is a pointer.
-        *   `0` : reference is null
-        *   `<valid pointer>` : reference is
-            non-null, structure content is at indicated memory address
-
-Structs are denoted by their declared name (e.g. <strong>Circle</strong>) and
-nullability:
-
-*   `Circle` : non-nullable Circle
-*   `Circle?` : nullable Circle
-
-The following example shows how structs are laid out according to their fields.
-
-```fidl
-struct Circle {
-    bool filled;
-    Point center;    // Point will be stored in-line
-    float32 radius;
-    Color? color;    // Color will be stored out-of-line
-    bool dashed;
-};
-struct Point { float32 x, y; };
-struct Color { float32 r, g, b; };
-```
-
-The Color content is padded to the 8 byte secondary object alignment
-boundary.
-
-![drawing](structs.png)
-
-### Unions
-
-*   Tagged option type consisting of tag field and variadic contents.
-*   Tag field is represented with a **uint32 enum**.
-*   Size of union is the size of the tag field plus the size of the largest
-    option including padding necessary to satisfy its alignment requirements.
-*   Alignment factor of union is defined by the maximal alignment factor of the
-    tag field and any of its options.
-*   Union is padded so that its size is a multiple of its alignment factor.
-    *   e.g. 1. a union with an **int32** and an **int8** option has an
-        alignment of 4 bytes (due to **int32**) and a size of 8 bytes including
-        the 4 byte tag (0 to 3 bytes of padding).
-    *   e.g. 2. a union with a **bool** and a **string** option has an alignment
-        of 8 bytes (due to **string**) and a size of 24 bytes (4 to 19 bytes of
-        padding).
-*   In general, changing the definition of a union will break binary
-    compatibility; instead prefer to extend interfaces by adding new methods
-    which use new unions.
-
-Storage of a union depends on whether it is nullable at point of reference.
-
-*   Non-nullable unions:
-    *   Contents are stored in-line within their containing type, enabling very
-        efficient aggregate structures to be constructed.
-    *   The union layout does not change when inlined; its options are not
-        repacked to fill gaps in its container.
-*   Nullable unions:
-    *   Contents are stored out-of-line and accessed through an indirect
-        reference.
-    *   When encoded for transfer, stored reference indicates presence of union:
-        *   `0` : reference is null
-        *   `UINTPTR_MAX` : reference is non-null,
-            union content is the next out-of-line object
-    *   When decoded for consumption, stored reference is a pointer.
-        *   `0` : reference is null
-        *   `<valid pointer>` : reference is
-            non-null, union content is at indicated memory address
-
-Union are denoted by their declared name (e.g. <strong>Pattern</strong>) and
-nullability:
-
-*   `Pattern` : non-nullable Shape
-*   `Pattern?` : nullable Shape
-
-The following example shows how unions are laid out according to their options.
-
-```fidl
-struct Paint {
-    Pattern fg;
-    Pattern? bg;
-};
-union Pattern {
-    Color color;
-    Texture texture;
-};
-struct Color { float32 r, g, b; };
-struct Texture { string name; };
-```
-
-When laying out **Pattern**, space is first allotted to the tag (4 bytes) then
-to the selected option.
-
-![drawing](unions.png)
-
-### Transactional Messages
-
-*   Transactions consist of sequences of correlated messages sent between the
-    client and implementation of an interface over a Zircon channel.
-*   Each message is prefixed with a simple 16 byte header, the body immediately
-    follows header.
-    *   `zx_txid_t txid`, transaction ID (32 bits)
-        * txids with the high bit set are reserved for use by zx_channel_call
-        * txids with the high bit unset are reserved for use by userspace
-        * See the [channel call] manpage for more details on txid allocation
-    *   `uint32 reserved0`, reserved for future use.
-    *   `uint32 flags`, all unused bits must be set to zero
-    *   `uint32 ordinal`
-        *   The zero ordinal is invalid.
-        *   Ordinals with the most significant bit set are reserved.
-            *   Ordinals 0x80001xxx are "control" messages
-            *   Ordinals 0x80002xxx are "fileio" messages
-*   A non-zero transaction ID is used to correlate sequences of messages which
-    involve a request and a response, e.g. in a two-way method call. The
-    initiator of the request is responsible for assigning a unique transaction
-    ID to the request. The handler of the request is responsible for echoing the
-    transaction ID it received back into the response which it sends. The
-    initiator can reuse transaction IDs once it receives their corresponding
-    responses.
-*   A zero transaction ID is reserved for messages which do not require a
-    response from the other side, e.g. one-way calls or system messages.
-*   There are three kinds of messages: method calls, method results, and control
-    messages.
-*   Ordinals indicate the purpose of the message.
-    *   Ordinals with the most significant bit set are reserved for control
-        messages and future expansion.
-    *   Ordinals without the most significant bit set indicate method calls and
-        responses.
-*   Flags control the interpretation of the message. All unused bits must be set
-    to zero.
-    *   Currently there are no flags, so all bits must be zero.
-
-Messages which are sent directly through Zircon channels have a maximum total
-size (header + body) which is defined by the kernel <em>(currently 64 KB,
-eventual intent may be 16 KB).</em>
-
-It is possible to extend interfaces by declaring additional methods with unique
-ordinals. The language also supports creating derived interfaces provided the
-method ordinals remain unique down the hierarchy. Interface derivation is purely
-syntactic; it does not affect the wire format).
-
-We'll use the following interface for the next few examples.
-
-```fidl
-    interface Calculator {
-        1: Add(int32 a, int32 b) -> (int32 sum);
-        2: Divide(int32 dividend, int32 divisor)
-        -> (int32 quotient, int32 remainder);
-        3: Clear();
-    };
-```
-
-_FIDL does not provide a mechanism to determine the "version" of an interface;
-interface capabilities must be determined out-of-band such as by querying a
-**ServiceProvider** for an interface "version" by name or by other means._
-
-#### Method Call Messages
-
-The client of an interface sends method call messages to the implementor of the
-interface to invoke methods of that interface.
-
-If a server receives an unknown, unsupported, or unexpected method call message,
-it must close the channel.
-
-The message indicates the method to invoke by means of its ordinal index. The
-body of the message contains the method arguments as if they were packed in a
-**struct**.
-
-![drawing](method-call-messages.png)
-
-#### Method Result Messages
-
-The implementor of an interface sends method result messages to the client of
-the interface to indicate completion of a method invocation and to provide a
-(possibly empty) result.
-
-If a client receives an unknown, unsupported, or unexpected method call message,
-it must close the channel.
-
-Only two-way method calls which are defined to provide a (possibly empty) result
-in the FIDL interface declaration will elicit a method result message. One-way
-method calls must not produce a method result message.
-
-A method result message provides the result associated with a prior method call.
-The body of the message contains the method results as if they were packed in a
-**struct**.
-
-The message result header consists of `uint32 txid, uint32 reserved, uint32
-flags, uint32 ordinal`.  The `txid` must be equal to the `txid` of the method
-call to which this message is a response. The flags must be zero. The `ordinal`
-must be equal to the `ordinal` of the method call to which this message is a
-response.
-
-![drawing](method-result-messages.png)
-
-#### Event Messages
-
-These support sending unsolicited messages from the server back to the client.
-
-```fidl
-interface Calculator {
-    1: Add(int32 a, int32 b) -> (int32 sum);
-    2: Divide(int32 dividend, int32 divisor) -> (int32 quotient, int32 remainder);
-    3: Clear();
-    4: -> Error(uint32 status_code);
-};
-```
-
-The implementor of an interface sends unsolicited event messages to the client
-of the interface to indicate that an asynchronous event occurred as specified by
-the interface declaration.
-
-Events may be used to let the client observe significant state changes without
-having to create an additional channel to receive the response.
-
-In the **Calculator** example, we can imagine that an attempt to divide by zero
-would cause the **Error()** event to be sent with a "divide by zero" status code
-prior to the connection being closed. This allows the client to distinguish
-between the connection being closed due to an error as opposed to for other
-reasons (such as the calculator process terminating abnormally).
-
-The body of the message contains the event arguments as if they were packed in a
-**struct**, just as with method result messages.
-
-![drawing](events.png)
-
-#### Control Messages
-
-Control messages support in-band signaling of events other than method calls and
-responses.
-
-If a client or server receives an unknown, unsupported, or unexpected control
-message, it must _discard it_. This allows for future expansion of control
-messages in the protocol.
-
-The maximum size of a valid control message is **512 bytes**, including the
-header.
-
-##### Epitaph (Control Message Ordinal 0xFFFFFFFF)
-
-An epitaph is a message with ordinal **0xFFFFFFFF**.  A server may send an
-epitaph as the last message prior to closing the connection, to provide an
-indication of why the connection is being closed.  No further messages may be
-sent through the channel after the epitaph.  Epitaphs are not sent from clients
-to servers.
-
-The epitaph contains an error status.  The error status of the epitaph is stored
-in the reserved uint32 of the message header.  The reserved word is treated as
-being of type **zx_status_t**: negative numbers are reserved for system error
-codes, positive numbers are reserved for application error codes, and ZX_OK is
-used to indicate normal connection closure.  The message is otherwise empty.
-
-## Details
-
-#### Size and Alignment
-
-`sizeof(T)` denotes the size in bytes for an object
-of type T.
-
-`alignof(T)` denotes the alignment factor in bytes
-to store an object of type T.
-
-FIDL primitive types are stored at offsets in the message which are a multiple
-of their size in bytes. Thus for primitives T_,_ `alignof(T) ==
-sizeof(T)`. This is called <em>natural alignment</em>. It has the
-nice property of satisfying typical alignment requirements of modern CPU
-architectures.
-
-FIDL complex types, such as structs and arrays, are stored at offsets in the
-message which are a multiple of the maximum alignment factor of any of their
-fields. Thus for complex types T, `alignof(T) ==
-max(alignof(F:T))` over all fields F in T. It has the nice
-property of satisfying typical C structure packing requirements (which can be
-enforced using packing attributes in the generated code). The size of a complex
-type is the total number of bytes needed to store its members properly aligned
-plus padding up to the type's alignment factor.
-
-FIDL primary and secondary objects are aligned at 8-byte offsets within the
-message, regardless of their contents. The primary object of a FIDL message
-starts at offset 0. Secondary objects, which are the only possible referent of
-pointers within the message, always start at offsets which are a multiple of 8.
-(So all pointers within the message point at offsets which are a multiple of 8.)
-
-FIDL in-line objects (complex types embedded within primary or secondary
-objects) are aligned according to their type. They are not forced to 8 byte
-alignment.
-
-<table>
-  <tr>
-   <td><strong>types</strong>
-   </td>
-   <td><strong>sizeof(T)</strong>
-   </td>
-   <td><strong>alignof(T)</strong>
-   </td>
-  </tr>
-  <tr>
-   <td>bool
-   </td>
-   <td>1
-   </td>
-   <td>1
-   </td>
-  </tr>
-  <tr>
-   <td>int8, uint8
-   </td>
-   <td>1
-   </td>
-   <td>1
-   </td>
-  </tr>
-  <tr>
-   <td>int16, uint16
-   </td>
-   <td>2
-   </td>
-   <td>2
-   </td>
-  </tr>
-  <tr>
-   <td>int32, uint32
-   </td>
-   <td>4
-   </td>
-   <td>4
-   </td>
-  </tr>
-  <tr>
-   <td>float32
-   </td>
-   <td>4
-   </td>
-   <td>4
-   </td>
-  </tr>
-  <tr>
-   <td>int64, uint64
-   </td>
-   <td>8
-   </td>
-   <td>8
-   </td>
-  </tr>
-  <tr>
-   <td>float64
-   </td>
-   <td>8
-   </td>
-   <td>8
-   </td>
-  </tr>
-  <tr>
-   <td>enum
-   </td>
-   <td>sizeof(underlying type)
-   </td>
-   <td>alignof(underlying type)
-   </td>
-  </tr>
-  <tr>
-   <td>array<T>:n
-   </td>
-   <td>sizeof(T) * n
-   </td>
-   <td>alignof(T)
-   </td>
-  </tr>
-  <tr>
-   <td>string, string?, string:N, string:N?
-   </td>
-   <td>16
-   </td>
-   <td>8
-   </td>
-  </tr>
-  <tr>
-   <td>vector<T>, vector<T>?,
-<p>
-vector<T>:N,
-<p>
-vector<T>:N?
-   </td>
-   <td>16
-   </td>
-   <td>8
-   </td>
-  </tr>
-  <tr>
-   <td>handle, handle?, handle<H>, handle<H>?,
-<p>
-Interface, Interface?, request<Interface>, request<Interface>?
-   </td>
-   <td>4
-   </td>
-   <td>4
-   </td>
-  </tr>
-  <tr>
-   <td>struct T
-   </td>
-   <td>sum of field sizes and padding for alignment
-   </td>
-   <td>maximum alignment factor among all fields
-   </td>
-  </tr>
-  <tr>
-   <td>struct T?
-   </td>
-   <td>8
-   </td>
-   <td>8
-   </td>
-  </tr>
-  <tr>
-   <td>union T
-   </td>
-   <td>maximum of field sizes and padding for alignment
-   </td>
-   <td>maximum alignment factor among all fields
-   </td>
-  </tr>
-  <tr>
-   <td>union T?
-   </td>
-   <td>8
-   </td>
-   <td>8
-   </td>
-  </tr>
-  <tr>
-   <td>message header
-   </td>
-   <td>16
-   </td>
-   <td>16
-   </td>
-  </tr>
-</table>
-
-#### Padding
-
-The creator of a message must fill all alignment padding gaps with zeros.
-
-The consumer of a message may verify that padding contains zeroes (and generate
-an error if not) but it is not required to check as long as it does not actually
-read the padding bytes.
-
-#### Maximum Recursion Depth
-
-FIDL arrays, vectors, structures, and unions enable the construction of
-recursive messages. Left unchecked, processing excessively deep messages could
-lead to resource exhaustion of the consumer.
-
-For safety, the maximum recursion depth for all FIDL messages is limited to
-**32** levels of nested complex objects. The FIDL validator **must** enforce
-this by keeping track of the current nesting level during message validation.
-
-Complex objects are arrays, vectors, structures, or unions which contain
-pointers or handles which require fix-up. These are precisely the kinds of
-objects for which **encoding tables** must be generated. See [C
-Language Bindings](../../languages/c.md)
-for information about encoding
-tables. Therefore limiting the nesting depth of complex objects has the effect
-of limiting the recursion depth for traversal of encoding tables.
-
-Formal definition:
-
-*   The message body is defined to be at nesting level **0**.
-*   Each time the validator encounters a complex object, it increments the
-    nesting level, recursively validates the object, then decrements the nesting
-    level.
-*   If at any time the nesting level exceeds **31**, a validation error is
-    raised and validation terminates.
-
-#### Validation
-
-The purpose of message validation is to discover wire format errors early before
-they have a chance to induce security or stability problems.
-
-Message validation is **required** when decoding messages received from a peer
-to prevent bad data from propagating beyond the service entry point.
-
-Message validation is **optional but recommended** when encoding messages to
-send to a peer to help localize violated integrity constraints.
-
-To minimize runtime overhead, validation should generally be performed as part
-of a single pass message encoding or decoding process such that only a single
-traversal is needed. Since messages are encoded in depth-first traversal order,
-traversal exhibits good memory locality and should therefore be quite efficient.
-
-For simple messages, validation may be very trivial, amounting to no more than a
-few size checks. While programmers are encouraged to rely on their FIDL bindings
-library to validate messages on their behalf, validation can also be done
-manually if needed.
-
-Conformant FIDL bindings must check all of the following integrity constraints:
-
-*   The total size of the message including all of its out-of-line sub-objects
-    exactly equals the total size of the buffer that contains it. All
-    sub-objects are accounted for.
-*   The total number of handles referenced by the message exactly equals the
-    total size of the handle table. All handles are accounted for.
-*   The maximum recursion depth for complex objects is not exceeded.
-*   All enum values fall within their defined range.
-*   All union tag values fall within their defined range.
-*   Encoding only:
-    *   All pointers to sub-objects encountered during traversal refer precisely
-        to the next buffer position where a sub-object is expected to appear. As
-        a corollary, pointers never refer to locations outside of the buffer.
-*   Decoding only:
-    *   All present / not-present flags for referenced sub-objects hold the
-        value **0** or **UINTPTR_MAX**.
-    *   All present / not-present flags for referenced handles hold the value
-        **0** or **UINT32_MAX.**
-
-Stricter FIDL bindings may perform some or all of the following additional
-safety checks:
-
-*   All padding is filled with zeroes.
-*   All floating point values represent valid IEEE 754 bit patterns.
-*   All bools have the value **0** or **1**.
-
-<!-- Footnotes themselves at the bottom. -->
-
-## Notes
-
-[channel call]: https://fuchsia.googlesource.com/zircon/+/master/docs/syscalls/channel_call.md
+This repository used to be the location of the documentation for [the 
+Fuchsia Project](http://fuchsia.googlesource.com).  Fuchsia's 
+documentation can now be found at 
+https://fuchsia.googlesource.com/fuchsia/+/master/docs.
 
-[^1]: Justification for unterminated strings. Since strings can contain embedded
-    null characters, it is safer to encode the size explicitly and to make no
-    guarantees about null-termination, thereby defeating incorrect assumptions
-    that clients might make. Modern APIs generally use sized strings as a
-    security precaution. It's important that data always have one unambiguous
-    interpretation.
-[^2]: Defining the zero handle to mean "there is no handle" makes it is safe to
-    default-initialize wire format structures to all zeroes. Zero is also the
-    value of the `ZX_HANDLE_INVALID` constant.
-[^3]: New handle types can easily be added to the language without affecting the
-    wire format since all handles are transferred the same way.
diff --git a/development/languages/fidl/tutorial/README.md b/development/languages/fidl/tutorial/README.md
index c0c7ddd..225b97b 100644
--- a/development/languages/fidl/tutorial/README.md
+++ b/development/languages/fidl/tutorial/README.md
@@ -1,424 +1,7 @@
+# Obsolete
 
-# FIDL tutorial
-
-_Audience: Beginning to intermediate FIDL developers._
-
-[TOC]
-
-## About this tutorial
-
-In this tutorial, we present a language-independent introduction to FIDL,
-followed by language-specific sections that develop the client
-and server sides of the examples.
-
-# Overview
-
-While "**FIDL**" stands for "Fuchsia Interface Definition Language,"
-the word itself is commonly used to refer to a lot of different things:
-
-*   the infrastructure required for the IPC calls,
-*   the FIDL language,
-*   the FIDL compiler, or
-*   the generated bindings.
-
-This tutorial describes the steps required to create interfaces, make calls, and
-write server code that uses the FIDL interprocess communication (IPC) system in Fuchsia.
-We'll also see an overview of the entire workflow required, for both service writers
-and users (clients).
-
-> Note that the Fuchsia operating system has no innate knowledge of FIDL.
-> The FIDL bindings use a standard channel communication mechanism in Fuchsia.
-> The FIDL bindings and libraries enforce a set of semantic behavior and
-> persistence formats on how that channel is used.
-
-For details on the design and implementation of FIDL, see
-the [main FIDL page](../README.md)
-
-## Example source code
-
-Most examples used in this tutorial are located in Garnet at:
-[//garnet/examples/fidl/](https://fuchsia.googlesource.com/garnet/+/master/examples/fidl/)
-
-Language-specific examples may be found in other directories;
-this is indicated as appropriate.
-
-## FIDL in a nutshell
-
-The main job of FIDL is to allow diverse clients and services to interoperate.
-Client diversity is aided by decoupling the implementation of the
-IPC mechanism from its definition, and is simplified by automatic
-code generation.
-
-The FIDL language provides a familiar (though simplified) C-like declaration
-syntax that allows the service provider to exactly define their interfaces.
-Basic data types, like integers, floats, and strings,
-can be organized into more complex aggregate structures and unions.
-Fixed arrays and dynamically sized vectors can be constructed from both
-the basic types and the aggregate types, and these can all be combined
-into even more complex data structures.
-
-Due to the number of client implementations target languages (C,
-C++, Rust, Dart, and so on), we don't want to burden the developer of
-the service with providing an interface for each and every one.
-
-This is where the FIDL toolchain comes in.
-The developer of the service creates just one `.fidl` definition file,
-which defines the interface.
-Using this file, the FIDL compiler then generates client and server code
-in any of the supported target languages.
-
-In many cases, there will only be one implementation of the server (for example, the
-particular service might be implemented in C++), whereas there could be any number
-of implementations of the client, in a multitude of languages.
-
-# FIDL architecture
-
-From a developer's point of view, the following are the main components:
-
-*   FIDL definition file &mdash; this is a text file (ending in `.fidl` by convention)
-    that defines the values, and interfaces (methods with their parameters),
-*   client code &mdash; generated by the FIDL compiler (`fidlc`) toolchain for each specific
-    target language, and
-*   server code &mdash; also generated by the FIDL compiler toolchain.
-
-We'll look at the client and server code generically in this chapter, and then
-in language specific detail in following chapters.
-
-## FIDL definition
-
-The FIDL definition file defines the interface.
-As a very simple example, consider an "echo" service &mdash; whatever the client sends
-to the server, the server just echoes back to the client.
-
-> Line numbers have been added for clarity and are not part of the `.fidl` file.
-
-```fidl
-1   library fidl.examples.echo;
-2
-3   [Discoverable]
-4   interface Echo {
-5       1: EchoString(string? value) -> (string? response);
-6   };
-```
-
-Let's go through it line by line.
-
-**Line 1:** The `library` keyword is used to define a namespace for this interface.
-FIDL interfaces in different libraries might have the same name, so the namespace
-is used to distinguish amongst them.
-
-**Line 3:** The `[Discoverable]` attribute indicates that the interface that
-follows should be made available for clients to connect to.
-
-**Line 4:** The `interface` keyword introduces the name of the interface, here it's called `Echo`.
-
-**Line 5:** The method, its parameters, and return values.
-There are three unusual aspects of this line:
-
-*   Note the `1:` before the method name.
-    This is the **ordinal number** of the interface.
-    This number can be used to ensure backwards compatibility when there are
-    multiple versions of the same interface.
-    All methods must have a unique ordinal number.
-*   Note the declaration `string?` (for both `value` and `response`).
-    The `string` part indicates that the parameters are strings (sequences of
-    characters), while the question mark indicates that the parameter is optional.
-*   The `->` part indicates the return, which appears after the method declaration, not before.
-    Unlike C++ or Java, a method can return multiple values.
-
-The above FIDL file, then, has declared one interface, called `Echo`, with one
-method, called `EchoString`, that takes a nullable string and returns a nullable string.
-
-## Aggregate data types
-
-The simple example above used just one data type, the `string` as both the input
-to the method as well as the output.
-
-The data types are very flexible:
-
-```fidl
-struct MyRequest {
-    uint32 serial;
-    string key;
-    vector<uint32> options;
-};
-```
-
-The above declares a structure called `MyRequest` with three members: an unsigned
-32-bit integer called `serial`, a string called `key`, and a vector of unsigned 32-bit
-integers called `options`.
-
-## Messaging
-
-In order to understand FIDL's messaging, we need to break things up into two layers,
-and clarify some definitions.
-
-At the bottom (the operating system layer), there's an asynchronous communications
-scheme geared towards independent progress of a **sender** and a **receiver**:
-
-*   **sender** &mdash; the party that originates a message,
-*   **receiver** &mdash; the party that receives a message,
-
-Sending a message is a non-blocking operation: the sender sends the message,
-and is then free to continue processing, regardless of what the receiver is doing.
-
-A receiver can, if it wants to, block in order to wait for a message.
-
-The top layer implements FIDL messages, and uses the bottom (asynchronous) layer.
-It deals with **client**s and **server**s:
-
-*   **client** &mdash; the party that is making a request (of a server),
-*   **server** &mdash; the party that is processing a request (on behalf of a client).
-
-> The terms "sender" and "receiver" make sense when we're discussing the messages
-> themselves &mdash; the underlying communications scheme isn't concerned about
-> the roles that we've assigned to the parties, just that one is sending and one
-> is receiving.
->
-> The terms "client" and "server" make sense when we're discussing the roles that
-> the parties play.
-> In particular, a client can be a sender at one time, and a receiver at a
-> different time; same for the server.
-
-Practically speaking, in the context of a client / server interaction,
-that means that there are several models:
-
-1.  **blocking call** &mdash; client sends to server, waits for