@beyondwork/docx-react-component 1.0.0 → 1.0.1

package/docs/reference/word-review-editor-ux-guide.md

@@ -1,253 +0,0 @@
-# WordReviewEditor UX Guide
-
-This document is the canonical implementation guide for the live `WordReviewEditor` workspace shell used by the harness launcher and mounted editor routes.
-
-It remains the current docx workspace guide inside the broader `react-ooxml-office` docs set. Future xlsx or platform-wide UX work should gain sibling docs rather than widening this one by implication.
-
-It does not replace `DESIGN.md`.
-
-- `DESIGN.md` defines the visual and interaction contract.
-- This guide turns that contract into a concrete screen, state, and component-mapping reference that can be implemented and reviewed.
-- Public component documentation stays in `docs/reference/public-api.md`.
-- Harness and demo operations stay in the Wave 11 runbooks.
-
-## Purpose
-
-The prototype design is now the canonical live UX. The goal is no longer to maintain a separate prototype route, but to keep the mounted runtime aligned with the designed workspace while staying honest about what is live today.
-
-It must:
-
-- feel like the future product, not a wireframe
-- keep `/demo` and `/editor/[sessionId]` on the same workspace shell
-- stay honest about non-production posture
-- map directly onto the current `WordReviewEditor` contract and `RuntimeRenderSnapshot` shape
-- cover the Wave 7 through Wave 11 end state in one reviewable surface
-
-## Route And Internal Interfaces
-
-The shared workspace currently lives at:
-
-- `services/react-word-editor/app/demo/page.tsx`
-- `services/react-word-editor/app/editor/[sessionId]/page.tsx`
-- `services/react-word-editor/components/harness-editor-session-client.tsx`
-- `src/ui/WordReviewEditor.tsx`
-- `src/ui-tailwind/tw-review-workspace.tsx`
-- `src/ui/headless/revision-filters.ts` (shared revision filtering helpers)
-- `src/ui/headless/comment-decoration-model.ts` (shared comment decoration model)
-- `src/ui/headless/revision-decoration-model.ts` (shared revision decoration model)
-- `services/react-word-editor/app/api/demo-sessions/route.ts`
-- `services/react-word-editor/lib/demo-fixtures.ts`
-
-Internal-only contracts:
-
-- `DemoSessionDefinition`: catalog entry for a sample session or scenario
-- `PrototypeRenderState` equivalent slices inside the fixture data:
-  - launcher cards and sample-session story
-  - document surface
-  - comments
-  - tracked changes
-  - health and compatibility
-- `GET /api/demo-sessions`: stable internal route for later session brokering
-
-No public `WordReviewEditorProps` or `WordReviewEditorRef` breaking changes are allowed for this workspace migration.
-
-## Screen Anatomy
-
-The shared experience is intentionally split into two layers.
-
-### 1. Demo framing layer
-
-This is a slim utility bar above the editor workspace. It is **not** part of
-the editor component itself. The host harness owns session management, upload
-flows, export/validation controls, and operator-only evidence surfaces.
-
-The host bar contains:
-
-- sample-session launch controls
-- file upload input (local-only, non-production)
-- internal posture label
-- reduced-motion toggle backed by the live host routes
-
-It must stay minimal and secondary to the editor itself. Verbose posture
-paragraphs, task strips, evidence cards, and wave references belong to the
-host app, not the editor component.
-
-### 2. Editor workspace layer
-
-This is the shipped `WordReviewEditor` shell.
-
-It contains:
-
-- compact top toolbar (icon-driven, Radix primitives)
-- single-line alert banner when export is blocked or warning-backed trust state exists
-- centered document surface with curated serif typography
-- floating selection toolbar (inline actions)
-- unified right rail with `Comments`, `Changes`, and `Health` tabs
-- minimal bottom status bar (dot indicators, not verbose key-value pairs)
-
-The `Health` tab renders both compatibility feature entries and runtime
-warnings (including `font_substitution` and other non-fatal trust cues).
-
-The document surface remains the primary visual focus.
-
-## Session Inventory
-
-The prototype must keep these named sessions current.
-
-### Clean Contract Review
-
-- calm baseline
-- supported-roundtrip
-- light comment and insertion signal
-- export-ready posture
-
-### Comment Negotiation
-
-- thread-heavy
-- anchor navigation
-- resolve flow with imported resolved-state visibility
-
-### Redline Negotiation
-
-- tracked changes
-- simple vs full markup
-- accept or reject flow
-- explicit preserve-only boundary note
-
-### Preserve-Only Package
-
-- locked package content
-- warnings without panic
-- export allowed with caution
-
-### Malformed / Blocked
-
-- read-only diagnostics
-- export blocked
-- fail-closed trust posture
-
-### Pilot Scenario · S02
-
-- realistic end-to-end review narrative
-- supported and preserve-only review states together
-- evidence surfaces for later Wave 9 through Wave 11 proof
-
-## Interaction Rules
-
-### Toolbar
-
-- Left cluster carries common edit controls only.
-- Right cluster carries review-surface controls, markup mode, view mode, and export.
-- The toolbar never becomes a ribbon or a dense operator dashboard.
-- `canvas` is the default workspace posture for legal review.
-- The live `/demo` and `/editor/[sessionId]` host routes are intentionally review-only today; they do not expose a separate editing-mode shell toggle.
-
-### Markup display
-
-- `simple` is the default reading posture.
-- `clean` reduces inline review density and hides deleted text.
-- `all` increases revision emphasis without overwhelming the document.
-
-### Comments
-
-- Clicking an anchor range or a thread card activates the same comment.
-- Active comment focus must be visible in both the canvas and the rail.
-- Resolved threads remain visible but quieter than open threads.
-- Detached comment states must read as warning-backed, not broken.
-
-### Changes
-
-- Supported inline revisions remain actionable.
-- Preserve-only revisions remain visible in the rail but never appear normally actionable.
-- Accept and reject are presented as command-backed review actions, not ad hoc visual toggles.
-
-### Health
-
-- `Health` is the primary explanation surface for preserve-only and fatal states.
-- Preserve-only content is explicit, calm, and export-aware.
-- Fatal state blocks export and strips editing affordances.
-
-### Demo framing
-
-- Upload messaging must remain safe and non-production.
-- Session selection must clearly distinguish fixtures from representative scenarios.
-- `/demo` must read as a launcher into the live shell, not as a second editor implementation.
-
-## Wave Alignment
-
-### Wave 7
-
-- preserve-only and fatal states are first-class UX states
-- blocked vs warning-backed export posture is visually distinct
-- preserve-only imported markup is visible and honestly labeled
-
-### Wave 8
-
-- keyboard flow across toolbar, canvas, rail, and framing controls
-- strong focus-visible states
-- reduced-motion preview
-- token-driven styling with no raw drift
-- non-color review cues for comments and revisions
-
-### Wave 9
-
-The editor must support the following reviewer workflows (the host app owns
-task management and evidence surfaces — the editor exposes the capabilities):
-
-- open a document
-- interpret warnings and health states
-- switch markup modes
-- navigate comments and revisions
-- accept or reject a change
-- export
-
-### Wave 10
-
-This route must make DESIGN.md conformance easy to review:
-
-- document remains central
-- review chrome remains secondary
-- markup remains clear without aggression
-- accessibility and performance checkpoints have obvious surfaces to inspect
-
-### Wave 11
-
-The route must already match the live demo story:
-
-- `app/demo/page.tsx` is the home
-- session brokering lives behind `app/api/demo-sessions/route.ts`
-- non-production posture is explicit
-- sample-session behavior stays separate from the public component contract
-- `/editor/[sessionId]` uses the same editor shell after launch
-
-## Mapping To The Final Component
-
-The workspace is implemented through the shipped component shell like this:
-
-- top toolbar -> future `WordReviewEditor` toolbar composition
-- trust banner -> compatibility and warning posture above the canvas
-- document surface -> runtime-owned surface projection
-- floating selection toolbar -> contextual selection tools
-- review rail `Comments` -> comment sidebar projection
-- review rail `Changes` -> revision sidebar projection
-- review rail `Health` -> compatibility and preserve-only surfaces
-- bottom status strip -> minimal runtime status bar
-
-The route-level framing should remain outside the public component:
-
-- session picker
-- safe upload note
-- validation and certification utilities
-- guide and API references
-- demo posture messaging
-
-## Review Checklist
-
-Use this checklist before calling a UX iteration complete.
-
-- The document surface still feels like the main stage.
-- The route is honest about supported, preserve-only, and blocked states.
-- Comments, revisions, and health each feel distinct without fragmenting the right rail.
-- The same layout works for clean, comment-heavy, redline-heavy, preserve-only, and blocked sessions.
-- The live shell still reads like a future product surface rather than a design exercise.
-- The launcher and mounted editor still feel like the same product surface.

