diff --git a/src/gui/ctrl/bus-controller.cpp b/src/gui/ctrl/bus-controller.cpp
index 2398eb131..db569704c 100644
--- a/src/gui/ctrl/bus-controller.cpp
+++ b/src/gui/ctrl/bus-controller.cpp
@@ -24,9 +24,9 @@
 /** @file bus-controller.cpp
  ** Implementation of the UI backbone service for messaging.
  ** Any globally relevant widget or controller within the Lumiera UI
- ** is connected to the [UI-Bus][ui-bus.hpp], which is largely implemented
- ** within this compilation unit. [Clients][gui::model::Tangible] typically
- ** use the [BusTerm-Interface][bus-term.hpp] to route generic actions and
+ ** is connected to the [UI-Bus](ui-bus.hpp), which is largely implemented
+ ** within this compilation unit. [Clients](\ref gui::model::Tangible) typically
+ ** use the [BusTerm-Interface](bus-term.hpp) to route generic actions and
  ** receive notifications, state changes and mutations.
  ** 
  ** @note as of 11/2015 this is complete WIP_WIP
@@ -119,7 +119,7 @@ namespace ctrl {
   
   
   /** capture and record a "state mark" for later replay for restoring UI state.
-   * @param subject the [endpoint-ID][BusTerm::endpointID_] of the emitting element
+   * @param subject the [endpoint-ID](BusTerm::endpointID_) of the emitting element
    * @param mark the actual state update or notification message to be remembered
    * @remarks relevant changes to presentation state, which are to be recalled and
    *          restored later, are emitted from the place they occur, packaged as
@@ -138,11 +138,11 @@ namespace ctrl {
   
   
   /** route a state update or notification to the given subject.
-   * @param subject the [endpoint-ID][BusTerm::endpointID_] of the element to address
+   * @param subject the [endpoint-ID](BusTerm::endpointID_) of the element to address
    * @param mark the actual state update or notification message to be delivered
    * @remarks each "subject" to be addressed is a gui::model::Tangible, and as such
    *          holds a BusTerm of its own, which in turn ensures a registration and
-   *          connection from the [central routing hub][gui::ctrl::Nexus] down to
+   *          connection from the [central routing hub](gui::ctrl::Nexus) down to
    *          the element. Thus, the default implementation is just to pass the
    *          given state mark "up", assuming that it will reach the hub
    *          eventually, which in turn knows hot to reach the element.
diff --git a/src/gui/ctrl/bus-controller.hpp b/src/gui/ctrl/bus-controller.hpp
index b3754a6ea..9a9d79d4b 100644
--- a/src/gui/ctrl/bus-controller.hpp
+++ b/src/gui/ctrl/bus-controller.hpp
@@ -22,10 +22,10 @@
 
 
 /** @file bus-controller.hpp
- ** The service actually operating the [UI-Bus][ui-bus.hpp].
+ ** The service actually operating the [UI-Bus](ui-bus.hpp).
  ** This service includes state management for the bus operations
- ** as a whole, it includes the setup of a [routing table][ctrl::Nexus]
- ** and it includes the management of connection to the [core service][core-service.hpp]
+ ** as a whole, it includes the setup of a [routing table](\ref ctrl::Nexus)
+ ** and it includes the management of connection to the [core service](core-service.hpp)
  ** Service for bus-controller.
  ** This header defines the basics of...
  ** 
@@ -37,8 +37,8 @@
  ** @todo WIP  ///////////////////////TICKET #959
  ** 
  ** @see ////TODO_test usage example
- ** @see [implementation][bus-controller.cpp]
- ** @see [front-end and lifecycle][UiBus]
+ ** @see [implementation](bus-controller.cpp)
+ ** @see [front-end and lifecycle](UiBus)
  ** 
  */
 
diff --git a/src/gui/ctrl/bus-term.hpp b/src/gui/ctrl/bus-term.hpp
index 639dc1ac8..821deb306 100644
--- a/src/gui/ctrl/bus-term.hpp
+++ b/src/gui/ctrl/bus-term.hpp
@@ -32,9 +32,9 @@
  ** \par Lifecycle and identity
  ** An BusTerm is always created starting from another BusTerm, to
  ** which it will be wired. Moreover, each BusTerm bears a distinct
- ** [identity][::endpointID_], which is used as _implicit subject_
+ ** [identity](\ref ::endpointID_), which is used as _implicit subject_
  ** for emanating messages, or as explicit destination for routing.
