Integrate Openspec specifications and designs into Sphinx documentation.

Sphinx Configuration:
- Add exclude_patterns for Openspec workflow files (AGENTS.md, project.md, changes/**) in conf.py.jinja.

New Documentation Structure:
- Create documentation/specifications/index.rst for capability specifications.
- Update documentation/architecture/designs/index.rst to include design.md files via glob.

Documentation Organization:
- Reference capability specifications instead of PRD in contribution.rst.jinja.
- Add design documents reference in contribution.rst.jinja.
- Update Resources toctree to include specifications/index instead of prd.

Co-Authored-By: Gemini <noreply@google.com>

Author: emcd

template/documentation/architecture/designs/index.rst

@@ -21,8 +21,11 @@
 Designs
 *******************************************************************************
 
+This section contains technical design specifications for capabilities.
+Each design documents Python-specific architecture, interface contracts, module organization, and implementation patterns.
+
 .. toctree::
    :maxdepth: 2
+   :glob:
 
-
-.. todo:: Add design documents to toctree.
+   ../openspec/specs/*/design

template/documentation/conf.py.jinja

@@ -56,7 +56,12 @@ extensions = [
 
 templates_path = [ '_templates' ]
 
-exclude_patterns = [ ]
+exclude_patterns = [
+    # Openspec workflow/meta files (not documentation)
+    'architecture/openspec/AGENTS.md',
+    'architecture/openspec/project.md',
+    'architecture/openspec/changes/**',
+]
 
 rst_prolog = f'''
 .. |project| replace:: {project}

template/documentation/contribution.rst.jinja

@@ -49,12 +49,10 @@ Development
 Architecture
 -------------------------------------------------------------------------------
 
-* The :doc:`Product Requirements Document <prd>` is a good starting point to
-  understand the motivations and rationale for the project. This should be
-  reviewed and updated, as necessary, when making changes that affect product
-  functionality or user experience. See the `requirements documentation guide
-  <https://emcd.github.io/python-project-common/stable/sphinx-html/common/requirements.html>`_
-  for PRD format and best practices.
+* The :doc:`capability specifications <specifications/index>` provide a good
+  starting point to understand the requirements and motivations for the project.
+  These should be reviewed and updated through the Openspec workflow when making
+  changes that affect product functionality or user experience.
 
 * The :doc:`system architecture overview <architecture/summary>` should be
   reviewed to understand the structure and operational patterns of the project.
@@ -66,8 +64,9 @@ Architecture
   <https://emcd.github.io/python-project-common/stable/sphinx-html/common/architecture.html>`_
   for ADR format and best practices.
 
-* Document interface specifications, schemas, and algorithms in the
-  ``architecture/designs/`` directory to guide implementation efforts.
+* Document technical design specifications for Python interfaces, module
+  organization, and implementation patterns in :doc:`design documents
+  <architecture/designs/index>` to guide implementation efforts.
 
 Guidance and Standards
 -------------------------------------------------------------------------------
@@ -129,6 +128,6 @@ Resources
 .. toctree::
    :maxdepth: 2
 
-   prd
+   specifications/index
    architecture/index
    devapi

template/documentation/specifications/index.rst

@@ -0,0 +1,30 @@
+.. vim: set fileencoding=utf-8:
+.. -*- coding: utf-8 -*-
+.. +--------------------------------------------------------------------------+
+   |                                                                          |
+   |  Licensed under the Apache License, Version 2.0 (the "License");         |
+   |  you may not use this file except in compliance with the License.        |
+   |  You may obtain a copy of the License at                                 |
+   |                                                                          |
+   |      http://www.apache.org/licenses/LICENSE-2.0                          |
+   |                                                                          |
+   |  Unless required by applicable law or agreed to in writing, software     |
+   |  distributed under the License is distributed on an "AS IS" BASIS,       |
+   |  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or         |
+   |  implied. See the License for the specific language governing            |
+   |  permissions and limitations under the License.                          |
+   |                                                                          |
+   +--------------------------------------------------------------------------+
+
+*******************************************************************************
+Specifications
+*******************************************************************************
+
+This section contains capability specifications managed through the Openspec workflow.
+Each specification documents requirements using scenario-based format (WHEN/THEN).
+
+.. toctree::
+   :maxdepth: 2
+   :glob:
+
+   ../architecture/openspec/specs/*/spec