package/docs/reference/xlsx/xlsx-ooxml-compliance.md

@@ -1,137 +0,0 @@
-# XLSX OOXML Compliance
-
-## Status
-
-- Planned compliance and validation stance for the future `xlsx` runtime.
-- Not a shipped contract today.
-- Written to match the current repo's support taxonomy and honesty rules.
-
-## Compliance Model
-
-The future spreadsheet editor must treat `.xlsx` as an OPC package first.
-
-That means every trustworthy import or export path must respect:
-
-- ZIP package integrity
-- content types
-- package and part relationships
-- SpreadsheetML structures the runtime explicitly owns
-- unsupported but preservable package content
-
-The final correctness bar is host behavior:
-
-- exported files reopen in recent Excel environments without repair prompts
-- supported workbook content does not silently disappear or rewrite incorrectly
-
-## Support Taxonomy
-
-Every feature should be classified as exactly one of:
-
-- `supported-roundtrip`
-- `preserve-only`
-- `unsupported-fatal`
-
-This intentionally matches the current docx repo stance.
-
-`supported-import-only` and `supported-export-only` are not valid canonical support classes for repo-facing docs. If the editor cannot safely carry a feature through import, runtime edit, export, and Excel reopen, it should remain `preserve-only` or `unsupported-fatal`.
-
-## Response Model
-
-Runtime behavior should stay explicit:
-
-- preserve
-- lock
-- warn
-- block
-- fail
-
-These responses answer "what the editor does right now" while the support taxonomy answers "what the editor claims to own."
-
-## Package-First Rules
-
-Importer and exporter rules:
-
-- preserve unknown package parts and relationships whenever possible
-- regenerate only parts the runtime explicitly owns
-- preserve extension and compatibility markup needed for safe reopen
-- keep preserve-only workbook regions visible and explainable in the UI
-- block edits that would require semantic rewriting of unsupported structures
-
-## v1 Planning Stance
-
-The future xlsx runtime should start conservatively.
-
-### Likely `supported-roundtrip` candidates
-
-- workbook and worksheet structure
-- core cell values and types
-- basic formulas with safe reference remapping
-- shared strings and inline strings
-- conservative styles subset
-- merges with top-left-cell semantics
-- sheet add, rename, reorder, and delete when safe
-- basic view and frozen pane state when proven with Excel reopen notes
-
-### Likely `preserve-only` candidates
-
-- threaded comments
-- pivot tables and pivot caches
-- charts and complex drawings
-- advanced conditional formatting
-- advanced table features
-- external links
-- advanced extension lists and rich value families
-- unknown OOXML inside known parts when preservation is possible
-- unknown package parts and relationships
-
-### Likely `unsupported-fatal` candidates
-
-- malformed OPC graphs the runtime cannot preserve safely
-- encrypted or protected workbook states the runtime cannot safely open or export
-- unknown compatibility constructs that require mandatory understanding
-
-## Format Stance
-
-The planned spreadsheet runtime should remain Transitional-first until strict roundtrip behavior is explicitly proven. Importing stricter variants may be possible, but export claims should stay conservative until the runtime has real reopen evidence.
-
-## Validation Policy
-
-Validation should remain multi-layered:
-
-- runtime structural validation in TypeScript
-- package graph integrity checks
-- internal validator service and Open XML SDK validation in CI or service contexts
-- Excel reopen certification as the final gate
-
-As with docx, the Open XML SDK is a validation input, not the shipped browser transformation engine.
-
-## Release Gates
-
-No xlsx feature should be promoted to `supported-roundtrip` without:
-
-1. package-backed import and export proof
-2. runtime edit proof
-3. re-import proof
-4. validator proof
-5. Excel desktop and web reopen evidence for the supported flow
-
-Helper-level XML or isolated serializer tests are not enough by themselves.
-
-## Relationship To Current Docx Docs
-
-This file does not replace the live docx compliance contract in `docs/reference/ooxml-compliance.md`.
-
-Instead:
-
-- `docs/reference/ooxml-compliance.md` remains the shipped docx contract
-- this file is the planned xlsx sibling
-- both roll up to the shared platform principles in `docs/architecture/platform/shared-openxml-editor-platform.md`
-
-## Source Research Mapping
-
-This canonical doc is derived from:
-
-- `docs/xlsx-react/xlsx-ooxml-compliance.md`
-- `docs/xlsx-react/shared-openxml-editor-platform-docx-xlsx.md`
-
-The research paper remains useful background, but this file is the repo-aligned planned compliance reference.