- ** The whole [UI-Bus][BusController] is built to perform within the
+ ** The whole [UI-Bus](\ref BusController) is built to perform within the
  ** UI event thread and thus is _not threadsafe_. For that reason,
  ** the automatic detachment built into each BusTerm's dtor is
  ** sufficient to ensure sane connectivity.
@@ -77,7 +77,7 @@ namespace ctrl{
   /**
    * connection point at the UI-Bus.
    * The UI-Bus is a star shaped network of terminal points,
-   * where each \link Tangible tangible UI element \endlink
+   * where each \ref model::Tangible "tangible UI element"
    * holds a BusTerm serving access point. The BusTerm interface
    * exposes the basic "verbs" available for communication within
    * the UI
diff --git a/src/gui/ctrl/nexus.hpp b/src/gui/ctrl/nexus.hpp
index 2890b63dc..c0e1108f2 100644
--- a/src/gui/ctrl/nexus.hpp
+++ b/src/gui/ctrl/nexus.hpp
@@ -23,8 +23,8 @@
 
 /** @file nexus.hpp
  ** Core hub and routing table of the UI-Bus.
- ** Any relevant element within the Lumiera GTK UI is connected to the [UI-Bus][ui-bus.hpp]
- ** through some [bus terminal][bus-term.hpp]. Actually, there is one special BustTerm
+ ** Any relevant element within the Lumiera GTK UI is connected to the [UI-Bus](ui-bus.hpp)
+ ** through some [bus terminal](bus-term.hpp). Actually, there is one special BustTerm
  ** implementation, which acts as router and messaging hub.
  ** 
  ** @todo initial draft and WIP-WIP-WIP as of 11/2015
@@ -100,7 +100,7 @@ namespace ctrl{
         }
       
       /** add a new down-link connection to the routing table
-       * @param identity the [endpoint-ID][BusTerm::endpointID_] used
+       * @param identity the [endpoint-ID](\ref BusTerm::endpointID_) used
        *         to address the new element to be connected to the bus.
        * @return backlink for the new Tangible's BusTerm to
        *         attach itself to the Nexus.
diff --git a/src/gui/model/tangible.cpp b/src/gui/model/tangible.cpp
index a710bfff9..9e792cc30 100644
--- a/src/gui/model/tangible.cpp
+++ b/src/gui/model/tangible.cpp
@@ -25,7 +25,7 @@
  ** Common base implementation of all tangible and connected interface elements.
  ** 
  ** @see abstract-tangible-test.cpp
- ** @see [explanation of the fundamental interactions][tangible.hpp]
+ ** @see [explanation of the fundamental interactions](tangible.hpp)
  ** 
  */
 
@@ -60,7 +60,7 @@ namespace model {
   /**
    * Prepare a command or action for actual invocation, once the execution context
    * has been established. The action is not executed right away, but it is now ready
-   * and bound to the concrete arguments supplied with the [record][lib::diff::Rec].
+   * and bound to the concrete arguments supplied with the [record](\ref lib::diff::Rec).
    * @param prototype handle to a command instantiation, to be readied for invocation
    * @param arguments suitable tuple of values, to be used to outfit the prototype
    */
diff --git a/src/gui/model/tangible.hpp b/src/gui/model/tangible.hpp
index cf3f59acb..c629e4601 100644
--- a/src/gui/model/tangible.hpp
+++ b/src/gui/model/tangible.hpp
@@ -24,7 +24,7 @@
 /** @file tangible.hpp
  ** Abstraction: a tangible element of the User Interface.
  ** This is a generic foundation for any elements of more than local relevance
- ** within the Lumiera UI. Any such element is connected to the [UI-Bus][ui-bus.hpp].
+ ** within the Lumiera UI.<br/> Any such element is connected to the [UI-Bus](ui-bus.hpp).
  ** 
  ** \par rationale
  ** Simple user interfaces can be built by wiring up the actions right within the
@@ -34,9 +34,7 @@
  ** in turn. This approach works, but is repetitive and thus lures the lazy programmer
  ** into taking shortcuts. Since we can foresee the Lumiera UI to become quite challenging
  ** in itself, we prefer to introduce a **mediating backbone**, impersonating the role
- ** of the _Model_ and the _Controler_ in the
- ** [MVC-Pattern][http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller]
- ** in common UI architecture.
+ ** of the _Model_ and the _Controler_ in the [MVC-Pattern] in common UI architecture.
  ** 
  ** The MVC-Pattern as such is fine, and probably the best we know for construction of
  ** user interfaces. But it doesn't scale well towards the integration into a larger and
@@ -50,14 +48,15 @@
  ** generic concerns of interaction control and command binding. The immediately tangible
  ** "mechanics" of the UI shall be implemented in a conventional way, right within the
  ** concrete widget (or controller) code. But, since any widget concerned with more than
- ** local behaviour will inherit from [Tangible], the embedded [UI-Bus terminal][Tangible::uiBus_]
+ ** local behaviour will inherit from \ref Tangible, the embedded [UI-Bus terminal](\ref ctrl::BusTerm)
+ ** `Tangible::uiBus_`
  ** can be used for interaction with core services.
  ** 
  ** \par the generic interface element API
- ** The _generic interface element_ based on [Tangible] covers a set of behaviour common to
- ** all elements of the interface. This behaviour is targeted towards the _integration_ with the
- ** core application. Beyond that, there are still several concerns regarding presentation, like
- ** a common styling. These are addressed the conventional way, through a common [WindowManager].
+ ** The _generic interface element_ based on [Tangible](\ref model::Tangible) covers a set of behaviour
+ ** common to  all elements of the interface. This behaviour is targeted towards the _integration_
+ ** with the core application. Beyond that, there are still several concerns regarding presentation,
+ ** like a common styling. These are addressed the conventional way, through a common \ref WindowManager.
  ** The following discussion focuses on the aspects of integration with the core.
  ** 
  ** For one reason ore another, any element in the UI can appear and go away.
@@ -80,7 +79,7 @@
  ** expanding and collapsing, moving by focus or manipulation of a similar presentation control.
  ** These manipulations in itself do not constitute an action. But there typically is some widget
  ** or controller, which is responsible for the touched presentation state. If this entity judges
- ** the state change to be relevant and persistent, it may [send][BusTerm::note()] a **state mark**
+ ** the state change to be relevant and persistent, it may [send](\ref BusTerm::note()) a **state mark**
  ** into the UI-Bus -- expecting this marked state to be remembered.
  ** In turn this means the bus terminal might feed a state mark back into the tangible element,
  ** expecting this state to be restored.
@@ -94,14 +93,14 @@
  ** 
  ** And finally, there are the _essential updates_ -- any changes in the model _for real._
  ** These are sent as notifications just to some relevant top level element, expecting this element
- ** to request a [diff][tree-diff.hpp] and to mutate contents into shape recursively.
+ ** to request a [diff](tree-diff.hpp) and to mutate contents into shape recursively.
  ** 
  ** \par Interactions
- ** - **lifecycle**: connect to an existing term, supply the [EntryID][Tangible::ID] of the new element.
+ ** - **lifecycle**: connect to an existing term, supply the [EntryID](\ref Tangible::ID) of the new element.
  **   This interaction also implies, that the element automatically detaches itself at end of life.
- ** - **act**: send a [GenNode] representing the action
+ ** - **act**: send a \ref GenNode representing the action
  ** - **note**: _send_ a GenNode representing the _state mark_
- ** - **mark**: _receive_ a [GenNode] representing the _feedback_ or a replayed _state mark_
+ ** - **mark**: _receive_ a GenNode representing the _feedback_ or a replayed _state mark_
  ** - **diff**: ask to retrieve a diff, which
  **   - either is an incremental status update
  **   - or is a from-scratch reconfiguration
@@ -112,11 +111,13 @@
  ** - slotReveal() prompts the element to bring the indicated child into sight.
  **   Typically, this request will "bubble up" recursively.
  ** These slots are defined to be `sigc::trackable` for automated disconnection
- ** see [Ticket #940][http://issues.lumiera.org/ticket/940#comment:3] for an explanation.
+ ** see [sigc-track] for an explanation.
  ** 
+ ** [MVC-Pattern]: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
+ ** [sigc-track]: http://issues.lumiera.org/ticket/940#comment:3 "Ticket #940"
  ** 
- ** @see [AbstractTangible_test]
- ** @see [BusTerm_test]
+ ** @see \ref AbstractTangible_test
+ ** @see \ref BusTerm_test
  ** 
  */
 
@@ -145,9 +146,9 @@ namespace model {
    * Interface common to all UI elements of relevance for the Lumiera application.
    * Any non-local and tangible interface interaction will at some point pass through
    * this foundation element, which forms the joint and attachment to the UI backbone,
-   * which is the [UI-Bus][ui-bus.hpp]. Any tangible element acquires a distinct identity
+   * which is the [UI-Bus](ui-bus.hpp). Any tangible element acquires a distinct identity
    * and has to be formed starting from an already existing bus nexus.
-   * @see [explanation of the basic interactions][tangible.hpp]
+   * @see [explanation of the basic interactions](tangible.hpp)
    */
   class Tangible
     : public sigc::trackable
diff --git a/src/gui/ui-bus.hpp b/src/gui/ui-bus.hpp
index 1d0bed798..89e38edf7 100644
--- a/src/gui/ui-bus.hpp
+++ b/src/gui/ui-bus.hpp
@@ -27,7 +27,7 @@
  ** This is a messaging system and taps into any widget of more than local relevance.
  ** To that end, any globally relevant (custom) widget, and all secondary controllers
  ** inherit from the gui::model::Tangible base. The top-level gui::UiBus element is
- ** a front-end and framework component managed by the [GTK-main][GtkLumiera::main].
+ ** a front-end and framework component managed by the [GTK-main](\ref GtkLumiera::main).
  ** 
  ** @warning as of 12/2015, this is still totally a mess. This \em will remain
  **          the one-and-only master controller of the UI, but I am determined
@@ -38,9 +38,7 @@
  ** 
  ** \par rationale
  ** The UI-Bus acts as a **mediating backbone**, impersonating the role
- ** of the _Model_ and the _Controler_ in the
- ** [MVC-Pattern][http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller]
- ** in common UI architecture.
+ ** of the _Model_ and the _Controler_ in the [MVC-Pattern]in common UI architecture.
  ** 
  ** The MVC-Pattern as such is fine, and probably the best we know for construction of
  ** user interfaces. But it doesn't scale well towards the integration into a larger and
@@ -59,19 +57,19 @@
  ** these core services will receive the messages, act on them and _respond asynchronously_.
  ** 
  ** \par Bus interactions
- ** The UI-Bus has a star shaped topology, with a central "bus master" hub, the ["Nexus"][Nexus],
+ ** The UI-Bus has a star shaped topology, with a central "bus master" hub, the ["Nexus"](\ref Nexus),
  ** which maintains a routing table. Attachment and detachment of elements can be managed automatically,
  ** since all of the UI-Bus operations _perform within the UI event thread._
  ** 
  ** We distinguish between _up-link messages,_ directed towards some central service
  ** (presentation state management or command invocation) and _down-link messages,_
  ** directed towards individual elements. The interactions at the bus are closely interrelated
- ** with the [elementary UI-Element operations][tangible.hpp].
+ ** with the [elementary UI-Element operations](tangible.hpp).
  ** 
  ** - **act**: send a [GenNode] representing the action
- **   - in a first step, a command prototype is [outfitted][InvocationTrail::bind()] with actual
+ **   - in a first step, a command prototype is [outfitted](\ref InvocationTrail::bind()) with actual
  **     parameter values. -> see [InvocationTrail]
- **   - the actual command invocation is triggered by a ["bang" message][InvocationTrail::bang()]
+ **   - the actual command invocation is triggered by a ["bang" message](\ref InvocationTrail::bang())
  ** - **note**: send a [GenNode] representing the _state mark;_
  **   some (abstracted) presentation state manager is expected to listen to these messages,
  **   possibly recording state to be restored later. The contents of the _state mark_ message
@@ -88,6 +86,8 @@
  ** @see ctrl/nexus.hpp
  ** @see ctrl/core-service.hpp
  ** 
+ ** [MVC-Pattern]: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
+ ** 
  ** @todo as of 1/2015, this header needs to be reshaped ////////////////////TICKET #959
  ** 
  */
diff --git a/src/lib/iter-cursor.hpp b/src/lib/iter-cursor.hpp
index 1e4ffa2b8..5abcb5d2f 100644
--- a/src/lib/iter-cursor.hpp
+++ b/src/lib/iter-cursor.hpp
@@ -26,12 +26,12 @@
  ** This wrapper relies on the ability of typical STL container iterators
  ** to work in both directions, similar to std::reverse_iterator.
  ** Yet it is a single, self-contained element and in compliance to the
- ** ["Lumiera Forward Iterator"][iter-adapter.hpp] concept. But it has
- ** the additional ability to [switch the working direction][IterCursor::switchDir].
+ ** ["Lumiera Forward Iterator"](iter-adapter.hpp) concept. But it has
+ ** the additional ability to [switch the working direction](\ref IterCursor::switchDir).
  ** 
  ** @see IterCursor_test
  ** @see iter-adapter.hpp
- ** @see [usage example][event-log.hpp]
+ ** @see [usage example](event-log.hpp)
  ** 
  */
 
@@ -156,7 +156,7 @@ namespace lib {
    * It can be built on top of any bidirectional STL iterator or similar entity,
    * which has an `--` operator. Initially, IterCursor will operate in forward
    * direction; irrespective of the current direction, it always fulfils the
-   * ["Lumiera Forward Iterator"][iter-adapter.hpp] concept, i.e. it can be
+   * ["Lumiera Forward Iterator"](iter-adapter.hpp) concept, i.e. it can be
    * iterated until exhaustion, in which case it will evaluate to bool(false).
    * @note IterCursor instances can be equality compared, also taking the
    *       current direction into account. As a special case, all
diff --git a/src/lib/test/event-log.hpp b/src/lib/test/event-log.hpp
index 17e07c88b..a58e6b0e9 100644
--- a/src/lib/test/event-log.hpp
+++ b/src/lib/test/event-log.hpp
@@ -34,7 +34,7 @@
  ** to deliver a precise indication what part of the condition failed.
  ** 
  ** @see TestEventLog_test
- ** @see [usage example][AbstractTangible_test]
+ ** @see [usage example](\ref AbstractTangible_test)
  ** 
  */
 
@@ -357,7 +357,7 @@ namespace test{
       /** find a match for an "event" _after_ the current point of reference
        * @remarks the term "event" designates several types of entries, which
        *          typically capture something happening within the observed entity.
-       *          Especially, the following [record types][lib::Record::getType()]
+       *          Especially, the following [record types](\ref lib::Record::getType())
        *          qualify as event:
        *          - `event`
        *          - `error`
@@ -552,7 +552,7 @@ namespace test{
   /****************************************************************//**
    * Helper to log and verify the occurrence of events.
    * The EventLog object is a front-end handle, logging flexible
-   * [information records][lib::Record] into a possibly shared (vector)
+   * [information records](\ref lib::Record) into a possibly shared (vector)
    * buffer in heap storage. An extended query DSL allows to write
    * assertions to cover the occurrence of events in unit tests.
    * @see TestEventLog_test
@@ -744,7 +744,7 @@ namespace test{
 
       
       /** Log the creation of an object.
-       *  Such an entry can be [matched as event][::verifyEvent] */
+       *  Such an entry can be [matched as event](\ref ::verifyEvent) */
       EventLog&
       create (string text)
         {
@@ -790,7 +790,7 @@ namespace test{
       /** start a query to match for some substring.
        *  The resulting matcher object will qualify on any log entry
        *  containing the given string. By adding subsequent further
-       *  query expressions on the returned [matcher object][EventMatch],
+       *  query expressions on the returned [matcher object](\ref EventMatch),
        *  the query can be refined. Refining a query might induce backtracking.
        *  The final result can be retrieved by `bool` conversion
        */
@@ -819,7 +819,7 @@ namespace test{
       /** start a query to match for some event.
        * @remarks only a subset of all log entries is treated as "event",
        *          any other log entry will not be considered for this query.
-       *          Besides the regular [events][::event()], also errors,
+       *          Besides the regular [events](\ref ::event()), also errors,
        *          creation and destruction of objects count as "event".
        * @param match text to (substring)match against the argument logged as event
        */
diff --git a/src/lib/test/test-helper.hpp b/src/lib/test/test-helper.hpp
index 8fc012c5d..babe35c1e 100644
--- a/src/lib/test/test-helper.hpp
+++ b/src/lib/test/test-helper.hpp
@@ -27,7 +27,7 @@
  ** for types. Some of these support meta programming to figure out the \em actual
  ** reference kind (value, lvalue, rvalue) of a template parameter instantiation.
  ** For GNU compatible compilers, we define here also an interface to the internal
- ** ABI for [demangling type names][demangleCxx].
+ ** ABI for [demangling type names](\ref demangleCxx).
  ** 
  ** @note this header is included into a large number of tests.
  ** @see TestHelper_test
diff --git a/tests/gui/abstract-tangible-test.cpp b/tests/gui/abstract-tangible-test.cpp
index c71aece07..c9e106608 100644
--- a/tests/gui/abstract-tangible-test.cpp
+++ b/tests/gui/abstract-tangible-test.cpp
@@ -24,8 +24,8 @@
 /** @file abstract-tangible-test.cpp
  ** Verify the common base shared by all interface elements of relevance.
  ** This test is not so much a test, than a test of the test support for testing
- ** [primary elements][gui::model::Tangible] of the Lumiera GTK UI. Any such element
- ** is connected to the [UI-Bus][gui::UiBus] and responds to some generic actions and
+ ** [primary elements](\ref gui::model::Tangible) of the Lumiera GTK UI. Any such element
+ ** is connected to the [UI-Bus](\ref gui::UiBus) and responds to some generic actions and
  ** interaction patterns. This is the foundation of any presentation state recording
  ** and restoration, and it serves to invoke any persistent action on the
  ** [Session] through a single channel and access point.
@@ -114,17 +114,17 @@ namespace test {
        * a [MockElm] with a suitable name / ID, we're able to operate this element
        * programmatically and to send messages and responses from the core "up"
        * to this mocked interface. And since this mock element embodies an
-       * [event log][EventLog], the unit test code can verify the occurrence
+       * [event log](\ref EventLog), the unit test code can verify the occurrence
        * of expected events, invocations and responses.
        * 
        * \par connectivity
-       * Any mock element will automatically connect against the [Test-Nexus][test/test-nexus.hpp],
+       * Any mock element will automatically connect against the [Test-Nexus](test/test-nexus.hpp),
        * so to be suitably rigged for unit testing. This means, there is no _live connection_
        * to the session, but any command- or other messages will be captured and can be
        * retrieved or verified from the test code. Since lifecycle and robustness in
        * "post mortem" situations tend to be tricky for UI code, we provide a dedicated
-       * ["zombification"][gui::test::TestNexus::zombificate()] feature: a [MockElm] can be turned
-       * into an _almost dead_ state, while still hanging around. It will be detached from the
+       * ["zombification"](\ref gui::test::TestNexus::zombificate()) feature: a \ref MockElm can be
+       * turned into an _almost dead_ state, while still hanging around. It will be detached from the
        * "living" Test-Nexus and re-wired to some special, hidden "Zombie Nexus", causing any
        * further messaging activity to be logged and ignored.
        */
diff --git a/tests/gui/test/mock-elm.hpp b/tests/gui/test/mock-elm.hpp
index a84b3e6cd..32d814349 100644
--- a/tests/gui/test/mock-elm.hpp
+++ b/tests/gui/test/mock-elm.hpp
@@ -48,7 +48,7 @@
  ** built with a distinct core, the UI should not contain anything not tangible enough
  ** as just to be verified by watching it in action. The push of a button should just
  ** invoke an action, and the action itself should be self contained enough to be
- ** tested in isolation. The UI-Bus and the [generic widget base][gui::model::Tangible]
+ ** tested in isolation. The UI-Bus and the [generic widget base](\ref gui::model::Tangible)
  ** was built to serve as a foundation to achieve that goal.
  ** 
  ** @see abstract-tangible-test.cpp
@@ -92,9 +92,9 @@ namespace test{
    * Mock UI element or controller.
    * Within Lumiera, all interface components of relevance are based
    * on the [Tangible] interface, which we mock here for unit testing.
-   * This special implementation is instrumented to [log][lib::test::EventLog]
+   * This special implementation is instrumented to [log](\ref lib::test::EventLog)
    * any invocation and any messages sent or received through the UI Backbone,
-   * which is formed by the [UI-Bus][ui-bus.hpp].
+   * which is formed by the [UI-Bus](ui-bus.hpp).
    * 
    * @todo some usage details
    * @see abstract-tangible-test.cpp
diff --git a/tests/gui/test/test-nexus.cpp b/tests/gui/test/test-nexus.cpp
index ba4d12a47..f60d7feb9 100644
--- a/tests/gui/test/test-nexus.cpp
+++ b/tests/gui/test/test-nexus.cpp
@@ -25,8 +25,8 @@
  ** Implementation of a fake UI backbone for testing.
  ** This compilation unit provides the actual setup for running a faked
  ** user interface from unit tests. Test code is assumed to access those
- ** features through the [front-end][gui::test::TestNexus], while the
- ** actual implementation instances are placed [as singletons][depend.hpp]
+ ** features through the [front-end](\ref gui::test::TestNexus), while the
+ ** actual implementation instances are placed [as singletons](depend.hpp)
  ** 
  ** @todo initial draft and WIP-WIP-WIP as of 11/2015
  ** 
@@ -69,7 +69,7 @@ namespace test{
      * @internal fake interface backbone and unit test rig
      * for simulated command and presentation state handling.
      * This implementation embodies the routing functionality
-     * as found in the [real nexus][gui::ctrl::Nexus], and additionally
+     * as found in the [real nexus](\ref gui::ctrl::Nexus), and additionally
      * also implements the handler functions of the [gui::ctrl::CoreService].
      * The latter allows us to intercept command invocations and presentation
      * state messages
diff --git a/tests/gui/test/test-nexus.hpp b/tests/gui/test/test-nexus.hpp
index 558c118a6..da84128c6 100644
--- a/tests/gui/test/test-nexus.hpp
+++ b/tests/gui/test/test-nexus.hpp
@@ -23,9 +23,9 @@
 
 /** @file test/test-nexus.hpp
  ** A fake UI backbone for investigations and unit testing.
- ** Any relevant element within the Lumiera GTK UI is connected to the [UI-Bus][ui-bus.hpp]
+ ** Any relevant element within the Lumiera GTK UI is connected to the [UI-Bus](ui-bus.hpp)
  ** So for testing and investigation we need a white room setup to provide an instrumented
- ** backbone to run any test probes against. The test::Nexus allows to [hook up][testUI()]
+ ** backbone to run any test probes against. The test::Nexus allows to [hook up](\ref testUI())
  ** a generic interface element, to participate in a simulated interface interaction.
  ** 
  ** This class test::Nexus acts as front-end for unit tests, while the actual implementation
@@ -59,8 +59,8 @@ namespace test{
   
   /**
    * Mock UI backbone for unit testing.
-   * In the absence of a real UI, this simulated [UI-Bus][ui-bus.hpp]
-   * can be used to wire a [test probe][MockElm] and address it in unit testing.
+   * In the absence of a real UI, this simulated [UI-Bus](ui-bus.hpp)
+   * can be used to wire a [test probe](\ref MockElm) and address it in unit testing.
    * 
    * @note behind the scenes, this is a singleton. Use the provided
    *       attachment point testUI() in order to wire and hook up new
diff --git a/tests/library/iter-cursor-test.cpp b/tests/library/iter-cursor-test.cpp
index f4ea5eee4..28f3e5b85 100644
--- a/tests/library/iter-cursor-test.cpp
+++ b/tests/library/iter-cursor-test.cpp
@@ -74,7 +74,7 @@ namespace test{
    *
    * @see iter-cursor.hpp
    * @see iter-adapter.hpp
-   * @see [usage example][event-log.hpp]
+   * @see [usage example](event-log.hpp)
    */
   class IterCursor_test : public Test
     {
diff --git a/tests/library/iter-explorer-test.cpp b/tests/library/iter-explorer-test.cpp
index 66733c260..fecaae6c9 100644
--- a/tests/library/iter-explorer-test.cpp
+++ b/tests/library/iter-explorer-test.cpp
@@ -192,12 +192,12 @@ namespace test{
    * @test use a simple source iterator yielding numbers
    *       to build various functional evaluation structures,
    *       based on the IterExplorer template.
-   *       - the [state adapter][verifyStateAdapter] iterator
+   *       - the [state adapter](\ref verifyStateAdapter) iterator
    *         construction pattern
-   *       - helper to [chain iterators][verifyChainedIterators]
-   *       - building [tree exploring structures][verifyDepthFirstExploration]
-   *       - the [monadic nature][verifyMonadOperator] of IterExplorer
-   *       - a [recursively self-integrating][verifyRecrusiveSelfIntegration]
+   *       - helper to [chain iterators](\ref verifyChainedIterators)
+   *       - building [tree exploring structures](\ref verifyDepthFirstExploration)
+   *       - the [monadic nature](\ref verifyMonadOperator) of IterExplorer
+   *       - a [recursively self-integrating](\ref verifyRecrusiveSelfIntegration)
    *         evaluation pattern
    * 
    * \par Explanation