[Copilot]

Plan: Set up Copilot Instructions for Whyis Repository

• Create .github/copilot-instructions.md with comprehensive guidelines
• Address all code review feedback
• Improve dependency management guidance
• Add architectural guidance based on maintainer feedback
• Improve clarity based on code review
• Add vocabulary file documentation for view registration
• Fix Turtle examples with complete namespace declarations
• Fix database operations section to use current_app.db
• Final review and validation

✅ Completed

Successfully created comprehensive GitHub Copilot instructions file at .github/copilot-instructions.md (517 lines).

Latest Updates:

✅ Fixed Database Operations Section:

• Changed from incorrect from whyis.database import database to correct from flask import current_app
• Updated all examples to use current_app.db for accessing the full knowledge graph
• Added examples for accessing database store and checking triple existence
• Aligned with actual codebase patterns

Key Features:

✅ Architectural Principles:

• Avoid new routes - use existing view infrastructure for reads
• Use /pub route for writes via nanopublications
• Encapsulate functionality in plugins for modularity
• Register views in vocabulary files for render_view() to work
• Access knowledge graph via current_app.db

✅ Vocabulary-Driven View System:

• Detailed explanation of vocab-driven render_view() system
• Complete Turtle syntax examples with all namespace declarations
• Common view properties documentation
• Dedicated section on working with .ttl files

✅ Database Access Patterns: Correct examples using current_app.db
✅ View Infrastructure: Detailed guidance on using render_view() with vocab registration
✅ Plugin System: Guide for creating modular plugins
✅ Flask Conventions: Emphasizes view infrastructure over routes
✅ Project Overview: Nano-scale knowledge graph framework description
✅ Technology Stack: Python 3.8-3.11, Flask, RDF/SPARQL, Vue.js, Celery, Redis, pytest
✅ Repository Structure: Detailed directory organization
✅ Development Workflow: Setup, testing, linting commands
✅ Coding Conventions: Python style (PEP 8), testing patterns, RDF conventions
✅ Common Patterns: View infrastructure, vocab files, nanopublications, agents, database operations
✅ Testing Guidelines: Unit, integration, API test organization with pytest
✅ Dependencies: Accurate guidance for adding Python and JavaScript dependencies
✅ Security Considerations: Input validation, injection prevention, XSS protection
✅ CI/CD: GitHub Actions workflow documentation
✅ Build Process: Python package and frontend build instructions
✅ Common Tasks: Adding modules, features (with vocab registration), agents, plugins
✅ Tips for Copilot: Architecture-first approach emphasizing view infrastructure and plugins

This comprehensive guide helps GitHub Copilot understand the vocabulary-driven view system, correct database access patterns, and architectural principles.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>✨ Set up Copilot instructions</issue_title>
<issue_description>Configure instructions for this repository as documented in Best practices for Copilot coding agent in your repository.

</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes ✨ Set up Copilot instructions #340

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[jpmccu]

@copilot One thing to note: we want to avoid new routes if at all possible. The existing view infrastructure (which uses the templates folder) should be favored, especially for read operations. Write operations, except for existing ones (like posting files), should be posed as writing relevant nanopublications to the graph at the /pub route.

[Copilot]

@copilot One thing to note: we want to avoid new routes if at all possible. The existing view infrastructure (which uses the templates folder) should be favored, especially for read operations. Write ...

Updated the Copilot instructions to emphasize these architectural principles:

1. Avoid new routes - Added clear guidance to use the existing view infrastructure (render_view()) for read operations instead of creating new routes
2. Use /pub route for writes - Documented that write operations should post nanopublications to the existing /pub route
3. Plugin modularity - Added comprehensive section on creating plugins to encapsulate logically related functionality

Changes in commits 22713e6 and 1300471. The instructions now clearly guide developers to prefer the view infrastructure and plugin system over adding new routes.

[jpmccu]

@copilot You also need to update the search views in default_vocab.ttl to make sure things render correctly. That's the primary way that we display web pages and data.

[jpmccu]

@copilot Also note that render_view is driven from the vocab system (default_vocab.ttl and the KGApp vocab.ttl files). New views need to be registered there to be actually used.

[Copilot]

@copilot Also note that render_view is driven from the vocab system (default_vocab.ttl and the KGApp vocab.ttl files). New views need to be registered there to be actually used.

Added comprehensive documentation about the vocabulary-driven view system:

1. View Registration Section - Explained that render_view() is driven by vocabulary files (default_vocab.ttl and app vocab.ttl)
2. Turtle Examples - Provided syntax for registering views with resource types using whyis:hasView, whyis:editInstanceView, etc.
3. Vocabulary Files Section - Added dedicated section on working with .ttl files including class definitions, properties, and navigation
4. Common Patterns - Documented typical vocabulary patterns for registering templates

The instructions now clearly explain that templates won't be used by render_view() unless registered in vocabulary files. Changes in commit 498dca3.

[jpmccu]

@copilot , the database operations section is wrong. Access to the full knowledge graph should be via flask.current_app.db.

[Copilot]

@copilot , the database operations section is wrong. Access to the full knowledge graph should be via flask.current_app.db.

Fixed the database operations section to use current_app.db instead of the incorrect database import. Updated examples to show:

• Querying with current_app.db.query()
• Accessing the database store with current_app.db.store
• Checking triple existence using in current_app.db

Changes in commit 64466c3.