package/docs/research/agent-context-sources.md

@@ -1,178 +0,0 @@
----
-title: "Agent Context Sources"
-summary: "Primary external sources used as inspiration for planning, harness design, skills and procedural memory, long-running agents, blackboard coordination, repository-context evaluation, and secure code generation."
----
-
-# Agent Context Sources
-
-This repository does not commit converted paper/article caches. Keep any hydrated local copies under `docs/research/agent-context-cache/` or another ignored cache directory.
-
-For a narrative synthesis of the most relevant MAS failure modes and how Wave responds to them, start with [coordination-failure-review.md](./coordination-failure-review.md) and then use this page as the bibliography.
-
-## Practice Articles
-
-- [Harness engineering: leveraging Codex in an agent-first world](https://openai.com/index/harness-engineering/)
-- [Unlocking the Codex harness: how we built the App Server](https://openai.com/index/unlocking-the-codex-harness/)
-- [Effective harnesses for long-running agents](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)
-
-## Planning and Orchestration
-
-- [SYMPHONY: Synergistic Multi-agent Planning with Heterogeneous Language Model Assembly](https://arxiv.org/abs/2601.22623)
-- [Verified Multi-Agent Orchestration: A Plan-Execute-Verify-Replan Framework for Complex Query Resolution](https://arxiv.org/abs/2603.11445)
-- [DOVA: Deliberation-First Multi-Agent Orchestration for Autonomous Research Automation](https://arxiv.org/abs/2603.13327)
-- [TodoEvolve: Learning to Architect Agent Planning Systems](https://arxiv.org/abs/2602.07839)
-- [Parallelized Planning-Acting for Efficient LLM-based Multi-Agent Systems in Minecraft](https://arxiv.org/abs/2503.03505)
-- [OrchMAS: Orchestrated Reasoning with Multi Collaborative Heterogeneous Scientific Expert Structured Agents](https://arxiv.org/abs/2603.03005)
-- [Exploring Advanced LLM Multi-Agent Systems Based on Blackboard Architecture](https://arxiv.org/abs/2507.01701)
-- [LLM-Based Multi-Agent Blackboard System for Information Discovery in Data Science](https://arxiv.org/abs/2510.01285)
-- [Terrarium: Revisiting the Blackboard for Multi-Agent Safety, Privacy, and Security Studies](https://arxiv.org/abs/2510.14312)
-- [MACC: Multi-Agent Collaborative Competition for Scientific Exploration](https://arxiv.org/abs/2603.03780)
-- [Building Effective AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering, and Lessons Learned](https://arxiv.org/abs/2603.05344)
-- [VeRO: An Evaluation Harness for Agents to Optimize Agents](https://arxiv.org/abs/2602.22480)
-- [EvoClaw: Evaluating AI Agents on Continuous Software Evolution](https://arxiv.org/abs/2603.13428)
-- [Towards Engineering Multi-Agent LLMs: A Protocol-Driven Approach](https://arxiv.org/abs/2510.12120)
-- [Advancing Multi-Agent Systems Through Model Context Protocol: Architecture, Implementation, and Applications](https://arxiv.org/abs/2504.21030)
-- [Enhancing Model Context Protocol (MCP) with Context-Aware Server Collaboration](https://arxiv.org/abs/2601.11595)
-- [Why Do Multi-Agent LLM Systems Fail?](https://arxiv.org/abs/2503.13657)
-- [Systematic Failures in Collective Reasoning under Distributed Information in Multi-Agent LLMs](https://arxiv.org/abs/2505.11556)
-- [Silo-Bench: A Scalable Environment for Evaluating Distributed Coordination in Multi-Agent LLM Systems](https://arxiv.org/abs/2603.01045)
-- [DPBench: Large Language Models Struggle with Simultaneous Coordination](https://arxiv.org/abs/2602.13255)
-- [Multi-Agent Teams Hold Experts Back](https://arxiv.org/abs/2602.01011)
-- [A Survey on LLM-based Multi-agent Systems: Workflow, Infrastructure, and Challenges](https://link.springer.com/article/10.1007/s44336-024-00009-2)
-- [LLM-Based Multi-Agent Systems for Software Engineering: Literature Review, Vision and the Road Ahead](https://arxiv.org/abs/2404.04834)
-- [The Orchestration of Multi-Agent Systems: Architectures, Protocols, and Enterprise Adoption](https://arxiv.org/abs/2601.13671)
-- [Describing Agentic AI Systems with C4: Lessons from Industry Projects](https://arxiv.org/abs/2603.15021)
-- [A Taxonomy of Hierarchical Multi-Agent Systems: Design Patterns, Coordination Mechanisms, and Industrial Applications](https://arxiv.org/abs/2508.12683)
-- [Blackboard Systems, Part One: The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures](https://ojs.aaai.org/index.php/aimagazine/article/view/537)
-- [A Blackboard Architecture for Control](https://www.sciencedirect.com/science/article/abs/pii/0004370285900633)
-- [Incremental Planning to Control a Blackboard-Based Problem Solver](https://cdn.aaai.org/AAAI/1986/AAAI86-010.pdf)
-- [Blackboard Systems](https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf)
-
-## Harnesses, Context Engineering, and Long-Running Agents
-
-- [Building Effective AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering, and Lessons Learned](https://arxiv.org/abs/2603.05344)
-- [Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models](https://arxiv.org/abs/2510.04618)
-- [ReSum: Unlocking Long-Horizon Search Intelligence via Context Summarization](https://arxiv.org/abs/2509.13313)
-- [ARC: Active and Reflection-driven Context Management for Long-Horizon Information Seeking Agents](https://arxiv.org/abs/2601.12030)
-- [Meta Context Engineering via Agentic Skill Evolution](https://arxiv.org/abs/2601.21557)
-- [Context Engineering for AI Agents in Open-Source Software](https://arxiv.org/abs/2510.21413)
-- [Context Engineering: From Prompts to Corporate Multi-Agent Architecture](https://arxiv.org/abs/2603.09619)
-- [CEDAR: Context Engineering for Agentic Data Science](https://arxiv.org/abs/2601.06606)
-- [VeRO: An Evaluation Harness for Agents to Optimize Agents](https://arxiv.org/abs/2602.22480)
-- [EvoClaw: Evaluating AI Agents on Continuous Software Evolution](https://arxiv.org/abs/2603.13428)
-- [Memory for Autonomous LLM Agents: Mechanisms, Evaluation, and Emerging Frontiers](https://arxiv.org/abs/2603.07670)
-
-## Skills and Procedural Memory
-
-- [SoK: Agentic Skills -- Beyond Tool Use in LLM Agents](https://arxiv.org/abs/2602.20867)
-- [Agent Skills for Large Language Models: Architecture, Acquisition, Security, and the Path Forward](https://arxiv.org/abs/2602.12430)
-- [Memory for Autonomous LLM Agents: Mechanisms, Evaluation, and Emerging Frontiers](https://arxiv.org/abs/2603.07670)
-- [Meta Context Engineering via Agentic Skill Evolution](https://arxiv.org/abs/2601.21557)
-- [Voyager: An Open-Ended Embodied Agent with Large Language Models](https://arxiv.org/abs/2305.16291)
-- [Toolformer: Language Models Can Teach Themselves to Use Tools](https://arxiv.org/abs/2302.04761)
-- [Large Language Models as Tool Makers](https://arxiv.org/abs/2305.17126)
-- [Synapse: Trajectory-as-Exemplar Prompting with Memory for Computer Control](https://arxiv.org/abs/2306.07863)
-- [ExpeL: LLM Agents Are Experiential Learners](https://arxiv.org/abs/2308.10144)
-- [Agent Workflow Memory](https://arxiv.org/abs/2409.07429)
-- [SkillWeaver: Web Agents can Self-Improve by Discovering and Honing Skills](https://arxiv.org/abs/2504.07079)
-- [ReUseIt: Synthesizing Reusable AI Agent Workflows for Web Automation](https://arxiv.org/abs/2510.14308)
-- [ProcMEM: Learning Reusable Procedural Memory from Experience via Non-Parametric PPO for LLM Agents](https://arxiv.org/abs/2602.01869)
-- [Learning Hierarchical Procedural Memory for LLM Agents through Bayesian Selection and Contrastive Refinement](https://arxiv.org/abs/2512.18950)
-- [Mem^p: Exploring Agent Procedural Memory](https://arxiv.org/abs/2508.06433)
-- [MemSkill: Learning and Evolving Memory Skills for Self-Evolving Agents](https://arxiv.org/abs/2602.02474)
-- [Reinforcement Learning for Self-Improving Agent with Skill Library](https://arxiv.org/abs/2512.17102)
-- [Evolving Programmatic Skill Networks](https://arxiv.org/abs/2601.03509)
-- [XSkill: Continual Learning from Experience and Skills in Multimodal Agents](https://arxiv.org/abs/2603.12056)
-- [Memento-Skills: Let Agents Design Agents](https://arxiv.org/abs/2603.18743)
-- [MetaClaw: Just Talk -- An Agent That Meta-Learns and Evolves in the Wild](https://arxiv.org/abs/2603.17187)
-- [SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks](https://arxiv.org/abs/2602.12670)
-
-## Agent Context Files and Configuration
-
-- [Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?](https://arxiv.org/html/2602.11988v1)
-- [Agent READMEs: An Empirical Study of Context Files for Agentic Coding](https://arxiv.org/abs/2511.12884)
-- [Beyond the Prompt: An Empirical Study of Cursor Rules](https://arxiv.org/abs/2512.18925)
-- [Decoding the Configuration of AI Coding Agents: Insights from Claude Code Projects](https://arxiv.org/abs/2511.09268)
-- [On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents](https://arxiv.org/abs/2601.20404)
-- [Interpretable Context Methodology: Folder Structure as Agentic Architecture](https://arxiv.org/abs/2603.16021)
-
-## Blackboard and Shared Workspaces
-
-- [LLM-Based Multi-Agent Blackboard System for Information Discovery in Data Science](https://arxiv.org/abs/2510.01285)
-- [Exploring Advanced LLM Multi-Agent Systems Based on Blackboard Architecture](https://arxiv.org/abs/2507.01701)
-- [Terrarium: Revisiting the Blackboard for Multi-Agent Safety, Privacy, and Security Studies](https://arxiv.org/abs/2510.14312)
-- [DOVA: Deliberation-First Multi-Agent Orchestration for Autonomous Research Automation](https://arxiv.org/abs/2603.13327)
-- [MACC: Multi-Agent Collaborative Competition for Scientific Exploration](https://arxiv.org/abs/2603.03780)
-- [M3-ACE: Rectifying Visual Perception in Multimodal Math Reasoning via Multi-Agentic Context Engineering](https://arxiv.org/abs/2603.08369)
-- [SYMPHONY: Synergistic Multi-agent Planning with Heterogeneous Language Model Assembly](https://arxiv.org/abs/2601.22623)
-- [Silo-Bench: A Scalable Environment for Evaluating Distributed Coordination in Multi-Agent LLM Systems](https://arxiv.org/abs/2603.01045)
-- [An Open Agent Architecture](https://cdn.aaai.org/Symposia/Spring/1994/SS-94-03/SS94-03-001.pdf)
-- [Blackboard Systems, Part One: The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures](https://ojs.aaai.org/index.php/aimagazine/article/view/537)
-- [A Blackboard Architecture for Control](https://www.sciencedirect.com/science/article/abs/pii/0004370285900633)
-- [Incremental Planning to Control a Blackboard-Based Problem Solver](https://cdn.aaai.org/AAAI/1986/AAAI86-010.pdf)
-- [Blackboard Systems](https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf)
-
-## Multi-Agent Orchestration and Architecture
-
-- [The Orchestration of Multi-Agent Systems: Architectures, Protocols, and Enterprise Adoption](https://arxiv.org/abs/2601.13671)
-- [Agentic Artificial Intelligence (AI): Architectures, Taxonomies, and Evaluation of Large Language Model Agents](https://arxiv.org/abs/2601.12560)
-- [Describing Agentic AI Systems with C4: Lessons from Industry Projects](https://arxiv.org/abs/2603.15021)
-- [A Taxonomy of Hierarchical Multi-Agent Systems: Design Patterns, Coordination Mechanisms, and Industrial Applications](https://arxiv.org/abs/2508.12683)
-
-## Security and Secure Code Generation
-
-- [Prompting Techniques for Secure Code Generation: A Systematic Investigation](https://arxiv.org/abs/2407.07064)
-- [Retrieve, Refine, or Both? Using Task-Specific Guidelines for Secure Python Code Generation](https://emaiannone.github.io/assets/pdf/c6.pdf)
-- [Discrete Prompt Optimization Using Genetic Algorithm for Secure Python Code Generation](https://www.sciencedirect.com/science/article/pii/S0164121225003516)
-- [SCGAgent: Recreating the Benefits of Reasoning Models for Secure Code Generation with Agentic Workflows](https://arxiv.org/abs/2506.07313)
-- [RESCUE: Retrieval Augmented Secure Code Generation](https://arxiv.org/abs/2510.18204)
-- [Improving LLM-Assisted Secure Code Generation through Retrieval-Augmented-Generation and Multi-Tool Feedback](https://arxiv.org/abs/2601.00509)
-- [Autoregressive, Yet Revisable: In Decoding Revision for Secure Code Generation](https://arxiv.org/abs/2602.01187)
-- [Security-by-Design for LLM-Based Code Generation: Leveraging Internal Representations for Concept-Driven Steering Mechanisms](https://arxiv.org/abs/2603.11212)
-- [Persistent Human Feedback, LLMs, and Static Analyzers for Secure Code Generation and Vulnerability Detection](https://arxiv.org/abs/2602.05868)
-
-## Security Benchmarks and Evaluation
-
-- [SecRepoBench: Benchmarking Code Agents for Secure Code Completion in Real-World Repositories](https://arxiv.org/abs/2504.21205)
-- [SecureAgentBench: Benchmarking Secure Code Generation under Realistic Vulnerability Scenarios](https://arxiv.org/abs/2509.22097)
-- [SeCodePLT: A Unified Platform for Evaluating the Security of Code GenAI](https://arxiv.org/abs/2410.11096)
-- [TOSSS: a CVE-based Software Security Benchmark for Large Language Models](https://arxiv.org/abs/2603.10969)
-- [From Vulnerabilities to Remediation: A Systematic Literature Review of LLMs in Code Security](https://arxiv.org/abs/2412.15004)
-- [Quality Assurance of LLM-generated Code: Addressing Non-Functional Quality Characteristics](https://arxiv.org/abs/2511.10271)
-
-## Multi-Agent Security
-
-- [Terrarium: Revisiting the Blackboard for Multi-Agent Safety, Privacy, and Security Studies](https://arxiv.org/abs/2510.14312)
-- [Security Considerations for Multi-agent Systems](https://arxiv.org/abs/2603.09002)
-
-## Skill Practice and Open Standards
-
-- [Agent Skills - Codex](https://developers.openai.com/codex/skills/)
-- [Customization - Codex](https://developers.openai.com/codex/concepts/customization/)
-- [Testing Agent Skills Systematically with Evals](https://developers.openai.com/blog/eval-skills/)
-- [Shell + Skills + Compaction: Tips for long-running agents that do real work](https://developers.openai.com/blog/skills-shell-tips/)
-- [Using skills to accelerate OSS maintenance](https://developers.openai.com/blog/skills-agents-sdk/)
-- [Equipping agents for the real world with Agent Skills](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills)
-- [Best practices for skill creators](https://agentskills.io/skill-creation/best-practices)
-- [Using scripts in skills](https://agentskills.io/skill-creation/using-scripts)
-
-## Adjacent Memory and Prompting Research
-
-- [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
-- [Run long horizon tasks with Codex](https://developers.openai.com/blog/run-long-horizon-tasks-with-codex/)
-- [Prompt guidance for GPT-5](https://developers.openai.com/api/docs/guides/prompt-guidance/)
-- [Codex Prompting Guide](https://developers.openai.com/cookbook/examples/gpt-5/codex_prompting_guide/)
-- [Writing effective tools for agents](https://www.anthropic.com/engineering/writing-tools-for-agents)
-- [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
-- [ReAct: Synergizing Reasoning and Acting in Language Models](https://arxiv.org/abs/2210.03629)
-- [Toolformer: Language Models Can Teach Themselves to Use Tools](https://arxiv.org/abs/2302.04761)
-- [Plan-and-Solve Prompting](https://arxiv.org/abs/2305.04091)
-- [Augmenting Language Models with Long-Term Memory](https://arxiv.org/abs/2306.07174)
-- [MemGPT: Towards LLMs as Operating Systems](https://arxiv.org/abs/2310.08560)
-- [Lost in the Middle: How Language Models Use Long Contexts](https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00638/119630/Lost-in-the-Middle-How-Language-Models-Use-Long)
-
-## Notes
-
-- Use these sources as inspiration and comparison points, not as canonical repo policy.
-- Context7 bundles should be narrow and task-scoped.
-- Cached local exports belong in ignored paths only.